/dev-run

name: dev-run
description: This skill should be used when the user asks to "dev-run", "自動実装", "タスクを一括実装", "auto implement", "run all tasks", "タスクを自動実行", "バッチ実装", "dev-run auth 001 005". Plan内の指定範囲のタスクをdev-impl/dev-verify/dev-debugのワークフローで自動実行するオーケストレーションスキル。
argument-hint: '<plan-name> <from-task-id> <to-task-id>'

Dev Run

Plan 内の指定範囲タスクに対し、impl → verify → debug のループを自動実行するオーケストレーションスキル。各タスクを Task サブエージェントに委託し、TaskCreate/TaskUpdate で依存関係付きの進捗管理を行う。

前提知識

dev-* スキルフロー内の位置

dev-context → dev-plan → [dev-run] → (完了)
                            ├─ impl サブエージェント (×タスク数)
                            ├─ debug サブエージェント (エラー時)
                            └─ verify サブエージェント (全タスク完了後)

引数フォーマット

/dev-run <plan-name> <from-task-id> <to-task-id>

• `plan-name`: 既存の Plan 名（`docs/dev/plans/<plan-name>/` が存在すること）
• `from-task-id`: 開始タスク ID（例: "001"）
• `to-task-id`: 終了タスク ID（例: "005"）

サブエージェント制約（重要）

サブエージェントは Task ツールを使用できない（ネスト不可のアーキテクチャ制約）。そのため:

• コード探索は Glob/Grep/Read を直接使用する
• TodoWrite は使用しない（TaskCreate/TaskUpdate で進捗管理する）
• プロンプトに context.md を埋め込み、サブエージェントのファイル読み込みを最小化する

ワークフロー

Step 1: 事前検証とコンテキスト読み込み

1. `docs/dev/context.md` の存在を確認する。存在しない場合は `/dev-context` の実行を案内して終了する 2. `docs/dev/plans/<plan-name>/` の存在を確認する。存在しない場合は `/dev-plan` の実行を案内して終了する 3. `docs/dev/context.md` を Read で読み込み、以下を抽出する:

• テスト実行コマンド（Test Framework セクション）
• ビルドコマンド（Build & Run セクション、あれば）
• Lint コマンド（Build & Run セクション、あれば）
• カバレッジ閾値（Test Framework セクションの Coverage Threshold）

4. `docs/dev/plans/<plan-name>/plan.md` を Read で読み込む 5. 指定範囲（from-task-id 〜 to-task-id）の全タスクファイルを Glob + Read で読み込む 6. 各タスクの `status`, `dependencies`, `estimated_complexity` を確認する

範囲外依存チェック

タスクファイルの `dependencies` に、指定範囲外のタスク ID が含まれる場合:

• そのタスクファイルを Read し、`status` を確認する
• `status: done` → 問題なし
• それ以外 → AskUserQuestion でユーザーに警告し、続行/中断を確認する

Step 2: TaskCreate で依存関係グラフ構築

2a. タスクの登録

指定範囲内で `status` が `done` でないタスクごとに TaskCreate を実行する:

TaskCreate:
  subject: "impl-NNN: <タスクタイトル>"
  description: "Plan <plan-name> のタスク NNN を TDD 実装する"
  activeForm: "Implementing task NNN: <タスクタイトル>"

2b. 依存関係の設定

タスクファイルの `dependencies` を TaskUpdate の `addBlockedBy` にマッピングする。

ID マッピングテーブルを構築: `{"001": "<TaskCreate_ID>", "002": "<TaskCreate_ID>", ...}`

• 範囲内の依存: 対応する TaskCreate ID を blockedBy に設定
• 範囲外の依存（done 済み）: blockedBy から除外
• `status: done` のタスク: TaskCreate しない、依存元からも除外

2c. verify タスクの登録

TaskCreate:
  subject: "verify: <plan-name>"
  description: "Plan <plan-name> の全体検証を実行する"
  activeForm: "Verifying plan <plan-name>"
  addBlockedBy: [全 impl タスクの ID]

Step 3: 実装ループ

TaskList で `status: pending` かつ `blockedBy` が空のタスクを取得し、順に実行する。

3a. impl タスクの実行

1. TaskUpdate で `in_progress` にする 2. `references/impl-prompt-template.md` を Read で読み込む 3. テンプレートのプレースホルダーを置換する:

• `{{CONTEXT_MD_CONTENT}}` ← context.md の全文
• `{{TASK_FILE_CONTENT}}` ← タスクファイルの全文
• `{{PLAN_MD_EXCERPT}}` ← plan.md の設計概要
• `{{TEST_COMMAND}}` ← テスト実行コマンド
• `{{TASK_FILE_PATH}}` ← タスクファイルのパス
• `{{ESTIMATED_COMPLEXITY}}` ← タスクの複雑度
• `{{COVERAGE_THRESHOLD}}` ← カバレッジ閾値

4. Task サブエージェント（general-purpose）を起動する 5. サブエージェントの出力を確認する:

• `IMPL_SUCCESS` を含む → 成功処理（3c へ）
• `IMPL_FAILED` を含む → debug 処理（3b へ）

3b. debug 処理（impl 失敗時）

1. impl サブエージェントの出力からエラー情報を抽出する 2. `references/debug-prompt-template.md` を Read で読み込む 3. テンプレートのプレースホルダーを置換する:

• `{{CONTEXT_MD_CONTENT}}` ← context.md の全文
• `{{ERROR_DETAILS}}` ← エラー情報（impl の出力から抽出）
• `{{TASK_FILE_CONTENT}}` ← タスクファイルの全文
• `{{TEST_COMMAND}}` ← テスト実行コマンド

4. Task サブエージェント（general-purpose）を起動する 5. サブエージェントの出力を確認する:

• `DEBUG_SUCCESS` → 成功処理（3c へ）
• `DEBUG_FAILED` → エスカレーション:

AskUserQuestion で以下を提示:

• このタスクをスキップして次へ進む
• 自動実行を中断する
• 手動修正後に再開する

3c. 成功処理

1. タスクファイルの frontmatter `status` を `done` に更新する（Edit ツール使用）

• **注意**: dev-run の allowed-tools に Edit は含まれないため、ここはサブエージェント内で実施済みのはず。サブエージェントが更新していない場合は Read で確認する

2. TaskUpdate で `completed` にする 3. TaskList で次のブロック解除タスクを確認する 4. 次のタスクがあれば 3a に戻る

Step 4: 全体検証（verify タスク実行）

全 impl タスクが completed になると verify タスクのブロックが解除される。

1. TaskUpdate で verify を `in_progress` にする 2. `references/verify-prompt-template.md` を Read で読み込む 3. テンプレートのプレースホルダーを置換する:

• `{{CONTEXT_MD_CONTENT}}` ← context.md の全文
• `{{PLAN_NAME}}` ← Plan 名
• `{{TEST_COMMAND}}`, `{{BUILD_COMMAND}}`, `{{LINT_COMMAND}}`
• `{{COVERAGE_THRESHOLD}}` ← カバレッジ閾値
• `{{TODAY_DATE}}` ← 実行日（YYYY-MM-DD）

4. Task サブエージェント（general-purpose）を起動する 5. サブエージェントが検証レポートを `docs/dev/plans/<plan-name>/reports/verify-<日付>.md` に出力する

Step 5: 検証結果パースと修正ループ

verify サブエージェント完了後:

1. 出力マーカーを確認する:

• `VERIFY_ALL_PASSED` → 全パス、Step 6 へ
• `VERIFY_ISSUES_FOUND` → 修正ループへ

修正ループ（最大2サイクル）

サイクルごとに:

1. レポートファイルを Read で読み込む 2. Issues Found セクションから問題を抽出する 3. 問題ごとに fix タスクを TaskCreate する:

   subject: "fix-NNN: <問題概要>"
   activeForm: "Fixing: <問題概要>"
   addBlockedBy: [verify タスクの ID]

4. re-verify タスクを TaskCreate する:

   subject: "re-verify-N: <plan-name>"
   activeForm: "Re-verifying plan <plan-name>"
   addBlockedBy: [全 fix タスクの ID]

5. fix タスクを実行する（debug サブエージェント使用、3b と同じフロー） 6. re-verify タスクを実行する（verify サブエージェント使用、Step 4 と同じフロー） 7. 結果を確認:

• 全パス → Step 6 へ
• まだ問題あり:
• サイクル 1 → サイクル 2 へ
• サイクル 2 → 残存問題を報告して Step 6 へ

Step 6: 最終レポート

ユーザーに以下を出力する:

## dev-run 完了レポート

### 実行概要
- Plan: <plan-name>
- 範囲: <from-task-id> 〜 <to-task-id>
- 実行タスク数: X / スキップ: Y (done 済み)

### 結果サマリー
| タスク | 結果 | 信号機 |
|-------|------|--------|
| NNN | 成功 / debug後成功 / スキップ | 🔵/🟡/🔴 |

### 検証結果
- テスト: X passed, Y failed
- カバレッジ: X/Y packages above threshold
- ビルド: OK / NG / N/A
- Lint: OK / NG / N/A
- 500行ルール: OK / X files over

### verify → fix サイクル
- サイクル N: [修正内容の概要]

### 残存問題（ある場合）
- [問題の詳細と推奨アクション]

### 🟡 要確認ファイル
- [ファイル一覧と確認ポイント]

### 🔴 要判断ファイル
- [ファイル一覧と判断が必要な理由]

Step 7: Docker クリーンアップ

プロジェクトルートに `docker-compose.yml` または `docker-compose.yaml` が存在するか確認する。存