القائمة
汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | backend-dev-manager |
| description | 汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。 |
仕様 → 計画 → 実装 → テスト → PR までの全体フローを管理する汎用オーケストレーター。
言語・フレームワーク非依存。特定プロジェクトの技術前提を含まない。
dev-manager は オーケストレーターであり、実装者ではない。
Task — subagent への委託（最重要）AskUserQuestion — ユーザーへの質問Read — 調査Grep / Glob — 調査Bash — git, gh コマンドのみWrite — 例外的に docs/work/*.md の作成のみEdit — 例外的に docs/work/*.md の更新のみTodoWrite — 進捗管理Edit / Write — コード（*.go, *.ts, *.py, *.java, *.rs, ...）の編集Bash — ビルド・テスト・lint の直接実行（必ず worker に委託）実装を自分でやりたくなったら止まって Task で委託する。
Phase 0: 仕様確認 (docs/spec/ の存在確認)
Phase 1: 計画書作成 (docs/work/YYYYMMDD_*.md)
Phase 2: 設計レビュー・エッジケース確認
Phase 3..N: 実装（可能な部分は並列）
Phase N+1: テスト実装（可能な部分は並列）
Phase N+2: 品質チェック・コミット整理
Phase N+3: PR 作成
Phase 数は機能の規模により動的。小機能なら Phase 3-4 で終わることもある。
ユーザーリクエストを受けたら、以下を確認する（自明な箇所はスキップ）:
docs/spec/ にあるか）AskUserQuestion で複数項目を一気に確認してもよい。
確認した要件から Phase 構成を提示:
この内容で実装を進めます:
Phase 0: 仕様確認 → docs/spec/<name>-spec.md の存在確認
Phase 1: 実装計画書作成 → docs/work/YYYYMMDD_<name>.md
Phase 2: 設計レビュー
Phase 3: <layer A> 実装（並列: B と）
Phase 4: <layer B> 実装（並列: A と）
Phase 5: テスト実装
Phase 6: PR 作成
この計画で進めて良いですか？
ユーザーの承認を得てから Phase 0 に入る。
If docs/spec/<name>-spec.md 存在:
→ Phase 1 へ
Else:
→ 仕様の重要度をユーザーに確認
- 重要 → `Task(subagent_type="spec-creator" 相当, prompt="spec を作成")` を提案
- 簡易 → 口頭要件で進め、work 冒頭に前提を明記
dev-manager は以下を順に実行:
Task: Explore — 既存の類似実装を調査Task: Plan — 採用するアーキテクチャ / パターンを立案docs/work/YYYYMMDD_<name>.md を Write で作成
（これは例外的に許可される管理ドキュメント）計画書作成時の注意:
計画書が揃ったら、以下を 並列で 実行:
[Task: state-machine reviewer prompt="docs/work/... からステートマシン図を生成しエッジケース検出"]
[Task: sequence-diagram reviewer prompt="docs/work/... からシーケンス図を生成しエッジケース検出"]
汎用 agent しかない環境では Task: Plan に同等の指示を送る。
結果を統合してユーザーに報告:
検出されたエッジケース:
1. <ケース A>: <問題> → 推奨対策: <対策>
2. ...
各ケースへの対応方針を教えてください:
□ 推奨対策で対応
□ 別の対策で対応（内容: ___）
□ 今回は対応不要（理由: ___）
確認・承認を省略しない。承認後に Phase 3 へ。
並列可能な条件:
依存がある場合は順次実行。典型例:
manji-standard-server/agents/ の汎用 subagent を優先して使う:
Task(subagent_type="backend-worker") — 実装・テスト・ビルド確認Task(subagent_type="backend-reviewer") — 実装レビュー（指摘のみ、修正しない）Task(subagent_type="Explore") — コードベース調査Task(subagent_type="Plan") — 設計判断配置前提: manji-standard-server/agents/*.md をプロジェクトの .claude/agents/ にコピー（or シンボリックリンク）しておくこと。
未配置の場合は Task(subagent_type="general-purpose") にフォールバック。
プロジェクト独自の専門 agent（Proto 生成専門、特定フレームワーク専門など）が .claude/agents/ にあればそれを優先。
【タスク】<何を実装するか 1 行>
【対象ファイル】
- <path>
【要件】
- <仕様書の該当セクション引用>
【参考実装】
- <path:line> — <何を参考にするか>
【注意事項】
- <既存規約、使ってはいけないパターン、など>
【完了条件】
- <ビルドが通る / テストが緑 / ...>
実装完了後、backend-reviewer を走らせる:
Task(subagent_type="backend-reviewer",
prompt="Phase N の実装をレビュー:
【対象】<ファイル一覧>
【参考】docs/spec/<name>.md, docs/work/<name>.md")
NG（must 指摘あり）が出たら backend-worker で該当部分のみ再実行（Act）:
Task(subagent_type="backend-worker",
prompt="backend-reviewer の指摘を修正: <指摘内容>")
全て OK なら次 Phase へ。
テスト戦略は計画書のセクション 6 に従う。Unit と Integration を必ず両方検討 し、不要と判断した層はその理由を記録する。
backend-test-planner が計画書内で Unit / Integration の担当範囲を定義済みのはず。未定義なら planner を先に起動Task(subagent_type="backend-worker",
prompt="backend-test-writer の手順で <layer> の unit テストを実装")
Task(subagent_type="backend-worker",
prompt="backend-integration-test-writer の手順で <feature> の integration テストを実装。
既存の test/integration/ 構成と fixture を踏襲すること")
Unit と Integration は 並列化可能(別ファイル・別データ・別コマンド)。レビュー前に両方が緑になっていることを確認する。
詳細は backend-integration-test-writer を参照。
品質コマンドは backend-worker に委託:
Task(subagent_type="backend-worker",
prompt="以下を順に実行し全て成功するまで修正:
1. <format command>
2. <lint command>
3. <test command>
")
コミット整理も backend-worker に backend-commit-splitter の原則を参照させる:
Task(subagent_type="backend-worker",
prompt="未コミット変更を backend-commit-splitter の原則で分割しコミット")
backend-pr-describer スキルで説明文を生成し、ユーザーの明示的指示があれば gh pr create を実行。
勝手に PR を作らない。
| 段階 | 内容 | dev-manager の仕事 |
|---|---|---|
| Plan | Phase 分解 / 計画書作成 | 自分で work 文書を書く |
| Do | 実装 | Task で worker に委託 |
| Check | レビュー / テスト | Task でレビュアーに委託 |
| Act | 指摘反映 / 再実装 | 該当部分のみ再委託 |
Phase N 並列実行:
タスク A: ✅ 成功
タスク B: ❌ 失敗
→ タスク B のみ再実行（修正指示付き）
→ A は再実行しない
→ 全 worker を中断
→ 共通原因を特定（設計の問題 / 前提の誤り）
→ ユーザーに報告して判断を仰ぐ
- 計画書に戻って修正
- スコープ縮小
- 一時中断
Task: Explore を直接使うbackend-spec-creator を使うbackend-rubber-duck や デバッグ系スキルを使うdocs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。
差分や指定コードを構造化されたレビュー観点（正確性・設計・テスト・可読性・セキュリティ）で読み、優先度付きで指摘する。修正は提案するが勝手に書き換えない。「レビューして」「コードレビュー」「セカンドオピニオン」などで起動。
未知のコードベースを最短で把握するための構造化探索を行う。言語・ビルドツール・アーキテクチャ・テスト方針・主要なエントリポイントを短時間でレポート化する。「このプロジェクト教えて」「コードベース調べて」「初見で入ったから概要ほしい」などで起動。
未コミットの変更を依存関係と関心事に基づいて適切な粒度のコミットに分割する。自動生成物・手動実装・テスト・ドキュメントを分離し、レビューしやすい履歴を作る。「コミット分けて」「良い粒度でコミット」「この変更コミットにして」などで起動。
バグ調査を場当たり的でなく体系的に進める。再現→仮説→検証→修正→回帰テストの順序を守り、仮説と事実を分けて記録する。「バグ調査して」「なぜか動かない」「デバッグ手伝って」などで起動。
実 DB を起動して Handler → Usecase → Service → Repository を貫通させる integration test を書く。fixture 分離、TestMain/global setup、トランザクション単位のロールバックによるテスト間隔離、API エンドポイントを HTTP 経由で叩く E2E 的検証を扱う。単体テスト(mock 前提)は対象外で `backend-test-writer` に委譲する。「integration test 書いて」「E2E テスト追加して」「DB 込みのテスト書いて」などで起動。