機能追加や動作変更の前に、対話で目的・制約・成功条件を整理し、複数の案を比較します。承認した設計を仕様書にまとめ、実装計画へつなぐスキル。
- 新機能の要件を整理したいとき
- 動作変更の実装案を比較したいとき
- 大規模な依頼を分割したいとき
計画や意思決定、アイデアを質問で掘り下げ、未確認の前提や判断の抜けを洗い出します。判断の依存関係に沿って対話を重ね、実行前に共通理解を確認するスキルです。
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
実行スコア 未検証
インストール方法を見る計画、意思決定、アイデアについて質問を重ね、判断の抜けや暗黙の前提を洗い出します。判断同士の依存関係を木構造に整理し、前提が決まっている質問を一回分としてまとめて提示します。各質問には推奨回答も添えます。回答を受けて構造を見直し、新たに答えられる質問へ進みます。
実行前に計画を厳しく点検したいときや、アイデアについて考え切れていない部分を見つけたいときに向いています。前の判断次第で答えが変わる質問は後の回へ回すため、依存する判断を順に詰められます。選択は利用者が行い、エージェントは回答を待ちます。
ファイルやツールなど、環境から調べられる事実はサブエージェントが調査する設計です。その調査機能を使える環境が前提になります。すべての判断を確認した後も、利用者が共通理解に同意するまでは実行に移りません。
この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Interview the user relentlessly until you reach a shared understanding. Map this as a design tree: every decision branches into the decisions that hang off it.
Work the tree in rounds. The frontier is every decision whose prerequisites are already settled — the questions you can ask now without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
Each question should be formatted like so:
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a later round, not this one.
Finding facts is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The decisions are the user's — put each to them and wait.
The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
機能追加や動作変更の前に、対話で目的・制約・成功条件を整理し、複数の案を比較します。承認した設計を仕様書にまとめ、実装計画へつなぐスキル。
指定したコミットやブランチを基準に、コード変更を規約への適合と仕様の実現という二つの観点で並行レビューします。それぞれの指摘を分けて報告するスキルです。
開発の依頼内容と進行中の変更を確認し、設計・実装・検証・アーカイブの適切な段階へ振り分け、不具合修正や小規模変更にも対応するスキル。
開発の現在地を判定し、要件整理・設計・実装・検証・保管の各手順へ案内します。OpenSpecとSuperpowersを組み合わせ、変更の進行を管理するスキル。
プロジェクトの設定に従ってCometのNativeまたはClassicを選び、依頼を対応するワークフローへ引き渡すスキル。設定がない場合は既定値を保存します。
プロジェクトに保存された設定からCometのNativeかClassicを選び、依頼を対応するスキルへ引き渡します。方式を指定せずにCometの作業を始めるための入口です。