Imported from tombolo-jp/cc-task-skills (skills/task-dev/SKILL.md). Install upstream with npx skills add tombolo-jp/cc-task-skills --skill task-dev. Copyright stays with the author.

タスクの開発実行

Name: task-dev
Author: tombolo-jp

あなたは経験豊富なソフトウェア開発者です。詳細設計に基づいて開発を進めます。

タスク「$ARGUMENTS[0]」の開発を開始します。

引数の解釈

このスキルは以下の引数を受け取ります:

第1引数（タスク指定子）: $ARGUMENTS[0] — 必須。処理対象のタスク名。カンマ区切りで複数のタスクを指定できます（例: task1,task2,task3）。
オプション: 第2引数以降に --team などのフラグが指定される場合があります。

オプション一覧

オプション	説明
`--team`	Agent Teams を有効化し、チームメイトと協調して作業を実行します（単一タスク指定時のみ）

引数全体: $ARGUMENTS

実行モードの判定【共通ブロックより先に評価】

この判定は、次節「重要: --team の有無による分岐【最優先】」よりも先に行ってください。 実行モードが決まらないと --team の扱いが確定しないためです。

第1引数（タスク指定子）を以下の規則でパースし、mode（single / multi）・tasks[]（タスク名の配列・入力順）・team_enabled（真偽値）を確定させます。

#	規則	具体
AP-1	先頭トークンをタスク指定子、2 番目以降をフラグとして扱う	`task1,task2 --team` → 指定子 `task1,task2` / フラグ `--team`
AP-2	指定子にカンマを含めば複数タスクモード、含まなければ単一タスクモード	後方互換の分岐点。カンマがなければ以降の挙動は従来と完全に同一
AP-3	区切り文字は `,` のみ。カンマ前後の空白はエラー	`task1, task2` は空白で 2 トークンに割れ、2 番目が既知フラグでないため AP-6 でエラー
AP-4	空要素はエラー	`task1,,task2` / `task1,task2,` / `,task1`
AP-5	タスク名は `^[A-Za-z0-9._-]+$` に一致すること。`.` のみ／`..` を含むものはエラー	パストラバーサル・コマンド注入の防止
AP-6	2 番目以降のトークンが既知フラグ以外ならエラー。既知フラグは `--team` のみであり、`--tema` / `--no-review` / `--review-only` のような未知フラグは黙って無視せずエラーとする	空白混入の検出を兼ねる。黙って無視すると `--tema` のような誤記が既定の実行経路へ落ちるが、本スキルはレビュー・修正ループでリポジトリ本体のコードを書き換えるため、従来「何も起きない」で済んだものが「意図しない変更」になる
AP-7	同一タスク名の重複は先頭 1 件のみ採用し、重複分は警告のうえ除去	報告を明快にするための事前除去
AP-8	複数タスクモードかつ `--team` 指定時は `--team` を無視し、警告を表示して続行	コンテキスト分離を優先。理由は下記

レビューを省略する導線は提供していません。 --no-review / --review-only に相当するオプションは存在せず、レビュー・修正ループは常に実行されます。

エラー時は即時終了してください（ファイル作成・git 操作を一切行わない）。この即時終了は「ステップ0: 全フェーズを Task として登録する」よりも前に行います（登録してから落ちると、実行されないフェーズが進捗表示に残るため）。

タスク指定子が不正な場合に表示する文言:

❌ タスク指定が不正です: <理由>
   - カンマ区切りは空白なしで指定してください（例: task1,task2,task3）
   - 空の要素（連続カンマ・先頭/末尾カンマ）は指定できません
   - タスク名に使用できる文字は英数字・ハイフン・アンダースコア・ドットのみです

未知フラグを検出した場合に表示する文言（AP-6）:

❌ 不明なオプションです: <トークン>
   このスキルが受け付けるオプションは --team のみです。
   （--no-review / --review-only 相当のオプションはありません。レビュー・修正ループは常に実行されます）

AP-8 に該当する場合に表示する警告文言:

⚠️ 複数タスク指定時は --team を利用できないため、--team を無視して実行します（理由: タスク実装をサブエージェントへ委譲するため、その内部でチームメイトを spawn できません）。

判定順序【この順序で確定させること】

(1) 引数トークン列の分解                 ← AP-1
(2) フラグ集合の確定と未知フラグ検出      ← AP-6（エラーなら即時終了。ステップ0 より前）
(3) タスク指定子のパース                 ← AP-3〜AP-5, AP-7
(4) mode の確定（single / multi）         ← AP-2
(5) team_enabled の確定                  ← AP-8（multi なら false へ強制＋警告）
(6) ステップ0: フェーズ登録               ← mode により登録系列が決まる
(7) 「重要: --team の有無による分岐」の評価

モード確定後の扱い:

モード	次節「`--team` の有無による分岐」の評価	実行する手順
単一タスクモード	通常どおり評価する（`--team` があれば Agent Teams モードへ）	ステップ1〜5
複数タスクモード	`--team` を「含まれない場合」として評価する（AP-8 で無視済みのため）	ステップ6（ステップ5 の規約を参照）

重要: `--team` の有無による分岐【最優先】

引数全体に --team が含まれるかを最初に判定してください。これがスキル全体の挙動を決める最上位フラグです。

含まれない場合:
- 「Agent Teams モード」節は完全に無視してください
- 起動時メッセージ（✅ / ⚠️）は一切表示しないでください
- Agent Teams 関連操作（ToolSearch 等）は一切実行しないでください
- メタ情報の Agent Teams は 無効（指定なし） と記録してください
- 「手順」セクションへ進んでください
含まれる場合のみ:
- 「Agent Teams モード」節へ進んでください

Agent Teams モード

【前提】このセクションは --team 指定時のみ評価します。未指定なら読まずに「手順」セクションへ進んでください。

チームメイトの起動（--team 指定時のみ）

Agent Teams は Agent ツールでチームメイトを spawn し、進捗はチームリード（あなた）が Task（ステップ0 で確定した進捗管理方式）で追跡する暗黙チーム方式で実行します。成果の返り方は spawn の形態によって決まります。

spawn の形態	成果の返り方
`name` を付けない同期委譲（`run_in_background: false`）	最終メッセージが tool result として戻り値で返ります
`name` を付けた spawn	バックグラウンド実行となり、成果は tool result では返りません（返るのは「まだ実行中」の旨のみで、完了はタスク通知で届きます）。この形態で成果本文を受け取る手段は `SendMessage` だけです

したがって、成果物を受領する必要がある委譲では name を付けない同期委譲を既定とし、name 付き spawn は成果の受領を伴わない作業か、SendMessage で送り返させることを委譲プロンプトへ明示した場合にのみ用いてください。

SendMessage（teammate 間のライブ通信）は 環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS が有効なときのみ利用できる任意機能であり、使えれば指示・連絡に併用してかまいませんが、使えなくても同期委譲の戻り値方式で成立します。

（注: 旧来のチーム生成／破棄 API は廃止済みのため使用しません。Agent は core ツールでメイン会話に常在するため、ToolSearch でのロードは不要です。）

待機作法【禁止事項】

チームメイトの完了を待つ目的で、TaskGet / TaskList / ListAgents / git status などのツールを 2 回以上連続して呼び出すことを禁止します。待機は同期委譲の await（戻り値）と、バックグラウンド実行の完了通知に委ねてください。完了確認のためにツールを呼ぶ必要は原理的に存在しません。

理由: ポーリングは状態を一切進めず、コンテキストのみを消費します。1 周目でコンテキスト予算を使い切ると、2 周目以降が実行不能になります。

待機状況を利用者へ伝える場合は、前回の表示から変化した情報のみを出してください。変化が無ければ何も出力しません。

協調ツールのロード（任意）

ライブ通信を使う場合は、以下でスキーマをロードしてください（Agent 自体は常在のため不要です）:

ToolSearch query="select:SendMessage" max_results=10

SendMessage が <functions> ブロックに含まれない場合は環境変数が無効です。その場合も同期委譲の戻り値方式で続行してかまいません（フォールバックは不要です）。

⚠️ コストに関する注意

Agent Teams はトークン消費が通常の2〜5倍に増加する可能性があります。

チームメイトの spawn と稼働確認

各担当を Agent ツールで spawn してください（subagent_type を指定）。成果を受領する委譲では name を付けず、run_in_background: false の同期呼び出しとしてください（name を付与するのは SendMessage の宛先が必要な場合に限ります）。独立した作業は、同一メッセージ内に複数の Agent 呼び出しを並べて並列起動してください。
チームメイトが少なくとも 1 体、実際に稼働（応答）したことを確認してください。
進捗はチームリード（あなた）がステップ0 で確定した方式（Task 方式／フォールバック時はチェックリスト）で追跡します。SendMessage が利用可能なら作業指示・連絡に併用してください（任意）。各 teammate の成果は、name を付けない同期委譲であれば戻り値で受け取ります。name 付き spawn を用いた場合は、SendMessage で成果を送り返すよう委譲プロンプトへ明示してください。
全成果の統合後、明示的なチーム破棄は不要です（自動クリーンアップ）。

spawn 失敗時のフォールバック【必須】

spawn したチームメイトが 1 体も稼働しなかった場合は、以下を必ず実行してください:

次のメッセージを表示する（省略・要約禁止）:

⚠️ Agent Teams（チームメイトの起動）が現在の環境で利用できないため、Agent Teams モードを起動できません。今回は通常モードで実行します。
以降の Agent Teams 関連手順を一切実行しない
「手順」セクションへ進み、単一エージェントとして通常通り作業する
メタ情報の Agent Teams は 無効（フォールバック） と記録する

役割分担

design.md の実装タスク一覧（各 T-nnn の依存フィールド）から依存関係を分析し、独立して並行実装できるタスク群を特定してください。todo.md がある場合は併せて参照してください。

チームメイトに以下のように作業を分担してください:

並行実装: 依存関係がないタスクは異なるチームメイトに割り当てて並行実装
順次実装: 依存関係があるタスクはチームリード（あなた）が順次実装
各チームメイトへの指示: 対象ファイル、実装内容、コーディング規約を明確に伝達

重要: 各チームメイトが同じファイルを同時に編集しないよう、ファイル単位で作業を分割してください。

レビューフェーズの役割分担（`--team` の適用対象）

レビューの委譲は name を付けない同期 Agent 委譲（run_in_background: false）で行います。--team は並列体数と観点分割のプロファイル選択を意味し（5-6-9 のプロファイル表: 無効＝1体が観点①〜⑤すべて、有効＝観点3分割で3体）、有効時の観点分割は次のとおりです:

担当	観点
担当A	①要件定義との整合性 ②設計書との整合性＋ ③実装タスクの完了状況
担当B	④コード品質（可読性・保守性・エラーハンドリング・テストの有無と網羅性）
担当C	⑤セキュリティ・堅牢性

チームリード（あなた）が行ってよいのは重複排除・優先度の統一・R-nnn の採番統一のみです。指摘の取捨選択は行いません（RI-5）。
観点の割当表と体数プロファイルはループ間で変えません（LC-7）。割当が変わると同じ欠陥が別の体へ当たり、指摘の有無が揺れて停滞判定（EA-1）が原理的に働きません。
一部の担当しか稼働しなかった場合は稼働分で続行し、欠けた観点を dev-result.md へ明記します（E-15）。0体なら共通ブロックのフォールバック文言を表示したうえで、レビュー委譲そのものは別途1体で試行します（Agent Teams のフォールバック＝レビューの自己化ではありません。E-25）。

修正フェーズは `--team` の適用対象外

修正は単一エージェントが逐次行います（RI-8。単一タスクモードではチームリード自身、複数タスクモードでは単一の修正サブエージェント）。並列化すると共有資源が競合し、どの修正がどの指摘に対応したのかが失われて終了保証が成立しなくなるためです。

統合

チームリード（あなた）は全チームメイトの成果を統合し、動作確認を行った上で dev-result.md を作成してください。

注: チームメイトが稼働せず、結果としてチームリード（あなた）が一人で全作業を完遂した場合、それは Agent Teams 実行が成立していない状態です。メタ情報は 無効（フォールバック） と記録してください。

パス解決ルール

重要: タスクファイルはプロジェクトルート配下に格納されています（~/.claude/tasks/ ではありません）。

最初に Bash ツールで pwd を実行し、プロジェクトルートの絶対パスを取得してください。以降のすべてのファイルパスは、取得したプロジェクトルートを先頭に付けた絶対パスで指定してください。

例: pwd → /Users/yuki/dev/www/my-project の場合

<PROJECT_ROOT>/.claude/tasks/$ARGUMENTS[0]/dev-result.md → /Users/yuki/dev/www/my-project/.claude/tasks/$ARGUMENTS[0]/dev-result.md

複数タスクモードの場合: タスクごとにパスが変わるため、以降は <TASK>（ループ中の対象タスク名）を用いて表記します。

<PROJECT_ROOT>/.claude/tasks/<TASK>/design.md
<PROJECT_ROOT>/.claude/tasks/<TASK>/todo.md（存在する場合）
<PROJECT_ROOT>/.claude/tasks/<TASK>/dev-result.md

成果物 dev-result.md は、タスクごとのディレクトリ配下にそれぞれ作成します。

手順

ステップ0: 全フェーズを Task として登録する【FR-1: フロー強制】

本スキルの手順に着手する前に、進捗管理用の Task ツールをロードしてください（deferred tool のため、ロードしないと呼び出せません）。この ToolSearch は進捗管理のためのものであり、Agent Teams とは無関係です（--team の有無にかかわらず実行します）。

ToolSearch query="select:TaskCreate,TaskUpdate,TaskList,TaskGet" max_results=10

判定は スキル実行あたり1回だけ 行い、フェーズごとに繰り返さないこと。

ToolSearch の結果	進捗管理の方式
`<functions>` ブロックに `TaskCreate` / `TaskUpdate` が含まれる	Task 方式（主経路）
含まれない、または ToolSearch がエラー終了	チェックリスト方式（フォールバック）

委譲ランタイムの判定は不要です。 本スキルの委譲（レビュー・実装・修正）は name を付けない同期 Agent 委譲のみを用います。Agent は core ツールとしてメイン会話に常在するため、ToolSearch によるロードも可否判定も行いません（判定フェーズそのものが存在しません）。Dynamic Workflows は使用しません（本リポジトリ全6スキル共通の方針）。

フェーズ登録の方式

Task 方式（主経路）: 下記の全フェーズを TaskCreate で1件ずつ登録し、着手時に TaskUpdate で in_progress へ、完了時に completed へ遷移させます（subject = フェーズ名の imperative 形、description = そのフェーズで行うことを1文）。

チェックリスト方式（フォールバック）: 下記の全フェーズを - [ ] のチェックリストとして応答中に宣言し、各フェーズの完了直後に再掲して - [x] へ更新します。フォールバックしたことを告知するメッセージは表示しないでください（チェックリスト自体が進捗表示を兼ねます）。

いずれの方式でも登録（宣言）は 省略不可 です（成果物の必須要素）。列挙順に実行し、どのフェーズもスキップ・前倒しをしないこと。登録するフェーズは 実行モードによって異なります（該当する側のみを登録）。

単一タスクモードのフェーズ（この順序・各項目は imperative 形・12件）:

プロジェクトルートを pwd で解決する
レビュー・修正ループを含む実行であることを警告表示する
design.md を読み込む（todo.md があれば併せて読む）
dev-result-template.md を読み込む
dev-result.md を初期化する（実装タスク一覧からチェックリスト抽出。既存の dev-result.md がレビュー節を持つ場合は初期化せず 1-5 の復帰手順で復元して再開する）
実装タスクを順に実装する（着手時に下記「実装タスクの動的追加」を行う）
実装フェーズの結果を dev-result.md へ追記する
レビュー担当への入力集合を確定する（req.md・design.md・レビュー対象ファイルのパス）
レビュー・修正ループを実行する（1周ごとに下記「確認パスの動的追加」を行う）
ループの終了理由と未解消の指摘を dev-result.md へ追記する
dev-result.md を完成させメタ情報を追記する
実行結果を報告する（ループ周回数・未解消の R-nnn・レビュー隔離の成否）

複数タスクモードのフェーズ（この順序・各項目は imperative 形・7件）:

プロジェクトルートを pwd で解決する
引数をパースし対象タスク一覧を確定する
事前検証を実行する（git 清浄性・成果物の存在・完了済みの検出）
コスト警告を表示する
実装対象の件数を表示する
タスクごとに実装・レビュー・修正を委譲しコミットする（着手時に下記「実装タスクの動的追加」を行う）
実行結果サマリを報告する

警告フェーズの位置: 目的はトークンを費やす前の予算告知です。単一タスクモードは pwd の直後、複数タスクモードは事前検証の後・件数表示の前（中断するなら警告は不要な情報のため）。

件数削減のための統合を行わないこと。 上記の件数は、実行主体が移動しただけのフェーズ（レビュー担当が自身の応答内で管理するもの）と、対象そのものが廃止されたフェーズを整理した結果です。相異なるフェーズを1つへまとめてはいけません。

確認パスの動的追加

固定フェーズ「レビュー・修正ループを実行する」に対し、確認パス1周ごとに次を動的追加します（TaskCreate。フォールバック時はチェックリスト項目として追加）。

追加タイミング	`subject`
パス `i` の開始時（カウンタを `i` へインクリメントした直後）	`[review pass <i>/2] レビューを委譲し指摘を集約する`
そのパスで `修正必須` が1件以上あった場合のみ	`[fix pass <i>/2] 修正必須の指摘を修正する`

パス内の個別項目（各 R-nnn の修正）は Task 化しません（項目数が入力依存で発散するため）。
早期中断した場合、進行中のパスは in_progress のまま残します（deleted は「不要になった」を意味し失敗を表さないため使いません）。
複数タスクモードではパス Task を追加しません（ループは委譲先の内部で回るため）。既存の [task <i>/<N>] のみを保持し、文言も変えません。

禁止事項: (a) Task 登録／チェックリスト宣言の省略、(b) フェーズのスキップ・前倒し、 (c) 状態遷移（completed 化・完了マーク更新）の省略。

--team 有効時: Agent Teams が成立している場合も、チームリード（あなた）が自身の Task 一覧（フォールバック時はチェックリスト）で全フェーズを追跡してください。チームメイトへ委任した作業は Agent の戻り値で完了を確認してから completed へ遷移させます。

ステップ1〜5 は単一タスクモード専用の実行経路です。 複数タスクモードの場合はステップ1〜4 を実行せず、ステップ6 へ直接進んでください（ステップ1〜4 相当の処理は、タスクごとにサブエージェントが担います）。ステップ5（レビュー・修正ループ）の規約は両モード共通であり、複数タスクモードではステップ6-3 (c) から参照されます。

ステップ1: 入力解決とファイル読み込み【単一タスクモード】

design.md が必須入力です。todo.md は「存在する場合のみ読む」補助入力です。

Readツールで以下を読み込み、設計とタスク内容を確認してください:

<PROJECT_ROOT>/.claude/tasks/$ARGUMENTS[0]/design.md — 必須
<PROJECT_ROOT>/.claude/tasks/$ARGUMENTS[0]/todo.md — 存在する場合のみ（後方互換）

1-1. 実装タスク一覧の検出手順（`T-nnn` の消費契約）

#	手順
1	design.md 内で `^## 12\. 実装タスク一覧` に前方一致する見出しを探す。番号が異なる場合に備え、`実装タスク一覧` という文字列を含む `##` 見出しを代替条件とする
2	見つかった見出しの次行から、次の `##` 見出しの直前までを対象範囲とする
3	範囲内で `T-nnn` を含む `- [ ]` 行を、出現順にタスクとして抽出する
4	抽出結果が 0 件なら「実装タスク一覧なし」として扱い、1-2 の分岐へ進む

T-nnn のチェックボックスは書き換えません。 design.md は設計書＝入力仕様であり実行記録ではないため、進捗は dev-result.md が持ちます（task-verify が自動実行フェーズで自身の V-nnn のチェックボックスを書き換えるのとは、意図的に異なる扱いです）。

1-2. 入力の分岐（A-1〜A-5）

判定順序【後方互換の必須要件】: 先に「todo.md が存在するか」を判定し、そのうえで design.md の実装タスク一覧の有無を見てください。 この順序を守らないと、todo.md を持つ既存タスクが design.md 単独パス（A-2 / A-3）へ落ち、従来の挙動が壊れます。

#	design.md	todo.md	実装タスク一覧	挙動
A-1	不在	—	—	スキップ（成果物欠落）。実装に着手しない
A-2	あり	不在	あり	design.md 単独で着手する
A-3	あり	不在	なし	実装タスク一覧を design.md へ追記してから着手する（1-3）
A-4	あり	あり	あり	両方を必ず参照。実装順は design.md の `T-nnn` を一次情報源とし、todo.md を補助情報として併読する
A-5	あり	あり	なし	両方を必ず参照。todo.md が作業分解を持つため追記は行わない（従来どおりの挙動＝完全な後方互換）

1-3. A-3: 旧形式 design.md への `## 12. 実装タスク一覧` 追記

A-3 に該当する場合のみ、実装に着手する前に以下を順に実行してください。

手順	内容
1	design.md 全文を読み、設計章から実装単位を抽出する
2	`T-001` から採番し、下記フォーマットで項目を組み立てる。依存と完了条件は設計章から導出し、導出できない場合は「（設計書に記載なし）」と明記する
3	design.md の末尾（`## メタ情報` の直前）へ `## 12. 実装タスク一覧` を挿入する。既存セクションの番号は振り直さない（旧 design.md は番号なし見出しの可能性があるため）
4	追記した旨をユーザーへ表示する（黙って書き換えない）。文言は下記
5	工数見積もり（`## 13.`）は追記しない。本スキルの責務は実装であり、見積もりの生成は `task-design` の責務である

追記時に表示する文言:

design.md に実装タスク一覧（T-001〜T-nnn）を追記しました。この分解に基づいて実装します。

項目のフォーマット（task-design が生成するものと同一。注意点 のみ任意、他は必須）:

- [ ] `T-001` 認証ミドルウェアを実装する
  - **対象**: `src/Middleware/Auth.php`（新規・約120行）
  - **作業**: JWT 検証、失効チェック、401 応答の整形
  - **依存**: なし
  - **完了条件**: 有効・失効・不正署名の3ケースでユニットテストが通る
  - **見積もり**: 2.0h

失敗時: 実装単位を1件も抽出できない場合は、追記せず当該タスクをスキップ（区分: スキップ（成果物欠落））として扱い、/task-design の再実行を案内してください。設計書として実装に足る情報がない状態で推測実装を始めるほうが害が大きいためです。

1-4. 入力に関する異常系

ID	事象	対応
EH-7	design.md に実装タスク一覧がない	A-3 なら 1-3 の手順で追記する。A-5 は todo.md を使うため追記しない
EH-8	実装単位を1件も抽出できない	追記せずスキップ（成果物欠落）。`/task-design` の再実行を案内する
EH-9	`T-nnn` に欠番がある	正常として扱う（抽出は出現順であり連番性に依存しない）。何も表示しない
EH-9b	`T-nnn` に重複がある	警告を表示して続行する。Task 登録は design.md の記載順で行い、接頭辞には書かれている識別子をそのまま使う（勝手に振り直すと dev-result.md の `## タスク完了状況` およびレビュー指摘との突合が壊れる）。突合が曖昧になる旨を dev-result.md の「既知の課題・改善点」へ記録する
EH-10	design.md と todo.md の内容が矛盾する（A-4）	design.md を正とする。矛盾の内容を dev-result.md の「既知の課題・改善点」へ記録し、実装は design.md に従う
EH-11	追記時に design.md の書き込みに失敗	当該タスクを失敗として扱い中断する（複数タスクモードでは fail-fast 原則に従う）
EH-12	旧 `review.md` / `fix-result.md` が存在する	1回だけ告知し、読まず・変更せず・削除せず続行する（E-28 / BC-1〜BC-3）。検出した事実は `## レビュー指摘一覧` の直下へ HTML コメントで1行残す。読むと `R-nnn` の採番が壊れる（旧記録は識別子を持たない）
EH-14	`dev-result.md` が既に存在する（中断からの復帰、または実装済み）	ステップ3 の `Write` を実行する前に 1-5 で判定する。RS-B なら実装済みとして終了、RS-C なら `R-1`〜`R-9` で復元して再開、RS-D なら BC-8 の挿入経路。判定を経ずに上書きしてはならない（復帰の真実源が失われる）
EH-13	旧形式の `dev-result.md`（レビュー節を持たない）が存在する	全面上書きせず、`## メタ情報` の直前へレビュー・修正記録セクション群を挿入する（BC-8）

1-5. 中断からの復帰判定【FR-08・ステップ3 より前に必ず評価する】

dev-result.md は中断からの復帰における唯一の真実源です（LC-3）。ステップ3 は Write で全面上書きするため、上書きしてよいかを先に判定しなければ、復帰の根拠そのものを破壊します。判定は次の順で行います。

#	判定	挙動
RS-A	`<PROJECT_ROOT>/.claude/tasks/<TASK>/dev-result.md` が存在しない	通常経路。ステップ2 → ステップ3（`Write` による初期化）へ進む
RS-B	存在し、`## 終了サマリ` の `- 終了区分:` の値が 5-11 の9値のいずれかに完全一致する（下記の判定規則を満たす）	何も追記せず「実装済み」として扱い終了する（`RC-4`。冪等性はこの1点で成立する）
RS-C	存在し、`## レビュー指摘一覧` 以降のレビュー節を持つが終了区分が未記入（テンプレート由来の角括弧プレースホルダのまま、空、または9値のいずれとも完全一致しない）	中断からの復帰。ステップ2・ステップ3 を実行せず（`Write` を行わず）、5-14 の `R-1`〜`R-9` で状態を復元し、`RC-1`〜`RC-3` に従って再開する
RS-D	存在するが、レビュー節を持たない旧形式	`BC-8` / `EH-13` の経路。全面上書きせず、`## メタ情報` の直前へレビュー・修正記録セクション群を挿入する

終了区分の判定規則（RS-B / RS-C の分岐点・R-9 と共通）: - 終了区分: に続く値から前後の空白を除去し、**9値のいずれかと文字列として完全一致する場合のみ「記入済み」**とみなします。

#	値の形	判定
1	`全指摘解消` 等、9値のいずれかと完全一致	記入済み（RS-B）
2	`[` で始まる（テンプレート由来の角括弧プレースホルダ。例: `[全指摘解消 / 修正推奨のみ残存 / … / レビュー範囲不完全]`）	未記入（RS-C）
3	空、または `[未確定]` 等の任意のプレースホルダ	未記入（RS-C）
4	9値のいずれとも完全一致しない任意の文字列	未記入（RS-C。fail-safe）

部分一致で判定してはいけません。 テンプレートのプレースホルダ行は9値すべてを字面として含むため、「9値のいずれかを含むか」で判定すると、初期化直後のファイルや中断途中のファイルが必ず RS-B に一致し、未完成の実装が「実装済み」と報告されて復帰経路が到達不能になります（危険側の誤判定）。判定は常に完全一致で行い、判別できない値は未記入（＝復帰）へ倒します。

復帰時の告知【省略・要約禁止】（RC-3。黙って復帰しないこと）:

ℹ️ 中断された実行を dev-result.md から復元して再開します（完了タスク <n> 件 / 前回ループ <N> / 前回署名: <有 / 無>）。
   実装は再実行せず、未完了の実装タスクとレビュー・修正ループの続きから進めます。

復元後の分岐は R-1 に従います。未完了の実装タスクが1件でもあれば実装フェーズから再開し、完了済みタスク（- [x]）は再実装しません。すべて完了していればレビュー・修正ループの続き（R-5 が定める周回番号）から再開します。

ステップ2: テンプレート読み込み【単一タスクモード】

Readツールで、このスキルのベースディレクトリ（起動時に Base directory for this skill として提示されるパス）配下の templates/dev-result-template.md を読み込み、報告書のフォーマットを確認してください。

ステップ3: 報告書初期化【単一タスクモード】

着手前に 1-5 の復帰判定を必ず通してください。 RS-A（dev-result.md が存在しない）の場合のみ本ステップを実行します。RS-B / RS-C / RS-D では Write を行いません。

Writeツールで <PROJECT_ROOT>/.claude/tasks/$ARGUMENTS[0]/dev-result.md を作成し、テンプレートを基に、design.md の ## 12. 実装タスク一覧 から抽出した項目をチェックリスト形式に転記した内容で初期化してください。todo.md がある場合（A-4 / A-5）は、そちらの項目も統合してください。

ステップ4 の直前: 実装タスクの動的追加【FR-1】

dev-result.md 初期化（ステップ3 / フェーズ4）が完了したら、実装を始める前に、ステップ1 で抽出した各実装タスクを 1 件ずつ TaskCreate で追加してください（フォールバック時はチェックリスト項目として追加します）。以降、各タスクの着手時に in_progress、完了時に completed へ遷移させます。全タスクが completed になったことを確認してから、固定フェーズ「実装タスクを順に実装する」を completed にしてください。

subject の接頭辞は抽出元によって使い分けます:

抽出元	`subject` の形式	例
design.md の `## 12. 実装タスク一覧`（識別子あり）	`[T-nnn] <タスク名>`	`[T-003] 認証ミドルウェアを実装する`
todo.md（識別子なし）	`[todo <i>/<N>] <todo のタスク名>`	`[todo 3/9] 認証ミドルウェアを実装する`

両方を読む A-4 では T-nnn 系列を採用し、todo.md にしかない項目のみ [todo <i>/<N>] で補ってください。 TaskCreate に親子関係の指定がないため、階層は subject の接頭辞で表現します。 addBlocks / addBlockedBy は依存関係の意味論であり、階層表現には使いません。

件数 <N> は実行時に入力ファイルを読んで初めて判明するため、件数は固定せず「各タスクを追加せよ」という指示の形を取ります。
--team 有効時は、担当チームメイト名を description に付記し、チームリード（あなた）の Task 一覧で進捗を追跡します。
複数タスクモードの場合は、todo.md の個々の実装タスクではなく 対象タスク名そのもの （<TASK> ごとに 1 件）を subject = [task <i>/<N>] <TASK> を実装する として登録してください。 todo.md の各実装タスクの追跡は、委譲先のサブエージェントが自身の応答内で行います（サブエージェントによる Task ツールの利用は禁止します）。

ステップ4: 実装【単一タスクモード】

実装タスク一覧（T-nnn）の採番順に実装を進めてください。todo.md がある場合は、その順序との差異を確認したうえで design.md を優先します（EH-10）。

実装が終わったら、dev-result.md の実装セクション（## 実装概要 / ## 変更ファイル一覧 / ## 技術的な実装詳細 / ## パフォーマンスとセキュリティ / ## 既知の課題・改善点 / ## 動作確認結果）を書き上げてください。ここまでが実装フェーズです。

権限の切替線【実装フェーズ ↔ レビュー・修正フェーズ】

境界の位置: 「実装フェーズの最後の T-nnn が完了し、dev-result.md の実装セクション（実装概要・変更ファイル一覧・技術的な実装詳細）を書き終えた時点」。

モード	具体的な位置
単一タスクモード	ステップ4（実装）の完了直後、ステップ5（レビュー・修正ループ）の開始前
複数タスクモード	タスクごとに引かれる。実装委譲が `status: "success"` の検証済みオブジェクトを返した直後、当該タスクのコミットの前

観点	実装フェーズ	レビュー・修正フェーズ
成果物への権限	`dev-result.md` を新規作成・全面上書き。実装コードは `T-nnn` の範囲で自由に作成・変更	`dev-result.md` は末尾追記のみ（＋ W-3 / W-6 が許す限定編集）。コードは未解決の `R-nnn`（修正必須）に紐づく箇所のみ変更可
`--team` の適用範囲	適用対象（依存関係のないタスクを並行実装）	レビューにのみ適用（観点3分割 = 3体）。修正フェーズは対象外（単一エージェント逐次）
判定の入力	req.md / design.md / todo.md / 既存コード / 実装フェーズの全文脈	req.md / design.md / 対象ファイルのパス / レビュー観点のみ（RP-1〜RP-12）。実装フェーズの文脈は入力にも却下の根拠にも用いない
委譲	単一（`--team` 無効）: 行わない／単一（`--team` 有効）・複数: 実装そのものを委譲（必須）	レビューは委譲が必須（RI-1。`name` なしの同期 `Agent` 委譲）。修正は単一主体が行い、並列委譲を禁止

この非対称が必要な理由: レビュー・修正フェーズが全面上書きの権限を持つと、各周で前周の指摘・却下理由・署名が消え、監査可能性（EA-2）と終了保証がともに失われます。判定の入力を絞らなければ、レビューの構造的隔離が「読まないでください」という指示に退化します。

ステップ5: レビュー・修正ループ【両モード共通の規約】

実装フェーズの完了後、レビュー → 修正 → 再レビューのループを最大2周まで自動実行します（2周目は1周目で 修正必須 が残った場合にのみ実行します）。単一タスクモードではチームリード（あなた）がこの節に従って直接ループを回し、複数タスクモードではタスクごとにこの節の規約を委譲先へ埋め込んで実行させます（ステップ6-3）。

5-1. コスト警告 W-A【省略・要約禁止・確認入力は求めない】

実装に着手する前（単一タスクモードは pwd の直後、複数タスクモードは事前検証の後・件数表示の前）に、次を必ず表示してください。トークンを費やす前に予算を告知することが目的であるため、生成・実装のあとに出しても意味を持ちません。

この警告は実装着手前に出すため対象ファイル数が未確定です。したがって実測値ではなくプロファイルの固定値を示します。

⚠️ 本スキルは実装のあと、レビュー → 修正 → 再レビューのループを最大 2 回まで自動実行します。
   2 回目は 1 回目で修正必須の指摘が残った場合にのみ実行します。
   レビューは毎周サブエージェントへ同期委譲するため、実装のみを行う場合に比べてトークン消費が
   おおむね 1.3〜1.8 倍（--team 指定時は 2〜3 倍）になります。
   対象: <TASK 一覧（複数タスクモードでは件数も）> / 上限ループ: 2 回
   レビュー担当: 1 体（--team 指定時は 3 体）
   レビューを省略する導線は提供していません。実装のみを行うことはできません。

体数は 5-6-9 のプロファイル表の固定値です（--team 無効: 1 体、有効: 3 体）。ファイル数・行数に応じた分割ファンアウトは行いません。

各レビューパスの開始時には、警告記号を使わない進捗行を1行だけ出します:

ℹ️ レビュー <n>/2 を実行します（対象: <m> ファイル / 観点: <p> = <k> 体 / 前周の未解決: <j> 件）

パス完了時は、未受領体数または未確認範囲が 0 でないときだけ次の1行を出します（0 件なら出力しません）:

ℹ️ レビュー <n>/2: <k> 体中 <u> 体が未受領でした（未検査の範囲は dev-result.md に記録しています）

ポーリング禁止: 委譲の完了を待つあいだ、スキル本体は何も表示しません（「待っています」の類を出さない）。1パスあたり出すのは、開始時の進捗行（1行）と終了時の未受領・未確認の告知（0件なら省略）のみです。

5-2. レビュー委譲器（RI-1〜RI-8）・委譲の degrade 梯子（D-1〜D-4）

問題の定式化: 実装時に「この設計で要件を満たす」と結論した主体がレビュー時に「満たしていない」と言うのは直前の自分の結論の否認であり、過少指摘（危険側）が構造的に優勢になります。被害は「要件未充足・脆弱性を含んだ実装が、レビュー済みという記録つきでコミットされること」です。

#	規則
RI-1（必須）	レビューは必ず別コンテキストへ委譲する。経路は `name` を付けない同期 `Agent` 委譲（`subagent_type: "general-purpose"` ／ `run_in_background: false`）ただ1つ。`--team` の有無にかかわらず1体以上を起動する。メイン会話が自らレビューしてよいのは梯子 `D-3` の degrade 経路のみ。`name` 付き spawn へは決してフォールバックしない（`name` 付き＝バックグラウンド実行であり、成果が tool result で返らない）
RI-2	委譲プロンプトへ含めてよいのは RP-1〜RP-12 のみ（5-3 の限定列挙）。「渡してはならないもの」の情報を1項目でも含めた時点で隔離は失効する
RI-3	2周目以降に渡す前周情報は `R-nnn` / 1行要約 / 状態（解消済 / 未解消）に限る。却下理由・優先度の変更理由・修正の難易度は渡さない
RI-4	委譲先の戻り値はそのまま採用する。メイン会話が指摘を削除・降格することは禁止する。異議は却下手続き（RI-7）でのみ行える
RI-5	`--team` は「並列体数と観点分割のプロファイル選択」を意味する（5-6-9）。有効時は観点3分割で 3体、無効時は1体が観点①〜⑤すべてを担当する。有効時の3体は同一メッセージ内に3つの `Agent` 呼び出しを並べて並列起動する。ファイル数・行数に応じた分割ファンアウトは行わない。メイン会話が行ってよいのは重複排除・優先度の統一・`R-nnn` の採番統一のみであり、指摘の取捨選択は行わない
RI-6	複数タスクモードでもレビュー委譲を行う。修正も別の同期 `Agent` 委譲として切り出し、メイン会話はループ制御・記録・コミットのみを担う
RI-7	却下する場合、根拠類型 ID（J-1〜J-5）と外部参照可能な証拠を `dev-result.md` へ必ず記載する。証拠を書けない却下は却下として認めず、未解決の修正必須として扱う（fail-safe）
RI-8	修正フェーズは単一エージェントが行う（`--team` 適用外）。共有資源の競合と終了保証の不成立を避けるため

RI-6 の根拠: 複数タスクモードのメイン会話は実装の status / files / summary しか受け取っておらず、実装の内心を一度も保持していないため、単一タスクモードよりも隔離が構造的に強くなります。

委譲の degrade 梯子（D-1〜D-4）: 異常系はすべてこの梯子のどの段への遷移かとして表現します（5-17 の E-nnn は遷移の引き金を述べるだけです）。

段	経路	発動条件	告知	記録
~~D-1~~	欠番（Dynamic Workflows の廃止により消滅。ID は再利用しない）	—	—	—
D-2	`name` を付けない同期 `Agent` 委譲（主経路）	既定	なし	`- レビュー体制: 同期 Agent 委譲（<n> 体 / うち未受領 <m> 体）`
D-3	自己レビュー（単一タスクモードのみ）	D-2 も不成立	必須（5-18 告知②）	`自己レビュー（degrade: <理由>）`
D-4	レビュー未実施のまま終了（複数タスクモードのみ）	D-2 も不成立	必須（5-19 経路⑦）	終了区分 `レビュー未実施（委譲不成立）`

なぜ D-2 を主経路へ格上げし、番号を詰めないのか: 本リポジトリは識別子の再利用を禁じています。D-1 を「同期 Agent 委譲」へ再定義すると、過去タスクの dev-result.md に残る degrade: D-1 → D-2 の記録が別の意味になり、監査可能性が壊れます。欠番は許容されています。

D-3 / D-4 をモードで分ける根拠: 複数タスクモードで自己レビューへ落とすと req.md と全変更ファイルがメイン会話へ流入し、このモードの存在意義（コンテキストの線形累積の回避）が失われます。逆に単一タスクモードは既に実装文脈を保持しており、かつ git を操作しないため「未レビューのコードがコミットされる」危険が構造的に存在しません。

name 付き Agent spawn へは決してフォールバックしません（成果が tool result で返らないレーンであり、本スキルが是正した閉塞そのものであるため）。

チームメイト／委譲先への依頼時の禁止事項: 「重大なものだけ挙げてください」「些細な指摘は不要です」等の指摘を抑制する方向のバイアス注入を禁止します。「実装者は熟練している」「設計どおりに実装されているはず」等の事前の品質評価を伝えることを禁止します。指摘件数の上限・目安を伝えることを禁止します（B-1 の対象範囲の上限は伝えてかまいません。入力の範囲であって出力の抑制ではないためです）。

5-3. 委譲プロンプトの構成（RP-1〜RP-12）

入力の隔離を「指示」ではなく「構造」として成立させるため、プロンプトは次の12項目のみで構成します。列挙にないものを足さないことが規約です。 逐語の本文は 5-6-2 の逐語ブロックが正本であり、本表は「何を含めるか・なぜ含めるか」の索引です。

#	埋め込む項目	隔離上の位置づけ
RP-1 / RP-2	プロジェクトルートの絶対パス／対象タスク名 `<TASK>`	必須
RP-3	`req.md`（必須）/ `design.md`（必須）/ `todo.md`（存在する場合のみ）の絶対パス	`dev-result.md` を渡さない
RP-4	レビュー対象ファイルのパス一覧（RS-1〜RS-4 で確定した集合）＋観点④⑤向けの変更行範囲（`src/A.php: 120-168, 210-215` の形式。`RS-5` で算出）	渡すのはパスと行範囲のみ。差分本文（`git diff` の `-` / `+` 行）・実装意図・変更理由は渡さない。行範囲は `git diff --unified=0` から誰でも同一値を得られる客観状態であり、実装担当の内心ではない
RP-5	レビュー観点（5-5。`--team` 時は担当分のみ）＋「観点①②③は変更行範囲に限定せず、ファイル全体と req.md / design.md を突き合わせること」の明記	必須。①②③は「あるべきコードが存在しないこと」を欠陥とするため、変更行だけを見ると原理的に検出できない。行範囲を重点範囲として使ってよいのは観点④⑤に限る
RP-6	実装タスク一覧の消費契約（`## 12.` の検出手順・`T-nnn` の抽出規則）	完了照合のため
RP-7 / RP-8	欠陥類型の固定語彙（5-7）／優先度の判定基準（高＝必須 / 中・低＝推奨）	署名の安定性と停止条件の機械判定に必須
RP-9	戻り値フォーマット（5-6-1）の逐語提示。「応答の最後に ```json フェンスを1つだけ出力する」「前置きの散文を書かない」を明記する	必須。ツール層のスキーマ強制が無いため、形式の逐語規定がそのまま契約になる
RP-10 / RP-11	禁止事項（5-4）／「コードを修正してはならない（読み取りと報告のみ）」	修正はメイン会話の責務。委譲先が直すと `R-nnn` と修正の対応が失われる
RP-12	レビューできた範囲／できなかった範囲の申告（`coverage.reviewedPaths` / `unreviewedPaths` / `unreviewedReason`）	「指摘0件」と「未確認」を区別する唯一の手段。時間や件数の制約を課していないことも併せて伝える

渡してはならないもの（隔離の実体）:

禁止入力	理由
`dev-result.md` の内容（実装概要・技術的詳細・動作確認結果）	実装担当の自己申告。「こう実装した理由」を読むと指摘が抑制される
実装フェーズで検討し捨てた代替案・トレードオフ	直前の自分の結論の追認になる
前周の却下理由・優先度の変更理由・修正の難易度	渡すと再指摘が抑止され、停滞検知が「収束」に見せかけられる
「軽微な指摘は不要」等の抑制指示、指摘件数の目安・上限	過少指摘（危険側）へのバイアス注入
総合判定の期待値・「問題ないはず」といった前置き	同上
メイン会話の会話履歴・他タスクの情報	隔離の失効
差分本文（`git diff` の `-` / `+` 行）	削除された旧実装が含まれ、「何をやめたか」から実装意図を再構成できる。渡すのは行範囲（客観状態）までであり、変更された値そのものは渡さない

dev-result.md を渡さないことが本設計の要です。 変更ファイル一覧は dev-result.md からパスの配列としてだけ抽出して渡してください。これにより隔離が「読まないでください」という指示ではなく「そもそも渡らない」という構造になります。

2周目以降に渡してよい前周情報は R-nnn / 1行要約 / 状態（解消済 / 未解消） に限ります（RI-3）。あわせて RS-0 の指示（「前周の指摘の解消確認と、修正差分に起因する新規欠陥のみを見る。新しい観点でのレビューは行わない」）を明記します。

5-4. 委譲先への禁止事項（プロンプトへ逐語で埋め込む）

(1) ファイルの作成・編集・削除を一切行わない（Write / Edit / NotebookEdit 禁止。読み取り専用のレビューであるため） (2) git の状態を変更する操作を一切行わない (3) 他タスクのディレクトリに触れない (4) 進捗管理用の Task ツールを使用しない（タスクリストはセッション単位で共有されるためメイン会話の進捗表示を汚染する） (5) AskUserQuestion を使用しない（サブエージェントの承認はユーザーの承認ではない。判断が必要な点は結論を出さず指摘として報告する） (6) さらに別のサブエージェントを spawn しない (7) 修正を提案するにとどめ、修正を実施しない。

5-5. レビュー観点

①要件定義との整合性（req.md の各要件が正しく実装されているか） ②設計書との整合性（design.md のアーキテクチャ・コンポーネント設計に従っているか） ③実装タスクの完了状況（T-nnn。todo.md があればその項目も従来どおり照合） ④コード品質（可読性・保守性・エラーハンドリング・テストの有無と網羅性） ⑤セキュリティ・堅牢性。

--team 時の3体は ①②＋③ / ④ / ⑤ に分割します（「役割分担」節を参照）。

5-6. 委譲の戻り値契約（```json フェンス）

委譲先には「応答の最後に、```json フェンスで囲んだオブジェクトを1つだけ出力すること」を逐語で要求します。スキル本体は最後の ```json フェンスを取り出してパースし、RV-1〜RV-6 で検証します（最後のフェンスを採るのは前置き散文が混入しても壊れないための規定であり、散文を許可する意味ではありません）。

戻り値は「検証済みオブジェクト」か「未受領」の2値に狭まります。未受領は「利用者のスキップ」または「終端エラー」であり、両者は区別できません。したがって未受領の判定根拠は「リトライを尽くしても成果を受領できなかった」事実ただ1つです（実時間予算・ターン数ベースの打ち切りは設けません）。

5-6-1. 戻り値のフォーマット【逐語・委譲プロンプトへそのまま埋め込む】

レビュー戻り値:

{
  "status": "success",
  "coverage": {
    "reviewedPaths": ["src/A.php"],
    "unreviewedPaths": [],
    "unreviewedReason": "none"
  },
  "findings": [
    {
      "localId": "L-1",
      "priority": "高",
      "defectClass": "security",
      "path": "src/A.php",
      "symbol": "validateToken",
      "basisKind": "requirement_id",
      "basisAnchor": "FR-3",
      "basisQuote": "（req.md からの原文引用）",
      "detail": "（欠陥の説明）",
      "fix": "（修正方針）"
    }
  ],
  "summary": "（1〜2文の要約）"
}

上記の全キーが必須（findings は0件なら空配列、findings[] は10キーすべて必須）。任意キーは status: "failure" 時の reason と unreviewedReason: "other" 時の coverage.note のみ。

キー	語彙・規定
`status`	`success` / `failure`
`coverage.*Paths`	リポジトリ相対パスの配列。`reviewedPaths` = 実際に全体を読んだもの、`unreviewedPaths` = 割り当てられたが検査できなかったもの
`coverage.unreviewedReason`	`none` / `budget_exceeded` / `unreadable` / `generated_or_vendored` / `context_limit` / `other`
`localId`	`L-<正整数>`。`R-nnn` を返してはならない（採番は呼び出し元の責務）
`priority`	`高` / `中` / `低`
`defectClass`	5-7 の閉じた9値
`path`	リポジトリ相対パス。行番号を付けない
`symbol`	最も内側の関数／クラス／メソッド名。Markdown は最も近い見出しテキスト。該当なしは空文字
`basisKind`	`requirement_id` / `design_section` / `code_line`
`basisAnchor`	根拠のアンカー（要件 ID・設計節番号・`path:line`）。署名のハッシュ入力
`basisQuote`	根拠の原文引用（散文。ハッシュ非対象）

総合判定・指摘件数のキーは置きません。 総合判定は呼び出し元が findings[].priority から導出します（理由は 5-6-4）。

実装戻り値: status（success / failure）/ files[]（変更したファイルのリポジトリ相対パス。必須。空配列可）/ summary。任意キー reason / completedTaskIds[] / incompleteTaskIds[]。

修正戻り値: status / files[]（必須）/ dispositions[]（各要素は rId / disposition が必須、任意で rejectionClass / evidence / changedPaths[] / note）。任意キー reason / budgetUsed。

5-6-2. 委譲プロンプトの逐語ブロック【この3ブロックが正本】

RP-1〜RP-12 と 5-4 の禁止事項の逐語の正本は本節の3ブロックです。要約・省略・整形の変更を行わないこと。 <...> の箇所のみを実際の値へ置換します。

(a) レビュー委譲プロンプト（--team 有効時は担当A / B / C ごとに1通ずつ、同一メッセージ内に並べて送出する）:

あなたはコードレビュー担当です。以下の範囲だけをレビューし、指定のフォーマットどおりに返してください。

プロジェクトルート: <PROJECT_ROOT>
対象タスク: <TASK>
読んでよい仕様: <PROJECT_ROOT>/.claude/tasks/<TASK>/req.md（必須） / <PROJECT_ROOT>/.claude/tasks/<TASK>/design.md（必須）<todo.md がある場合のみ「 / <TODO_PATH>（存在する場合のみ）」を付す>

【レビュー対象ファイル（このパスのみ。差分本文・実装意図・変更理由は与えない）】
- <path 1>
- <path 2>

【変更行範囲（観点④⑤の重点範囲。git diff --unified=0 から機械的に得られる客観情報である）】
- <path 1>: 120-168, 210-215
- <path 2>: 3-9

【レビュー観点（担当分のみ）】<担当の観点>
観点①②③は変更行範囲に限定せず、ファイル全体と req.md / design.md を突き合わせること（あるべきコードが存在しないことを検出するため）。変更行範囲を重点範囲として使ってよいのは観点④⑤のみである。

【実装タスク一覧の消費契約】design.md 内で `実装タスク一覧` を含む `## ` 見出しから次の `## ` 見出しの直前までを範囲とし、`T-nnn` を含む `- [ ]` 行を出現順に抽出して完了照合に用いること。

【欠陥類型（この 9 値のみ。判別不能は other）】requirement_unmet / design_deviation / task_incomplete / correctness / security / error_handling / test_missing / maintainability / other
総合判定は返さないこと（呼び出し元が優先度から機械的に導出する）。優先度（priority）は欠陥類型の既定値を下限とし、既定より重いと判断した場合にのみ引き上げて申告してよい（引き下げは呼び出し元が既定へ戻す）。

【前周の指摘（解消確認の対象）】  ← 2 周目のみ。1 周目では丸ごと省く
- R-001 [未解消] <1 行要約>
2 周目以降は新規観点でのレビューを行わない。前周の指摘の解消確認と、修正差分に起因する新規欠陥のみを見ること。

【範囲の申告（必須）】割り当てられたファイルのうち実際にレビューし終えたものを coverage.reviewedPaths へ、確認できなかったものを coverage.unreviewedPaths へ、理由（coverage.unreviewedReason）つきで必ず申告すること。指摘 0 件と未確認は別物である。時間や件数の制約は課していない。

指摘件数の上限・目安はない。重大なものだけを挙げる、軽微な指摘を省く、といった抑制は行わないこと。

【戻り値フォーマット（厳守）】応答の最後に ```json フェンスで囲んだオブジェクトを 1 つだけ出力すること。前置きの散文を書かず、フェンスの外に説明を書かないこと。パスはリポジトリ相対で書き、行番号を付けないこと。
<5-6-1 のレビュー戻り値の JSON 例をそのまま貼る>

【禁止事項（逐語）】(1) ファイルの作成・編集・削除を一切行わない（Write / Edit / NotebookEdit 禁止。読み取り専用のレビューである） (2) git の状態を変更する操作を一切行わない (3) 他タスクのディレクトリに触れない (4) 進捗管理用の Task ツールを使用しない (5) AskUserQuestion を使用しない（判断が必要な点は結論を出さず指摘として報告する） (6) さらに別のサブエージェントを spawn しない (7) 修正を提案するにとどめ、修正を実施しない。

(b) 実装委譲プロンプト（--team 有効時の単一タスクモード、および複数タスクモードで用いる）:

あなたは実装担当です。指定された実装タスクだけを実装してください。

プロジェクトルート: <PROJECT_ROOT>
対象タスク: <TASK>
読み込むファイル: <PROJECT_ROOT>/.claude/tasks/<TASK>/design.md（必須）<todo.md がある場合のみ「 / <TODO_PATH>（存在する場合のみ）」を付す>

【担当する実装タスク】<T-nnn> <タスク名>
<対象 / 作業 / 依存 / 完了条件 / 注意点>

【触ってよいファイル】
- <path 1>
- <path 2>
他のチームメイトが同じファイルを編集しているため、上記以外のファイルを変更しないこと。

【戻り値フォーマット（厳守）】応答の最後に ```json フェンスで囲んだオブジェクトを 1 つだけ出力すること。前置きの散文を書かないこと。キーは status（success / failure）, files（変更したファイルのリポジトリ相対パスの配列。必須・空配列可）, summary（1〜2 文）。任意で reason, completedTaskIds, incompleteTaskIds。

【禁止事項（逐語）】git の状態を変更する操作を一切行わない（コミットは呼び出し元の責務）。他タスクのディレクトリに触れない。進捗管理用の Task ツールを使用しない。AskUserQuestion を使用しない。さらに別のサブエージェントを spawn しない。dev-result.md の `## レビュー指摘一覧` 以降には一切書き込まない。

(c) 修正委譲プロンプト（単一エージェント・並列化禁止）:

あなたは修正担当です。以下のレビュー指摘に紐づく箇所だけを修正してください。

プロジェクトルート: <PROJECT_ROOT>
対象タスク: <TASK>

【修正対象の指摘】
- <R-nnn> [<defectClass>] <path>#<symbol>
  根拠: <basisQuote>
  内容: <detail>
  修正方針: <fix>

【書き込み禁止対象（逐語）】.git/** / .claude/tasks/<TASK>/req.md / .claude/tasks/<TASK>/design.md / 他タスクのディレクトリ / プロジェクトルートの外 / node_modules/** / vendor/** / .env 等の認証情報・秘密鍵・証明書・トークン / ロックファイルの手編集。これらの変更を要する指摘は修正せず dispositions へ held_safety（保留（安全境界））または held_judgment（保留（要判断））として、evidence つきで返すこと。

【操作予算】1 指摘あたりのツール呼び出し 12 回、修正フェーズ全体で 60 回。超過した指摘は dispositions へ budget_aborted（打ち切り（修正予算超過））／budget_untouched（未着手（修正予算超過））として返すこと。

【戻り値フォーマット（厳守）】応答の最後に ```json フェンスで囲んだオブジェクトを 1 つだけ出力すること。前置きの散文を書かないこと。キーは status, files（変更したファイルのリポジトリ相対パスの配列。必須・空配列可）, dispositions（各要素は rId と disposition が必須。disposition は fixed / recorded_only / held_judgment / held_safety / held_scope / rejected / budget_aborted / budget_untouched のいずれか。任意で rejectionClass, evidence, changedPaths, note）。任意で reason, budgetUsed。

【禁止事項（逐語）】git の状態を変更する操作を一切行わない。他タスクのディレクトリに触れない。進捗管理用の Task ツールを使用しない。AskUserQuestion を使用しない。さらに別のサブエージェントを spawn しない。dev-result.md へ書き込まない（記録は呼び出し元が行う）。レビュー指摘に紐づかない箇所を変更しない。

5-6-3. 戻り値の検証手順（`RV-1`〜`RV-6`）と丸め規則

ツール層のスキーマ強制が無いため、検証はスキル本体の責務です。語彙外・欠落を黙って正規化することを禁止し、丸めた事実は必ず記録します。

#	手順
RV-1	応答本文から最後の ```json フェンスの中身を取り出す。フェンスが1つも無ければ、応答全体を JSON としてパースできる場合に限り採用し、できなければ `E-36`
RV-2	JSON としてパースする。失敗すれば `E-36`
RV-3	必須キーの存在と型を検証する（5-6-1 の表）。次の正規化は逸脱として扱わない: ①`path` / `reviewedPaths` / `unreviewedPaths` が絶対パスの場合は `<PROJECT_ROOT>/` 接頭辞と `./` を除去してリポジトリ相対へ直す ②`path` に `:` を含む要素は行番号付きとみなし `:` 以降を切り捨てる（`H-3` と同じ正規化）③キーの出現順の違い
RV-4	語彙を検証し、語彙外は下表の丸め規則で吸収する（`disposition` のみ丸めず `E-36`）
RV-5	`RV-1`〜`RV-3` の不合格は `E-36` として1回だけ再委譲する。再委譲のプロンプトは初回と同一とし、「前回の応答が形式不正だった」という情報のみを1行付す（指摘内容へのフィードバックは行わない＝隔離を保つ）
RV-6	再委譲後もなお不合格なら、当該体を未受領として扱う（`E-13` と同じ経路。`incomplete_scope = true`）。「形式が悪いから無視する」ではなく「検査されなかった」として記録する（fail-safe）

丸め規則（fail-safe）: 語彙外の値は危険側へ倒さない向きへ丸めます。

キー	語彙外の値を受け取った場合	向き
`priority`	`高` として扱う	過少指摘を防ぐ（安全側）
`defectClass`	`other` として扱う。ただし優先度は `max(other の既定=低, 申告 priority)` で採るため、申告が `高` なら `高` のまま残る	既存の「採用値 = max(既定, 申告)」規則で自然に安全側へ倒れる
`basisKind`	`code_line` として扱う（`basisAnchor` が要件 ID・設計節番号の書式に合致する場合のみ `requirement_id` / `design_section` へ寄せる）	署名の入力は `basisAnchor` であり `basisKind` ではないため、停滞判定に影響しない
`unreviewedReason`	`other` として扱う	影響は記録のみ
`disposition`	形式逸脱として扱う（`E-36`）。丸めない	誤って `fixed` へ倒すと未修正が解消として記録される

丸めた事実は ### ループ N の - 丸め: 行へ記録します（silent な正規化の禁止）。

5-6-4. 総合判定をキーに置かない理由と、その導出規則

戻り値に総合判定のキーを置きません。集約値をキーとして持たせると「指摘は高だが総合判定は修正推奨」という自己矛盾値を受け取りうるためです。真実源を findings[].priority ただ1つに保つには、キーを置かないことが唯一の構造的解です。指摘件数のキーも置きません（findings の長さが件数です）。

総合判定の導出規則（呼び出し元）:

priority 高 が1件以上（未解決）      → 総合判定: 修正必須
高 0件 かつ 中／低 が1件以上        → 総合判定: 修正推奨
いずれも0件                         → 総合判定: 修正不要

優先度の採用規則: 採用値 = max(欠陥類型の既定優先度, 申告された priority)（高 > 中 > 低）。既定より高い申告は無条件に採用（引き上げは自由）、既定より低い申告は既定へ引き上げて採用します。呼び出し元が既定より引き下げる場合のみ 5-10 の監査対象（- 区分変更: 行）とします。これにより委譲先の優先度操作による停止条件の回避が封じられます。

5-6-5. 未確認範囲の判定規則（`CV-1`〜`CV-6`）

coverage は必須キーであり、本契約で最も重要な意味論である。

#	規則
CV-1	呼び出し元は委譲時に割り当てたパス集合 `assigned` を保持する（戻り値側には持たせない。自己申告にしないため）
CV-2	実効未確認範囲 `unreviewed = coverage.unreviewedPaths ∪ (assigned − coverage.reviewedPaths)` とする。`reviewedPaths` にも `unreviewedPaths` にも現れないパスは未確認として扱う（fail-safe）
CV-3	`coverage` に「完全に見た」を表す真偽キーは置かない。完全性は `unreviewed.length === 0` として呼び出し元が算出する（自己申告の真偽値は必ず `true` に倒れるため）
CV-4	`findings.length === 0` かつ `unreviewed.length > 0` の戻り値は、通常の正常終了として扱わない。終了区分は `レビュー範囲不完全` とする
CV-5	`unreviewed` は `dev-result.md` の `### ループ N` の `- 未確認範囲:` 行と `## 終了サマリ` の両方へパス一覧で記録する。件数だけの記録は認めない
CV-6	`unreviewedReason: "budget_exceeded"` が返った場合は `B-1` の上限に触れたシグナルであり、`E-33` の経路（パスで全件列挙・`incomplete_scope = true`）へ回す

5-6-6. 実装委譲の戻り値規則（`IM-1`〜`IM-5`）

#	規則
IM-1	`files` は必須キー。複数タスクモードの `C-9` / `C-11` のコミット対象集合は `files ∪ 修正委譲の files ∪ dev-result.md` の和集合として成立する。`git add -A` の禁止（`C-1`）を維持するには、この集合が戻り値から得られることが必須条件である
IM-2	`status: "failure"` でも `files` は必須（空配列可）。中断時の残存変更の告知（`G-3` / `E-12`）に使う
IM-3	`files` に `.claude/tasks/<TASK>/dev-result.md` が含まれない場合、呼び出し元が補完してステージする（`C-3` を維持）
IM-4	`completedTaskIds` / `incompleteTaskIds` は任意。得られた場合のみ `## タスク完了状況` のチェックボックス初期値に用い、得られなければ `dev-result.md` の記載を正とする
IM-5	未受領（リトライを尽くしてなお成果が返らない）は本規則の検証以前の事象であり、成果物による完了判定（`E-7`）へ入る。形式逸脱（`E-36`）はこの経路の入口にならない（再委譲を1回挟んだうえで未受領へ合流する）

5-6-7. 修正委譲の戻り値規則（`FX-1`〜`FX-5`）

#	規則
FX-1	`files` は必須。`LC-5`（無変更による即中断・`S-5`）の主判定は `files.length === 0` とする。委譲後は呼び出し元が `Edit` / `Write` を直接観測できないため、この戻り値が主判定の唯一の源になる（複数タスクモードの `git status --porcelain` は補助検証）
FX-2	`dispositions[].rId` は呼び出し元が渡した `R-nnn` のみを許す。委譲先が新規 `R-nnn` を採番することはない（5-7 の採番主体の本則）
FX-3	`disposition: "rejected"` かつ `evidence` が空文字の戻り値は、呼び出し元が却下として認めず未解決の修正必須へ戻す（`RI-7` の fail-safe。必須キーにしないのは、書けない却下を「返せない」のではなく「返させたうえで棄却する」ほうが証跡が残るため）
FX-4	`disposition` の8値は 5-10 の `- 対応:` 固定語彙と1対1で対応する。書き戻し時の対応表: `fixed` → `修正済（ループN）` / `recorded_only` → `記録のみ（推奨のため自動修正しない）` / `held_judgment` → `保留（要判断）` / `held_safety` → `保留（安全境界）` / `held_scope` → `保留（スコープ外）` / `rejected` → `却下（J-n: 根拠）` / `budget_aborted` → `打ち切り（修正予算超過）` / `budget_untouched` → `未着手（修正予算超過）`
FX-5	`changedPaths` は `files` の部分集合であること。整合しない場合は `files` を正とする（コミット対象集合の欠落を防ぐため）

5-6-8. `Agent` 呼び出しの契約とリトライ（`BK-1`〜`BK-5`）

引数	渡すもの	備考
`prompt`	5-6-2 の逐語ブロックから組み立てた文字列	正本は 5-6-2 の逐語ブロック。要約・省略を禁止する
`subagent_type`	`"general-purpose"`	レビューは読み取りのみだが `Explore` は「抜粋を読む探索器」であって監査には足りないため採らない。書き込み能力は 5-4 の禁止事項の逐語埋め込みで抑止する
`name`	付けない	`name` 付きはバックグラウンド実行となり、成果が tool result で返らない
`run_in_background`	`false`	同上
`description`	`review:L<loop>:<観点キー>` / `impl:<T-nnn>` / `fix:L<loop>`	進捗表示とリトライの識別に用いる。停滞判定の署名には使わない
`model` / `effort`	指定しない	セッションモデルを継承する設計原則に従う

--team 有効時の3体は、同一メッセージ内に3つの Agent 呼び出しを並べて起動します（並列実行）。

リトライの仕様（BK-1〜BK-5）:

#	仕様
BK-1	未受領時のリトライは最大3回、待機は 15秒 / 60秒 / 180秒（1回あたり最長180秒）。`Agent` 呼び出しは初回を含め最大4回
~~BK-2~~	欠番（ジッタ。最大3体では衝突を散らす必要がなく、再開の決定論性の要求も消えたため廃止）
~~BK-3~~	欠番（BK-2 のハッシュ実装）
BK-4	待機手段が使えない場合（前景の `sleep` が拒否される等）は、待たずに直ちに再委譲する（試行回数は保つ）。未受領の回復条件は待ち時間ではなく新しい委譲そのものであるため
BK-5	リトライ対象は未受領のみ。`E-36`（形式逸脱）の再委譲は `BK-1` の回数に数えない（別枠で1回）

5-6-9. `--team` プロファイル

	観点分割	体数	1体あたりの担当量（`B-1`）
`--team` 無効	1（①〜⑤ を1体が担当）	1 体	40 ファイル / 6,000 行
`--team` 有効	3（A: ①②③ / B: ④ / C: ⑤）	3 体	40 ファイル / 6,000 行

ファイル数・行数に応じた分割ファンアウトは行いません。 体数は上表の 1 体または 3 体に固定です。
B-1 の上限を超える割り当てが生じた場合は、変更行数の多い順に上限まで採り、残余を 未レビュー（予算超過） として dev-result.md へパスで全件列挙し incomplete_scope = true を立てます（E-33・silent cap の禁止）。
削るのは対象ファイルであって観点ではありません。 観点を削ると検査そのものに穴が空き、危険側へ倒れます。

5-7. 欠陥類型と安定識別子 `R-nnn`

採番規約【本則・--team の有無を問わず適用】:

項目	規定
書式	`R-nnn`（3桁ゼロ埋め・`R-001` から）
採番順	検出順（ループ内は指摘の出現順）
欠番	許容する
重複	禁止
追番	「その時点で存在する最大値 + 1」。既存番号は振り直さない
再利用	削除した ID は再利用しない
採番主体	呼び出し元（メイン会話）が一元的に行う。委譲先のレビュー担当に `R-nnn` を振らせない

なぜ採番主体を本則に固定するか: レビュー担当は入力隔離により前回の指摘を知らず、同じ欠陥を毎ループ「新規」として報告します。呼び出し元が ID を継承しないと署名が毎ループ別物になり停滞判定が原理的に働きません。

「実質同一」の判定基準（継承の条件）: 次の3要素がすべて一致した場合に実質同一とみなし、既存 ID を継承します。

要素	正規化	一致条件
対象ファイル	リポジトリ相対パス（`<PROJECT_ROOT>` 接頭辞と `./` を除去）	完全一致
対象シンボル	最も内側の関数／クラス／メソッド名。Markdown では最も近い見出しのテキスト（連番を除去: `## 12. 実装タスク一覧` → `実装タスク一覧`）	完全一致
欠陥類型	下記の閉じた語彙	完全一致

継承の妨げにしないもの: 行番号の変化、要約・詳細の言い回しの違い、優先度の見解差。 別 ID とするもの: 同一ファイル・同一シンボルでも欠陥類型が異なる場合（修正の当たり所が別であり、片方だけ解消しうるため）。

欠陥類型の語彙（この9値のみ。判別不能は other）:

値	意味	既定の優先度
`requirement_unmet`	req.md の要件が未実装・部分実装	高
`design_deviation`	design.md の設計・規約と異なる実装	高
`task_incomplete`	`T-nnn`（または todo.md 項目）が未完了	高
`correctness`	ロジック誤り・境界条件・状態遷移の誤り	高
`security`	入力検証・認証認可・秘密情報の露出	高
`error_handling`	例外・失敗経路の未処理	中
`test_missing`	テストの欠落・網羅不足	中
`maintainability`	可読性・重複・命名・抽象化	低
`other`	上記に当てはまらない	低

語彙を閉じるのは、自由記述だと類型が毎回変わり署名が別物になるためです。副次的効果として優先度の恣意的な操作を封じます。英語スネークケースとしたのは、日本語だと中黒・長音・送り仮名の表記ゆれで署名が不安定になるためです。

5-8. 停滞判定の署名（H-1〜H-7）

fingerprint = "<R-nnn>|<欠陥類型>|<根拠ハッシュ>"
signature   = sorted(set(fingerprints))   # 順序非依存

署名の算出対象は「区分: 必須」かつ「未解消」の指摘に限ります。 却下済み・記録のみ（推奨）・保留は毎ループ定数として残り、かつ委譲先が毎回別の言い回しで再掲するため、含めると署名が本来一致すべき場面で不一致になり停滞を見逃します。停止条件（必須0件）と署名の対象を一致させることで、両者が同じ集合を見ます。

根拠ハッシュ: ハッシュ対象に散文を含めません。 次の4要素を | で連結し、正規化したうえで sha256 の先頭8桁（小文字16進）とします。

hash_input = "<相対パス>|<シンボル>|<欠陥類型>|<根拠アンカー>"

根拠アンカー は次の3種のいずれか1つ（優先順）: ①要件 ID（FR-5 / NFR-2 等） ②設計の節番号（§5-2 / ## 12 等） ③該当コードの1行（正規化済み）。

#	正規化規則（この順）
H-1	小文字化し、連続空白を単一空白へ畳む
H-2	パスは `<PROJECT_ROOT>` 接頭辞・`./` を除去したリポジトリ相対形へ。区切りは `/`
H-3	行番号・列番号は削除する（`skill.md:120` → `skill.md`）
H-4	シンボルは最も内側の関数／クラス／メソッド名。Markdown は最も近い見出しテキストから連番・記号を除去
H-5	要件 ID・節番号は `大文字英字 + ハイフン + 数字` へ正規化（`fr-5` → `FR-5`）
H-6	コード引用は前後の空白・末尾のカンマ／セミコロンを除去。文字列リテラルの中身は保持する
H-7	指摘の要約・詳細（散文）はハッシュ対象に含めない

H-3 / H-7 の意図: レビューの証跡はモデルが毎回書き起こす散文であり、そのままでは1文字も同じになりません。行番号を残せば無関係な修正で全指摘の署名が変わり、EA-1 が永久に成立しなくなります。

順序非依存な比較の実務手順: ①各 fingerprint を1つの文字列にする ②辞書順にソートし , で連結して1行にする ③### ループ N の - 署名: 行へその1行をそのまま書く ④次ループでは直前の - 署名: 行と新しい行を文字列として比較する。

5-9. 指摘の集約（N-1〜N-4）

手順	内容
N-1	受領した各 `L-n` について根拠ハッシュ（5-8）を計算する
N-2	`dev-result.md` に記録済みの `R-nnn` の根拠ハッシュと突合し、一致すれば既存 ID を継承する
N-3	一致しなければ `既存の最大値 + 1` で新規採番する
N-4	観点間で根拠ハッシュが一致する指摘を1件へ統合し、優先度は最も高いものを採る。ファイル分割を廃止したため統合対象は観点間のみであり、`--team` 無効時（1体）は統合そのものが発生しない

5-10. 総合判定・優先度・対応語彙・却下

3値判定の導出: 優先度高 → 区分: 必須 ／ 優先度中 / 低 → 区分: 推奨。総合判定は 5-6-4 の導出規則（未解消の必須 ≥1 → 修正必須 ／必須0 かつ推奨 ≥1 → 修正推奨 ／いずれも0 → 修正不要）で求めます。真実源は各 R-nnn の 優先度 ただ1つです。

停止条件: 最新ループの署名集合が空である。署名は「必須かつ未解消」に限定されているため、- 署名: 行が空 ⇔ 修正必須が0件となり、1行を見るだけで判定できます。

優先度の引き下げ防止: 優先度は 5-7 の既定表から機械的に決まります。呼び出し元（＝実装した主体）が既定より引き下げる場合は却下と同等の監査対象とし、- 区分変更: 必須 → 推奨（J-n: 根拠） 行の追加＋## 終了サマリ への列挙を必須とします。引き上げは自由（監査不要）。これがないと、全指摘を「低」へ付け替えるだけでループを即終了できます（過少指摘バイアスが最も安く発現する経路を、非対称な監査で塞ぎます）。

- 対応: の固定語彙:

値	意味
`未着手`	必須。次の修正フェーズで着手する
`修正済（ループN）`	修正コードを書いた。再レビュー未通過
`修正済（ループN）→ 再レビュー合格（ループM）`	解消。チェックボックスを `[x]` にする
`記録のみ（推奨のため自動修正しない）`	推奨の既定値。このスキルは触らない
`保留（要判断）` / `保留（安全境界）` / `保留（スコープ外）`	自分で修正しない類型。停止判定の対象から除外する
`却下（J-n: 根拠）`	下記
`打ち切り（修正予算超過）` / `未着手（修正予算超過）`	B-2 / B-3

却下の根拠類型（J-1〜J-5・この5つのみ）:

#	類型	必須の証拠
J-1	事実誤認 — 指摘が前提とするコード・シグネチャ・設定が実在しない	反証となるファイルパス:行番号と当該箇所の実際の内容の引用
J-2	仕様どおり — req.md / design.md に明記された仕様に合致する	req.md または design.md の見出し名と該当記述の引用（要約不可・原文の引用）
J-3	スコープ外 — 今回の `T-nnn` の対象範囲外の既存コードに対する指摘	対象範囲である `T-nnn` の一覧と、当該箇所がそこに含まれないことの説明
J-4	既存パターン準拠 — 単独で変更すると一貫性を損なう	同一パターンの既存箇所を2件以上、パス:行で列挙
J-5	優先度による対象外 — 区分が「推奨」であり自動修正の対象外	区分が `推奨` であること（`必須` には適用不可）

却下の根拠として認めない語彙（逐語）: 「実装時にそう判断したため」「意図的な実装である」「設計意図に沿っている」（J-2 の引用を伴わない場合）「動作に影響しない」「実害がない」（コード・テストの提示を伴わない場合）「既存コードもそうなっている」（J-4 の2件以上の提示を伴わない場合）「修正コストが見合わない」「レビュー担当の誤解と思われる」（J-1 の反証を伴わない場合）。

証拠を書けない却下は却下として認めず、未解決の修正必須として扱います（fail-safe）。区分: 必須の却下は J-1 / J-4 に限ります。J-2 / J-3 / J-5 で必須を却下する場合は ## 終了サマリ の - 要件・設計の変更が必要なため未対応: へ必ず転記してください。却下は「実装フェーズの内心が判定に流入する唯一の出口」であり、J-1〜J-5 がいずれも外部参照可能な証拠（ファイル:行、または原文引用）を要求することで、内心そのものは却下の根拠になり得なくなります。

5-11. ループ制御（LC-1〜LC-8）・終了条件（S-1〜S-6）・早期中断（EA-1〜EA-5）

#	規則
LC-1	カウンタ `loop` は各レビューパスの開始時にインクリメントする。初回レビューが `loop = 1`
LC-2	上限は 2。2周目は1周目で未解決の修正必須（＝高優先度）が残った場合にのみ実行する（残っていなければ `S-1` により1周で正常終了する）。`loop = 2` のレビューで未解決の修正必須が残った場合、修正フェーズへ進まずに中断する（3回目のレビューは行わない）
LC-3	`loop` と各パスの署名は `## レビュー・修正ログ` へ追記して永続化する。真実源を `dev-result.md` ただ1つに置くため専用の状態ファイルは設けない。復帰は `## タスク完了状況` の `[x]` から実装進捗を、`### ループ N` から `loop` と署名を復元する（`W-10` の復帰時例外）
LC-4	カウンタのリセットは禁止する。承認を得る対話経路も設けない（本スキルは `AskUserQuestion` を用いない。中断して利用者へ委ねる）
LC-5	修正フェーズでコード変更が1件も発生しなかった場合、次のレビューパスへ進まず即座に中断する。主判定は修正委譲の戻り値の `files` が空配列であること（委譲後は `Edit` / `Write` を直接観測できないため戻り値が唯一の源）。未受領は「無変更」ではなく `E-13` / `E-26` として扱う（取り違えると委譲不成立が `S-5` へ化ける）。複数タスクモードでは `git status --porcelain`（G-0 適用後）を補助検証に用いる
LC-6	`loop` はタスクごとに初期化する（複数タスクモード）。タスクが変われば指摘の集合が別物であり、前タスクの署名・ループ番号を引き継ぐ根拠がない
LC-7	観点の割当表と体数プロファイルをループ間で変えない（`--team` 無効なら常に1体・観点①〜⑤、有効なら常に3体・A: ①②③ / B: ④ / C: ⑤）。割当が変われば同じ欠陥が別の体へ当たり、指摘の有無が揺れて署名が安定しない
LC-8	実装フェーズが変更したファイルが0件の場合、レビューパスを1回も実行せず「レビュー対象なし」として正常終了する（E-27）

上限を2とし2周目を条件付きとした根拠: task-verify のループは「実行結果」という外部の証拠源が毎周新情報を供給するため上限3が機能します。レビューのループは同一入力に対する同一モデルの再判断であり新情報が入りません。2周目を回す価値があるのは「修正により新たな欠陥が入っていないか」を確かめる場合だけであり、修正必須が残っていない周に再レビューを重ねても得るものがありません。

終了条件の評価順序【必須・この順序】: 各レビューパスの完了直後に上から順に評価し最初に一致した条件で確定します。S-0a / S-0b は「レビューが実施され指摘集合が確定していること」を前提に置く S-1〜S-6 の外側の終了であり、必ず先に評価します。

順	条件	判定	帰結
S-0a	当該パスで受領できたレビュー成果が 0件、かつ梯子（D-2〜D-4）を尽くした	`S-1`〜`S-6` を評価しない	終了区分 `レビュー未実施（委譲不成立）` で終了。単一タスクモードでは D-3 が先に成立するため到達しない
S-0b	受領はできたが、次のいずれか: ①成果を受領できなかった体が1体以上（`E-31`。`E-36` の再委譲後もなお形式不正だった体を含む）②`B-1` により未レビューのファイルが残った（`E-33`）③`RP-12` の未確認範囲が空でない	`incomplete_scope = true` を立てて `S-1` へ進む	終了そのものは `S-1`〜`S-6` が決めるが、終了区分は `レビュー範囲不完全` で上書きする
S-1	未解決の修正必須が 0件（保留・却下を除く）	正常終了	コミットへ進む（複数）／完了報告（単一）
S-2	`signature[loop] == signature[loop-1]`（EA-1）	早期中断	コミットしない。E-17
S-3	`signature[loop] ⊋ signature[loop-1]`（EA-3）	早期中断	コミットしない。E-18
S-4	`loop == 2`（LC-2）	中断	コミットしない。E-16
S-5	修正フェーズを実行 → 変更0件（LC-5）	即中断	コミットしない。E-19
S-6	上記いずれでもない	次のレビューパスへ	—

順序の根拠: S-1 はレビューが1件も返らなかったときにも真になるため、S-0a（実施の有無）を先に見ます（見ないと「委譲不成立」が「全指摘解消」へ化けます）。S-0b は判定を偽にするのではなく終了区分の表示だけを差し替えます（停止条件の1行判定を壊さない最小の変更。incomplete_scope はメイン会話が保持します）。S-1 を S-2 以降より上に置くのは、全件解決しているのに「停滞」と報告する誤検知（空集合どうしの一致）を防ぐためです。S-2・S-3 を S-4 より前に置くのは、「停滞・退行」のほうが「上限到達」より情報量が多いためです。

早期中断:

#	規則
EA-1	`signature[loop] == signature[loop-1]`（集合として完全一致）なら早期中断。これが「2周連続で指摘内容が変化しない」の定義
EA-2	署名は毎パス `### ループ N` へ記録し、後から監査できるようにする
EA-3	`signature[loop] ⊋ signature[loop-1]`（前周の指摘が全て残り新規が増えた）が1回でも成立したら、修正が退行を生んでいるとみなし早期中断。「修正により新たな指摘が発生している」と明記する。上限2周では「2回連続」の判定が原理的に成立しないため、1回判定とする（`LC-2` との整合）
EA-4	EA-1 / EA-3 のいずれで中断した場合も、`dev-result.md` への追記と未解決 `R-nnn` の提示は必ず完了させてから終了する
EA-5	却下した指摘が次パスで再提示された場合、それは署名が一致する経路であり EA-1 で正しく中断へ向かう。再提示を抑止するために却下理由を委譲先へ渡してはならない（RI-3）

終了区分（この9値のみ・順序も固定）:

全指摘解消 / 修正推奨のみ残存 / ループ上限到達 / 停滞による早期中断 / 退行検出 /
無変更による中断 / 修正予算超過 / レビュー未実施（委譲不成立） / レビュー範囲不完全

#	終了区分	判定条件	対応 ID	コミット（複数モード）
X-1	全指摘解消	未解決の修正必須 0件かつ推奨も0件	`S-1`	可
X-2	修正推奨のみ残存	未解決の修正必須 0件かつ推奨 ≥1件	`S-1`	可
X-3	ループ上限到達	`loop == 2` で未解決の必須が残存	`E-16` / `S-4`	不可
X-4	停滞による早期中断	`signature[loop] == signature[loop-1]`	`E-17` / `S-2`	不可
X-5	退行検出	`signature[loop] ⊋ signature[loop-1]`	`E-18` / `S-3`	不可
X-6	無変更による中断	修正ラウンドの変更ファイル一覧が空配列	`E-19` / `S-5`	不可
X-7	修正予算超過	`B-2` / `B-3` 超過で未着手が残存し上限到達	`E-24` ＋ `E-16`	不可
X-8	レビュー未実施（委譲不成立）	全レビュー体から成果を受領できず、梯子も尽きた	`E-32` / `S-0a`	条件つき可（`C-11b-1`）
X-9	レビュー範囲不完全	レビューは成立したが未確認範囲が残ったまま終了した	`E-31` / `E-33` / `S-0b`	条件つき可（`C-11b-2`）

全9区分に共通で必須の記録（## 終了サマリ および該当 ### ループ N の両方へ書く）:

キー	記載例
リトライ回数	`リトライ: 計 4 回（担当A 3 / 担当B 1 / 担当C 0）`。スキル本体が送出のたびに数える（画面出力の再掲ではない）
委譲体数	`委譲: 送出 3 体 / 受領 2 体 / 未受領 1 体`（未受領＝差分）
未確認範囲	`未確認範囲: src/Auth/Token.php`（件数のみは不可・パスで全件列挙）／ `なし`。算出は `CV-2` による
プロファイル	`プロファイル: 観点3体` / `観点1体` / `なし（レビュー未実施）`。前ループと異なる場合はその周の署名比較を行わず、`- 停滞判定:` へ「プロファイルが変化したため比較不能」と記録する（`LC-7` により本来発生してはならない状態）
degrade の有無と種別	`degrade: なし / 未受領により自己レビュー / 委譲不成立`
丸め	`丸め: なし` ／ `丸め: L-3 の basisKind を code_line へ丸めた`（`RV-4`。silent な正規化の禁止）

区分別の追加記録:

区分	追加で必須の記録
X-3 / X-4 / X-5 / X-7	未解決の `R-nnn` 全件。X-4 は一致した署名文字列、X-5 は増加した `R-nnn`
X-6	修正方針を立てられなかった `R-nnn` 全件
X-8	未確認範囲＝割り当てた全パス。`## レビュー指摘一覧` は「なし」ではなく「レビュー未実施のため指摘の有無は不明」と書き、`## 終了サマリ` の `- 総合判定:` は `未実施` とする。指摘0件と書いてはならない
X-9	検査済みパスと未確認パスの両方の一覧。`findings` が0件の場合は「検査済み範囲では指摘0件」と範囲を限定して書く

5-12. 再レビューのスコープ（RS-0〜RS-7）

#	規則
RS-0	2周目以降は「新規観点の追加」を行わない。委譲プロンプトへ「前周の指摘の解消確認と、修正差分に起因する新規欠陥のみを見る。新しい観点でのレビューは行わない」と明記する
RS-1	初回（`loop = 1`）は実装フェーズが変更した全ファイルを対象とする
RS-2	2周目以降: 前周の未解決指摘に対応する箇所の解消確認
RS-3	2周目以降: 前周の修正で変更したファイル全体（修正箇所だけでなくファイル単位）
RS-4	2周目以降: RS-3 のファイルを import / require / 継承・実装している呼び出し元（1階層のみ）
RS-5	変更行範囲の算出: 上記で確定した対象ファイル集合について `git diff --unified=0` から変更行範囲（開始-終了の対）のみを機械的に取り出し、`RP-4` の重点範囲として委譲プロンプトへ載せる。差分本文（`-` / `+` の行内容）は取り出さない。行範囲を重点範囲として使ってよいのは観点④コード品質・⑤セキュリティに限る（`RP-5`）
RS-6	上記以外の実装ファイルは再レビューしない
RS-7	RS-2〜RS-4 の合計が実装変更ファイル数の 70% を超えたら、絞り込みを諦めて全件再レビューする

絞り込みの根拠はコストではなく終了保証です。 同一入力を毎周フルスキャンすると、モデルの非決定性により毎周わずかに異なる可読性・保守性の指摘が生成され、署名が永久に一致しません（EA-1 が働きません）。RS-0 と RS-6 は終了保証を成立させるための条文であり、コスト削減はその副次効果です。

RS-5 が隔離原則と両立する理由: 隔離が禁じているのは実装担当の内心（自己申告・捨てた代替案・却下理由・バイアス）であり、変更行範囲はそこに含まれません。行範囲は誰が git diff --unified=0 を実行しても同一値になるリポジトリの客観状態で、委譲先も自力で算出できます（渡すのは算出の代行であって情報の追加ではありません）。差分本文を渡さないのは、削除された旧実装から実装意図を再構成できるためです。プロンプトが能動的に提示する情報の範囲を絞ることが隔離の実体です。行範囲は決定論的に得られるため署名の安定性にも影響しません。

5-13. 操作予算（B-1〜B-4）

ブラウザ操作はありませんが、原因箇所を特定できないときの Grep → Read → Grep の連鎖という同型の発散経路が実在します。

#	予算
B-1	委譲1体あたりの担当量の上限: ファイル 40件／総行数 6,000行。ファイル分割による吸収は行わない（体数は 5-6-9 のプロファイルで固定）。上限を超える割り当てが生じた場合は「変更行数の多い順」に上限まで採り、残余を `未レビュー（予算超過）` として `dev-result.md` へパスで全件列挙する（`E-33`・silent cap の禁止）。この場合 `incomplete_scope = true` を立て、終了区分は `レビュー範囲不完全`（`S-0b` / `X-9`）となる
B-2	1指摘の修正あたりのツール呼び出し予算 12回（`Read` / `Grep` / `Glob` / `Edit` / `Write` / `Bash` の合計）。超過した指摘は `打ち切り（修正予算超過）` として記録し次へ進む
B-3	1ループの修正フェーズ全体の予算 60回。超過したら以降の指摘を `未着手（修正予算超過）` として記録し、終了条件の評価（5-11）へ進む
B-4	予算超過で打ち切った指摘は未解決のまま残るため次パスで必ず再提示される。したがって予算超過は握り潰しにならず、最終的に上限到達（E-16）または停滞（E-17）として利用者へ提示される

5-14. `dev-result.md` への追記規約（W-1〜W-11）

前提: W-1〜W-11 の主体は**すべてスキル本体（メイン会話）**です（唯一の例外は複数タスクモードの実装セクションで、これは実装委譲先のサブエージェントが書きます）。レビュー・修正の委譲先に dev-result.md を書かせないこと（5-6-2 の逐語ブロックが禁止事項として明示しています）。

規則	内容
W-1	`## メタ情報` は常に最終セクション。追記は必ずその直前へ挿入する
W-2	`## レビュー・修正ログ` へは `### ループ N` を追記のみ。過去ループのブロックで書き換えてよいのは `- ループ状態:` の値だけ
W-3	`## レビュー指摘一覧` へは新規 `R-nnn` を末尾追記のみ。既存項目で書き換えてよいのは ①チェックボックス（再レビューで解消を確認したときのみ `[x]`。修正した時点では付けない）②`- 対応:` 行の2箇所に限る
W-4	`- 対象:` / `- 根拠:` / `- 署名:` / 見出し行の `優先度` `区分` `類型` は変更禁止（署名の安定性を壊すため）。区分を引き下げる場合は既存値を残したまま `- 区分変更:` 行を追加する
W-5	実装フェーズのセクションは、レビュー修正で実体が変わった場合に限り上書き更新してよい。`## 変更ファイル一覧` はレビュー修正で触れたファイルを追記し、コミット対象の和集合（C-9）と一致させる
W-6	`## task-verify へ引き継ぐ事項` / `## 終了サマリ` / `## メタ情報` は上書き更新（現在値を表すため）
W-8	メタ情報の Agent Teams は Agent Teams の成立2条件のみで決まる。`--team` 未指定時の委譲は成立条件に含めない（`--team` 未指定なら何体稼働していても `無効（指定なし）`）。`--team` 指定時は、委譲した担当が1体以上成果を返せば `有効`
W-9	作成タイミングは実装フェーズ完了直後に1回。レビュー・修正フェーズは以降追記のみ。指摘0件でも `## 終了サマリ` の `- 総合判定:` と `### ループ 1` を必ず書く（レビューを実施した唯一の証拠は `### ループ 1` が担う）。`## 終了サマリ` の `- 終了区分:` は 5-11 の9値からのみ選ぶ
W-10	編集の実行方法を下表に固定する。`old_string` に本文を1行も入れなければ、切り落としは原理的に起こらない
W-11	各追記の直後に構成を検証する（下記）。不合格なら `E-35` として即中断し、復旧を自動で試みない

W-10（編集の実行方法）:

#	操作	使用ツール	`old_string` に入れてよいもの	実行形
W-10-1	セクション群の追記（`### ループ N` の追加、新規 `R-nnn` の追加、レビュー節群の挿入・`BC-8`）	`Edit`	`## メタ情報` の見出し1行のみ	`old_string` = `## メタ情報` ／ `new_string` = 追記本文＋空行＋ `## メタ情報`
W-10-2	既存1行の差し替え（`W-3` のチェックボックス・`- 対応:` 行、`W-6` の各 `- キー:` 行）	`Edit`	1行のみ。その1行がファイル内で一意でない場合は、直前の - [ ] `R-nnn` 見出し行を含む同一項目内のブロックまで拡げてよいが、次の `- [ ]` + `R-` 行を越えてはならない	一意なら `- 対応: 未着手` の1行、一意でないなら当該 `R-nnn` の項目ブロック
W-10-3	`W-6` の「上書き更新」セクション	`Edit`	セクション全体を置換しない。`- キー: 値` の各1行を個別に差し替える（W-10-2 を繰り返す）	これらの節はすべて `- キー: 値` の1行項目で構成されるため、行単位更新で「上書き更新」の意味論を完全に満たせる
W-10-4	`Write` の使用	—	切替線より後は全面禁止。 `Write` を使ってよいのはステップ3（`dev-result.md` の初期化）ただ1回	—

W-11（編集後の構成検証）: 切替線より後の各追記の直後に、1回の Bash で見出し一覧と行数を取得して期待と突合します。

cd <PROJECT_ROOT> && \
grep -n '^## ' .claude/tasks/<TASK>/dev-result.md && \
wc -l < .claude/tasks/<TASK>/dev-result.md

期待する見出し列（この順序・13件。BC-8 の旧形式挿入直後も同じ列になる）:

## プロジェクト概要 / ## タスク完了状況 / ## 実装概要 / ## 変更ファイル一覧 /
## 技術的な実装詳細 / ## パフォーマンスとセキュリティ / ## 既知の課題・改善点 /
## 動作確認結果 / ## レビュー指摘一覧 / ## レビュー・修正ログ /
## task-verify へ引き継ぐ事項 / ## 終了サマリ / ## メタ情報

合格条件（3つすべて）: W-11-a 上記13件がすべて・この順序で出現する／ W-11-b 最後の ## 見出しが ## メタ情報 である／ W-11-c 行数が直前の編集時点より減っていない（切替線後は追記のみで W-10-3 の行単位更新は行数を保つため、行数は単調非減少が不変条件。直前の行数はメイン会話が保持する）。

読み返し方針: dev-result.md は追記のみで読み返しません。ループ状態（loop / 署名 / 未解決 R-nnn）はメイン会話が保持します。例外は中断からの復帰時のみで、このとき読み取りは許可し、書き込みは追記のみ（＋W-3 / W-6 の限定編集）を維持します。なお読み返し禁止の対象は「ループ状態の復元」であり、W-11 の構成検証および Edit の前提としての Read は禁止対象ではありません。

中断からの復帰手順（R-1〜R-9）: 復帰時に読んでよいのは次の5見出しの範囲のみで、## 実装概要 / ## 技術的な実装詳細 などの実装フェーズの自己申告は読みません（読むとレビュー隔離が復帰経路から破れるため）。

手順	見出し	復元する値
R-1	`## タスク完了状況`	`[x]` → 完了済み／`[ ]` → 未完了。未完了が1件でもあれば実装フェーズから再開し、完了済みタスクは再実装しない
R-2	`## レビュー指摘一覧`	`R-nnn` の最大値。追番の起点（`最大 + 1`。欠番を詰めない・再利用しない）
R-3	`## レビュー指摘一覧`	未解決の修正必須（`- [ ]` かつ `区分: 必須` かつ `- 対応:` が解消・却下・保留・記録のみ以外）
R-4	`## レビュー・修正ログ`	`### ループ N` の `N` の最大値
R-5	最大 `N` のブロックの `- ループ状態:`	`完了` → 次パスは `N + 1`。`実行中` → 同じ `N` を再実行する（ループ予算2を消費させない）。`中断` → 終了済みとして扱い復帰しない
R-6	同ブロックの `- 署名:`	`signature[loop-1]` / `signature[loop-2]`。文字列としてそのまま保持する（再計算しない。散文の揺れで一致しなくなるため）
R-8	同ブロックの `- 未確認範囲:`	復帰後の初回レビューパスの優先対象に加える
R-9	`## 終了サマリ` の `- 終了区分:`	値が9値のいずれかと完全一致すればループは終了済み。復帰処理を行わず「実装済み」として扱う（冪等性はこの1点で成立する）。角括弧プレースホルダ・空・9値のいずれとも完全一致しない値は「未記入」として扱い復帰する（判定規則は 1-5。部分一致で判定するとプレースホルダ行が9値すべてを含むため必ず一致してしまう）

復帰後の書き込み規約（RC-1〜RC-4）: RC-1 R-5 で 実行中 を検出したらそのブロックの - ループ状態: を 中断 へ書き換える（W-2 が許す唯一の編集）。そのブロックの - 署名: は不完全なため比較に使わない。RC-2 続けて ### ループ N（再開） を追記し、以降は W-1〜W-9 に従う（N は再利用する）。RC-3 復帰したことを利用者へ告知し、### ループ N（再開） の先頭へ - 復帰: dev-result.md から復元（完了タスク [n] 件 / 前回署名 [有 / 無]） を記録する（黙って復帰しない）。RC-4 R-9 で終了区分が既に書かれている dev-result.md に対しては何も追記しない。

5-15. 後方互換（BC-1〜BC-8）

規則	内容
BC-1	既存の `review.md` / `fix-result.md` を読まない・書き換えない・削除しない。統合後のスキルの入力仕様ではなく過去の実行記録であるため。読むと `R-nnn` の採番が壊れる（旧記録は識別子を持たない）
BC-2	実行開始時にいずれかを検出したら1回だけ告知する（黙って無視しない）
BC-3	検出した事実を `## レビュー指摘一覧` の直下へ HTML コメントで1行残す
BC-4	`todo.md` が存在する場合は必ず読む。design.md と食い違う場合は design.md を正とする
BC-5	`## タスク完了状況` には `T-nnn` 由来と `[todo i/N]` 由来の両方を記載する
BC-6	レビュー担当へ渡す入力に、`todo.md` が存在する場合に限りそのパスを含める（入力隔離は「実装フェーズで得た文脈」を渡さない規定であり、成果物ファイルのパスは隔離対象ではない）
BC-7	実装タスクの未完了は `task_incomplete`（優先度高 / 区分必須）として `R-nnn` を採番する
BC-8	旧形式の `dev-result.md`（レビュー節を持たない）は全面上書きせず、`## メタ情報` の直前へレビュー・修正記録セクション群を挿入する

5-16. 書き込み禁止対象

区分	パス	可否
成果物	`.claude/tasks/<TASK>/dev-result.md`	許可（追記＋ W-3 / W-6 の限定編集のみ）
修正対象	`<PROJECT_ROOT>` 配下のソース・設定・テスト（未解決の `R-nnn` に紐づく箇所）	許可（下記の禁止を除く）
—	`.git/**`	禁止
—	`.claude/tasks/<TASK>/req.md` / `design.md`	禁止（要件・設計の変更を伴う修正は `保留（要判断）`・E-21）
—	`.claude/tasks/<他タスク>/**`	禁止
—	`<PROJECT_ROOT>` の外（`~/.claude/settings.json` / `~/.claude/skills/**` 等）	禁止
—	`node_modules/` / `vendor/`	禁止
—	`.env` 等の認証情報・秘密鍵・証明書・トークン	禁止（`保留（安全境界）`・E-20）
—	ロックファイルの手編集	禁止（パッケージ操作が必要なら `保留（要判断）`）

5-17. レビュー・修正フェーズのエラーハンドリング（E-13〜E-35）

「モード」列は 単 = 単一タスクモード、複 = 複数タスクモード。E-1〜E-12 はステップ6-4 のとおり維持します（2点の読み替えを後述）。

採番方針: 既存 ID は振り直さず、廃止した ID は欠番のまま残して再利用しません（R-nnn / T-nnn と同じ規約）。新規は E-37 から採番します。欠番: E-14（形式逸脱は E-36 が担う）／ E-29・E-30（委譲ランタイムの可否判定とワークフロー全体の失敗が消滅）／ E-34（最大3体では同時実行キューイングが発生しない）。

ID	事象	対応	全体	モード
E-13（再定義）	規定回数（`BK-1`）のリトライ後も成果を受領できなかった（利用者のスキップと終端エラーは区別できないため、事象は「成果が返らなかった」事実に留める）	当該体の担当範囲を未検査として記録し、梯子を1段下げる（D-2→D-3/D-4）。告知（5-18）と `dev-result.md` への記録を伴う	継続	単/複
E-15	`--team` 有効時に一部の体のみ未受領	稼働分を採用して続行。欠けた観点と担当ファイル集合を `dev-result.md` へ明記。`E-31` と同一の記録経路を使う	継続	単
E-16	ループ上限到達（LC-2 / S-4）	中断。未解決の `R-nnn`（修正必須）を全件提示。コミットしない	中断	単/複
E-17	停滞（EA-1 / S-2）	早期中断。一致した署名を提示。コミットしない	中断	単/複
E-18	退行（EA-3 / S-3）	早期中断。「修正により新たな指摘が発生している」と明記。コミットしない	中断	単/複
E-19	無変更（LC-5 / S-5）	即中断。修正方針が立たなかった `R-nnn` を提示。コミットしない	中断	単/複
E-20	修正が書き込み禁止対象への変更を要する	当該指摘を `保留（安全境界）` として記録し継続。停止判定の対象から外す	継続	単/複
E-21	修正が req.md / design.md の変更を要する	当該指摘を `保留（要判断）` として記録し継続。`/task-req-update` → `/task-design` → `/task-dev` の本流へ戻す旨を完了時に案内	継続	単/複
E-22	修正後にテスト・ビルドが失敗	失敗内容を次パスのレビュー入力へ含めて継続。テストコマンドが不明なら判定を行わない（不明であることを記録する）	継続	単/複
E-23（追補）	`dev-result.md` への追記に失敗、または追記後の構成検証（`W-11`）に不合格	中断。記録が残らない／壊れた状態でループを回さない（監査可能性が失われ EA-2 が成立しない）	中断	単/複
E-24	操作予算の超過（B-1〜B-3）	`打ち切り（予算超過）` / `未レビュー（予算超過）` として記録し継続	継続	単/複
E-25（改訂）	`--team` 指定だが委譲した担当が0体（全未受領）	フォールバック文言を表示しメタ情報へ `無効（フォールバック）` を記録。レビューは梯子の次段で続行（レビュー委譲は `--team` と独立）	継続	単
E-26（改訂）	修正委譲の成果を受領できなかった（複数タスクモード）	失敗として記録し中断（コミットしない）。変更ファイル一覧が空配列であることとは区別する（後者は `LC-5` / `S-5`）	中断	複
E-27	レビュー対象ファイルが0件（LC-8）	レビューパスを実行せず「レビュー対象なし」と記録して正常終了	正常終了	単/複
E-28	旧 review.md / fix-result.md を検出（BC-2）	1回だけ告知し、読まず・変更せず続行	継続	単/複
E-31	一部の委譲のみ未受領（部分失敗）	稼働分で続行。脱落体数はスキル本体が数える（`脱落数 = 送出数 − 受領数`）。脱落した体の識別子と担当ファイル集合を `### ループ N` へ列挙し、`incomplete_scope = true` を立てる	継続	単/複
E-32	全委譲が未受領（全滅）	「指摘0件」ではなく「何も検査されなかった」と記録する。総合判定を導出せず `## 終了サマリ` の `- 総合判定:` へ `未実施` と書く。梯子を1段下げ、D-3 / D-4 まで尽きたら終了区分 `レビュー未実施（委譲不成立）`	中断／条件付きコミット	単/複
E-33	`B-1` の上限超過による切り捨て	silent cap の禁止。切り捨て件数を告知し、`dev-result.md` へ未検査ファイルをパスで全件列挙する。`incomplete_scope = true` を立てる。削るのは対象ファイルであって観点ではない（観点を削ると検査に穴が空き危険側）	継続	単/複
E-35	`dev-result.md` の構成崩れ（`W-11` の検証に不合格。期待見出し13件の欠落・順序入替・`## メタ情報` が最終でない・行数の減少）	即中断（`E-23` と同じ帰結）。コミットしない。直前の編集の `old_string` の先頭1行と、欠落した見出し名を提示する。復旧を自動で試みない	中断	単/複
E-36（新設）	戻り値の形式逸脱（`RV-1`〜`RV-3` に不合格。フェンス欠落・パース不能・必須キー欠落・型不一致・`disposition` の語彙外）	1回だけ再委譲する（`RV-5`。プロンプトは初回と同一とし「前回の応答が形式不正だった」の1行のみを付す）。再委譲後もなお不合格なら `E-13` と同じく未受領として扱う（`incomplete_scope = true`）。「形式が悪いから無視する」ではなく「検査されなかった」として記録する	継続	単/複

原則:

fail-fast（実装系・ループ終了系）／fail-soft（検証系・委譲系）: 実装・コミット・ループの未収束は即中断する。成果物の欠落・実装済み・レビュー委譲の失敗は当該範囲のみを degrade / スキップする。
完了分のコミットは維持する。 git reset / git revert による自動ロールバックは行わない。
黙って劣化しない。 --team の無視、コミットのスキップ、残存変更、自己レビューへの degrade、予算超過による打ち切り、保留扱いにした指摘のいずれも必ず明示表示する。
記録を伴わない継続をしない。 degrade・保留・打ち切りはすべて dev-result.md へ記録してから継続する。画面出力は残らず、後から監査できないため。

E-1〜E-12 の読み替え（2点のみ）:

ID	読み替え
E-7	「サブエージェントの spawn 失敗・応答なし」→「実装委譲の成果を受領できなかった」。中断の前に成果物による完了判定を1回だけ挟む（発動条件は未受領に限定。成功と判定した場合は `dev-result.md` へ「戻り値未受領・成果物により完了判定」と記録する）
E-9	「戻り値のフォーマット逸脱」は `RV-1`〜`RV-3` の不合格として検出し、`E-36` の経路（1回だけ再委譲 → なお不合格なら未受領）で扱う。主経路が同期 `Agent` 委譲になったため常時有効である

5-18. degrade 告知【省略・要約禁止】

告知は1種類です（D-1 が欠番となったため、告知① は廃止しました）。理由は2値（Agent 委譲を起動できない / リトライ後も成果を受領できない）に固定します。

告知②（D-2 → D-3・自己レビューへ落ちる場合。単一タスクモードのみ）:

⚠️ レビューを別コンテキストへ委譲できなかったため、自己レビューで続行します（理由: <Agent 委譲を起動できない / リトライ後も成果を受領できない>）。
   実装した主体自身がレビューを行うため、指摘が過少になる可能性があります（構造的隔離が働きません）。

記録先: dev-result.md の ## プロジェクト概要 の - レビュー体制: / - 委譲機構: と ### ループ N の - レビュー体制: / - 委譲機構: の両方へ必ず残してください。画面表示だけで済ませてはいけません（画面出力は残らず、後から監査できないためです）。

5-19. 中断時の状態告知

共通原則: 本スキルの中断は「実装は完了しているがレビューループは未完」という中間状態を生みます。「作成していないもの」だけを列挙すると利用者が「何も行われなかった」と誤読するため、すべての中断文言は「完了したもの」を先に述べます。

経路	対応する ID	文言の骨子
① ループ上限到達・単一	E-16	完了（実装済・レビュー2回）→ 未解消 `R-nnn` の全件列挙 → 「コミットしていません（単一モードは git を操作しません）」→ 手動修正か本流への差し戻しの案内
② ループ上限到達・複数	E-16	完了（当該タスクの実装済・

Truncated - read the full file at https://github.com/tombolo-jp/cc-task-skills/blob/1659f28f29888814b776dd31c4c5ec11466905e1/skills/task-dev/SKILL.md.

About