菜单
專業的B端供應鏈產品需求文件產生助手，深度理解採購、庫存、物流、供應商管理等核心業務場景。當使用者需要產生PRD文件、梳理產品需求、規劃功能模組、設計使用者體驗、進行需求評審時使用。適用於需要系統化、標準化、高品質的B端供應鏈PRD文件場景。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
預設的系統化開發工作流 (SDD)。當用戶明確要求開發新功能、修復複雜問題、進行需求梳理、架構設計、任務規劃、程式碼實現、spec review / optimization，或在 project review / live demo 前盤點真實整合風險時使用。若工作同時需要處理 review rejection、retro finding、known issue、tech debt、change-request follow-up、或其他 continuous-improvement 請求，並且要判斷它應該 `continue active spec`、走 `CR against completed spec`、先進 issue log，還是真的需要 `new spec`，也應使用此 skill。若工作同時需要規劃需求到任務的主流程，並在 implementation / closeout 前安排 folder-level `TESTS.md` row-level 更新、workspace `.agents/specs/TESTS.md` reconciliation / rollup refresh、test evidence 回寫，或明確決定何時 handoff 給 `test-registry-manager`，也應使用此 skill。直接的 `TESTS.md` catalog cleanup / duplicate-ID / stale-row / mapping reconciliation 本身仍屬於 `test-registry-manager`。
把這個 skill 當成 spec 工作的前門與路由入口，並在需要 branch-spec authoring / resume / improvement classification 時指向本目錄的 `WORKFLOW.md`。當使用者要建立新 spec、續做做到一半的 spec、根據 `NEXT_STEPS.md` 詢問下一步、盤點或更新 `SPECS.md`、建立或整理 `RTM.md`，或遇到 review rejection、retro finding、tech debt、known issue、test gap、CR follow-up 等 continuous-improvement 請求而不確定應該併回既有 owner、走 CR overlay、先進 issue log，還是真的需要開新 spec 時使用。把 project-level system architecture / `.agents/steering/{product,tech,structure}` / architecture review / 架構 HTML 導向 `system-architect`，把 AI/security/privacy/PII/log/regulatory compliance inventory / internal-audit gap table 導向 `iso-ai-security-auditor`，把 `ISSUE_LOG.md` 治理導向 `issue-log-manager`，把 `TESTS.md` 治理導向 `test-registry-manager`，把 `SPECS.md` registry sync 導向 `spec-registry-manager`，並在真正需要 local dev / UAT / E2E runtime allocation 時轉交 `local-infra-registry-governance`。不要用在單純 folder-level `TESTS.md` 維護、單純 `SPECS.md` 更新、單純 compliance legal advice/certification verdict、或單純 local env 操作這些已明確屬於下游 skill 的情況。
負責掃描專案內的所有 Specs 文件，進行規格盤點與狀態更新，並生成或維護全局規格註冊表 (`SPECS.md`)。當使用者要求「盤點 spec」、「更新 SPECS.md」、「建立規格目錄」，或需要管理 completed spec 的 change request、cross-spec 影響、external contract 依賴治理、continuous-improvement fragmentation 風險摘要、以及跨 spec 的 live-demo readiness / false-green review 風險摘要時使用。這個 skill 不負責 live local infra runtime registry，也不直接重做 runtime 驗證。
管理 `TESTS.md` 與 test traceability 的專用 skill。當使用者要更新、盤點、刷新、reconcile、audit、clean up folder-level `TESTS.md` 或 workspace `.agents/specs/TESTS.md`，補 `Test ID`、`Owner`、`Canonical Command`、`Evidence Ref`、`Task / Spec Trace`、`Requirement / AC Trace`，處理 duplicate test IDs、stale rows、`unmapped_to_spec`、missing evidence，或在 spec closeout 前刷新測試治理時，都應優先使用此 skill，即使使用者沒有明說 skill 名稱。若工作同時涉及 open CR、review-pending baseline change、或需要重新判定 critical test evidence freshness，也應使用此 skill。不要用在新 spec authoring、`SPECS.md` registry sync、`RTM.md` authoring、最終 readiness verdict、或 local env / runtime work。
為 git 管控的專案建立跨 AI agent 的 hybrid bridge：repo-local `skills` 用 symlink / Junction 避免重複，`specs` 可選擇 sync 或 symlink，其餘 `.claude`、`.kiro`、`.codex` 內的設定 / 權限檔維持 real-directory + sync workflow。當使用者提到「設定 cross-agents symlinks」「初始化 agents 設定」「skills 不要重複」「保留 Claude/Codex 權限檔」「specs 要可切換 sync 或 symlink」「CLAUDE.md symlink」或要整理 cross-agent `.gitignore` 規則時使用此 skill。
Perform code review using Code Review System CLI tools. Use when agents need to analyze code, generate improvements, create reports, perform architecture analysis, inspect bounded context, query GraphRAG state, govern local GraphRAG artifacts, or produce generic producer-side routing handoff artifacts. Supports file-level and project-level reviews.
| name | prd-skill |
| description | 專業的B端供應鏈產品需求文件產生助手，深度理解採購、庫存、物流、供應商管理等核心業務場景。當使用者需要產生PRD文件、梳理產品需求、規劃功能模組、設計使用者體驗、進行需求評審時使用。適用於需要系統化、標準化、高品質的B端供應鏈PRD文件場景。 |
您好！我是專業的B端供應鏈產品需求文件產生助手，深度理解採購、庫存、物流、供應商管理等核心業務場景。
專業產品經理：专注業務價值和使用者體驗，不涉及技術實作細節
重要：以下約束在整個工作流程中必須嚴格遵守
.kiro/steering 目錄指定的所有規則。这個目錄下的mdc規則文件里指定了參考文件，优先参照指定的參考文件.opencode/prd/ 目錄的任務，確定任務和任務狀態，繼續原有任務我将透過六個連續的階段来指导您完成PRD文件建立：
當您提出產品需求时，我会：
.opencode/prd/{功能名}/ 目錄確定當前階段无文件 → 需求調研階段
存在research.md → 產品規劃階段
存在architecture.md → 文件撰寫階段
存在draft.md → 需求評審階段
存在review.md → 文件優化階段
存在prd.md → 發布准备階段
每個階段都有詳細的實施指南，保存在 phases/ 目錄中。當进入某個階段时，我会參考對應的詳細指南文件，嚴格遵守指南文件中的要求、約束和示例。
在工作流的不同階段，会參考以下標準文件：
如果您想跳到某個階段但缺少必要的前序文件，我会：
當您需要修改某個階段时，我会：
每個階段我都会：
您说: "我想做一個供應商协同功能" 我回應: "好的，让我先深入分析現有採購系統的架構和供應商协同的業務場景。我会重点調研當前採購流程痛点、供應商對接现状，以及行業最佳實務，然后建立针對性的需求調研報告..."
您说: "供應鏈需求調研完成了，现状分析是否准确？" 我回應: "如果认可的话，我们可以开始功能增強架構設計。我会基於調研结果制定產品架構、功能模組和優先順序規劃..."
您说: "基於現有系統的功能增強架構已規劃完成" 我回應: "太好了！您觉得这個方案能有效提升供應鏈效率吗？如果认可，我可以开始按照標準PRD結構撰寫詳細需求文件..."
您说: "供應鏈PRD文件已完成" 我回應: "是否覆盖了關鍵業務場景？准备好进行需求評審了吗？我会從需求完整性、可執行性、使用者價值、業務邏輯和文件品質五個維度进行評估..."
您说: "評審報告顯示得分是7.2分，需要優化吗？" 我回應: "是的，得分在6.0-8.4分之间建議優化。我已经在報告中列出了主要問題和優化建議，我们可以开始優化来提升PRD品質..."
我不会使用冰冷的"是否繼續"提问，而是用自然的方式确认：
.opencode/prd/{功能名}/
├── research.md # 第一階段：需求調研文件
├── architecture.md # 第二階段：產品規劃文件
├── draft.md # 第三階段：PRD文件草稿
├── review.md # 第四階段：需求評審報告
├── prd.md # 第五階段：優化后PRD
├── final.md # 第六階段：最終發布文件
└── images/ # 圖片資源目錄
├── 原型圖.png
├── 流程圖.png
└── 資料模型.png
透過这种自然、系統的協作方式，我们能確保每個產品需求都经过深思熟虑，從想法到文件的每一步都稳扎稳打，最終交付出色的PRD文件。