pm-planning について
PM エージェントがアーキテクチャ文書から、人向けの計画と着手可能な開発タスクを作るためのスキルです。小さな作業単位、明示的な依存関係と受け入れ条件を重視し、不完全な設計には差し戻します。
主な機能
- 01アーキテクチャ文書から計画とタスクを作成
- 024時間以内のタスクへの分割
- 03タスクの依存関係と担当者の指定
- 04具体的な完了条件の定義
- 05設計が不完全な場合の計画差し戻し
活用シーン
- 01開発エージェント向けの着手可能な作業準備
- 02機能を独立して納品できるタスクに分割
- 03依存関係のある並行タスクの調整
- 04計画前にアーキテクチャの明確化を依頼
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ avelikiy/ great_cto --skill pm-planningインストール後、Claude Code で/pm-planningを入力して読み込まれたか確認します。
詳細
PM による計画 — ARCH をタスクに分解する
pm エージェントの役割は、アーキテクトの ARCH ドキュメントを受け取り、次の 2 つを作成することです。
- 人間向けの
PLAN-<feature>.md - senior-dev が担当できる
bd createタスクの一連のリスト
新しい senior-dev(事前のコンテキストなし)が bd タスクに取り組み、確認のために戻ってくることなくリリースできれば、その計画は適切です。
分解のルール
ルール 1. タスクは 4 時間以内
それより大きいものは分割します。「認証システムを構築する」というタスクなら、次のように分割します。
- ユーザーテーブルのスキーママイグレーション
- ハッシュ化を行うサインアップエンドポイント
- JWT を発行するログインエンドポイント
- ログアウト/トークンの失効
- テスト
各タスクは 4 時間以内にします。分割できない場合、そのタスクは不明確です。ARCH に戻って明確にしてください。
ルール 2. タスクごとに成果物は 1 つ
各タスクで作成する成果物は、次のいずれか 1 つです。
- コードファイル(新規または変更)
- データベースマイグレーション
- テストファイル
- ドキュメントの更新
- 設定の変更
タスクで関連のない成果物が複数作成される場合は、分割してください。
ルール 3. --blocks で依存関係を明示する
タスク B がタスク A の成果物を必要とする場合:
bd create "Task A: schema migration" -p P1
# returns id: my-proj-001-abc
bd create "Task B: signup endpoint" -p P1 \
--blocks-on my-proj-001-abc \
--label senior-dev
パイプラインオーケストレーターは bd ready --assignee senior-dev を読み取り、担当可能なタスクを把握します。未完了の前提タスクによってブロックされているタスクは表示されません。
ルール 4. 受け入れ基準 — 「完了」とは?
すべてのタスクの説明は、箇条書きの「完了条件:」セクションで締めくくります。
## Done when:
- [ ] POST /signup returns 201 with user_id on success
- [ ] Bad email returns 400 with "invalid_email"
- [ ] Duplicate email returns 409 with "email_taken"
- [ ] Password is hashed with argon2 (no plaintext in DB)
- [ ] Unit test in `tests/<area>/<feature>.test.ts` covers all 4 cases
- [ ] `npm test` passes
Senior-dev は、何をいつまでにリリースすればよいかを正確に把握できます。
ルール 5. 担当者と並列処理
3 つのタスクを並列で実行できる場合は、それぞれに担当エージェントを割り当てます。タスクをまとめないでください。
bd create "..." --label senior-dev
bd create "..." --label senior-dev # parallel
bd create "..." --label devops # parallel, different agent
PLAN-*.md のテンプレート
# PLAN — <feature>
Date: <ISO>
Architect ARCH: docs/architecture/ARCH-<feature>.md
Owner: pm
## Summary
2-3 sentences. What problem, what solution. Reference ARCH for detail.
## Cost estimate
(Follow skill: cost-model)
## Tasks
1. **<title>** [P1, ≤2h, senior-dev]
- Goal: <one-sentence>
- Done when: <bulleted criteria>
- bd id: <ID after create>
2. **<title>** [P1, ≤4h, senior-dev]
- Blocked on: 1
- Goal: ...
- Done when: ...
3. **<title>** [P2, ≤1h, qa-engineer]
- Blocked on: 1, 2
## Pre-mortem
(Follow skill: pre-mortem)
## Gates
(Follow GATES_BY_ARCHETYPE for this archetype + project_size)
- [ ] gate:plan — after pm finishes, before senior-dev starts
- [ ] gate:qa — after qa-engineer, before ship
- [ ] gate:ship — after security-officer, before devops
pm が計画を立てずに差し戻すべき場合
ARCH が不完全な場合、pm エージェントは計画を拒否することができます。拒否することが期待されています。具体的には次のとおりです。
❌ ARCH に機能自体の受け入れ基準がありません。 差し戻し:「ARCH には『Webhook ハンドラーを構築する』とありますが、成功とみなす条件が指定されていません。成功基準を明示して、アーキテクチャを再設計してください。」
❌ ARCH に失敗時の動作が指定されていません。 差し戻し:「ARCH には『エラーを適切に処理する』とありますが、『適切』の意味が示されていません。ログに記録して ACK するのか、ログに記録して再試行するのか、ログに記録してアラートを出すのかを定義してください。」
❌ ARCH が既存の ADR と矛盾しています。 差し戻し:「ARCH では Postgres を提案していますが、ADR-005 では DynamoDB が必須とされています。計画の前に解決してください。」
差し戻しは bd update とラベル re-arch を使用してアーキテクトに送ります。ARCH が改訂されるまで、計画はブロックされます。
アンチパターン
❌ タスク名が目標ではなくコンポーネントに基づいています。 「UserService を構築する」では曖昧です。「パスワードを argon2 でハッシュ化する POST /signup エンドポイントを追加する」なら明確です。
❌ 依存関係が宣言されていません。 同じファイルを編集する 2 つのタスクに --blocks-on が指定されていないと、競合します。必ず宣言してください。
❌ タスクを 1 つも実行せずに見積もっています。 タスク 1 にかかる時間が本当に分からない場合は、まず senior-dev にタスク 1 を実行してもらい、報告を依頼してください。その後でタスク 2~N を見積もります。
❌ 8 時間を超えるタスク。 分割してください。例外はありません。