コードベース全体のレビュー・監査。perf/sec/test/arch/cq/docs の6観点を並列委譲し、優先度付き issue ファイルと観点サマリをメモリディレクトリに生成する。コードベース全体の監査・定期レビュー・リリース前品質確認の依頼時、/codebase-review 実行時に使用。境界: PR 単位は pr-review、自ブランチの提出前確認は self-review。
grilling
既存の計画・設計・アイデアを尋問形式でストレステストし、前提と未決定事項を洗い出す対話スキル。「グリルして」「grillして」「この計画を詰めて」「計画の穴を突いて」「ストレステストして」等の依頼時、実装着手前に計画の前提を検証したい時に使用。要件書等は生成せず、確定した重要決定だけを ADR に記録する。
境界: ゼロからの要件定義は design-feature。
含まれるファイル(1)
- SKILL.md6.1 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Grilling
計画・設計のあらゆる側面をユーザーにインタビューし、設計ツリーの各分岐を1つずつ解決しながら、共有理解(shared understanding)に至るまでストレステストする。
出典: mattpocock/skillsのgrilling を既存規約にフル適合させたもの。
用語注記: 本スキルの「AskUserQuestion」はユーザーへの選択肢提示質問を指す。Claude CodeではAskUserQuestionツール(1回最大4問)を使い、無い環境(Codex等)では番号付き選択肢のテキスト質問で代替する(1回4問の上限も同様に扱う)。
原則
- 独立枝はまとめる、依存枝は1つずつ: 互いに前提を変えない独立した枝は1回のAskUserQuestionで最大4問までまとめて聞く(AskUserQuestionの上限は4問)。回答が後続の質問の前提を変える依存関係のある枝は、従来どおり1問ずつ降りる。判断に迷ったら1問ずつが安全側
- 推奨回答を必ず添える: 各質問に自分の推奨案と根拠を提示する
- 設計ツリーを枝ごとに降りる: 決定間の依存関係を意識し、前の回答が後の質問の前提を変える箇所ではまとめず順に解決する
- 調査で答えが出る質問はユーザーに聞かない: コードベース・公式ドキュメントの調査で確定できる事項は自分で調べて確定し、事実として提示する(推測禁止・調査先行の最優先指示と整合)
- 共有理解に至るまで実行しない: ユーザーが「共有理解に達した」と確認するまで、計画の実行・実装に着手しない
ワークフロー
1. 対象の把握
- グリル対象(計画・設計・アイデア)を特定する。会話中に提示済みならそれを使い、ファイル(30_plan.md等)が指定されたら読む
- 対象に関連する既存コードがあれば先に調査し、事実ベースの質問を組み立てる
2. 尋問ループ
- AskUserQuestionで質問する。独立した枝は1回のツール呼び出しで最大4問までまとめ、依存関係のある枝は1問ずつ降りる。推奨案は先頭オプションに置き、ラベル末尾に「(推奨)」を付ける。選択肢化が不自然な自由回答型の質問のみテキストで聞く
- 質問の観点例: 目的・成功条件 / スコープ境界 / エッジケース / 依存関係と順序 / 技術選定の根拠 / 運用・移行・ロールバック / 非機能(性能・セキュリティ)
- 回答によって前提が変わったら、影響を受ける未解決の枝に戻って質問し直す
- ユーザーの回答が既存コード・事実と矛盾する場合は、調査結果を添えて指摘する
3. 収束
- 未解決の枝がなくなったら、合意事項・却下した代替案・残リスクをサマリとして提示し、共有理解に達したかユーザーに確認する
- サマリ提示時に、ADR条件(下記)を満たす決定があればADRとして記録する
- 確認が取れるまで実装・実行には移らない
決定の記録(ADR等 → .local/docs/)
グリル中に確定した決定のうち、以下の3条件をすべて満たすものは、ADRとして ${MEMORY_DIR}/docs/adr/NNNN-<slug>.md(MEMORY_DIR未定義時は .local/docs/adr/)に保存する:
- 覆しにくい: 後から方針転換するコストが大きい
- 文脈なしでは不可解: 将来の読者がコードだけを見て「なぜこうした?」と不思議に思う
- 実在したトレードオフの結果: 本物の代替案があり、特定の理由で選んだ
3条件を満たさない決定は記録しない(覆しやすい決定は覆せばよく、自明な決定は誰も理由を問わない)。
- 形式: タイトル+1〜3文(文脈・決定・理由)で足りる。セクションを埋めること自体に価値はない。決定が再訪されそうな場合のみStatus(proposed / accepted / deprecated / superseded by ADR-NNNN)を、却下理由が非自明な場合のみ「考慮した選択肢」を追加する
- 連番:
docs/adr/内の最大番号+1。ディレクトリは最初のADRが必要になった時に遅延作成する - 用語集: グリル中に用語の揺れ(同じ概念への複数の呼び名)が問題になったら、
.local/docs/context.mdに推奨語と回避語(Avoid)を記録する - 境界: タスク限りの「やらない判断」は従来どおり99_history.md。タスクを超えて残すべき設計決定のみADRにする
- worktree内での実行時: メモリファイル同様、元repoの絶対パスに書く(@AGENTS.md「worktree運用ルール」)
既存設定との関係
- Phase 0-5(@context/workflow-rules.md): Phase 2(計画)の補完。複雑タスクの計画をグリルした場合、合意事項を30_plan.mdに反映し、経緯を05_log.mdに記録する。却下した代替案は99_history.mdに記録する
- メモリディレクトリ(@context/memory-file-formats.md): 既存構造を使用。加えて、ADR条件を満たす決定のみ
${MEMORY_DIR}/docs/に記録する(上記「決定の記録」参照) - AskUserQuestion運用(@AGENTS.md): 「曖昧な点は推測せず質問する」ルールの実行手段として機能する
既存設定への参照
- @context/workflow-rules.md
- @context/memory-file-formats.md
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
変更をコミットする。/commit 実行時、「コミットして」「pushして」等の依頼時に使用。--push 引数または「pushして」の依頼で push も行う。
PR を Draft で作成する。PR テンプレートを全セクション埋め、対象 repo の既存 PR の分量に合わせて書きすぎを削る。PR 作成の依頼時、実装が一段落して PR 化する時、/create-draft-pr 実行時に使用(gh pr create を直接実行しない)。引数でベースブランチを指定できる。境界: 個別レビューコメントへの対応は pr-comment。
スキルを新規作成する。「スキルを作って」「この手順をスキル化して」等の依頼時、/create-skill 実行時に使用。AGENTS.md・context・既存スキルと整合させ、重複・競合を避ける。境界: 既存スキル・指示ファイルの修正は update-inst、指示ファイル全体の監査は instructions-audit。
抽象的な要件・事業側の要求を深掘りし、既存実装との整合を確認して実装マスタとシステム要件書を作成する。「こういう機能を作りたい」「この要求を満たす機能を設計して」等の抽象要件の提示時、既存機能の拡張や Phase 分割の要件定義開始時、/design-feature 実行時に使用。境界: 要件確定後の実装計画書・PR 分割と実装進行は plan-feature-prs。
画面の設計判断(ナビゲーション・重ね方・通知と空状態と読み込み・外枠とトークンと状態表現)の型を決定表で選び、アプリ内の全画面で揃える。画面・ページ・レイアウト・ナビゲーション・ダイアログ・コンポーネントを新しく作る・作り直す時、モックやダッシュボードを作る時、サイドバー・タブ・モーダル・シート・toast・バナー・空状態のどれを使うか決める時に使用。PJ に components.json があれば shadcn の部品とトークンへの対応も扱う。主要なデザインシステム(Material・HIG・Carbon・Primer・Atlassian・Fluent・GOV.UK・NN/g・WAI-ARIA APG・WCAG)の一致点を規則にし、食い違いの採否を定めてある。境界: 画面の文言は writing-ui-text、画面に何を出すかと提示前の完了基準は context/ui-artifact-standards.md、コードの実装原則は writing-code、shadcn 部品の API と組み立ては shadcn。