prd-generator

PRD ジェネレーター — セキュリティ重視

このスキルが接続できるサービス

いずれも必須ではありません。PRD はどちらの場合も生成され、コネクターが利用できない場合はエラーではなくローカルファイルに出力されます。

MCP コネクター	用途	優先度
Atlassian	Confluence ページの作成	最優先 — 常に試行
Slack	ステークホルダーへの通知	任意
Linear	バッチ計画 → チケット	任意
Asana	バッチ計画 → タスク	任意
Notion	ドキュメントのミラーリング	任意
Gmail	PRD をステークホルダーに送信	任意

想定するツール：present_files、create_file、bash_tool。

このリストは以前、compatibility: フロントマターキーに記載されていました。Agent Skills の仕様で許可されているのは name、description、allowed-tools のみで、余分なキーがあると無視されず、ハードエラーが発生して claude.ai へのアップロードに失敗します。そのため、このリストは本文に記載します。

カスタマイズ（初回使用時に必須）

最初の PRD を生成する前に、Claude が以下の設定を尋ねます。これらはパイプライン全体とすべての出力で使用されます。

設定	説明	例
オーナー名	すべての出力で PRD オーナーとして表示する名前	@jane.doe / @john.smith
デフォルトのステークホルダー	すべての PRD に追加する関係者	@product-team、@security-lead
Confluence スペースキー	PRD ページを作成する Atlassian Confluence のスペース	ENG、PRODUCT、SEC
Confluence テンプレートのタイトル	PRD を配置する親ページのタイトル	PRD Templates、Product Specs
Slack チャンネル	PRD 通知のデフォルトチャンネル（任意）	#product-specs、#security-reviews
メールの宛先	Gmail の下書きに設定するデフォルトのステークホルダーのメールアドレス（任意）	[email protected]

設定方法：

1. 対話形式（推奨）： このスキルを初めて使用するとき、Claude は PRD を生成する前にこれらの値を尋ねます。回答はそのセッションで使用されます。

2. 環境変数： 設定を永続化するには、シェルプロファイルまたは .env で以下を設定します：

   export PRD_OWNER="@your-name"
   export PRD_STAKEHOLDERS="@stakeholder1, @stakeholder2"
   export PRD_CONFLUENCE_SPACE="YOUR_SPACE_KEY"
   export PRD_CONFLUENCE_TEMPLATE="Your Template Page Title"
   export PRD_SLACK_CHANNEL="#your-channel"
   

3. リクエストごとの上書き： プロンプトに以下のいずれかを含めます：

   Write a PRD for feature X. Owner: @jane. Space: ENG. Notify #product-specs.
   

設定が指定されていない場合、Claude は処理を進める前に確認します。

---

このスキルの機能

機能の説明を受け取り → 10 役割の仕様策定パイプラインを実行し → すべての出力を生成します。 コネクターは Claude が直接呼び出すため、ユーザーによる別途の操作は不要です。

出力	コネクター／ツール
PRD 全文の Markdown	create_file + present_files
.cursor/plans/ ファイル	create_file + present_files
設定済みスペース内の Confluence ページ	Atlassian:createConfluencePage（直接呼び出し）
バッチ計画から作成する Linear の課題	Linear MCP（ユーザーが確認した場合）
バッチ計画から作成する Asana のタスク	Asana MCP（ユーザーが確認した場合）
Slack 通知	Slack:slack_send_message（チャンネルが指定されている場合）
Notion ミラー	Notion:notion-create-pages（ユーザーが確認した場合）
ステークホルダーへのメール	Gmail:gmail_create_draft（ユーザーが確認した場合）

---

実行手順

ステップ 1 — 設定を確認し、意図を抽出する

1a. カスタマイズ設定を確認します。 以下を確認してください。

• 環境変数（PRD_OWNER、PRD_STAKEHOLDERS、PRD_CONFLUENCE_SPACE など）
• ユーザーのプロンプトで指定された値（例：「Owner: @jane」「Space: ENG」）
• どちらもない場合は、先に進む前にユーザーに確認してください。

  「PRD を生成する前に、いくつか確認させてください。

  1. オーナーとして記載するのは誰ですか？（例：@your-name）
  2. 主なステークホルダーは誰ですか？（例：@product-lead、@security-lead）
  3. 公開先の Confluence スペースはどれですか？（例：ENG、PRODUCT）
  4. Slack チャンネルへの通知や、誰かへのメール送信は必要ですか？（任意）」

1b. ユーザーの説明から意図を抽出します。

• 機能名 → Confluence のタイトルに PROJECT-NAME として使用します
• 問題の説明 — これが必要な理由
• 大まかなスコープ — 対象範囲と対象外
• 有効にするコネクター — 文脈から推測します。下部のヒューリスティックを参照してください

重要な情報が不足している場合は、確認質問を最大 1 つします。その後、作業を進めます。

---

ステップ 2 — 仕様パイプラインを実行する（ロール 01〜10、インライン）

各ロールを頭の中で実行し、出力を連結します。

ロール	出力	トークン予算
01 コンテキストキュレーター	CLEAN_CONTEXT：事実、決定事項、未解決の質問	≤900
02 スコープカッター	SCOPE_DEFINITION：目標、非目標、対象範囲／対象外	≤800
03 制約抽出担当	ACTIVE_SET：テスト可能な AC 8〜15 件	≤700
04 要件エンジニア	NORMATIVE_REQUIREMENTS：RFC-2119、ID、P0/P1/P2	≤1500
05 曖昧さ検出担当	CLARIFICATIONS：重大な曖昧さにフラグを付けます。必要に応じて 04 に戻ります（最大 3 回）	≤1000
06 セキュリティエンジニア	SECURITY_REQUIREMENTS + THREAT_MODEL	≤1200
07 コントラクトアーキテクト	CONTRACTS：API、イベント、エラー分類	≤1200
08 検証マトリクス	すべての MUST に検証手順があること	≤1000
09 バッチプランナー	BATCH_PLAN：段階的で検証可能なバッチ	≤1200
10 最終ゲート	SHIP / NO_SHIP + ブロッカーの一覧	≤800

---

ステップ 3 — PRD を作成する

PRD テンプレート（このファイルの末尾を参照）を使用して、ドキュメント全体を作成します。

---

ステップ 4 — ファイルを書き込む

outputs/{feature-slug}-PRD.md          ← full PRD document
outputs/{feature-slug}-cursor-plan.md  ← .cursor/plans format

両方のファイルに create_file を使用し、その後、両方のパスを指定して present_files を呼び出します。

---

ステップ 5 — Confluence に公開する（必ず試行）

次の正確な順序でツールを呼び出します。

5a. クラウド ID を取得

tool: Atlassian:getAccessibleAtlassianResources
→ capture cloudId from response

5b. 親ページを検索

tool: Atlassian:searchConfluenceUsingCql
  cql: title = "{YOUR_TEMPLATE_TITLE}" AND space = "{YOUR_SPACE_KEY}"
→ capture page ID from first result
  fallback: ask user for parent page ID if search returns nothing

5c. PRD ページを作成

tool: Atlassian:createConfluencePage
  cloudId: {from 5a}
  spaceKey: {YOUR_SPACE_KEY}
  title: "{PROJECT-NAME} — {Feature Name}"
  parentId: {from 5b}
  body: {full PRD markdown content}

作成されたページの URL をユーザーに知らせます。いずれかのステップに失敗した場合は、その理由を記載し、いずれにしてもファイルを提供します。

---

ステップ 6 — 任意のコネクター

ユーザーの意図に基づいて有効にします（下部のヒューリスティックを参照）。Confluence への公開後に、一度だけ確認します。

「Linear／Asana のチケット作成、Slack への投稿、または仕様書のメール送信も行いますか？」

6a. Linear — バッチ計画から課題を作成

tool: Linear (search or create project matching feature name)
For each BATCH in BATCH_PLAN:
  create issue:
    title: "{BATCH_ID} — {batch goal}"
    description: steps + validation criterion + requirements covered
    priority: P0 batches → urgent | P1 → medium | P2 → low

6b. Asana — バッチ計画からタスクを作成

tool: Asana (find or create project "{PROJECT-NAME}")
For each BATCH:
  create task:
    name: "{BATCH_ID} — {batch goal}"
    notes: steps + validation + requirements
    assignee: infer from stakeholders or leave unassigned

6c. Slack — ステークホルダーに通知

tool: Slack:slack_search_channels → find #{channel}
tool: Slack:slack_send_message
  channel: #{channel}
  text: |
    📋 *New PRD: {Feature Name}*
    Status: DRAFT | Owner: @{OWNER_NAME}
    Confluence: {page URL from Step 5}
    _{2-sentence summary}_
    Batches: {N} | P0 requirements: {count}
    Reply to request changes.

6d. Notion — ページをミラーリング

tool: Notion:notion-search → find "Product Features" page or space root
tool: Notion:notion-create-pages
  parent: {found page}
  title: "{PROJECT-NAME} — {Feature Name}"
  content: full PRD markdown

6e. Gmail — ステークホルダー宛ての下書きを作成

tool: Gmail:gmail_create_draft
  subject: "[PRD DRAFT] {Feature Name}"
  body: executive summary + Confluence link + P0 requirements list
  (to: leave blank unless user provides emails)

---

PRD テンプレート

# {FEATURE_NAME}

**Owner:** @{OWNER_NAME}
**Status:** DRAFT
**Date:** {ISO_DATE}
**Version:** 1.0

---

## Interested Parties
- @{STAKEHOLDER_1}
- {other stakeholders}

---

## Document Status Reference

| Status | When | Action |
|--------|------|--------|
| DRAFT | Work in progress | Draft document |
| APPROVED | Reviewed and approved | Approved version |
| ARCHIVED | Obsolete | No longer active |

---

## 0) Overview

{problem_statement}

### Context
{clean_context summary — FACTS + DECISIONS from Role 01}

### Goals
{goals — from Role 02 Scope Cutter}

### Non-Goals
{non_goals — from Role 02 Scope Cutter}

---

## Features

### FEATURE 1 — {name}

**Objective:** {one-line}

#### Functional Logic
{R-FUNC-* requirements with IDs, priority tags, maps_to AC#}

#### UI / UX Changes *(if applicable)*
{R-UX-* requirements}

#### Data Model Changes *(if applicable)*
{field names, types, constraints, migration notes}

#### Export Requirements *(if applicable)*
{formats: CSV / PNG / PDF; fields included; filter state preservation}

#### Open Questions
1. {question}

---

{repeat FEATURE block for each logical grouping from normative requirements}

---

## Security Requirements

### Threat Model
- **Assets:** {list}
- **Actors:** {list}
- **Entry Points:** {list}
- **Trust Boundaries:** {list}
- **High-Risk Flows:** {list}

### Security Requirements
{R-SEC-* with IDs, [P0/P1], proof_hint: test|static|contract|manual}

### Abuse Cases *(only if they produce new requirements)*
{AC-SEC-* items}

---

## API Contracts

{API-001, EVT-001 definitions from Role 07 Contract Architect}

---

## Verification Matrix

| Requirement ID | Level | Proof Type | Proof Artifact | Notes |
|---|---|---|---|---|
| R-FUNC-001 | MUST | test | test_{name} | |
| R-SEC-001 | MUST | static | rule_{name} | |

---

## Delivery Plan

### BATCH 1 — {name}
- **Goal:** {goal}
- **Covers:** R-FUNC-001, R-SEC-001
- **Steps:**
  1. {step}
- **Validation:** {done-when criterion from verification matrix}
- **Risks/Rollback:** {risk + rollback strategy}

{repeat per batch}

---

## Data & Performance Considerations
{NFRs: volume thresholds, precomputation requirements, caching strategy, timezone handling}

---

## Risk & Mitigation

| Risk | Mitigation |
|------|-----------|
| {risk} | {mitigation} |

---

## Open Clarification Summary

1. {Q1}
2. {Q2}

---

## References
- Baseline spec: {reference doc or "N/A"}
- Confluence: {page URL from Step 5}

---

Cursor プランの形式

outputs/{slug}-cursor-plan.md として保存します。ユーザーはこれを .cursor/plans/ に配置します。

# Plan: {Feature Name}
Date: {ISO date}
Status: DRAFT

## Objective
{one paragraph}

## Implementation Batches

### Batch 1 — {name}
**Files to touch:** {list or TBD}
**Requirements:** R-FUNC-001, R-SEC-001
**Steps:**
1. {step}
**Done when:** {validation criterion}

### Batch 2 — ...

## P0 Requirements
- R-FUNC-001 [P0] MUST ...
- R-SEC-001 [P0] MUST ...

## Open Questions (resolve before implementation)
- Q1: ...

---

出力形式のルール

• 全体を通じて RFC 2119 を使用します：MUST / MUST NOT / SHOULD / MAY
• 要件 ID：R-FUNC-001、R-SEC-001、R-REL-001、R-UX-001
• 優先度タグ：[P0] クリティカルパス / [P1] 重要 / [P2] あると望ましい
• すべての機能要件に maps_to: AC# を記載します
• 事実を捏造しません。不明点は未解決の質問として明示します
• 全セクション合計で要件は最大 40 件です
• すべての MUST に検証マトリクス上の検証手順を設けます

---

エラー処理

状況	対応
説明が曖昧すぎる	質問を1つして、前提にフラグを付けたうえで進めます
Atlassian MCP の認証に失敗	ファイルのみを提出し、エラーを明確に記録します
Linear／Asana のプロジェクトが見つからない	新しいプロジェクトを作成し、名前をユーザーに報告します
Slack チャンネルが見つからない	正しいチャンネル名をユーザーに確認します
パイプラインで未解決の質問が10件を超える	優先度の高い阻害要因を5件提示し、残りは優先度の低い項目として保留します
要件に矛盾がある	CLARIFICATIONS に記載し、自動的に解決しないでください
Final Gate = NO_SHIP	阻害要因を明示的に列挙し、すべてのファイルを作成したうえで、PRD のステータスを BLOCKED にします

---

コネクターの有効化ヒューリスティクス

ユーザーのメッセージに以下のシグナルが含まれている場合、コネクターを積極的に有効化します。

シグナル	コネクター
「チケットを作成」「Linear に追加」	Linear
「Asana に追加」「タスクを作成」	Asana
「チームに通知」「Slack に投稿」、チャンネル名への言及	Slack
「送信」、または「仕様をメールで送信」、メールアドレスへの言及	Gmail
「Notion に追加」	Notion
PRD に関する依頼全般	Atlassian（常に）

シグナルがない場合のデフォルト：Atlassian + ファイルのみ。 Confluence へのプッシュ後、一度だけ尋ねます：「Linear チケットの作成、Slack での通知、または関係者へのメール送信も行いますか？」