成果物を次工程へ渡すパイプライン

対話ヒアリングの前に /init でプロジェクト文脈を確立し、--permission-mode plan の読み取り専用で要件を詰めたいとき。# プレフィックスのクイックメモリで確定要件をその場で CLAUDE.md に固定する。

新機能・コンポーネント作成や挙動変更など、創作系タスクの実装前に必ず使う。簡単に見える小さな変更でも、境界条件と影響範囲を選択肢付きで1問ずつ洗い出すために起動する。

ユーザーが暗黙の前提を抱えたまま要件を語っている、または性能・セキュリティ・スケールなど非機能要件が曖昧なときに使う。曖昧さゲートが十分に明確になるまでソクラテス式の質問を継続する。

実装前に既存コードの構造・命名規則・依存を把握したいとき、Glob で俯瞰し Grep で検索、Read で核ファイルを確認する。LSP の goto definition / find references で間接的な呼び出し元まで追う。

単発の Grep では追えない「認証がどこでどう実装されているか」のような横断的な問いを、コードベース全体を高速マッピングして解きたいときに使う。裏で explore エージェント（haiku）が動く。

React 19 や Stripe API など外部ライブラリ/フレームワークの最新仕様を、訓練データではなく Context7 MCP 経由で公式ドキュメントから確認したいとき。バージョン不一致が疑わしい API 調査で特に有効。

新機能を自作する前に既存の解決策がないか必ず確認したいとき。GitHub リポジトリ検索 → パッケージレジストリ確認 → ドキュメント参照の順でリサーチファースト開発をワークフロー化する。

実装に入る前に、コードベースを読み取り専用で調査して計画を固めたいとき。Glob/Grep/Read のみで変更を伴わないため安全に方針を検討できる。

brainstorming で仕様が固まった後、実装計画を構造化したいとき。ファイル構造をマッピングし、各タスクを短く検証可能な粒度に分解する。

仕様書や要件から実装の青写真を作りたいとき。opus で最適な実行順序を提案させる、計画策定の中核エージェント。

システム設計・モジュール境界・トレードオフを検討する必要があるとき。単なるタスク分解ではなく設計判断が絡む計画で使う。

計画の盲点を潰したいとき。planner が計画を策定し critic がダメ出しする反復をコンセンサスに達するまで回す。曖昧な ralph/autopilot/team 要求の前段ゲートにもなる。

認証リファクタリング等、複数の実装方針が考えられる計画で複数視点を比較したいとき。独立した複数エージェントが計画を策定し統合する。

実装の起点。Read で既存コードを把握し、Edit / MultiEdit / Write で変更、Bash でビルド・型チェックを回す基本ループに使う。

新機能やバグ修正のコードを書く前に必ず使う。失敗するテストを先に書き RED を確認してから最小実装する Iron Law を強制したいときに。

独立したタスクの実装・リファクタリングを本体コンテキストから切り離して任せるとき。複雑な作業は model=opus に切り替えて使う。

要件が固まっていて、アイデアから動くコードまで計画→実装→検証を単一リードエージェントに自律実行させたいときに使う。

npm run test / tsc --noEmit / lint / build を Bash で実行し、結果を直接読んで失敗数を確認したいとき。LSP診断でリアルタイムにエラーを検出する際にも使う。

機能やバグ修正の実装前に、先にテストを書いて RED-GREEN-REFACTOR サイクルを回したいとき。テストが実装の仕様を駆動する場面で使う。

「完了」を宣言する直前に必ず使う。IDENTIFY→RUN→READ→VERIFY→THEN claim のゲートで、検証コマンドの出力を読まずに完了と言わせない。

実装が完了条件を満たすかをエージェントに検証させ、完了の証拠を収集させたいとき。verifier による独立した検証パスとして使う。

テスト失敗が複数残っていて、test→verify→fix→repeat を自動ループで全件パスまで回したいとき。手動の修正→再実行が非効率な局面で使う。

「十分にテストした」という主観ではなく、プロジェクトが定めたカバレッジ基準を確認したいとき。どのパスが未テストかを特定する場面で使う。

実装直後に、書いた本人とは別コンテキストで品質・セキュリティ・保守性を体系的に検査したいとき。自己承認を避けるため必ず別エージェントに委譲する。

認証・認可、入力処理、シークレット、APIエンドポイント変更を含む差分で、コード品質レビューとは独立にセキュリティ特化の確認をしたいとき。「小さな変更だから」と省略しない。

「実装完了」を宣言する前に、ビルド・テスト・型チェック等の検証コマンドを実際に走らせて結果を確認したいとき。診断のみで終わらせない完了ゲートとして使う。

セッション履歴の盲点を避けて、code-reviewer サブエージェントに精密に作成したコンテキストだけを渡してレビューさせたいとき。実装とレビューのコンテキスト分離を強制する。

レビュー指摘を受け取ったとき、機械的修正や「おっしゃる通り！」の表面的同意で済ませず技術的に検証してから対応したいとき。

.claude/ 配下（CLAUDE.md・settings.json・MCP・hooks・エージェント定義）の設定ファイルレベルでインジェクションや誤設定を自動監査したいとき。人手のレビューでは見落としやすい設定リスクを補完する。

git diff で変更を確認し、ステージング・コミット・gh pr create による PR 作成まで一連のリリース操作を任せたいとき。CI 状況の確認も自然言語で依頼できる。

実装が完了しブランチをどう締めるか決める段階で、マージ・push&PR・保持・破棄の選択を安全に行いたいとき。

リリース単位を確定し、バージョン番号の更新と CHANGELOG を手作業なしで整えたいとき。リリースノート未作成のまま出荷するのを避けたい場面で使う。

CI/CD パイプラインの構成や、デプロイ後に問題が出た際のロールバック戦略を本格的に設計したいとき（Docker・ヘルスチェックを含む）。

セッション終了前に、# プレフィックスのクイックメモリや /memory で CLAUDE.md を更新し、学んだ知見をその場で永続化したいとき。リリース直後の「次タスクへ即移行」を防ぐ最初の一手として使う。

うまくいった解法やワークフローを再利用可能なスキルパターンとして抽出したいとき。手動メモでは取りこぼす暗黙知を品質ゲートで篩いにかけて残したい場面で使う。

信頼度スコア付きの instinct として学習を蓄積し、/evolve でスキルへ進化、/instinct-export と /instinct-import でチームへ展開したいとき。個人の学習を組織知に変える振り返りの締めで使う。