「eq」の検索結果

GitHubのIssueを条件で絞り込み、修正・テスト・PR作成をバックグラウンドのエージェントに任せます。重複作業の回避やレビュー指摘への対応も扱います。

• ラベルや担当者で課題を選びたいとき
• 複数の課題の修正PRを作りたいとき
• 作成したPRのレビュー対応

Gemini CLIで質問への回答や文章生成、ファイル内容の要約を単発で実行します。モデルやJSON出力の指定、拡張機能などの管理コマンドも扱います。

• メモファイルを要約したいとき
• 単発の依頼で文章を生成したいとき
• 回答をJSON形式で受け取りたいとき

仕様や要件を、変更するファイル・関数の定義・テスト・確認手順が分かる実装計画にまとめるスキル。コードを書く前に作業を分け、担当者へ引き継げる形に整えます。

• コードを書く前に機能実装を計画したいとき
• 要件をテスト可能なタスクに分けたいとき
• 別の担当者やエージェントに引き継ぎたいとき

コードレビューの指摘を実際のコードや対応環境と照らし合わせ、妥当性を確認します。不明点の整理、根拠を示した返答、修正ごとのテストまで進めるスキルです。

• 曖昧なレビュー指摘を整理したいとき
• 提案された変更の互換性確認
• 追加機能が使われているか調べたいとき

作業完了や不具合修正を報告する前に、テストやビルドを実行して結果を確認します。コミットやPR作成の前にも、実際の出力を根拠に状況を伝えるスキルです。

• 完了報告の前に結果を確認したいとき
• 不具合の修正を確かめたいとき
• コミットやPR前の検証

コード変更を確認する人に向けて、図や差分による要約、変更前後の動作証拠、取り消しやすさと影響範囲を短く整理したプルリクエスト本文を書くスキル。

• プルリクエスト本文を作成したいとき
• 構成変更をツリーや差分で説明したいとき
• 画面変更の前後を証拠で示したいとき

プロジェクト文書の整理依頼を適切な専門スキルへ振り分け、文書の役割、リンク、設計判断の索引、根拠への参照を、ファイルを変更せずに点検するスキルです。

• プロジェクト文書の整理手順を選びたいとき
• 既存文書の情報源を把握したいとき
• ローカルリンクと設計判断の索引の点検

GitHubの課題やプルリクエストを仕分けし、実行予定の作業をLinearにつなげて、公開状況と社内の担当・優先度・次の対応を整理するスキル。

• 未対応の課題やプルリクエストの仕分け
• Linearのタスクが必要か判断したいとき
• 進行中の作業と社内の担当・優先度の連携

Laravelの環境設定からコード検査、テスト、依存関係の脆弱性、データベース変更、キューまで順に確認し、マージやデプロイ前の問題を調べるスキル。

• Laravelのプルリクエスト前の確認
• 大きな改修や依存関係更新後の検証
• ステージング・本番へのデプロイ前確認

資金調達に向けた投資家への初回メール、紹介依頼、面談後の連絡を作成するスキル。相手の投資方針や具体的な実績を踏まえ、簡潔で次の行動が明確な文面に整えます。

• 投資家への初回メールを作りたいとき
• 転送用の説明を添えた紹介依頼
• 返信がない場合の連絡計画

予約済みのItô GPU環境で機械学習の訓練が利用可能かを確認するスキル。現状は訓練を実行せず、未提供の機能と将来の引き渡し条件を整理します。

• GPU予約後に訓練可否を確認したいとき
• 追加学習の引き渡し要件の確認
• 予約・予算・確認手続きの整理

Djangoの公開や変更提案の前に、環境・コード品質・データベース変更・テスト・脆弱性・設定を順に検証し、段階別の合否と修正すべき問題をレポートにまとめます。

• Djangoの変更提案前の確認
• マイグレーションを確認したいとき
• テストカバレッジの目標確認

開発の目的に合うECCのコマンド群を選び、実行順序と停止条件を案内します。現在のファイルを基に一覧も整理し、複数コマンドの使い分けを助けます。

• バグ修正のコマンド順序を知りたいとき
• MVP開発のコマンドを選びたいとき
• ECCの作業手順を一覧で見たいとき

複数の視点でまとめた重要な意思決定の草案に、Codexによる外部批評を一度追加します。結論の弱点や見落とし、反対意見の扱いを確認するスキルです。

• 判断が難しい重要な草案の検討
• 草案にない失敗の可能性の確認
• 強い反対意見の見落としの確認

Claude Codeで開発作業を繰り返し進める自律ループの設計を案内します。順次実行から並列作業まで、履歴の引き継ぎや品質確認、停止条件を整理します。

• 順次実行の開発手順を設計したいとき
• 反復実行で進捗を引き継ぎたいとき
• 並列作業と変更の統合を調整したいとき

REST・GraphQL APIの不具合を、接続、認証、送受信データの順に切り分けます。再現用コマンドや回帰テストを整え、原因と修正案をまとめるスキル。

• APIの認証エラーを調べたいとき
• Postmanとコードの動作差を再現
• ページ分割や回数制限の確認

Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when drafting a PRD or requirements document with objectives and scope, or when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.

日本語の概要は準備中です。原文の説明を表示しています。

Evaluate and carry out non-trivial software-system changes from first principles. Use when assessing RFCs, issues, designs, features, refactors, migrations, dependency changes, or proposed fields, events, APIs, modules, and services whose need, consumers, system fit, validation, or rollback require scrutiny. Read the actual system, identify the concrete problem and named semantic consumers, choose the smallest sufficient solution, reject pseudo-requirements and speculative abstractions, and require evidence proportional to risk. Do not use for mechanical edits, source-code explanation, or a dedicated review of an already-complete diff.

日本語の概要は準備中です。原文の説明を表示しています。

Create validated architecture, workflow, sequence, data-flow, lifecycle/state, entity-relationship, class/interface, tree, timeline, and execution waterfall diagrams as explorable standalone HTML with inline SVG, dark/light themes, optional motion, and image/SVG/WebM export. Accept plain-language requirements or Mermaid; inspect repository evidence for code-backed diagrams. Use when visualizing infrastructure, cloud/security networks, API calls, data pipelines, ETL/ELT, state machines, database schemas, class contracts, module hierarchies, incident/release histories, or request and agent-run timings. Also use for everyday subjects with steps, parts, relationships, or states: leave and travel plans, applications and approvals, renting conversations, money or document flows, and order progress. Not for numeric charts or dashboards.

日本語の概要は準備中です。原文の説明を表示しています。

Create a GitHub pull request following project conventions. Use when the user asks to create a PR, submit changes for review, or open a pull request. Handles commit analysis, branch management, PR template usage, and PR creation using the gh CLI tool.

日本語の概要は準備中です。原文の説明を表示しています。

ACTIVATES ONLY on an explicit user request for the ulw-plan workflow: the user themselves saying ulw-plan, ulw plan, /skill:ulw-plan, or asking in their own words for a work plan before coding. NEVER self-activates: a bare ulw/ultrawork run, an agent-side routing decision, or reading this file is not a request, and the plan-gated reviewers (metis/momus) stay locked without a user request plus a written .omo/plans plan file. Explore-first planning consultant (Prometheus) that grounds in the codebase, asks only the forks exploration cannot resolve - or researches them to best practice when the intent is fuzzy - waits for explicit approval, then writes ONE decision-complete work plan a worker executes with zero further interview. Triggers: ulw-plan, ulw plan, plan this, make a plan, plan before coding, interview me, break this down, start planning, plan mode.

日本語の概要は準備中です。原文の説明を表示しています。

Source-control safety for Git. Two rules apply whether or not you read the body. First, never commit, amend, push, tag, rebase, cherry-pick, revert, or reset --hard unless the user asked for that exact write in this session. An explicit request to create a new commit counts anywhere in the user's own task text, but it is not a request to amend, push, or tag. Finishing a task without that request is not authorization, so leave your work uncommitted for review. Second, when a Git lock file or corrupt index blocks you, never kill the holding process or bulldoze through with deletions - wait, retry, use the holder's own stop mechanism, or stop and report. Load the body only before writing Git history or recovering Git state.

日本語の概要は準備中です。原文の説明を表示しています。

On an explicit planning request, always call `read_skill` for this skill before answering. Research first, then return one concise inline plan; do not create a plan file unless the user explicitly asks or a governing workflow requires one. Start and end the reply by saying this is not a special mode and `go` executes the plan; do not implement in the planning turn. For ordinary implement, build, fix, debug, or refactor requests, work directly. When an explicit plan divides work into separate diffs, commits, or PRs and the user asks to publish, preserve that split and tell the user before deviating.

日本語の概要は準備中です。原文の説明を表示しています。

Reconcile new evidence into existing ChatGPT Pages or a Space when the user requests upkeep. For a direct text correction, use write-page. Do not use for ordinary chat drafts, writing, or advice, or treat a selected Page as a request to save. Schedule future upkeep only when requested.

日本語の概要は準備中です。原文の説明を表示しています。