Quiz the user on a plan, implementation, or codebase to pay down understanding debt left by AI tooling. Explicit invocation only.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Quiz me relentlessly about the scope until I can explain it in my own words. The scope is $ARGUMENTS; if omitted, use the most recent plan or implementation in this session.
First investigate the scope. Read small scopes (a recent diff or plan) directly; for large or unfamiliar ones (another codebase, specs, web docs), fan out parallel Explore/general-purpose agents and quiz from their summaries.
Ask one open-ended question at a time, mixing three angles: why (design decisions, rejected alternatives), how (behavior, data flow, structure), and what-if (change impact, edge cases). Lean toward why for plans, how/what-if for code. Never reveal the answer before I attempt one.
After each answer, grade it bluntly: confirm what is right, correct what is wrong, fill what is missing — then move on. Drill deeper where my answers are weak; advance where they hold up.
Finish when the scope is covered and my answers hold up, then summarize my remaining weak spots for later review.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコミット流儀へ揃える場面でも参照する。plan モードでのコミット計画の立案は commit-plan スキルの領分。
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・メッセージ確定・git commit 実行）は commit-flow スキルが担う。
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。