prd-to-plan

prd-to-plan skill の概要

prd-to-plan skill は、プロダクト要件定義書（PRD）を、細くてエンドツーエンドな vertical slice を積み重ねる段階的な実装計画に変換するための skill です。ありがちな汎用バックログや、レイヤーごとに分解した技術チェックリストを出すのではなく、prd-to-plan は schema・backend・UI・testing をまとめて横断する tracer-bullet 方式のフェーズを作り、その結果を Markdown として ./plans/ に保存する前提で設計されています。

prd-to-plan が向いている用途

prd-to-plan は、すでに PRD があり、そこからチームや agent が実際に実装へ進める計画を作りたいときに向いています。特に相性がよいのは次のケースです。

• 機能仕様を実装フェーズに落とし込みたい product engineer
• コーディング開始前に Requirements Planning を行う tech lead
• 計画成果物をローカルファイルとして残したい AI 支援ワークフロー
• 「まず backend 全部」ではなく、小さくデモできる slice を重視するチーム

prd-to-plan で特に価値を得やすい人

prd-to-plan が最もハマるのは、次の 2 つをどちらも持っている人です。

• ある程度具体化された PRD
• 対象 codebase へのアクセス、または少なくともその architecture の把握

アイデアが 1 行しかない段階なら、prd-to-plan を使うにはまだ早めです。逆に、必要な ticket がすでに正確に見えているなら、使いどころとしては遅いかもしれません。

本当に片づけたい仕事

この skill の本質は「PRD を要約すること」ではありません。答えるべき問いは、「いまの system を踏まえたうえで、安全に進められる小さく完結した実装ステップの順序は何か」です。architecture と順序設計が重要な場面では、単なる brainstorming prompt よりも、prd-to-plan for Requirements Planning のほうが実務で役立ちます。

通常の prompt と違う prd-to-plan の特徴

prd-to-plan のいちばん大きな違いは、tracer-bullet アプローチにあります。

• 各 phase が stack を通しで貫く完結した経路になっていること
• 各 phase が単独で test または demo できること
• 長く効く architecture の判断を plan の冒頭で押さえること
• 早い段階で file 単位の細かすぎる実装詳細に落ちないこと

この組み合わせによって、実行しやすく、あとから見直しやすい計画になりやすいのが強みです。

install 前にいちばん重要なポイント

この prd-to-plan skill はかなり軽量で、repository 内の主な情報源は helper script や充実した reference ではなく SKILL.md にほぼ集約されています。導入しやすい反面、出力の質は PRD の出来と、こちらが渡す文脈にかなり依存します。チームで厳密な template、見積もりルール、Jira にそのまま入れられる ticket 生成まで必要なら、後続の独自 workflow を足す前提で考えるのが現実的です。

prd-to-plan skill の使い方

prd-to-plan の install 情報

Skills ecosystem を使っているなら、prd-to-plan は mattpocock/skills repository から次のコマンドで install できます。

npx skills add mattpocock/skills --skill prd-to-plan

install 後にまず読むべき主ファイルは以下です。

• prd-to-plan/SKILL.md

この skill はシンプルなので、通常はこのファイルをひととおり読むだけで、重要なポイントの大半を把握できます。

prd-to-plan に必要な入力

prd-to-plan usage の精度を高めるには、次の 3 つをセットで渡すのが基本です。

1. PRD の本文、またはその file path
2. codebase の文脈
3. 絶対に外せない architecture 制約

最低限あると役立つ文脈は次のとおりです。

• user flow または acceptance criteria
• 現在の stack と主要な境界
• auth model
• data model 上の制約
• integration と外部 service
• 「feature flag の裏で出す必要がある」といった delivery 制約

これらが不足していると、plan 自体はもっともらしく見えても、実際の状況からズレた内容になりがちです。

ラフな PRD をこの skill で使える状態にする方法

粗い PRD でも、実行に必要なシグナルを補えば prd-to-plan で扱えるようになります。

• feature リリース後にユーザーが何をできるか
• どの data が新規作成・変更されるか
• どの UI surface に影響するか
• どの既存 system と連携する必要があるか
• 最初に demo できる slice を何と見なすか

たとえば「通知機能を追加したい」だけでは弱い入力です。よりよい入力は、次のように具体化されています。

• v1 は in-app notifications のみ
• dashboard に notification center を置く
• nav に unread count を出す
• event は comment と approval を起点にする
• read/unread state を保存する
• email はまだやらない

ここまで書ければ、prd-to-plan は推測ではなく slice を設計しやすくなります。

prd-to-plan をうまく prompt する方法

よい invocation prompt は、ほしい planning output と repository context の両方を明示しています。たとえば次のような形です。

“Use prd-to-plan on the PRD below. Explore the repo first, identify durable architecture decisions, then produce a phased plan using thin vertical slices. Keep phases demoable, avoid file-level implementation detail, and save the final plan in ./plans/.”

これは単に “make an implementation plan” と頼むより効果的です。prd-to-plan が持つ planning 上の作法を崩さずに使えるからです。

prd-to-plan usage のおすすめ workflow

実践的な流れとしては、次の手順がおすすめです。

1. PRD を会話に貼るか、file を指定する
2. repo を agent に確認させる
3. まず durable architecture decisions を出してもらう
4. その判断が正しいかレビューする
5. その後に phased plan を生成する
6. コーディングに入る前に phase の境界を調整する

この 2 段階レビューにすると、最初の出力をそのまま受け入れるよりも planning ミスを見つけやすくなります。

なぜ codebase の探索が重要なのか

この skill は、slice を切る前に repo を探索することを明示的に前提にしています。これは重要です。phase の順序は次のような現実に左右されるからです。

• 既存の route pattern
• 現在の data model の形
• すでに API があるかどうか
• auth check がどこに置かれているか
• repo がどんな test style を採っているか

PRD だけを見て plan を立てると、見た目は整っていても、実際の codebase には合わない計画になりやすいです。

slice に入る前に確認したい durable decisions

prd-to-plan で最もレビュー価値が高いのは、plan の先頭に置かれる durable decisions のセットです。最低でも次は確認したいところです。

• route または URL structure
• database schema の方向性
• 主要 entity とその relationship
• auth と authorization の model
• third-party との境界

ここが誤っていると、その後の phase 順序も高確率で崩れます。

prd-to-plan における良い vertical slice とは

prd-to-plan の良い slice は、狭いけれど完結しています。たとえば次のようなものです。

• 1 つの新しい entity を end-to-end で作る
• 限定された 1 本の API path を公開する
• 1 つの user role 向けに 1 つの UI path を描画する
• 正常系のフルパスを test する

逆に悪い slice は、レイヤーごとの水平分割です。

• 「database table を全部作る」
• 「backend endpoint を全部実装する」
• 「UI を丸ごと完成させる」

各 phase を実際に動く形で見せられるとき、この skill は最も力を発揮します。

出力に含まれるべき内容

./plans/ に出力される Markdown plan には、通常次の内容を期待できます。

• durable architectural decisions をまとめた短い header
• 複数の phase
• 各 phase が end-to-end slice として説明されていること
• 実装の指針になる程度の具体性
• ただし file 名や壊れやすい内部構造を固定してしまうほど細かすぎないこと

このバランスが重要です。実装可能でありつつ、早すぎる過剰具体化は避ける、ということです。

導入前に見る repository の読み順

この repository の該当箇所は最小限なので、最短で把握するなら次の順で十分です。

1. SKILL.md
2. frontmatter description
3. process と vertical-slice のルール

support script、reference、rules folder などは用意されていないため、導入リスクは低めです。その一方で、裏側に自動化や validation helper があることは期待しないほうがよいです。

出力品質を上げる実践的なコツ

prd-to-plan guide の結果を良くしたいなら、次の情報を足すと効果的です。

• 機能一覧だけでなく、サンプルの user journey も入れる
• 後続 phase に回せるものを明示する
• 「今 sprint では schema migration なし」のような制約を伝える
• 再利用必須の既存 module を指定する
• 不確かな architecture 前提は別枠で flag するよう頼む

こうした入力があると、見せかけの確信を減らし、より使える phase 境界を作りやすくなります。

prd-to-plan skill FAQ

prd-to-plan は初期アイデアの探索に向いているか

あまり向いていません。prd-to-plan が最も機能するのは、feature に順序設計できるだけの輪郭がある段階です。まだ brief が探索寄りなら、先に PRD drafting を進め、要件が計画に落とせる程度に安定してからこの skill を使うほうが適切です。

prd-to-plan は初心者にも使いやすいか

はい。ただし注意点が 1 つあります。初心者は architecture 上の前提を早い段階で受け入れすぎる傾向があります。この skill は整った plan を返せますが、durable decisions が自分たちの stack に本当に合っているかは、別途レビューが必要です。見栄えのよい出力を、検証済みの出力と取り違えやすい点には注意が必要です。

AI に実装計画を頼むのと何が違うのか

通常の prompt だと、大きくて水平分割の phase になりやすく、architecture の確認ポイントも飛ばされがちです。prd-to-plan skill はそこがより明確で、codebase の探索、durable decisions、tracer-bullet slice を前提にしています。そのため、段階的に実装しやすい plan につながりやすいのが違いです。

prd-to-plan を使わないほうがいいのはいつか

次のような場合は prd-to-plan を無理に使わないほうがよいです。

• まだ実質的な PRD がない
• 作業がごく小さな bug fix である
• architecture はすでに確定していて、必要なのが task 分解だけである
• 正確な ticket、見積もり、sprint 要員計画まで必要である

こうしたケースでは、別の planning workflow のほうがたいてい適しています。

prd-to-plan は ticket や file-level task を生成するか

いいえ。prd-to-plan は、メインの slicing 段階では詳細な file 名や function ごとの実装分解を意図的に避けます。まず必要なのは phase planning です。plan が承認されたあとで ticket を生成する流れが合っています。

prd-to-plan は大きな feature 専用か

いいえ。順序設計や integration リスクが重要な中規模 feature にも十分向いています。判断基準はサイズだけではありません。単純な checklist より end-to-end slicing のほうが有効かどうかがポイントです。

PRD が現在の codebase と食い違っている場合はどうするか

まさにそこが prd-to-plan usage の価値が出る場面です。agent に repo を確認させ、phase に入る前に durable decisions の中で衝突点を表面化させましょう。codebase の文脈を伏せたままだと、plan の信頼性は下がります。

prd-to-plan skill を改善する方法

まず plan ではなく PRD を改善する

prd-to-plan の出力を最短で改善したいなら、まず PRD の入力品質を上げるのが有効です。

• user role を明確にする
• 最初に demo できる到達点を定義する
• non-goal を明記する
• data ownership と integration を特定する
• v1 と後続の enhancement を分ける

多くの場合、prompt を磨くより、PRD を良くするほうが結果への影響は大きいです。

architecture の文脈をより強く渡す

最初の plan が汎用的すぎると感じるなら、agent に system 制約が足りていない可能性が高いです。次の情報を追加してください。

• framework と app structure
• 既存 service の境界
• 現在の database pattern
• auth flow
• deployment 制約
• testing に対する期待値

これにより、prd-to-plan for Requirements Planning は実装現場に合った slice を出しやすくなります。

前提を明示させるよう依頼する

よくある失敗のひとつが、前提が隠れたまま進むことです。次のように頼むと、skill の実用性が上がります。

• “List uncertain assumptions before the plan”
• “Mark decisions that need validation”
• “Separate inferred architecture from confirmed architecture”

こうしておくと、レビューがかなり速く、しかも安全になります。

phase のサイズを思い切って絞る

もうひとつの典型的な失敗は、phase が大きすぎることです。plan が少数の巨大 phase しか持っていないなら、agent に次を依頼します。

• 各 phase をより細い end-to-end slice に分割する
• 各 slice が独立して demo 可能であることを保証する
• 任意の polish や edge case は後回しにする
• 各 slice には 1 つの明確な learning objective だけを残す

これで tracer-bullet の方法論を保ちやすくなります。

実装詳細に早く入りすぎるのを防ぐ

出力が早い段階から具体的な file、class、低レベル function 名まで挙げ始めたら、軌道修正したほうがよいです。prd-to-plan は、まず phase と capability のレベルにとどめたほうがうまく機能します。slice の順序が固まってから、必要に応じて ticket レベルの詳細を足せば十分です。

plan は 2 パスで見直す

信頼できる review loop は次の 2 段階です。

1. 1 回目: architecture decisions と phase の順序を検証する
2. 2 回目: 各 phase の scope、risk、acceptance check を調整する

順序の問題を直す前に wording を整える必要はありません。実際の planning ミスの多くは、書きぶりではなく順番と境界にあります。

各 slice に acceptance check を追加する

より実行可能な plan がほしいなら、各 phase に簡単な verification statement を付けてもらうと有効です。たとえば次のような観点です。

• どの user path が動くのか
• どの data change が目に見えるのか
• どの API behavior が test 可能なのか
• 何を demo できればその slice 完了と見なせるのか

こうすると、ticket レベルの細分化を強制せずに、抽象的な slice を build-ready な milestone に近づけられます。

prd-to-plan の後に分解ステップを組み合わせる

有効なパターンは、まず prd-to-plan を使い、その後に承認済み phase を ticket、estimate、coding prompt に変換する別 workflow を回すことです。これなら、implementation detail に入る前に順序設計と slicing を固めるという、この skill の強みを保てます。

prd-to-plan の主な制約を理解しておく

この repository は良い planning パターンを提供していますが、それを強制する仕組みまでは持っていません。出力の一貫性を保つ bundled script、template、reference doc は用意されていません。チーム全体で再現性を高めたいなら、skill の周りに自前の review checklist を作るのがおすすめです。

• PRD は十分に具体化されていたか
• durable decisions は検証されたか
• phase は本当に vertical slice になっているか
• 各 phase は demo 可能か
• 低レベル detail は適切に後回しにされているか

この程度のシンプルな wrapper でも、日常運用における prd-to-plan の安定性はかなり上がります。