依頼文サンプル

開発サイクルの各ステップで AI エージェントに渡す依頼文。【】の穴を埋めて使う。どのモデル・どのツールでも同じ依頼ができるように、必要な参照先をすべて依頼文の中に書く。

Claude Code では /dev-cycle、/grilling、/tdd、/eng-practices、/create-pr のスキルが対応する手順を呼び出すが、依頼文をそのまま貼っても同じ結果になることを前提にする。

1. プランドキュメントの作成（インタビュー式）

【機能名】を作りたい。要望：docs/backlog/【要望ファイル】.md
参考：仕様ページ docs/spec/todo.md、未解決論点 docs/open-questions.md

まず実装に入らず、プランを書くために必要な質問を私にすること。
技術面・エッジケース・トレードオフについて、答えにくい質問ほど価値がある。
仕様ページに書いてあることは質問せず自分で読む。未解決論点に関わる判断は私に聞く。
質問が尽きたら、プランを docs/plans/【日付-機能名】.md に8項目
（概要・背景・詳細設計・テスト影響範囲・新規テストケース・実装順・コミット前テスト実行・スコープ外）で書き出すこと。
実装順には、タスクごとの担当（セッション・サブエージェントと、モデルの段：強い／標準／軽い）まで書くこと。

2. プランのAIレビュー

実装セッションとは別のセッションで。

docs/plans/【プランファイル】.md をレビューすること。私は書いた本人ではない前提で読む。
判定の基準：docs/process/rules/ のルールと docs/spec/todo.md。
基準の文書に加えて、プランが触ると書いたファイルと、それを参照している実コード・テストも読み、
プランの前提（関数・型・依存の向き・ファイルの置き場所）が実コードと合っているかを確かめること。
指摘は P0（実装前に必ず直す）／P1（推奨）／P2（軽微）に分類し、
プランのどの記述が・どの基準と・なぜずれるのかを1件ずつ示すこと。

3. テスト網羅のレビュー

docs/plans/【プランファイル】.md の「新規テストケース」だけをレビューすること。
仕様ページ docs/spec/todo.md と要望の受け入れ条件と突き合わせ、
[1] 条件に対応するテストが欠けていないか
[2] 境界値の両側・異常系が入っているか
[3] 実装しないと決めたスコープ外がテストに紛れていないか
を確認し、足りないテストケースを提案すること。docs/process/rules/testing.md の骨抜き禁止に照らすこと。

4. 実装

docs/plans/【プランファイル】.md の実装順に従って実装すること。
先に AGENTS.md と docs/process/rules/architecture.md を読むこと。
プランにない変更が必要になったら、実装せずに立ち止まって報告すること。

5. テストの実装と全通過

プランの「新規テストケース」をテストコードに落とすこと。docs/process/rules/testing.md に従う。
各テストは先に実行して失敗（Red）を確認してから実装を直す。
最初から通ってしまったテストは、実装済みか assert が弱いかを判定して報告する。
最後に pnpm web:typecheck && pnpm web:test を実行し、全通過の出力を見せること。

6. 実装のAIレビュー（観点別並列）

実装が終わった。次の3体のサブエージェントを並列で実行し、報告を P0 から P2 に整理して返すこと。
- design-reviewer：プランとの整合（不足と過剰）と設計
- edge-case-reviewer：異常系と境界値の抜け
- spec-reviewer：docs/spec/ の正式ページとの整合
P2 は直さず、docs/architecture/known-issues.md の「見送った軽微な指摘（P2）」に1行で記録すること。
P0・P1 があれば修正し、指摘を出した観点だけで再レビューすること。3ラウンドを超えたら止めて私に裁定を求めること。

Claude Code 以外のツールでは、観点ごとに別セッションを立てて .claude/agents/ の各ファイル本文をそのまま依頼文にする。

7. 人間のレビュー（AIへの壁打ち）

実装した【機能名】について、レビューする私に説明すること。判定はしなくてよい。
0. 説明の前に、変更した画面をブラウザで操作して確かめ、スクリーンショットを添える。
1. 変更の要点を、データの流れ（画面 → shared/api → MSW ハンドラ → fixtures）がわかる粒度で説明する。
2. 設計判断を3つまで挙げ、それぞれ採らなかった選択肢と併記する。
3. 各判断の根拠が docs/plans/【プランファイル】.md のどこにあるかを示す。プランに書いていないものは「実装時の判断」と明示する。
4. 壊れたときに影響が大きい箇所を、理由とともに挙げる。

8. 振り返り（体制の進化）

今回のサイクル（docs/plans/【プランファイル】.md）を振り返ること。
ルールが足りなかった・邪魔だった・依頼文が通じなかった・手戻りが起きた箇所を挙げ、
docs/process/evolution.md の「候補」に追記する文案を提案すること。採用の判断は私がする。
それぞれに、きっかけ（人間レビュー／AI レビュー／作業中の失敗など）と、止め方の案を添えること。
1回目の失敗は記録だけを提案し、仕組みにするのは同じ種類の失敗が2回目に起きたときにする（戻せない失敗は1回目から）。
止め方は、ルールを足すより先に、機械で止める・自動で組み立てる仕組みを考える。