to-prd

to-prd スキルの概要

to-prd ができること

to-prd スキルは、今の会話コンテキストとコードベースの理解をもとに PRD を作成し、プロジェクトの issue tracker に公開します。すでに書けるだけの情報がそろっていて、探索的なヒアリングではなく、構造化されたプロダクトブリーフがほしい場面向けです。

どんな人・状況に向いているか

to-prd スキルは、既存リポジトリの中で作業していて、変更内容のおおまかな見通しがあり、プロジェクト固有の用語、ADR、tracker の運用に合った PRD が必要なときに向いています。特に、Skill Authoring や agent 主導の実装フローのように、次の担当者へ引き継ぐ前提の作業で役立ちます。

何が違うのか

to-prd の大きな特徴は、「インタビューしない」姿勢です。既知の情報から内容を組み立て、その結果を正しい triage label 付きで tracker に送ります。そのため、汎用的なプロンプトより速い一方で、必要な repo コンテキストと tracker 設定が最初からそろっていることへの依存度は高くなります。

to-prd スキルの使い方

インストールと前提コンテキスト

to-prd install を使う場合は、プロジェクトの skill installer を使ってから、使いたい issue tracker のワークフローに repo が接続されているか確認してください。このスキルは、issue tracker と triage label の語彙がすでに利用可能であることを前提にしています。まだなら、先に /setup-matt-pocock-skills を実行してください。これを飛ばすと、PRD の下書きはできても、きれいに公開するところで失敗することがあります。

to-prd を使うときのプロンプトの書き方

最も良い to-prd usage は、実装対象が明確で、repo パスや機能領域が示され、既知の制約があればそれも入っている形です。たとえば、「apps/web に OAuth refresh handling を追加する PRD を作成し、repo の glossary と既存 ADR を使って tracker に公開して」といった入力が理想です。一方で、「auth の PRD を書いて」のような曖昧な依頼は弱く、このスキルは質問して掘り下げるのではなく、合成するためのものです。

最初に確認すべきファイルとシグナル

出力をそのまま信用する前に、まず SKILL.md を確認し、その次に repo の README.md、AGENTS.md、metadata.json、そして存在するなら rules/、resources/、references/、scripts/ フォルダも見てください。このリポジトリでは SKILL.md が主情報なので、ワークフローは意図的に軽量です。その分、PRD の品質は、あなたが渡す実際のコードベースコンテキストに強く左右されます。

より良い出力を得るための実践的な進め方

変更内容をすでにプロダクトの言葉で説明できるときにこのスキルを使い、problem statement、solution、user stories を含む PRD に変換させるのが効果的です。ドメイン用語の glossary と ADR を尊重するよう依頼し、どの module を変更候補にするか、どこで test coverage が重要かも明示してください。to-prd for Skill Authoring を使うなら、プロンプトは upstream リポジトリ全体ではなく、文書化したいスキルの挙動に絞るのがコツです。

to-prd スキル FAQ

to-prd はあらゆる PRD タスクに向いているか

いいえ。to-prd スキルが最適なのは、変更内容をコンテキストから書ける程度にはすでに理解できている場合です。ディスカバリー、プロダクトインタビュー、市場調査が必要なら、to-prd より通常のプロンプトワークフローのほうが適しています。

to-prd は一般的なプロンプトとどう違うのか

一般的なプロンプトでも PRD は依頼できますが、to-prd には repo を意識した動作があります。glossary 用語を探し、ADR を尊重し、深い module を拾い、ready-for-agent ラベル付きで issue tracker に公開します。つまり、自由形式の PRD 依頼より運用向きです。

初心者でも使えるか

はい。ただし、具体的な機能方向を示せて、スキルが追加質問をしないことを理解している場合に限ります。初心者が最も良い結果を得られるのは、初回の依頼に repo の対象領域、ユーザーの問題、譲れない制約を入れているときです。

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

tracker が使えないとき、label の語彙が不明なとき、あるいは機能の探索段階にあるときは、to-prd を使わないでください。PRD を書く前にステークホルダーへの反復インタビューが必要な場合も、向いていません。

to-prd スキルを改善するには

スキルへの入力をもっと具体的にする

品質を最も左右するのは、入力の具体性です。repo の場所、解決したい問題、期待するユーザー成果、さらに platform、performance、rollout の制約などを含めてください。入力が強いほど、to-prd は実装現実に近く、より具体性のある PRD を出しやすくなります。

module と test の期待値を明示する

このスキルは deep modules を明示的に見に行き、どの module に test を付けるべきかも尋ねます。出力をよくしたいなら、候補 module を挙げ、浅く保つべき module を示し、切り出すべき独立ロジックがあればそれも伝えてください。そうすることで引き継ぎ時の摩擦が減り、次の agent がすぐ使える PRD になります。

ありがちな失敗パターンに注意する

一番多い失敗は、コンテキスト不足です。すると PRD が、判断を導く計画ではなく、広くて tracker には載せやすいだけの文章になります。もう一つのリスクは、repo の glossary や ADR が最新でない場合に、用語が古くなることです。この両方を防ぐには、現在のコードベース状態を軸にプロンプトを組み、公開を頼む前にブリーフを更新してください。

最初のドラフトから反復して詰める

最初の PRD のあとに、user stories を絞り込み、acceptance の境界を明確にし、issue label と tracker の送信先が正しいか確認して磨きます。to-prd では、反復の目的は scope を広げることではなく、曖昧さを減らすことです。