prd-to-issues

prd-to-issues スキルの概要

prd-to-issues は、プロダクト要件定義書を、レイヤーごとの作業分解ではなく、縦切りの vertical slice として小さく独立して価値を出せる GitHub issue 群に落とし込むための planning skill です。すでに PRD を持っていて、「build backend」「build frontend」「write tests」のような曖昧なチケットだらけの backlog ではなく、そのまま実装に移せる粒度の作業分解が欲しい創業者、product engineer、tech lead、agent 利用者に特に向いています。

prd-to-issues が実際にやること

prd-to-issues の中核は、単に「PRD を要約する」ことではありません。要件を tracer-bullet 型の issue に組み替え、schema、API、UI、tests をまたぐ薄い end-to-end の slice として整理します。つまり、各チケットが単体でデモできる形になるのがポイントです。

要件プランニングで prd-to-issues が向くケース

プロダクトの意図を、実行可能な順序に変えたいときは prd-to-issues for Requirements Planning が有効です。特に次のようなものを求めるチームに向いています。

• 実装にそのまま使える GitHub issues
• 依存関係を踏まえた実行順
• 自律的に進められる作業と、人の判断が必要な checkpoint の混在
• merge リスクや調整コストを下げる、小さめのチケット

なぜチームは汎用プロンプトではなく prd-to-issues を選ぶのか

通常のプロンプトだと、feature-component ベースの checklist になりがちです。prd-to-issues skill は、vertical slice、明示的な blocker、そしてチケット種別の切り分けを強く促します。

• AFK: 人の追加判断なしで実装できる
• HITL: 人の判断、レビュー、承認が必要

agent を活用した delivery、非同期での実行、triage queue を前提に計画するなら、この違いは実務上かなり役立ちます。

最大の差別化ポイント

いちばん大きい違いは、slice の考え方です。各 issue は狭いけれど完結しているべき、という前提で設計されます。だからこそ、開発者や agent がそのチケットを実際に拾って、終わらせて、検証して、merge まで持っていけます。あとから別タスクがいくつも揃わないと価値が出ない、中途半端な技術レイヤー分割とはここが違います。

このスキルで置き換えられないもの

prd-to-issues は、product discovery、architecture design、roadmap prioritization の代わりにはなりません。PRD 自体がまだ曖昧だったり、認識が割れていたり、scope の境界が決まっていなかったりすると、出力は整理されて見えても、中身は間違っている可能性があります。

prd-to-issues スキルの使い方

prd-to-issues のインストール前提

Skills workflow を使っている場合は、mattpocock/skills repository から prd-to-issues を install します。

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

その後、PRD を implementation issue に変換したいタイミングで、agent 環境から呼び出します。

repository で最初に読むべきもの

この skill はかなり軽量です。まず読むべきメインのファイルは次です。

• SKILL.md

追加の helper script、reference doc、rules folder はここでは表に出ていません。なので、実際の価値の多くは SKILL.md の workflow を理解することと、repository 単体では補えない質の高い入力を与えることにあります。

prd-to-issues に最低限必要な入力

最低限、prd-to-issues usage がうまく機能するのは、次の情報を渡したときです。

• PRD の GitHub issue number または URL
• product goal
• すでに分かっている hard constraint
• 事前に agent が codebase を調べるべきかどうか

PRD がすでにコンテキスト内にない場合、skill は agent がそれを取得する前提になっています。通常は comment を含めて gh issue view <number> を使います。

入力が強いほど issue 分解の質は大きく上がる

「この PRD を issue にして」のような雑な依頼だけでは、たいてい不十分です。より良い入力には次のような情報が含まれます。

• 対象ユーザーや workflow
• 既知の技術的境界
• rollout 上の制約
• 既存システムへの依存
• speed、low risk、autonomy のどれを優先するか

より強いプロンプトの例は次のとおりです。

“Use prd-to-issues on GitHub issue #123. Break it into thin vertical slices. Prefer AFK slices where possible. We already have auth and billing, but no notification system. Optimize for demoable increments and minimal cross-team coordination.”

こうした指定があると、PRD の title だけでは読み取れない planning constraint を skill に与えられます。

prd-to-issues がたどる実務的な workflow

prd-to-issues guide の流れはシンプルです。

1. PRD issue を特定する。
2. 必要なら issue の内容をコンテキストに取り込む。
3. 必要に応じて codebase を調べ、現在の実装実態を把握する。
4. 薄い vertical slice を下書きする。
5. 各 slice を AFK または HITL として分類する。
6. slice 間の blocker を明示する。
7. ticket を作成する前に、分解案をユーザーに提示してレビューしてもらう。

この review step は重要です。この skill は、確認なしに backlog を黙って作るためではなく、分解案を提案するために設計されています。

codebase 調査は任意だが、実際には価値が高いことが多い

repository 上では codebase exploration は optional ですが、実運用ではこれが出力品質を大きく左右することが少なくありません。codebase の文脈なしだと、見た目は整っていても次のような点を無視した slice になりがちです。

• 既存の abstraction
• data model の制約
• naming convention
• すでに一部出荷済みの実装

PRD が現在のシステム挙動に依存するなら、先に codebase を確認したほうが安全です。

良い issue 一覧に含まれているべきもの

prd-to-issues がうまく働いているとき、提案される各 slice には少なくとも次が含まれます。

• 短く分かりやすい title
• Type: HITL または AFK
• Blocked by: 順序が重要な場合の先行 slice

良い出力ほど、「なぜこの ticket が単独で成立するのか」「どうなれば検証可能なのか」が一目で分かります。

粗い PRD を、より良い prd-to-issues プロンプトに変える方法

PRD が広すぎる場合は、skill を呼ぶ前に planning instruction を足してください。

• “Prefer many thin slices over a few large ones.”
• “Each slice must be demoable on its own.”
• “Avoid phase-based tickets like backend/frontend/testing.”
• “Call out any slice that needs product or design review as HITL.”
• “Flag sequencing only when a real blocker exists.”

これらの指示は、repository が意図している vertical-slice 前提を補強し、ありがちな generic backlog を避けるのに役立ちます。

よくある出力パターン

UI、API、persistence を含む feature なら、この skill は次のような slice に寄せるべきです。

• 最小限の end-to-end happy path
• 追加の validation や permissions に関する follow-up slice
• edge case handling の slice
• 必要に応じた observability または reporting の slice

逆に、次のような分け方にデフォルトで流れるべきではありません。

• database ticket
• API ticket
• frontend ticket
• QA ticket

後者こそ、prd-to-issues が避けようとしているパターンです。

いつ HITL と AFK を明示して依頼すべきか

チームが agent を使う、または非常に async に作業を進めるなら、AFK slice を最大化するよう明示するとよいです。逆に、UX、compliance、architecture に未解決の論点があると分かっているなら、それらを実装タスクの中に埋め込まず、HITL ticket として切り出すよう依頼してください。

planning サイクルの中で prd-to-issues を使うベストタイミング

prd-to-issues skill は、PRD がユーザー成果と制約を具体的に説明できる程度には固まっていて、まだ engineer が手で分解を始める前のタイミングで使うのが最適です。早すぎると ticket が推測ベースになりますし、遅すぎるとすでに work breakdown が存在していて、付加価値が薄れます。

prd-to-issues スキル FAQ

prd-to-issues は初心者にも向いているか

はい。PRD がある程度明確であれば、初心者でも扱いやすい形式です。ただし、出力品質は依然として、scope の境界をどれだけ伝えられるか、そして生成された slice をきちんとレビューできるかに左右されます。

prd-to-issues は AI に ticket 作成を頼むのと何が違うのか

違いは planning model にあります。prd-to-issues は、独立して拾える tracer bullet、明示的な blocker、HITL/AFK のラベル付けに強く寄っています。汎用プロンプトだと、実行に移しにくく、順序づけも弱い ticket になりやすいです。

prd-to-issues が向かないのはどんなときか

次のような場合は相性がよくありません。

• PRD が未解決の問いだらけ
• 作業の大半が research
• 成功が未確定の architecture choice に依存する
• issue 分解より sprint estimation が必要

この場合は、先に discovery や design review を行うべきです。

このスキルには GitHub issues が必要か

実務上は、ほぼ必要です。この workflow は、GitHub issue number または URL として保存された PRD を前提にしており、出力も GitHub issues になることを想定しています。別の場所に応用することはできますが、自然な適用先は GitHub です。

prd-to-issues は issue を自動作成するのか

元の guidance は、まず番号付きの breakdown を下書きし、それを提示するところに重点があります。明示的に独自の issue-creation workflow へ組み込まない限り、基本的には planning aid として扱うのがよいです。

codebase に不慣れでも prd-to-issues を使ってよいか

はい。ただし、最初に codebase exploration を行うよう依頼してください。repository が大規模だったり legacy 要素が強かったりする場合、この工程を省くと、現実離れした slice や見えない blocker が増えやすくなります。

prd-to-issues スキルを改善する方法

prd-to-issues に、より鋭い planning constraint を与える

prd-to-issues の結果を最も手軽に改善する方法は、自分たちのチームにとって「良い breakdown」とは何かを明示することです。役立つ constraint としては次のようなものがあります。

• チケットの最大サイズ
• AFK 作業の優先度
• release order
• risk tolerance
• 変更してはいけない system

これがないと、構造としては正しくても、実運用では扱いにくい issue が出てくることがあります。

skill 実行前に PRD 自体を改善する

この skill は、弱い PRD を救済することはできません。prd-to-issues を使う前に、PRD に次が明確に書かれているか確認してください。

• 誰のための feature か
• ユーザーが達成したい job は何か
• scope に含まれるもの、含まれないもの
• success condition
• 既知の constraint や dependency

短い PRD でも、これらが明文化されているだけで、ずっと分解しやすくなります。

必要だと思うよりも薄い slice を要求する

よくある失敗は、まだ大きすぎる issue をそのまま受け入れてしまうことです。初回の出力が重いと感じたら、次のように頼んでください。

“Make these slices thinner. Each issue should produce a verifiable user-visible or system-visible outcome with minimal parallel coordination.”

これで pickup のしやすさが上がり、blocker chain も減ることが多いです。

end-to-end 思考を強制する

出力が component ベースの ticket に流れ始めたら、はっきり修正を入れます。

“Rewrite these as vertical slices. No layer-only tickets unless a task is truly impossible to validate end-to-end.”

これは prd-to-issues usage 中に行える修正の中でも、特に価値が高いもののひとつです。

不確実性と実装を分離する

ある slice の中に、隠れた意思決定が含まれているなら、skill に次のように分割させてください。

• HITL の意思決定または review issue
• その決定後に進める 1 つ以上の AFK implementation issue

こうしておくと、自律実行できる作業が詰まりにくくなり、人の判断が必要な箇所も暗黙ではなく可視化されます。

blocker は second-pass review で見直す

blocker は、実際より多く宣言されがちです。最初の draft が出たら、次を確認してください。

• どの dependency が本当に必須か
• どの slice が並行して進められるか
• 完了済みの upstream work ではなく、interface assumption だけで進められる slice はどれか

特に小規模チームでは、これだけで plan の実行性が大きく上がります。

出力を 3 つの品質チェックで確認する

issue 一覧を採用する前に、各 ticket が次を満たしているか確認してください。

1. PRD 全体を読み直さなくても理解できる
2. デモ可能またはテスト可能な outcome を生む
3. 重大な未解決論点を隠していない

このどれかに失敗する slice は、issue 化する前に修正したほうがよいです。

「もっと良くして」ではなく、具体的なフィードバックで改善する

最も効く改善プロンプトは具体的です。たとえば次のような形です。

“Revise the prd-to-issues breakdown so the first two slices are mergeable within a day, maximize AFK, and isolate design-review dependencies into separate HITL issues.”

この種のフィードバックは backlog を実際に変えます。逆に、抽象的なフィードバックではあまり改善しないことが多いです。