Menu
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。
要件確定後、実装前に使用。メインセッションで人間パートナーと対話しながら設計を深掘りし、合意した設計を design.md にまとめる。
| name | roadmap |
| description | 大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。 |
複数機能にまたがる大規模な変更を、フェーズに分割して管理する。 各フェーズの範囲・マイルストーン・依存関係・リスクを定義し、実装の全体見通しを立てる。
入力: REQ パス + 承認済みの requirements.md（複数機能を含む）+ design.md（全体アーキテクチャ）
出力: docs/plans/{slug}-roadmap.md（承認済みロードマップ）
原則: 大規模を大規模のまま扱うな。分割して、各フェーズを planning スキルに渡せ。
フェーズ分割なしに大規模実装を始めるな
ロードマップは docs/plans/ に置け
以下のいずれかに該当する場合:
使わない場合:
迷ったら人間パートナーに聞く。
digraph roadmap {
rankdir=TB;
input [label="複数機能の設計確定\ndesign.md + requirements.md", shape=ellipse];
decompose [label="フェーズ分割\nroadmap-planner", shape=box, style=filled, fillcolor="#cce5ff"];
milestone [label="マイルストーン定義\n依存・リスク分析", shape=box, style=filled, fillcolor="#ccccff"];
review [label="ロードマップレビュー\nplan-reviewer", shape=box, style=filled, fillcolor="#ffffcc"];
approve [label="人間パートナーの\n承認", shape=diamond];
done [label="フェーズごとの\nplanning へ", shape=ellipse];
input -> decompose;
decompose -> milestone;
milestone -> review;
review -> approve;
approve -> done [label="承認"];
approve -> decompose [label="修正要求"];
}
roadmap-planner に設計をフェーズに分割させる。
分割の基準:
| 基準 | 内容 |
|---|---|
| 依存関係 | 後続フェーズが前フェーズの成果物に依存する場合、分離する |
| リスク順 | 技術的に不確実な部分を先のフェーズに。失敗しても後続への影響を最小化 |
| 価値順 | ユーザーに価値を届けられるフェーズを先に |
| 独立性 | 並列実行可能なフェーズを識別する |
各フェーズのゴール・完了条件・リスクを定義する。
マイルストーンに含めるもの:
plan-reviewer にロードマップを検証させる。
検証の観点:
ロードマップを提示し、承認を得る。
docs/
plans/
{slug}-roadmap.md # ★ロードマップ
design/
{slug}.md # 設計書（design スキルで作成済み）
requirements/
REQ-001-xxx/
requirements.md # 要件（requirements スキルで作成済み）
---
status: Draft | Approved
last_updated: YYYY-MM-DD
phases: N
---
# REQ-001: <プロジェクト名> — ロードマップ
## プロジェクト概要
[全体目的、複数機能の関係性]
## フェーズ分割の根拠
[なぜこの粒度で分割したのか。依存性、リスク、制約等]
## フェーズ一覧
### Phase 1: [ゴール]
- **含まれる機能**: FR-1, FR-2
- **完了条件**: [テスト GREEN + 何が動く状態か]
- **依存**: なし
- **リスク**: [技術的不確実性]
### Phase 2: [ゴール]
- **含まれる機能**: FR-3, FR-4
- **完了条件**: [テスト GREEN + 何が動く状態か]
- **依存**: Phase 1 完了
- **リスク**: [外部依存等]
### Phase N: ...
## フェーズ間の依存関係
Phase-1 → Phase-2 → Phase-4
↘ Phase-3 → Phase-4
## 並列実行可能なフェーズ
- Phase-2 と Phase-3 は Phase-1 完了後に並列実行可能
## クリティカルパス
Phase-1 → Phase-2 → Phase-4（最長経路）
## リスク管理
| リスク | 影響 | 対策 |
|--------|------|------|
| [技術リスク] | [影響範囲] | [代替案] |
| [スケジュールリスク] | [遅延時] | [巻き戻し計画] |
| 言い訳 | 現実 |
|---|---|
| 「全部一気にやった方が速い」 | コンテキストが溢れて後半で品質が落ちる。ECC の実績でもフェーズ分割の方が速い |
| 「フェーズ分割は大企業のやること」 | 3機能以上あるなら個人でも有効。管理コストは roadmap.md 1ファイルだけ |
| 「依存があるから分割できない」 | 依存をグラフにすれば、意外と並列可能な部分が見つかる |
| 「計画は変わるから無駄」 | 変わった時に、何が変わったか追跡できることが重要 |
以下のどれかに当てはまったら、ロードマップを見直せ。
あなたはこのスキルのマイルストーン定義・承認プロセスを自分で実行する。ただしフェーズ分割とレビューは委譲する。
前提: 対応する REQ を特定する。 ディスパッチ前に、このタスクに対応する requirements/REQ-*/requirements.md と design.md を特定しろ。見つからなければ人間パートナーに確認しろ。
roadmap-planner エージェントをディスパッチしてフェーズ分割する
roadmap-planner はフェーズ一覧 + 依存関係 + リスクを報告するあなたがマイルストーンを整理し、roadmap.md を作成する
docs/plans/{slug}-roadmap.md に出力するplan-reviewer エージェントをディスパッチしてレビューする
レビュー結果に対応する
承認後、各フェーズを planning スキルに渡す
前提スキル:
必須ルール:
次のステップ:
このスキルを使うスキル:
このスキルの出力を参照するエージェント: