backend-dev-manager

name	backend-dev-manager
description	汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。

Dev Manager (Generic)

仕様 → 計画 → 実装 → テスト → 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 で終わることもある。

Stage 1: 要件明確化

ユーザーリクエストを受けたら、以下を確認する（自明な箇所はスキップ）:

• 実装範囲（API / UI / インフラ / DB / ドキュメント のどれを含むか）
• 既存仕様の所在（docs/spec/ にあるか）
• 完了条件
• 期限・制約

AskUserQuestion で複数項目を一気に確認してもよい。

Stage 2: Phase 計画プレビュー

確認した要件から 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 に入る。

Phase 0: 仕様確認

If docs/spec/<name>-spec.md 存在:
  → Phase 1 へ
Else:
  → 仕様の重要度をユーザーに確認
    - 重要 → `Task(subagent_type="spec-creator" 相当, prompt="spec を作成")` を提案
    - 簡易 → 口頭要件で進め、work 冒頭に前提を明記

Phase 1: 計画書作成

dev-manager は以下を順に実行:

1. Task: Explore — 既存の類似実装を調査
2. Task: Plan — 採用するアーキテクチャ / パターンを立案
3. dev-manager 自身が docs/work/YYYYMMDD_<name>.md を Write で作成 （これは例外的に許可される管理ドキュメント）
4. 計画書の内容は work-planner の SKILL.md のテンプレートに従う

計画書作成時の注意:

• 調査結果を統合して書く（Explore / Plan の結果を貼り付けない）
• 具体的なファイルパス・行番号を参照先として明記
• 実装コードは書かない（参考 path の列挙まで）

Phase 2: 設計レビュー・エッジケース確認

計画書が揃ったら、以下を 並列で 実行:

[Task: state-machine reviewer prompt="docs/work/... からステートマシン図を生成しエッジケース検出"]
[Task: sequence-diagram reviewer prompt="docs/work/... からシーケンス図を生成しエッジケース検出"]

汎用 agent しかない環境では Task: Plan に同等の指示を送る。

結果を統合してユーザーに報告:

検出されたエッジケース:
1. <ケース A>: <問題> → 推奨対策: <対策>
2. ...

各ケースへの対応方針を教えてください:
□ 推奨対策で対応
□ 別の対策で対応（内容: ___）
□ 今回は対応不要（理由: ___）

確認・承認を省略しない。承認後に Phase 3 へ。

Phase 3..N: 実装

並列化の原則

並列可能な条件:

• 依存関係なし（入力・出力が独立）
• 同一ファイルを編集しない
• 使う agent が並列実行に対応

依存がある場合は順次実行。典型例:

• データモデル → ビジネスロジック → インターフェース
• 実装 → テスト（同じ agent なら順次、別 agent なら並列可）

委託先

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> — <何を参考にするか>

【注意事項】
- <既存規約、使ってはいけないパターン、など>

【完了条件】
- <ビルドが通る / テストが緑 / ...>

各 Phase 後のレビュー

実装完了後、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 へ。

Phase N+1: テスト

テスト戦略は計画書のセクション 6 に従う。Unit と Integration を必ず両方検討 し、不要と判断した層はその理由を記録する。

テスト Phase の標準フロー

1. テスト計画の再確認 — backend-test-planner が計画書内で Unit / Integration の担当範囲を定義済みのはず。未定義なら planner を先に起動
2. Unit テスト実装 — mock 前提、Service / Usecase のロジック分岐検証が中心

   Task(subagent_type="backend-worker",
        prompt="backend-test-writer の手順で <layer> の unit テストを実装")
   

3. Integration テスト実装 — 実 DB 起動、Handler → Repository 貫通、proto ↔ Entity 変換やトランザクション境界までを検証

   Task(subagent_type="backend-worker",
        prompt="backend-integration-test-writer の手順で <feature> の integration テストを実装。
                既存の test/integration/ 構成と fixture を踏襲すること")
   

Unit と Integration は 並列化可能(別ファイル・別データ・別コマンド)。レビュー前に両方が緑になっていることを確認する。

Integration テストの追加要件

• docker-compose や CI の service container で Postgres 等を起動
• fixture は TestMain / global setup で一度だけ投入
• テスト間はトランザクションロールバック等で隔離
• API を HTTP 境界経由で叩く(Repository 直叩きしない)

詳細は backend-integration-test-writer を参照。

Phase N+2: 品質チェック・コミット整理

品質コマンドは 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 の原則で分割しコミット")

Phase N+3: PR 作成

backend-pr-describer スキルで説明文を生成し、ユーザーの明示的指示があれば gh pr create を実行。

勝手に PR を作らない。

PDCA の実装

段階	内容	dev-manager の仕事
Plan	Phase 分解 / 計画書作成	自分で work 文書を書く
Do	実装	Task で worker に委託
Check	レビュー / テスト	Task でレビュアーに委託
Act	指摘反映 / 再実装	該当部分のみ再委託

エラーハンドリング

部分失敗

Phase N 並列実行:
  タスク A: ✅ 成功
  タスク B: ❌ 失敗

→ タスク B のみ再実行（修正指示付き）
→ A は再実行しない

全失敗

→ 全 worker を中断
→ 共通原因を特定（設計の問題 / 前提の誤り）
→ ユーザーに報告して判断を仰ぐ
  - 計画書に戻って修正
  - スコープ縮小
  - 一時中断

リトライ戦略

• 自動リトライ: 1 回まで（同じ指示）
• 修正リトライ: 2 回まで（修正指示付き）
• エスカレーション: 3 回失敗でユーザー報告

いつ使うか

• 機能規模が中〜大（Phase 3 以上に分けたくなる）
• 並列化で時間短縮したい
• 計画書を残す必要がある（他メンバーのレビュー前提、チーム開発）

いつ使わないか

• 小さな修正（1-2 ファイル）→ 直接実装
• 調査のみ → Task: Explore を直接使う
• 仕様策定のみ → backend-spec-creator を使う
• デバッグ → backend-rubber-duck や デバッグ系スキルを使う

関連

• backend-spec-creator — Phase 0 で仕様が無い場合に先行
• backend-work-planner — Phase 1 の計画書テンプレートを提供
• backend-commit-splitter — Phase N+2 のコミット分割
• backend-pr-describer — Phase N+3 の PR 文生成
• backend-test-planner — Phase N+1 のテスト戦略(Unit / Integration の区分けを設計)
• backend-test-writer — Phase N+1 の Unit テスト実装
• backend-integration-test-writer — Phase N+1 の Integration テスト実装