prd-planner

prd-planner skill 概覽

prd-planner 是做什麼的

prd-planner 是一個用來產出產品需求文件的 Requirements Planning skill。它不是靠一次很長的 prompt 直接生成，而是採用可持續、以檔案為核心的工作流程。它真正的價值不只是「寫一份 PRD」，而是把研究內容、前提假設、任務進度、最終需求與技術延伸事項，分開存放在穩定的檔案中，避免 agent 在流程進行到一半時遺失上下文。

哪些人適合使用 prd-planner

如果你是團隊成員，或是獨立開發者，而且你要的不只是一次性的 PRD 草稿，那 prd-planner 會很適合。特別是在你需要把探索、邊界情境、PRD 撰寫與技術設計串起來並保有可追蹤性時，它會很有幫助。若你預期需求會經過多輪修訂，這個 skill 會比一般單次 prompt 更可靠。

要完成的工作

多數人會採用 prd-planner，是因為他們需要一套能承受反覆迭代的結構化 PRD 產出流程：先釐清需求、整理筆記、產出可用的 PRD，接著往往還要銜接到技術設計。這個 repository 也明確把它定位成解決情境切換、想法遺失，以及 PRD 輸出品質不一致等問題的方式。

prd-planner 的差異化在哪裡

prd-planner 最明顯的差異，在於它的 4-file pattern。它不會把所有內容一次塞進同一份回應，而是建立 plan、notes、PRD 與 technical design 四種獨立檔案，通常放在 docs/ 下，並共用同一個 scope 前綴。對於需要回頭檢視、審閱與持續擴寫的 Requirements Planning 工作來說，這種做法明顯更合適。

什麼情況下不適合用 prd-planner

如果你只需要很快產出一份功能簡述、做一場鬆散的腦力激盪，或只想寫純技術解法架構文件，就不適合用 prd-planner。這個 skill 本身也明講：如果是純 architecture 類需求，除非使用者明確要求 PRD，否則應該改用 architecting-solutions。

如何使用 prd-planner skill

prd-planner 的安裝情境

這個 repository 並沒有在 skill 內提供通用型的 package installer。隨附的 README.md 展示的是把 skill 以本機 symlink 方式安裝到 Claude skills 目錄：

ln -s ~/Documents/code/GitHub/agent-playbook/skills/prd-planner/SKILL.md ~/.claude/skills/prd-planner.md

如果你用的是其他 skill loader，就要依照你的 agent 平台所要求的目錄位置或註冊方式，套用相同概念去調整。若你是從 GitHub 瀏覽，這個 skill 位於 zhaono1/agent-playbook 的 skills/prd-planner。

先讀這些檔案

如果你想快速完成 prd-planner install 與初步評估，建議依照以下順序閱讀：

1. skills/prd-planner/SKILL.md
2. skills/prd-planner/README.md
3. skills/prd-planner/references/edge-case-analysis.md

SKILL.md 會告訴你啟用規則、工作流程意圖、工具需求，以及核心的檔案模式。reference 檔則補上實務上很重要的邊界情境掃描方法，對提升 PRD 品質有明顯幫助。

prd-planner 會如何啟用

這個 skill 的設計，是在使用者明確要求 PRD、說出「product requirements document」，或使用對應的中文說法時才會觸發。這點很重要，因為它不是通用型規劃工具。若你的 prompt 比較像「設計系統架構」，而不是「建立 PRD」，就可能觸發錯誤流程，或拿到較弱的結果。

你應該預期的 4-file pattern

一般的 prd-planner usage 流程，會在 docs/ 下用簡短的 kebab-case scope 建立四個專案檔案：

docs/{scope}-prd-task-plan.md
docs/{scope}-prd-notes.md
docs/{scope}-prd.md
docs/{scope}-tech.md

這是這個 skill 的核心運作模型。如果你不希望建立檔案，也不想留下可持續迭代的產物，那 prd-planner 大概就不是最適合你的選擇。

prd-planner 需要你提供哪些輸入

當你提供以下資訊時，prd-planner 的效果最好：

• 功能或產品目標
• 目標使用者
• 商業目標或成功指標
• 時程、平台、合規或既有技術棧等限制條件
• 已知的非目標
• 相關程式碼、文件、tickets 或範例連結

如果缺少這些資訊，這個 skill 仍然可以起草 PRD，但會更依賴假設來補足空白。

把模糊需求變成高品質 prompt

弱的 prompt：

Create a PRD for notifications.

較強的 prompt：

Create a PRD for in-app notifications for our B2B admin dashboard.
Users are account admins and support managers.
Goal: reduce missed follow-up tasks and improve response SLA compliance.
Constraints: web app first, existing React frontend and Node backend, no push notifications in v1.
Non-goals: email campaign tooling, mobile support.
Please use docs/notifications as the scope basis and call out edge cases, permissions, and rollout risks.

後者提供了足夠的上下文，讓 prd-planner 能寫出具體的 PRD，而不是空泛的通用文件。

實務上建議的 prd-planner 工作流程

一個實際可行的流程通常是：

1. 明確要求產出 PRD。
2. 提供商業背景、範圍與限制條件。
3. 讓 skill 建立整組檔案。
4. 先看 notes 檔，不要只看最後的 PRD。
5. 盡早修正錯誤假設。
6. 再要求針對邊界情境、acceptance criteria 與技術影響做第二輪補強。
7. 把產出的 *-tech.md 當成銜接實作規劃的橋梁。

這也是它勝過單一 prompt 的地方：你可以透過修改 notes 再重新整合，而不是每次都從零開始。

及早使用 edge-case 參考檔

最值得優先使用的輔助檔案是 references/edge-case-analysis.md。裡面包含需求類型分類，以及掃描 codebase pattern 的指令，涵蓋像是刪除策略、loading states、pagination、validation 與 error handling 等面向。這對 Requirements Planning 很有價值，因為很多品質不佳的 PRD，正是漏掉了這些行為細節。

能提升輸出品質的 repo 實務提醒

這個 skill 允許使用 Read、Write、Edit、Bash、Grep、Glob、AskUserQuestion 與 WebSearch 等工具。實務上這表示：prd-planner 的設計前提，是要去檢視真實 codebase，並在必要時追問澄清問題，而不是憑空生成一份文字。如果你的環境禁止寫檔或 shell 搜尋，就會失去這個 skill 很大一部分的預期價值。

面對既有產品時，最佳的 prd-planner prompt 模式

如果這個功能屬於既有系統，請直接在需求中附上 codebase 線索，例如：

Create a PRD for bulk user deactivation.
Relevant areas:
- `src/features/users/`
- existing soft delete behavior
- admin audit log requirements
Please inspect current list, detail, and permission patterns before drafting requirements.

這樣能把 prd-planner 引導到更貼近現況的需求整理，而不是停留在抽象的產品文字撰寫。

接受輸出前要先檢查什麼

在你把 PRD 視為定稿之前，請確認 prd-planner 是否有涵蓋以下內容：

• 使用者角色與權限
• 明確的非目標
• 邊界情境與失敗狀態
• rollout 或 migration 相關考量
• 可衡量的成功標準
• 對現有系統行為的依賴

少了這些，即使文件看起來很完整，實際上仍然有風險。

prd-planner skill 常見問題

prd-planner 適合初學者嗎

適合，前提是你已經知道自己要做的功能，只是需要一個有結構的方式來整理。這套檔案模式可以降低面對空白頁時的不知所措。但它不是用來跳過產品思考的捷徑；如果輸入內容薄弱，產出的需求一樣會很淺。

prd-planner 和一般 PRD prompt 有什麼不同

一般 prompt 通常只會回傳一份文件。prd-planner skill 則是圍繞可持續保存的規劃產物來設計，讓 agent 能把研究、進度、輸出與技術後續拆開管理。這通常會帶來更好的修訂品質，也比較不容易在過程中丟失上下文。

prd-planner 只能拿來做新產品嗎

不是。對既有產品來說，它甚至可能更有價值，因為 reference material 會鼓勵你掃描 codebase 裡現有的模式。這能讓產出的 PRD 更貼近真實的實作限制。

我可以只拿 prd-planner 來做 architecture design 嗎

不太理想。這個 skill 已經明確指出：如果只是 architecture-only request，應該使用 architecting-solutions，除非使用者真正要求的是 PRD。比較好的用法是把 prd-planner for Requirements Planning，而不是把它當成萬用設計工具。

prd-planner 一定需要檔案寫入權限嗎

如果你想用到它原本設計的工作流程，實際上是需要的。這個 skill 的核心價值就在於把內容寫成檔案並持續迭代。如果你的環境只有 chat，仍然可以借用它的 prompting 方法，但會失去它的持久化模型。

什麼時候應該跳過 prd-planner

如果你只需要一小段一段落簡述、單純 user story，或還在做沒有穩定 scope 的探索式發想，就可以跳過。4-file 流程的成本，比較適合用在 PRD 需要被審閱、修訂，或交接給工程團隊的情境。

如何提升 prd-planner skill 的效果

給 prd-planner 更清楚的 scope 定義

影響品質最大的槓桿，就是 scope 是否清楚。請提供一個簡短且不易混淆的 scope 名稱，並明確界定哪些是 v1、哪些不在範圍內。這不只讓檔名更乾淨，也能有效控制需求蔓延。

提供商業意圖，不只丟功能名稱給 prd-planner

「Build approvals」太模糊了；「Build an approval flow for purchase requests over $5,000 to reduce manual finance review time by 40%」則能讓 prd-planner 產出更好的目標、user stories 與 acceptance criteria。

一開始就提供已知限制條件

請儘早告知這個 skill 你的技術棧、合規要求、時程、組織邊界與現有流程。這些限制對 PRD 的影響，通常比大多數使用者想像得還大。缺少限制條件，常會導致文件看起來漂亮，卻根本無法落地。

明確要求它記錄 assumptions

一個很實用的 prd-planner guide 用法，是直接告訴 agent：「請把 assumptions 另外列在 notes 檔，並標出哪些需要確認。」這樣可以避免未被驗證的猜測悄悄混進最終 PRD，看起來像已經定案的事實。

用具備 codebase awareness 的方式做 edge-case analysis

如果你能存取原始碼，請要求 prd-planner 在定稿前先檢查現有模式，包括 validation、pagination、loading、permissions 與 delete behavior。這裡提供的 reference 檔特別有用，因為它把模糊的「記得考慮 edge cases」變成了具體可執行的掃描方式。

在看最終 PRD 前，先審 notes 檔

很多人只讀 *-prd.md，但品質瓶頸通常其實出在 *-prd-notes.md。在 notes 階段修正錯誤假設，成本遠低於後面再重寫一份表面完整、但方向不對的 PRD。

迭代時補的是缺失的決策，不只是文字細節

第一版產出後，不要只要求「寫更詳細」。更好的做法是要求它針對具體問題補強，例如：

• 更明確的成功指標
• 清楚的權限規則
• 失敗情境與恢復流程
• 相依關係整理
• rollout sequencing
• 需要 stakeholder 回答的 open questions

這種迭代提升的是決策品質，而不只是文件篇幅。

要特別留意的常見失敗模式

常見的弱輸出通常有這些特徵：

• persona 很泛，沒有真實使用者脈絡
• 需求忽略現有系統行為
• 缺少非目標
• 沒有處理 edge cases
• technical design 看起來像套版
• acceptance criteria 模糊到無法驗證

這些問題通常不只是 model 問題，更常是輸入品質出了問題。

把 prd-planner 納入 stakeholder review 迴圈

當你把第一版視為 working draft，而不是最終稿時，prd-planner usage 的效果會更好。可以讓 product 看 PRD、engineering 看 technical design，而所有人一起檢視 assumptions。這個以檔案為核心的結構，很適合支援這種分工式審查。

透過自家模板標準化，提升 prd-planner 採用率

如果你的團隊喜歡這套流程，可以圍繞 prd-planner 定義自己的 scope 命名方式、docs/ 慣例、PRD 章節格式與 review checklist。這個 skill 本身已經提供了很扎實的骨架，再加上內部標準後，輸出會更穩定，也更接近可直接交付的品質。