Claude Code Plugins

Community-maintained marketplace

Feedback

create-prd

@yurenju/eyerolling-skills
13
0

|

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

name create-prd
description Generate Product Requirements Document (PRD) through interactive Q&A. Use when: clarifying feature requirements, defining user stories, establishing acceptance criteria, starting a new feature. Keywords: PRD, product requirements, requirements document, feature requirements, user stories, acceptance criteria. This is the first step of the spec-driven development workflow (or second if research was done first).

產生產品需求文件 (PRD)

目標

引導 AI 助理根據使用者的初始提示，以 Markdown 格式建立詳細的產品需求文件 (PRD)。PRD 應該清晰、可執行，並且適合產品經理和業務人員理解功能的商業價值和使用者需求。PRD 應使用與使用者對話中相同的語言（英文或中文）撰寫。

工作流程脈絡

整體開發流程

本指令是 claude-code-config 三步驟開發流程中的第一步：需求澄清。完整流程如下：

  1. 【選用】需求研究 (/research)：深入調查技術問題、探索解決方案、產出研究文件
  2. 【當前】需求澄清 (/create-prd)：透過問答釐清需求、產出 PRD 文件
  3. 實作規劃 (/create-impl-plan)：分析 PRD 和程式碼庫、產出任務清單和驗收測試
  4. 任務執行 (/process-task-list)：逐一實作任務、執行驗收測試

當前階段的輸入與輸出

輸入來源：

  • 使用者的初始功能描述
  • 澄清問題的回答
  • 【選用】research 文件（如果使用者先執行了 /research）

輸出目標：

  • PRD 文件 (docs/specs/[date]-[feature-name]/prd.md)
  • 目標讀者：產品經理、業務人員、專案管理者
  • 閱讀目的：理解功能的商業價值、使用者需求、驗收標準

當前階段的職責範圍

應該包含：

  • 功能的商業背景和使用者價值
  • 清晰的使用者故事和使用場景
  • 功能需求（做什麼，而非怎麼做）
  • 高階的驗收標準（業務層面的判斷標準）
  • 高層次的技術方向（例如「需與現有認證系統整合」）

不應該包含：

  • 詳細的程式碼範例或實作步驟（這些屬於 implementation.md）
  • 具體的 API 設計或檔案結構（這些屬於 implementation.md）
  • 詳細的 Gherkin 測試場景（這些會在 acceptance.feature 中產生）
  • 技術選型的深入分析（這些屬於 implementation.md 的「實作參考資訊」）

與其他階段的關係

與 research 文件的關係：

  • 如果 PRD 基於 research 文件，應該「引用」研究發現，而非「複製」技術細節
  • Research 中的程式碼範例、架構決策、技術分析，應該透過引用提及，真正的保留和展開會在 implementation.md 階段發生
  • 例如：「基於 research 文件的分析，建議採用事件驅動架構」（而非複製整個架構圖和程式碼）

為下游階段準備：

  • PRD 會被 /create-impl-plan 讀取，用來產生詳細的任務清單
  • 高層次的技術方向會在 implementation.md 中被展開成具體的實作要點
  • 高階驗收標準會在 acceptance.feature 中被轉化成詳細的 Gherkin 場景
  • Research 文件的技術細節會在 implementation.md 的「實作參考資訊」章節中被保留和引用

流程

  1. 接收初始提示： 使用者提供新功能或功能性的簡要描述或請求。
  2. 詢問澄清問題： 在撰寫 PRD 之前，AI 必須 詢問澄清問題以收集充分的細節。目標是理解功能的「什麼」和「為什麼」，而不一定是「如何」（這將由開發者解決）。
  3. 產生 PRD： 根據初始提示和使用者對澄清問題的回答，使用下面概述的結構產生 PRD。如果使用者引用了研究文件，將該研究的見解納入 PRD 中。
  4. 取得當前日期： 取得日期： date +%Y-%m-%d
  5. 儲存 PRD： 將產生的文件儲存為 docs/specs/[date]-[feature-name]/prd.md。

澄清問題（範例）

AI 應根據提示調整其問題，但以下是一些常見的探索領域：

  • 問題/目標： 「這個功能為使用者解決了什麼問題？」或「我們希望透過這個功能達成什麼主要目標？」
  • 目標使用者： 「誰是這個功能的主要使用者？」
  • 核心功能： 「您能描述使用者應該能夠使用這個功能執行的關鍵操作嗎？」
  • 使用者故事： 「您能提供一些使用者故事嗎？（例如，作為[使用者類型]，我想要[執行動作]以便[獲得益處]。）」
  • 驗收標準： 「我們如何知道這個功能已經成功實作？」
  • 範圍/邊界： 「這個功能有任何特定不應該做的事情嗎（非目標）？」
  • 資料需求： 「這個功能需要顯示或操作什麼類型的資料？」
  • 邊緣案例： 「我們應該考慮任何潛在的邊緣案例或錯誤情況嗎？」

PRD 結構

產生的 PRD 應包含以下部分：

  1. 簡介/概述： 簡要描述功能及其解決的問題。陳述目標。如果基於研究，引用研究文件（例如，「基於 docs/research/[date]-[topic].md 中的研究發現」）。
  2. 目標： 列出此功能的具體、可衡量的目標。
  3. 使用者故事： 描述功能使用和效益的詳細使用者敘述。
  4. 功能需求： 列出功能必須具備的特定功能。使用清晰、簡潔的語言（例如，「系統必須允許使用者上傳個人資料圖片。」）。為這些需求編號。
  5. 非目標（超出範圍）： 明確說明此功能_不會_包含的內容以管理範圍。
  6. 設計考量（選擇性）： 連結到模型、描述 UI/UX 需求，或提及相關元件/樣式（如適用）。
  7. 技術考量（選擇性）： 提及任何已知的技術限制、相依性或建議（例如，「應與現有的身份驗證模組整合」）。
  8. 開放問題： 列出任何剩餘的問題或需要進一步澄清的領域。
  9. 參考資料（如適用）： 列出任何為此 PRD 提供資訊的研究文件或其他資源。

目標讀者

假設 PRD 的主要讀者是產品經理、業務人員和專案管理者。因此，需求應該明確、不含糊，並專注於商業價值和使用者需求。使用業務語言而非技術專業術語。提供充分的細節讓他們理解功能的目的、使用者價值和商業邏輯，但不需要包含實作細節（這些會在後續的實作規劃階段處理）。

語言選擇

PRD 應使用與使用者對話中相同的語言撰寫：

  • 如果使用者使用中文溝通，用中文撰寫 PRD
  • 如果使用者使用英文溝通，用英文撰寫 PRD
  • 在整個文件中保持與使用者語言的一致性

最終指示

  1. 不要開始實作 PRD
  2. 確保詢問使用者澄清問題
  3. 納入使用者對澄清問題的回答以完善 PRD
  4. 讓 PRD 的語言與使用者的對話語言相符

範例

完整的 PRD 範例請參考：examples/migrate-to-skills-prd.md