Claudeのwrite-specスキルで機能仕様書(PRD)を書く手順
product-managementプラグインのwrite-specスキルの動き方を、聞かれる内容・PRDの8節・ゴールと非ゴール・受け入れ基準・段階分けの順にたどります。
write-specは、Anthropicが公開しているproduct-managementプラグインに入っている、機能仕様書(PRD)を作るスキルです。「SSO対応」のような機能名でも、「オンボーディングの離脱をなんとかしたい」という曖昧な話でも、聞き取りを挟んでから8つの節を持つ仕様書にまとめます。
最初から全部を書かせる道具ではありません。まず質問を返し、足りない材料を埋めてから文書を出す作りです。プラグイン全体の一覧はClaude部門別プラグインの使い方にあります。
write-specとは何か — PRDを聞き取りから組み立てるスキル
write-specはproduct-management/skills/write-spec/SKILL.mdに置かれたスキルです。frontmatterのdescriptionには、曖昧な依頼を構造化文書にする場面、ゴールと非ゴールで範囲を切る場面、成功指標と受け入れ基準を決める場面、大きな依頼を段階に分ける場面で使うと書かれています。argument-hintは<feature or problem statement>で、機能名か課題文を引数に取ります。
スキルが出すPRDは次の8節です。
| 節 | 指示されている中身 |
|---|---|
| Problem Statement | 指示されている中身誰がどんな問題を抱え、解かないと何が起きるか。2〜3文 |
| Goals | 指示されている中身ユーザー指標か事業指標に結びつく、測れる成果を3〜5個 |
| Non-Goals | 指示されている中身範囲外のことを3〜5個。それぞれ理由つき |
| User Stories | 指示されている中身「As a [user type], I want [capability] so that [benefit]」形式。ペルソナ別 |
| Requirements | 指示されている中身P0・P1・P2に分け、各項目に受け入れ基準を付ける |
| Success Metrics | 指示されている中身先行指標と遅行指標。具体的な目標値つき |
| Open Questions | 指示されている中身未解決の問いと、誰が答えるか(エンジニアリング・デザイン・法務・データ) |
| Timeline Considerations | 指示されている中身期限、依存関係、段階分け |
出力形式の指示は「見出しと太字だけ読めば要点が分かる、読み飛ばしやすい文書にする」というものです。仕様書を読む側の忙しさを前提に組まれています。
導入と呼び出し — Claude CodeでもCoworkでも同じスキル
プラグインのREADMEは、Cowork向けに主に設計したもので、Claude Codeでも動くと説明しています。Claude Codeでの導入は、マーケットプレイスの追加とインストールの2行です。
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install product-management@knowledge-work-pluginsCoworkではclaude.com/pluginsの一覧から選んで入れます。導入後の呼び出しは、READMEでは/write-specと書かれていますが、Claude Codeのドキュメントに載っている形は/product-management:write-specです。
/product-management:write-spec 注文履歴をCSVでエクスポートできるようにしたい引数は省略してもかまいません。省略した場合、スキルはまず何を仕様化したいのかを尋ねます。
write-specのfrontmatterにはdisable-model-invocationがありません。このフィールドの既定値はfalseで、Claudeが説明文を手がかりに自分でスキルを呼び出せます。「この機能のPRDを書いて」と普通に頼んでも、スキルが選ばれることがあります。毎回自分で呼びたい場合は、スキル側でdisable-model-invocation: trueにするか、設定のskillOverridesで"user-invocable-only"を指定する方法が公式ドキュメントにあります。スキルの書き方そのものはClaude Code Skillsのfrontmatter全フィールドで扱っています。
聞かれる順番 — 質問は小出しにされる
スキルの手順は5段階です。
write-specの実行手順
- 1
機能を受け取る
機能名・課題文・ユーザーの要望・曖昧なアイデアのどれでも受け付けます。
- 2
文脈を聞く
ユーザーの課題、対象ユーザー、成功指標、制約、先行事例を尋ねます。指示文には「質問を一度に全部出さず、重要なものから順に、会話しながら埋める」とあります。
- 3
接続先から集める
接続済みのツールがあれば、関連チケットや過去の仕様、デザインを引いてきます。
- 4
PRDを生成する
8節を埋めた文書を出します。
- 5
見直す
調整したい節がないか尋ね、デザインブリーフ、エンジニア向けのチケット分解、ステークホルダー向けの説明資料といった続きの成果物を提案します。
聞き取りの5項目のうち、ユーザーの課題と成功指標は、後ろの節に直接つながります。手元に数字があれば最初の返信に添えておくと、後の質問が減ります。「Enterprise顧客から月に5件、SSOの要望が来ている」のような一文でも、Problem Statementの根拠になります。
接続先がなくても動く
手順3は、接続しているツールの種類で動きが変わります。
| 接続の種類 | 引いてくるもの |
|---|---|
| プロジェクトトラッカー | 引いてくるもの関連チケット、エピック、既存の要件や受け入れ基準、他の作業への依存 |
| ナレッジベース | 引いてくるもの調査文書、過去の仕様、デザイン文書、ユーザー調査、議事録や意思決定記録 |
| デザインツール | 引いてくるものモックアップ、ワイヤーフレーム、関連するデザインシステムの部品 |
どれも未接続の場合の指示は明確で、ユーザーが渡した情報だけで進め、接続を促さないとされています。つなげないと使えないスキルではありません。
プラグイン側の.mcp.jsonには、Slack・Linear・Asana・monday.com・ClickUp・Atlassian・Notion・Figma・Amplitude・Pendo・Intercom・Fireflies・Similarwebなどが事前設定されています。スキルの本文はツール名ではなく~~project trackerのような分類名で書かれており、同じ分類の別のMCPサーバーでも代用できます。分類と代替候補の対応表は、プラグインのCONNECTORS.mdにあります。
ゴールと非ゴールの切り分け
write-specが最も細かく指示しているのが、ゴールと非ゴールです。
ゴールは「成果(outcome)で書き、成果物(output)で書かない」が原則です。指示文の例では、「オンボーディングウィザードを作る」は成果物で、「初回価値到達までの時間を50%減らす」が成果です。各ゴールには「うまくいったとどう分かるか」に答えさせ、ユーザーのゴールと事業のゴールを区別するようにも指示されています。
非ゴールは、範囲外にすることと、その理由を並べます。理由の型は指示文に4つ挙がっています。効果が小さい、複雑すぎる、別の取り組みで扱う、時期尚早、の4つです。実装中の範囲拡大を防ぎ、関係者の期待を揃えるための節です。
ゴールの書き方
成果物で書いた場合
- オンボーディングウィザードを作る
- 検索画面を作り直す
成果で書いた場合
- 初回価値到達までの時間を50%減らす
- 「見つからない」系のサポート問い合わせを四半期で30%減らす
上の「30%」は説明用の数字です。実際の目標値は、類似機能の実績や業界の目安、明示した仮説から決めるよう、スキルは求めています。
受け入れ基準と成功指標を仕様書に入れる
受け入れ基準
受け入れ基準は、Given/When/Then形式か、チェックリスト形式で書きます。スキルの例を日本語にすると、次の形です。
Given 管理者が組織のSSOを設定済み
When チームメンバーがログインページを開く
Then 組織のSSOプロバイダーへ自動的に遷移する書くときの注意として、正常系・異常系・境界の3種を網羅すること、実装ではなく期待する挙動を書くこと、「起きてはいけないこと」も含めること、各項目を単独でテストできる粒度にすること、が挙がっています。「速い」「使いやすい」「直感的」のような曖昧語は、具体的な数値や挙動に言い換えるよう指示されています。
成功指標
成功指標は2層に分かれます。
成功指標の2層
先行指標
採用率、有効化率、タスク完了率、完了までの時間、エラー率、利用頻度。
遅行指標
継続率への影響、売上への影響、NPSや満足度の変化、サポート問い合わせの減少、競合に対する勝率。
目標値は「30日で50%が採用」のように具体的に書き、成功ラインとストレッチ目標を分け、測定方法(ツール・クエリ・期間)と評価時期(1週間後・1か月後・四半期後)まで決めるのが指示です。指標の数字を埋めるところまで求められるため、手元のデータがない状態で走らせると、この節だけが仮置きだらけになります。Open Questionsに「現状の採用率の基準値(データ担当)」を挙げさせる使い方が合います。
大きすぎる依頼を段階に分ける
要件は優先度で3つに分けます。
- P0(Must-Have):なければ出荷できない。「外してもコアの課題は解けるか」と自問し、解けるならP0ではない
- P1(Nice-to-Have):体験を大きく良くするが、なくても核は動く。出荷後の早い追加対応になりやすい
- P2(Future Considerations):v1の範囲外だが、後で足せるよう設計だけ意識しておく
スキルはMoSCoW(Must・Should・Could・Won't)との対応も示しています。ここで厳しく言われているのがP0の絞り込みで、「すべてがP0ならP0はない」という趣旨の一文があります。P1は近いうちに作る確信があるものに限り、願望リストにしません。P2は、将来の機能を邪魔する設計判断を避けるための保険の役割です。
段階分けの指示は2か所にあります。Timeline Considerationsでは、1回のリリースに大きすぎるなら段階を提案します。Tipsでは、依頼が1本の仕様に収まらなければフェーズに分け、最初のフェーズだけを仕様化するよう求めています。
範囲が膨らむ兆候も列挙されています。承認後に要件が増え続ける、小さな追加が積み重なる、誰も求めていない機能を作り始める、期日だけが動く、何も外さずに要件だけ足される、の5つです。対策は、非ゴールを毎回書くこと、追加するなら削除か期間延長を同時に求めること、v1とv2を分けること、調査に期限を設けること、良いが範囲外の案を置く「駐車場」を作ることです。
出力をClaude Codeの実装に渡す
ここからはスキルの指示ではなく、Claude Codeで使うときの運用例です。
write-specは文書を出すところまでが仕事で、保存先は指定されていません。会話の中に出して終わりにせず、リポジトリに置くと実装側から参照できます。
/product-management:write-spec 注文履歴をCSVでエクスポートできるようにしたい
(PRDが出たら)
この内容を docs/specs/order-csv-export.md に保存して。
P0の受け入れ基準は、Given/When/Thenごとにテストケースの雛形も作って。受け入れ基準を「各項目が単独でテストできる」形で書かせているので、そのままテストの雛形に変換しやすい構造です。Open Questionsのうち、着手前に答えが要る問い(blocking)は実装を始める前に潰し、実装中に決められる問い(non-blocking)は残して進める、という区別もスキルが指示しています。
仕様書の置き場所や書式の規約をチーム固有に揃えたい場合は、CLAUDE.mdに「仕様書はdocs/specs/に置く」と一行書いておくと、毎回の指示を省けます。
食い違いに注意する点
product-managementのREADMEには、コマンドの表に/write-specが載り、スキルの表にはfeature-specが載っています。ところがリポジトリのskills/ディレクトリでは、write-specはスキルとして存在し、feature-specというディレクトリはありません。PRD構成や受け入れ基準の内容は、すべてwrite-spec/SKILL.mdの中に入っています。READMEのfeature-specを探してもたどり着けないので、write-specを読めば足ります。プラグイン全体の食い違いは、部門別プラグインの解説にまとめています。
同じ型のプラグインでスキルの中身を読み解く記事に、small-businessプラグインの請求・月次締めがあります。
まとめ
write-specは、質問を小出しにしながらPRDの8節を埋めるスキルで、強みは範囲を絞る側の指示の細かさにあります。ゴールは成果で書く、非ゴールには理由を付ける、P0は疑って絞る、大きければ最初のフェーズだけ仕様化する、という指示が揃っています。
使い始めるなら、課題の根拠になる数字を一文だけ用意して/product-management:write-specを打つのが最短です。トラッカーやナレッジベースは未接続でも動くので、まずは会話だけで1本通してから、接続を足すかどうかを決められます。