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のワークフローで自動実行するオーケストレーションスキル。
Scanned 9/12/2026
Install to Claude Code
npx -y skills add aibot88/sec_skill_store --skill dev-run --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Dev Run?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/aibot88-dev-run)More formats (shields.io, HTML) on the badges page.
---
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: 最終レポート
ユーザーに以下を出力する:
```markdown
## 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` が存在するか確認する。存在する場合:
1. `docker compose down` を実行してコンテナを停止する
2. 停止に失敗した場合はユーザーに報告する(ブロッキングにしない)
## エスカレーション条件
以下の場合は自動実行を停止し、AskUserQuestion でユーザーに確認する:
1. **範囲外依存が未完了**: 依存先タスクが done でない
2. **impl + debug 両方失敗**: サブエージェントが修正できなかった
3. **verify 2サイクル後も問題残存**: 残存問題をレポートして終了
4. **🔴 セキュリティ/パフォーマンス問題**: レポートに明記、人間レビュー推奨
5. **context.md / plan が存在しない**: 前提スキルの実行を案内して終了
## マーカー文字列
| マーカー | 意味 |
|---------|------|
| `IMPL_SUCCESS` | 実装成功(テスト全通過) |
| `IMPL_FAILED` | 実装失敗(3サイクル超え) |
| `DEBUG_SUCCESS` | デバッグ成功(エラー解消) |
| `DEBUG_FAILED` | デバッグ失敗(3サイクル超え) |
| `VERIFY_ALL_PASSED` | 検証全項目 OK |
| `VERIFY_ISSUES_FOUND` | 検証で問題あり |
## ルール・制約
- context.md が存在しない場合は `/dev-context` を案内して終了する
- plan が存在しない場合は `/dev-plan` を案内して終了する
- `status: done` のタスクはスキップする(再開対応)
- verify → fix → re-verify のサイクルは最大2回
- サブエージェントには Task ツールを使用させない(プロンプトで明示)
- 各プロンプトに context.md を埋め込みサブエージェントの Read 回数を最小化する
- テスト/ビルド/Lint コマンドは context.md から取得する(ハードコードしない)
- すべてのファイルは 500 行以内
- Bash コマンドはプロジェクトルートの **絶対パス** を使用する(`$(git rev-parse --show-toplevel)` でルートを取得)
## 追加リソース
### リファレンスファイル
- **`references/impl-prompt-template.md`** — impl サブエージェントに渡すプロンプトテンプレート
- **`references/debug-prompt-template.md`** — debug サブエージェントに渡すプロンプトテンプレート
- **`references/verify-prompt-template.md`** — verify サブエージェントに渡すプロンプトテンプレート
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!