execute-plan

プランの実行

承認済みの継続型プランを完了まで進めます。独立したタスクを依存関係に従ったウェーブで実行し、各タスクに新しい実装サブエージェントを割り当て、各タスクの差分を2つの判定でレビューし、最後にブランチ全体をレビューします。タスク間で人間による確認待ちはありません。

このスキルではありません：

意図	代わりに使用
Execution-mode: story-unit（人間の承認が必要なレビュー単位）	必須サブスキル：execute-story を使用
サブエージェントを使わない／コントローラーが実装する／ユーザーがインライン実行を選択した	必須サブスキル：execute-inline を使用

**新しいサブエージェントを使う理由：**各ワーカーには、タスクに必要なコンテキストだけを渡します。サブエージェントはセッション履歴を引き継ぎません。ワーカーの実行環境は自分で構築します。大量の成果物は貼り付けたテキストではなく、.skills/ 配下のファイルパスで渡します。

**進捗の説明：**ツール呼び出しの間に書けるのは、短い行を最大1つまでです。記録は台帳とツールの結果に残します。

モードの確認

tasks.md では Execution-mode が必須ヘッダーです。このスキルは値が continuous の場合にのみ実行します。

ヘッダー	アクション
continuous	以下のセットアップに進む
story-unit	このスキルのループは実行しない。必須サブスキル：execute-story を使用
欠落／unset／無効	ユーザーに確認し、tasks.md に continuous または story-unit を記入する（追跡対象の場合はコミットする）。ユーザーが story-unit を選んだ場合は execute-story を使用する。continuous を選んだ場合は続行する。確認せずに continuous と決めてはならない。プロジェクトレベルのデフォルトはない

このスキルでは、ユニットの障壁設定、ユニットの導出、人間によるユニットごとの停止を決して行わないでください。それらは execute-story でのみ扱います。

考え	実際
「以前の execute-plan は両方のモードを扱っていたので、story-unit でも続けよう」	Story-unit は execute-story で扱います。このスキルを続けるのは、両モードの混同です
「サイズの目安としてユニットを導出してから、continuous にしよう」	このスキルにユニット表はありません。ウェーブは Depends-on のみから決定します
「リードが人間による確認を求めているので、continuous のまま一時停止しよう」	一時停止の方針はヘッダーで決まります。story-unit を記入して execute-story を使用するか、continuous のまま一時停止せずに進めます
「PM／スタンドアップだから、確認せずに continuous をデフォルトにしよう」	モードが空欄なら、準備ができていません。確認してフィールドに記入してください

セットアップ

1. 最初にモードを確認します。 上の表に従って Execution-mode: を解析します。完了条件： continuous モードであるか、execute-story に引き継いでいること。
2. ワークスペースを確認します — まず質問します。 まだ隔離されたワークスペースがない場合は、次のどちらにするか尋ねます： worktree で隔離するか、現在のブランチで実装するか。尋ねずに worktree を作成してはいけません。隔離する場合 → REQUIRED SUB-SKILL: worktrees を使用します。現在のブランチが main/master の場合は、実装前に別途明示的な同意を得ます。「no worktree」は main/master を変更する同意ではありません。完了条件：ワークスペースの選択が明確であること。
3. 台帳を確認します。 .skills/ をローカル専用にします： grep -qxF '.skills/' .gitignore 2>/dev/null || { printf '.skills/\n' >> .gitignore && git commit -m 'chore: ignore local skills artifacts' -- .gitignore; } .skills/progress.md が存在する場合は読みます。完了と記載されているタスクはすべて完了済みです — 記載されていない最初のタスクから再開します。完了条件：次のタスクが分かっていること。
4. 計画を読みます。 tasks.md を一度、最後まで読みます。すべてのレビュー担当者への依頼に Global Constraints をそのまま記載します。docs/agents/project.md がない場合は、その旨を伝え、setup-repo を提案し、検証コマンドは Global Constraints から取得します。## Team にロスター／バンドがある場合は、バンドの packaging だけを読み込みます — Solo で二重判定レビューを省略してはいけません。完了条件：制約を一字一句そのまま記録していること。
5. Todo — GATE。 ディスパッチ前に、TodoWrite を使ってタスクごとに 1 件の todo を作成します。完了条件：todo リストが計画を反映していること。
6. 事前の計画レビュー。 内部の欠陥（矛盾、アサーションのないテスト、計画が必須としているコピー＆ペーストされたロジック）を一度確認します。ディスパッチ前に、見つかった問題をすべてまとめてユーザーに 1 つの質問として提示します。問題がなければコメントしません。完了条件：矛盾が解消されているか、存在しないこと。
7. ウェーブを計画します。 各タスクの Depends-on: 行を読みます。指定されたタスクは先に完了させます。Depends-on: none は前提条件なしです。行がない場合は、前にあるすべてのタスクに依存します。トポロジカルソートしてウェーブに分けます。Depends-on のエッジがない場合は、1 ウェーブにつき 1 タスクとします（厳密な直列実行）。完了条件：すべてのタスクがいずれかのウェーブに含まれていること。

タスクごとのループ

タスク N について：

1. ベースを記録します。 BASE=$(git rev-parse HEAD) — 必ずディスパッチ前に実行します。
2. ブリーフを作成します。 タスク N のブロックと Global Constraints の原文を合わせて .skills/task-N-brief.md に記載します。docs/architecture/ の設計の骨格がある場合は、関連する **ARCH-N** を含めます。Team バンドの packaging をトーンに反映します — レビュー義務は省略してはいけません。
3. implementer-prompt.md（このファイルと同じ場所にあります）を使い、新しい実装担当者をディスパッチします。ディスパッチ時に渡す情報は、配置先を示す 1 行、要件としてのブリーフのパス、先行タスクでは把握できないインターフェース／決定事項、曖昧な点の解消内容、レポートのパス .skills/task-N-report.md、明示的なモデルだけです。セッション履歴は渡しません。計画ファイルも渡しません。
4. 実装担当者が作業を進める前に、質問には漏れなく回答します。
5. ステータスを下の表に従って処理します。DONE の作業はコミット済みです。
6. 差分をパッケージ化して .skills/review-<base7>..<head7>.diff に保存します： git log $BASE..HEAD --oneline、git diff --stat $BASE HEAD、 git diff -U10 $BASE HEAD。ベースに HEAD~1 を使ってはいけません。
7. ブリーフ、レポート、差分パッケージ、Global Constraints の原文、明示的なモデルを添えて、task-reviewer-prompt.md を使い、タスクのレビュー担当者をディスパッチします。設計の骨格がある場合 → REQUIRED SUB-SKILL: check-invariants も使用します。violates は修正ループに進みます。
8. 修正ループ。 Critical／Important → 修正サブエージェント（tdd に従って対象テストを再実行し、同じレポートに追記）→ 再レビュー。同じ指摘が 3 サイクル続けて残る場合は停止します。計画／設計／要件が無効になった場合 → REQUIRED SUB-SKILL: correct-course を使用します。それ以外はエスカレーションします。コントローラーのコンテキスト内で修正してはいけません。軽微な指摘は、ブランチ全体のトリアージ用に台帳へ記録します。
9. レビュー担当者が差分から検証できなかった ⚠️ 項目を解決します。
10. 台帳に記録します。 Task N: complete (commits <base7>..<head7>, review clean)。todo を完了にします。
11. 次へ進みます。 タスク番号順ではなく、ウェーブの順序に従って進めます（Parallel waves を参照）。タスク間で許可を求めて一時停止してはいけません。

並列ウェーブ

単一タスクのウェーブでは、ブランチ上でタスクごとのループを実行します。これは一般的なケースです。独立したタスクが2つ以上あるウェーブでは、git worktree が使用可能な場合に限り、それぞれ専用のワークツリーで並行して実行します。それ以外の場合は順次実行します。

1. ウェーブのベースを記録します。 WBASE=$(git rev-parse HEAD)。
2. 作業対象が重複しないことを確認します。 2つのブリーフで同じファイルを作成または変更してはいけません。重複がある場合は順次実行に切り替え、作業対象が重複するタスクを並列実行しないでください。
3. タスクごとにワークツリーを作成して振り分けます。 WBASE のプライマリワークツリーにとどまります。各タスクについて、git worktree add .worktrees/<branch>-taskN -b <branch>-taskN WBASE を実行し、そのワークツリー内で タスクごとのループのステップ1〜9 を実行します。バリアに到達するまで、台帳の更新と次への進行は保留します。実装担当者は並行して作業します。
4. バリアの後、タスク順にマージします。 ウェーブ内のすべてのタスクがレビューに合格した後に限り、タスク番号の昇順で各タスクを 機能ブランチ にマージします（main/master には絶対にマージしないでください）。git merge --no-ff <branch>-taskN を実行します。競合が発生した場合は停止してエスカレーションしてください。ウェーブのマージを確認せずに解決してはいけません。
5. 台帳を一度更新し、ワークツリーを削除します。
   タスクごとに Task N: complete (merged <branch>-taskN at <merge7>, review clean) と記録します。TODO を完了にし、各ワークツリーで git worktree remove を実行します。

実装担当者のステータスへの対応

ステータス	対応
DONE	差分をまとめてタスクレビューに回します。
DONE_WITH_CONCERNS	懸念事項と .skills/implementation-notes.md の両方を読みます。計画を覆す逸脱がある場合は、必須サブスキルとして correct-course を使用します。逸脱を申告しているのにメモがない場合は、まず記録するよう再指示します。
NEEDS_CONTEXT	指摘された情報を提供し、同じモデルに再指示します。
BLOCKED	コンテキスト不足なら提供します。能力の上限なら、より強力なモデルに切り替えます。規模が大きすぎるなら分割します。計画が誤っているなら、必須サブスキルとして correct-course を使用します。

各タスクの再指示は最大2回までです。それでも DONE にならない場合は、ユーザーにエスカレーションします。何も変更せずに同じモデルへ再試行を強制してはいけません。

モデルのティア分け

再指示のたびにモデルを明示してください。モデルを省略すると、セッションのモデル（通常は最も高価なモデル）が引き継がれます。

• 低コスト： 書き起こし、または単一ファイルの機械的な修正。
• 中位以上： すべてのレビュアー、および文章の指示に基づいて作業するすべての実装担当者。
• 最上位： 設計判断、広範なコードベースの理解、ブランチ全体のレビュー。

レビュアーのティアは、差分の規模とリスクに応じて調整します。

レビュアー向けプロンプトの衛生管理

• 発見事項を事前に限定してはいけません（「X は指摘しない」「せいぜい軽微」「計画でこう決まっている」など）。
• 計画で要求されている欠陥も、指摘事項です。どちらを優先するか確認してください。
• 具体的なタスク固有の理由がない限り、範囲を限定しない「すべてを確認してください」といった依頼は避けてください。
• 実装担当者が報告ですでに根拠を示したテストを再実行しないでください。

継続的な進捗管理

会話の記憶はコンパクション後には保持されません。TODO は現在のセッションの進捗を示し、台帳はコンパクション後も残ります。一方を理由に、もう一方を省略してはいけません。

• 開始時に .skills/progress.md を読み、最後に完了したタスクの次から再開します。
• コンパクション後は、記憶より台帳と git log を信頼します。
• 台帳で完了と記録されたタスクを再指示してはいけません。
• ウェーブの途中でクラッシュした場合は、未マージのワークツリーを破棄し、WBASE を起点にウェーブ全体を再実行します。
• .skills/ は Git に無視されます。消去された場合は、git log から再構築します。

最後のタスクの後

1. ブランチ全体をレビューします。 必須サブスキルとして、base に git merge-base main HEAD を指定して code-review を使用します。ブランチ途中の SHA は指定しないでください。台帳に記録された軽微な指摘もレビューに含めます。最上位モデルのティアを使用します。
2. 指摘事項の完全な一覧に対して、修正担当者を1人だけ割り当てます。 その後、再レビューします。指摘事項ごとに修正担当者を割り当ててはいけません。
3. 仕上げます。 受け入れ前に、ブランチ全体の差分に対して必須サブスキルの polish を使用します。
4. 受け入れ確認を行います。 必須サブスキルの acceptance-check を使用します。問題があれば debug を使用し、その後、コミット済みの ID 付きテストに昇格させます。任意：/allocate-attention（ゲートではありません）。
5. 準備します。 必須サブスキルの prepare-change を使用します。
6. 完了します。 必須サブスキルの finish-branch を使用します。

インラインルート

コントローラー側での逐次実行（実装サブエージェントなし）は execute-inline が担当します。ユーザーがインラインを選択した場合、または環境で実装者を複数に振り分けられない場合は、必須サブスキルとして execute-inline を使用します。ディスパッチなしで、このスキルのサブエージェントループを中途半端に実行しないでください。

注意すべき点 — 絶対にしないこと

• Execution-mode が story-unit のときに、このスキルのループを実行する（execute-story に引き継いでください）
• ユーザーがインライン／サブエージェントなしを選択した後も、このスキルを続ける（execute-inline に引き継いでください）
• continuous のもとで、ユニットのバリア、ユニットの導出、または人によるユニット停止を実行する
• タスク間で一時停止し、続行してよいか尋ねる
• ヘッダーがないことを理由に Execution-mode: continuous を作り出す
• 同じ worktree で2人の実装者を動かす、または worktree を分離せず、対象範囲が重複していないことを確認せずに並列実行する
• 並列ウェーブ内のすべてのタスクがレビューに合格する前に、マージしたり台帳に記録したりする
• サブエージェントにプランファイル全体を渡す（その概要がサブエージェントの作業範囲です）
• レビューのベースとして HEAD~1 を使用する
• 修正後の再レビューを省略する、またはいずれかの判定が欠けているレビューを受け入れる
• Critical／Important の指摘が未解決のまま次のタスクに進む
• 実装者自身のレビューをタスクレビューの代わりにする
• レビュアーに指摘しないよう伝える、またはディスパッチ時に重要度をあらかじめ評価する
• 差分パッケージなしでレビュアーをディスパッチする
• 台帳で完了とされているタスクを再ディスパッチする
• todo リストができる前に最初のタスクをディスパッチする
• コントローラーのコンテキストでレビュアーの指摘を修正する
• 明示的な同意なしに main/master で実装を開始する
• 許可を求めずに worktree を作成する、または「現在のブランチ」を main/master での作業への同意として扱う