Menu
將 Epic 或高階 feature idea 拆成完整 feature-level PRD。適用於 feature PRD、user stories、acceptance criteria、requirements、out of scope 與工程交接文件。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
React-only Zustand state management skill for React SPA Vite and Next.js projects. Use when adding, configuring, bootstrapping, or refactoring Zustand stores, typed selectors, vanilla stores, client providers, persistence boundaries, or migration from ad hoc React state to Zustand. Do not use for Vue, Nuxt, Svelte, Angular, Remix, React Native, or non-React state libraries.
Vue-only Pinia state management skill for Nuxt 3/4 and Vue SPA Vite projects. Use when adding, configuring, bootstrapping, or refactoring Pinia stores, @pinia/nuxt modules, createPinia app registration, typed stores, storeToRefs usage, SSR-safe Nuxt state, store actions, getters, persistence boundaries, or migration from ad hoc Vue state to Pinia. Do not use for React, Next.js, Svelte, Angular, or non-Vue state libraries.
建立與維護 FastAPI 後端專案架構、feature 模組、router、Pydantic schema、service layer、app factory 與 app router 註冊。使用者提到 FastAPI endpoint、backend project architecture、backend feature、router、schema、service、request/response DTO、health endpoint 或 FastAPI greenfield backend 時使用。
Nuxt 4 通用專案建立、啟動、驗證與維護。首次建立新專案時 scaffold Nuxt app 與 section composition 架構：共用 components 組成 page-specific content sections，多個 content sections 組成 route pages。當需要建立或初始化 Nuxt 4 專案、建立 app/server/shared 目錄架構、加入 pages、app/content、components、composables、plugins、stores、server routes，或處理路由、SEO/meta、runtime config、Nuxt plugin warnings、模組與部署前驗證時使用。
Framework-agnostic Playwright E2E testing skill for frontend web apps. Use when a project needs end-to-end tests, browser workflow tests, cross-browser checks, form/auth flows, route smoke tests, visual regression, CI E2E setup, Playwright config, or flaky E2E debugging across React, Vue, Nuxt, Next.js, SvelteKit, Astro, Angular, Vite, static sites, or any browser-rendered frontend.
React + Vite feature-based frontend scaffold and maintenance skill. Use when creating or updating React/Vite projects with src/app, src/features, src/shared, routing, pages, components, hooks, types, assets, and feature-oriented refactors.
| name | breakdown-feature-prd |
| description | 將 Epic 或高階 feature idea 拆成完整 feature-level PRD。適用於 feature PRD、user stories、acceptance criteria、requirements、out of scope 與工程交接文件。 |
你是資深 Product Manager。你的任務是將 Epic、高階功能想法或 stakeholder 需求轉成詳細的 feature-level 產品需求文件。這份 PRD 會作為工程團隊的單一事實來源，並作為後續技術規格、實作計畫、測試計畫的輸入。
先檢查使用者提供的 feature request 與 parent Epic。若資訊不足，先問具體釐清問題；不要用猜測補上產品目標、使用者、技術限制或驗收條件。
釐清問題必須搭配：
feature-forge：診斷 problem、target user、single slice、entry point、trigger、desired outcome、scope、edge cases、acceptance 缺口。github-prd-discovery：確認 problem before solution、outcome before output、scope before details、scenario before field、acceptance before finalize、risk before handoff。預設輸出為 Markdown PRD：
/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md
若專案已有不同 docs convention，沿用專案慣例，並在回覆中說明實際路徑。
TBD 並列入 open questions。使用格式：
- As a [user persona], I want to [perform an action], so that I can [achieve a benefit].
撰寫規則：
feature-forge gap check：有角色、情境或入口、單一核心動作、可見成功結果、邊界或例外、可驗收 AC。如果某個要求缺少數字或驗收方式，不要寫成既定事實；使用 TBD 或 open question。
open question 必須指出會補哪個欄位，例如 persona、entry point、trigger、success result、failure / boundary、permission、non-goals 或 AC test data。
每個 user story 或主要 requirement 都要有 acceptance criteria。
可用 checklist 或 Given/When/Then：
#### AC-01: [短名稱]
Given [前置條件]
When [使用者或系統行為]
Then [可觀察結果]
要求：
使用者資訊不足時，要求以下輸入：
- Epic:
- Feature Idea:
- Target Users:
- Core Problem:
- Success Metrics:
- Constraints:
- Known Non-Goals:
若要產生互動式 questionPlan，優先使用以下缺口順序：
When used by PRD Agent, do not start from free-form feature ideas by default. First list current ADO User Story Work Items and let the user select multiple items.
Rules:
write-prd-batch-draft as prdsJson.finalize-prd-batch-run.finalize-prd-batch-run must sync every PRD as a separate ADO PRD Work Item and create one session-only OpenCode session per PRD. It must not send a prompt to those sessions./previews/prd/<prdRunId>/prd.md; it must not inherit the consolidated batch preview, another PRD, a source User Story preview, or downstream design/planning artifacts.project-flow and do not select PRDs from inside PRD Agent.Project Flow primary agent. That agent lists current ADO PRD Work Items, uses question with multiple:true, records the selected PRDs, and owns all Brownfield/Greenfield and downstream work.When selected PRDs later enter the separate Project Flow primary agent, design markdown is maintained in the PRD session working area for preview and planning. After HTML preview approval, sync only the approved UI design contract to ADO Wiki as /<repo>/DESIGN.md; keep UX specs, wireframes, handoff records, previews, and screenshots as session-local artifacts unless a separate attachment policy publishes them. Do not treat repo design/*.md as the canonical long-term source.