execute-phase

実行フェーズ

ユニットのステップ実行ツールです。ユニットのドキュメント（unit-lane が作成）は Tasks P1…Pn、Evidence の行、および Progress ログを管理します。これらは PLAN.md、TASKS.md、progress.md、ACCEPTANCE.md に代わるものです。各ステップは、アトミックなゲート／コミットとして実行されます。

引数の解決（最初に一致したものを適用）：

• <NN-slug> P<k> — トリアージ順で指定されたステップ（P1、P2、…）のみ
• <NN-slug>（ステップなし）— 残りのすべてのステップを、それぞれ1コミットで実行
• P<k> のみ — 現在のユニット内の位置で指定されるステップ（最後に判明した NN-slug）

ユニットのドキュメント内のトリアージブロックにないステップ ID を推測してはいけません。

ターンの契約

ターンを終える前にすべてのボックスにチェックを入れてください。未チェックのボックスがある場合、ターンは完了していません。

✓ Triage verified — unit doc Evidence section header matches
  `bun scripts/unit-route.mjs --triage <slug>` output block (PREFLIGHT.md)
✓ Unit doc read and step selected (explicit P<k> or first unfinished)
✓ Step executed and committed (one commit per step, conventional format)
✓ Evidence rows updated (command → exit/digest → output → verified-by)
✓ Progress log updated with a dated `YYYY-MM-DD HH:MM` entry (what, commit, next)
✓ Diff guard passed (on implement steps) — see `diff-guard` in PREFLIGHT.md
✓ → Next: block printed as the absolute last output

使用する場面

• unit-lane でトリアージされたユニットで、ステップに implement／tests／evidence が含まれる場合は、<NN-slug> または <NN-slug> P<k> で実行します。
• ドキュメントのみのユニット（トリアージの結果が [docs, evidence] のみ）は、このスキルを読み込みません。unit-lane の指揮役がその場で実行します。
• 残りのステップをすべて実行するには、ステップ引数なしで <NN-slug> を指定します。
• 失敗したステップを修正するには、<NN-slug> P<k> を指定します（同じステップを再試行します）。

ステップ 0 — プロジェクトを確認する

エージェントガイドの Workflow conventions と documentation map に従って、docs/features/<NN-slug>/SPEC.md にあるユニットのドキュメントを読みます。## Tasks（P1…Pn）、## Evidence、## Progress の各セクションがあることを確認します。ない場合、そのユニットは準備ができていません。停止し、まず unit-lane でトリアージするよう提案してください。

プロセス

1. トリアージが最新であることを確認する

bun scripts/unit-route.mjs --triage <slug> を実行し、そのブロックをユニットのドキュメントにある Evidence セクションのヘッダーと比較します。不一致の場合 → 停止し、まず再トリアージしてください。 これにより、実行ツールと unit-lane のステップ認識が一致していることを確認します。

2. ステップを選択する

ステップ引数（例：P2）が指定されている場合は、そのステップを使用します。指定されていない場合は、Tasks 内でチェックが入っていない最初の P、つまり最初の未完了ステップを使用します。トリアージでスキップされたステップは実行しないでください。

3. ステップ前のゲート

ゲートを順番に実行します。いずれかが失敗した場合は停止してください（PREFLIGHT.md を参照）。

1. パス保護チェックポイント — コミット対象の範囲を保護対象パス（例：tests/、fixtures/）と照合します。終了コード 1 → ゲートの拒否ブロックを表示して停止します。--force による回避はできません（上書きできるフラグはありません）。
2. フェーズリント — ステップが implement で、ユニットに Tasks P1…Pn がある場合に限り、bun scripts/phase-lint.mjs <unit-doc> を実行します。PLAN.md／TASKS.md ではなく Tasks セクションを解析します。終了コード 1 → 停止します。スクリプトがない場合は、8 つの phase-contract ルールを手作業で適用し、判定がより弱いことを明記して開示します。
3. 書き込み前のマッパー — implement ステップでは、ブランチ作成、計画コミット、ソース／テストの編集より前に、書き込み前マッパーの契約を確定します（implementation-discovery）。このマッパーは 7 つのエビデンスに関する質問を解決し、READY | REPLAN | NEEDS-DESIGN | BLOCKED に振り分けます。最初の書き込みを許可するのは READY のみです。
4. 依存関係／不変条件のチェック — unit-lane のトリアージカタログのルールに従います。必要な依存関係がマージ済みであること、不変条件が維持されていること、または明示的な判断が記録されていることを確認します（編集前に violates／introduces／changes をブロックします）。

4. ステップを実行する

このステップについて unit-lane のリファレンス（references/STEPS.md のカタログ）に従います。つまり、ステップのリファレンスファイルを読み、チェックリストを実行し、作業をコミットします。implement ステップでは、効果がある箇所（コア／ドメイン、オーケストレーション）はテストを先に記述します（実装前に、失敗する red 実行のコマンド、終了コード、失敗したテスト名を記録し、その後 green にします）。UI／アダプターの接着コードは、後からテストしてもかまいません。

5. ステップ後

1. 差分ガード（実装ステップのみ）：bun scripts/diff-guard.mjs --base <last-step-commit> --unit <unit> を実行します — ブロックをそのまま貼り付けます。違反 → 停止 （再トリアージするか、例外を記録します）。不正な操作の防止：コメント、 空行、ドキュメント、テストを削除して差分を決して縮小しないでください。
2. エビデンス行：満たしたACごとに1行 — | AC | command | exit/digest | output (≤2 lines) | verified-by |。Evidenceセクションに追記します。
3. 進捗ログ：日付付きのエントリーを追記します — YYYY-MM-DD HH:MM — <what was done> → <commit sha> — next: <what is next>。
4. コミット：git add <changed files>、続けて git commit -m "<type>(<scope>): <step-summary>" を実行し、SHAを貼り付けます。

6. レッドゲート（修復ループ）

各ステップの後に、プロジェクトの検証ゲート（型チェック＋テスト＋ビルド）を実行します。

• ゲートがグリーン → 続行します。

• ゲートがレッド → 終了コードと失敗したテスト名を進捗ログに記録し、 同じステップを修復して再試行します。既定値は --max-attempts 3 です（ユーザー指定値が優先されます）。

• 試行回数を使い切った場合 → 次の内容で停止します。

  UNIT LOOP — <unit> BLOCKED at <P<k>>
  Reason: <NO-PROGRESS|ATTEMPT-BUDGET> · Attempts: <n>
  Last validator: <command> → <exit/status + compact failure>
  Preserved: no red commit; acceptance blob <sha> unchanged
  
  → Next: inspect the named blocker, then re-run /execute-phase <unit> <P<k>>
    · architecture/product decision required → resolve it before resuming
    · continue atomically → /execute-phase <unit> <P<k>>
  

7. ユニット全体モード

ステップを指定せずに <NN-slug> として呼び出された場合、残りのすべてのステップを それぞれ1コミットで順に実行します。各ステップの後に、ゲート、実行、差分ガード（実装の場合）、 エビデンス／進捗の更新、コミットを行います。中間レビューのチェックポイントは省略し、 必須の最終レビューで累積した差分全体を確認します。いずれかのステップでゲートがレッドになった場合は、 そのステップを修復して（--max-attempts 回まで）からループを続行します。最終出力：

UNIT LOOP — <unit> COMPLETE
Steps: <n> · Commits: <sha list> · Gate: PASS
PR: <url>

→ Next: /review-change on the changed HEAD — the mandatory end review
  · findings (REVIEW-FAIL) → /fold-findings repairs them; a fresh /review-change follows the fold
  · merge gate after REVIEW-PASS → /audit-pr

8. スコープ除外ガード

実行中にあらゆるイシューを作成する前に、スコープ除外テストで分類します。 スコープ除外（受け入れ基準またはタスクをスコープ外に移すこと）には、 まずユーザーの明示的な承認が必要です。その後、ユニットドキュメントの ## References セクションに（フォローアップイシューではなく）次の形式で記録します。 - <YYYY-MM-DD> — descoped: "<criterion>" — approved by user。 スコープ除外を最初に記録する場所として、イシューを使用してはなりません。

必須の参照資料

トピックが対象となる場合、次のファイルを読み込む必要があります。

• PREFLIGHT.md — すべてのゲートブロック（依存関係、ステータス、実行前、エビデンス、リント、パス保護）
• EXECUTION_CONTRACT.md — ステップ完了ゲート、アーキテクチャ上の不変条件
• PRE_EXECUTION_GATE.md — 実行前レビューゲート、正規化の順序
• FOLDING.md — レビュー指摘の取り込みサイクル
• DESCOPE.md — スコープ除外テストと改訂ルール
• FORGE_BODY.md — Forge操作（gh body-fileルール）

ガードレール

許可される操作：

• ユニットドキュメントのEvidenceヘッダーに記載された、トリアージ済みのステップのみ
• 受け入れ基準とステップのタスクに限定した変更
• ユニットドキュメントの更新（Evidence、Progress、References）
• プロジェクトのワークフロー規約に従ったConventional Commitメッセージ
• ステップ固有の参照ファイル（ユニットドキュメントのカタログから1段階たどって読む）

禁止事項：

• レッド（テスト失敗）の状態でコミットしてはなりません — ステップのスコープ内で修正するか、ブロッカーを記録して停止します。
• バリデーターを弱めてはなりません（アサーションを緩める、カバレッジを減らすなど）— 修復後もアサーションは少なくとも同等の強さを維持する必要があります。
• トリアージでスキップされたステップを実行してはなりません — カタログが正となります。
• ユニットドキュメントの受け入れ基準を編集してはなりません（これはユーザーの同意を得た再トリアージにあたります）。
• Non-goalsで定義された範囲を超えてスコープを拡大してはなりません — 実装中に見つかった指摘によってユニットの範囲を広げてはなりません。
• 受け入れ基準を作り出してはなりません — 具体的な選択肢を示してユーザーに確認してください。

他のスキルとの関係

unit-lane は（トリアージ → 手順 → ドキュメント更新）を実行し、このスキルは（1 ステップずつ、または残りすべてのステップ）を実行します。fold-findings はレビューで見つかった指摘の修正を担当します。レビューの各観点（review-implementation、review-code、review-security、review-perf、review-a11y、review-debt）がレビューのステップを構成し、workflow-status はここに処理を振り分けます。triage-issue は課題をレーンに取り込みます。このスキルは、ユニットのトリアージ済みステップを完全なゲートの仕組みのもとで実行するために、各ターンで呼び出されるステップ実行ツールです。

移植性（Claude Code 以外のエージェント）

• スラッシュメニューはありません — 新しい会話でこの SKILL.md を開き、その記述に厳密に従ってください。run と書かれている場合は、シェルコマンドを直接実行します。
• モデルのティアはありません — トリアージとレビューには最も高性能なモデルを使い、実行ステップにはより安価なモデルを使ってもかまいません。作成者より性能の低いモデルでレビューを行わないでください。
• /loop／サブエージェントはありません — 残りすべてのステップには <NN-slug>（組み込みのループ）を、個別のステップには <NN-slug> P<k> を呼び出してください。
• 新しいワーカーはありません — インラインで実行し、各コミット後に状態をユニットのドキュメントに集約してください。以前のファイルを再読しないでください。

完了条件

• 要求された範囲（残りすべてのステップ、または明示された 1 ステップ）が実装され、ゲートが合格し、ユニットのドキュメントの Evidence／Progress が最新で、作業がコミットされていること。
• 最後の → Next: ブロックが出力されていること。

終了時の推奨事項

→ Next: /unit-lane <NN-slug> — the conductor continues with the next triaged step
  · all steps done → /review-change — the mandatory end review
  · findings (REVIEW-FAIL) → /fold-findings repairs them; a fresh /review-change follows the fold
  · merge gate after REVIEW-PASS → /audit-pr — the merge gate