| name | ai-dev-exec |
| description | PlanGate の exec フェーズを TDD で実行する。Use when: C-3 APPROVED 後にコード実装を開始したい時、workflow-conductor 配下で実装タスクを進めたい時。 |
AI-Driven Exec (PlanGate / Codex 共用)
PlanGate ワークフローの exec フェーズ（WF-04 Build & Refine） を Codex / Claude Code 両方で実行する skill。
前提条件（exec 開始ゲート）
-
docs/working/TASK-XXXX/approvals/c3.json が存在し、その approval_kind に応じた承認条件を
満たすこと。判別は python3 の strict JSON で行う（非アンカーな grep/sed は c3-prime で
誤動作する。契約 §5）:
| record 種別 | 判別 | 承認済みと見なす条件 |
|---|
| legacy | approval_kind キー なし | c3_status: APPROVED |
| c3-prime | approval_kind: "c3-prime" | decision: "AUTO_APPROVED"（c3_status は契約 §5 で明示禁止。含まれていたら FAIL）かつ Plan Package 束縛の全数検証 PASS（plan_hash / artifact_hashes 6 要素 / plan_package_hash / source_sha / reviewer verdict 整合）。正本: docs/workflows/ai-loop/c3-prime-contract.md §2〜§5 |
| それ以外の値 | — | 受理拒否（exec 不可） |
-
validate 相当が PASS（plan_hash 整合 / artifact 整合 / EH-3 整合）
-
exec 入口も上記 1 と同じ分岐で承認済み record のみ受理する（CLI がある環境では
CLI 側が機械チェック済み。CLI が無い環境では自分で確認する）
これらが満たされなければ exec を開始しない。実際のコマンド表記（bin/plangate /
plangate / CLI 不在）・TASK-XXXX の解決先・CLI が無い環境での代替手順は
「CLI 呼び出し」節を参照する（CLI が無いことを理由にゲートを省略しない）。
settings タスクロック (plangate doctor --check-settings) は V-1 / handoff 完了の前提条件（.claude/rules/working-context.md → fallback <plugin_root>/rules/working-context.md が正本）。exec 入口では block しない。詳細は ai-dev-verify skill。
Read First
参照解決順（導入先で必ずこの順に探す）
本 skill の参照は上流リポジトリ（s977043/plangate）基準の相対パスで書かれている。
導入先ではそのままでは解決できないものがあるため、次の順で探索する:
- 導入先リポジトリの相対パス（例:
.claude/rules/working-context.md）
- 無ければ plugin root 配下（例:
<plugin_root>/rules/working-context.md）
<plugin_root> は Bash で ls "${CLAUDE_PLUGIN_ROOT}/rules/" を実行して得た絶対パス。
Read ツールは絶対パスを要求し環境変数を展開しないため、${CLAUDE_PLUGIN_ROOT}/...
という文字列をそのまま Read しても必ず失敗する- 変数が空・未設定なら glob（
~/.claude/plugins/cache/** 等）で推測せず 3 へ進む
- どちらにも無い場合は 「解決できなかった」と明示し、推測で内容を補わない
plugin root 配下の探索は docs/** には適用しない（手順 2 は rules/*.md 等の
配布対象にのみ適用する）: plugin が配布するのは agents / commands / skills / rules 等の
定義ディレクトリのみで docs/ を配布対象として認識せず、plugin root 配下に相当する配布物が
存在しないため必ず空振りする。docs/** は手順 1 で解決できなければ手順 2 を飛ばして手順 3 へ進む。
| 参照 | install.sh --claude 経由 | plugin（Claude marketplace）経由 | Codex 経由 |
|---|
rules/*.md（下記 3〜5） | .claude/rules/ に着地（解決可） | <plugin_root>/rules/ で解決 | 未配置（解決不可 → 手順 3 へ） |
docs/**（docs/workflows/ai-loop/c3-prime-contract.md 等） | コピー対象外（解決不可） | バンドル対象外（解決不可） | 未配置（解決不可） |
bin/**（CLI） | コピー対象外（解決不可） | バンドル対象外（解決不可） | 未配置（解決不可） |
scripts/** | コピー対象外（解決不可） | <plugin_root>/scripts/ は存在するが install-plangate-skills.sh のみ（ai-dev-workflow / codex-guarded.sh 等は解決不可） | 未配置（解決不可） |
docs/working/TASK-XXXX/*（下記 6〜7）は配布物ではなく導入先で作成する作業成果物なので、
導入先リポジトリ内でそのまま解決する（存在しなければ plan フェーズが未完了）。
読む順序
CLAUDE.mdAGENTS.md.claude/rules/working-context.md → fallback <plugin_root>/rules/working-context.md（exec phase の出力規約）.claude/rules/hybrid-architecture.md → fallback <plugin_root>/rules/hybrid-architecture.md（Rule 1〜5）.claude/rules/responsibility-classes.md → fallback <plugin_root>/rules/responsibility-classes.md（AI-owned / Human-owned 境界）docs/working/TASK-XXXX/plan.md / todo.md / test-cases.mddocs/working/TASK-XXXX/current-state.md
Rules
- TDD 厳守: Red → Green → Refactor。test-cases.md の各 AC に対応するテストを先に書く。
- todo.md 順守: depends_on を尊重し、🚩 checkpoint ごとに current-state.md 更新。
- 計画逸脱の即時記録: 計画外のリネーム / 削除 / 設計変更は status.md「計画からの変更点」に記録。
- scope 越境禁止: plan.md「Files / Components to Touch」外の変更は禁止。必要時は plan 再生成 + C-3 再承認。
- L-0〜V-4 は workflow-conductor が自動制御: 本 skill 範囲外。
- AI 自己改変ガード尊重:
.claude/settings*.json / Hardening Override 対象は触らない（Human-owned）。
- decision-log.jsonl 追記: 主要判断は append-only で記録。
Output
- 実装コード（plan.md「Files / Components to Touch」内）
- テストコード（test-cases.md と 1:1 対応）
docs/working/TASK-XXXX/current-state.md 更新docs/working/TASK-XXXX/status.md 追記docs/working/TASK-XXXX/decision-log.jsonl 追記
CLI 呼び出し
呼び出し表記は実行環境で変わる。相対パス形式（bin/plangate / ./scripts/...）が成立するのは
上流リポジトリ（s977043/plangate）を clone した cwd に居るときだけで、導入先には bin/ も
scripts/（の CLI 本体）も配置されない。導入先で PATH を通した場合のコマンド名は
plangate（bin/plangate ではない）。どちらの環境かを確定してから使う。
| 用途 | 上流リポジトリの cwd | 導入先 + PATH に plangate あり | 導入先 + PATH に無い（既定） |
|---|
| exec dispatch | bin/plangate exec TASK-XXXX [--mode <mode>] | plangate exec TASK-XXXX は実在するが対象が CLI 側（下記注意）→ 導入先の TASK には使えず手動で TDD 実行 | 手動で TDD 実行 |
| plan_hash / artifact 機械検証 | bin/plangate validate TASK-XXXX | plangate validate --dir docs/working/TASK-XXXX | 次節のフォールバック（sha256 突合） |
注意: TASK-XXXX 位置引数は cwd ではなく CLI 本体の位置を基準に解決される。
bin/plangate は自身のパスから plangate_root（= bin/ の親）を求め、
<CLI の repo root>/docs/working/TASK-XXXX を読み書きする。bin/ は導入先に配置されない
ため、PATH 上の plangate は必ず別の場所にある上流 clone の実体を指す。つまり導入先で
plangate exec TASK-XXXX を実行しても、対象は導入先の docs/working/ ではなく
その clone 側の docs/working/ になる。cwd 非依存でパスを明示できる --dir を持つのは
validate / validate-schemas だけで、exec / resume / status / review / eval /
metrics / context / render / approve に相当オプションは無い。
- 並行で
./scripts/ai-dev-workflow TASK-XXXX exec も利用可（上流リポジトリの cwd のみ。scripts/ai-dev-workflow は配布対象外）
- Codex CLI 経由の場合は
scripts/codex-guarded.sh --task TASK-XXXX exec --full-auto を推奨（上流リポジトリの cwd のみ。pre-flight で validate + doctor --check-settings 実行、post-flight で plan.md drift 検知）
❌ Codex CLI 物理 hook 等価達成 (PR #347) 未達成（2026-08-13 実測）: .codex/hooks.json は設定ファイル全体が parse 拒否されており、hook は 1 件も登録されていない。EH-1/2/3/6/9 は Codex session で一度も発火していない。scripts/codex-guarded.sh の session 前後検知は正規入口を経由した場合のみ機能する（入口を強制する機械ゲートは無い）。Codex session 中の write は物理 block されないものとして扱い、ゲートは人手で維持すること。 上流リポジトリでの詳細は docs/ai/settings-wiring-contract.md §Codex CLI parity を参照。これらは配布対象外でもあるため、導入先では下記フォールバックでゲートを人手維持する。
CLI 不在時のフォールバック（導入先では既定）
上表の「導入先 + PATH に無い（既定）」に該当する場合は次に従う:
-
exec 本体は手動で TDD 実行する — Red → Green → Refactor の順序と「Output」の出力契約は
CLI の有無に関わらず不変
-
exec 入口ゲート（前提条件）は自分で確認する — まず approvals/c3.json に
approval_kind キーがあるかを strict JSON で読んで経路を分ける
（python3 -c 'import json,sys; d=json.load(open(sys.argv[1])); print("approval_kind" in d)' <path>）。
(a) legacy c3.json（approval_kind キー無し）の場合 — c3_status が
APPROVED であることを読んで確認し、続けて plan_hash を突合する。plangate validate の
plan_hash 検査は plan.md の素の sha256（正規化・前処理なし）と c3.json の plan_hash
から sha256: prefix を除いた値の単純比較なので、CLI 無しで再現できる:
sha256sum docs/working/TASK-XXXX/plan.md | awk '{print $1}'
shasum -a 256 docs/working/TASK-XXXX/plan.md | awk '{print $1}'
openssl dgst -sha256 docs/working/TASK-XXXX/plan.md | awk '{print $NF}'
python3 -c 'import hashlib,sys; print(hashlib.sha256(open(sys.argv[1],"rb").read()).hexdigest())' docs/working/TASK-XXXX/plan.md
不一致なら C-3 承認後に plan が改変されている → exec に進まず、再承認（c3.json の
plan_hash 更新）または plan の revert を行う。上記 4 手段がすべて無い場合に限り
スキップし、その事実を decision-log.jsonl に記録して 「機械検証済み」と書かない
（python3 は PlanGate ツールチェーンの事実上の必須依存なので、実際にはほぼ到達しない）
(b) approval_kind: "c3-prime" の record の場合 — 上記 (a) の手順は使えない。
c3-prime は c3_status を持たず（契約 §5 で明示禁止）、plan_hash は legacy と同じ
sha256:<64hex> 形式だが top-level と reviewer snapshot に複数回出現するため、
非アンカーな grep/sed 抽出は多行マッチして誤動作する（契約 §5。読むなら python3 の
strict JSON のみ）。さらに受理には Plan Package 6 要素（pbi-input.md / plan.md /
todo.md / test-cases.md / / ）の
全数照合 + + （検証時点の対象 SHA と一致）+ reviewer
snapshot の三つ組一致 + までの束縛検証が必要
（正本: §3〜§5）。
— 単体の hash 一致だけで
入口ゲート確認済みとして exec に進むと、残り 5 artifact と の stale を見逃す。
この場合は item 4 の上流 clone 経由 で機械検証するか、
機械検証できない旨を に記録して
次フェーズへ
exec 完了後は ai-dev-verify skill で V-1〜V-4 + handoff.md 発行。L-0〜V-4 は workflow-conductor が自動進行。
