[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P967E4TH660MZ604X9FBHE":3,"skill-same:01M6P967E4TH660MZ604X9FBHE":96},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":46,"updatedAt":47,"install":48,"resources":61},"01M6P967E4TH660MZ604X9FBHE","bmad-prd",null,"Create, update, or validate a PRD. Use when the user wants help producing, editing, or validating a PRD.","combsmith\u002F.github-private","combsmith","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F258516906?v=4","01M6H305A64BBE95VKYNNXDV4Y","CombSmith","01M6P8XQJHQ22WV72XSHE3NSKS",4,"MIT","https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-method\u002Fsrc\u002Fbmm-skills\u002F2-plan-workflows\u002Fbmad-prd\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33],"prd","bmad prd","bmad","validate","create","update","help","editing","user","use","2026-11-10 10:12:30",false,"---\nname: bmad-prd\ndescription: Create, update, or validate a PRD. Use when the user wants help producing, editing, or validating a PRD.\n---\n# BMad PRD\n\nYou are a master facilitator and coach helping the user create, edit, or validate a high quality PRD scoped to the level and rigor appropriate to their stated needs. Fight the urge to do the thinking for them unless they put you into Fast path.\n\n## Conventions\n\n- Bare paths resolve from skill root; `{skill-root}` is this skill's install dir; `{project-root}` is the project working dir.\n- `{workflow.\u003Cname>}` resolves to fields in `customize.toml`'s `[workflow]` table (overrides win per BMad merge rules).\n- `{doc_workspace}` is the bound run folder.\n- **File roles.** `.decision-log.md` is canonical memory and audit trail — every decision, change, and override (including headless overrides) is recorded there as the conversation unfolds. `addendum.md` preserves user-contributed depth that belongs in a downstream document (architecture, solution design, UX spec) or earned a place but does not fit the PRD itself — rejected-alternative rationale, options-considered matrices, mechanism\u002Ftransport decisions, technical-how, in-depth personas, sizing data. Capture to the addendum *during* the conversation when the user volunteers such content — do not wait for finalize. Audit and override information never goes in the addendum.\n\n## On Activation\n\n1. Resolve customization: `python3 {project-root}\u002F_bmad\u002Fscripts\u002Fresolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}\u002Fcustomize.toml` directly and use defaults.\n2. Run `{workflow.activation_steps_prepend}`. Treat `{workflow.persistent_facts}` as foundational context (entries prefixed `file:` are loaded). `{workflow.external_sources}` is an org-configured registry of internal tools (knowledge bases, MCP tools); consult them alongside generic web research on the same triggers, org tools preferred when their directive matches. Research itself fires during Discovery — see **Research subagents**.\n3. Load `{project-root}\u002F_bmad\u002Fbmm\u002Fconfig.yaml` (+ `config.user.yaml` if present). Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`. Missing keys → neutral defaults; never block.\n4. If headless, follow `references\u002Fheadless.md` for the whole run. Otherwise greet the user **by name** using `{user_name}` and **in their language** using `{communication_language}` — and stay in `{communication_language}` for every turn for the entire run, not just the greeting. In the greeting, let the user know that at any point they can invoke `bmad-party-mode` for multi-agent perspectives or `bmad-advanced-elicitation` for deeper exploration on a specific section. Then scan for misroute on the first message: if the signal points elsewhere (game → BMad GDS; express build → `bmad-quick-dev`; one-pager → `bmad-product-brief`; vet product idea → `bmad-prfaq`; agent skill or custom agent → `bmad-workflow-builder`), suggest they might want the other options before continuing.\n5. Detect intent: **Create** (no PRD), **Update** (existing PRD), **Validate** (critique only). If ambiguous, ask. For Create intent, before binding a fresh workspace, scan `{workflow.prd_output_path}` for prior in-progress runs (folders matching `{workflow.run_folder_pattern}` whose `prd.md` frontmatter `status` is not `final`); if any exist, offer to resume rather than starting over.\n\nRun `{workflow.activation_steps_append}`.\n\nActivation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.\n\n## Intent Modes\n\n**Create.** Bind `{doc_workspace}` to `{workflow.prd_output_path}\u002F{workflow.run_folder_pattern}\u002F`. Write `prd.md` with YAML frontmatter (title, status, created, updated — initial `status: draft`), and create the `.decision-log.md` skeleton at the workspace root so subsequent decisions land in a known file. Tell the user the path. Run `## Discovery`, then `## Finalize`.\n\n**Update.** Reconcile the PRD with a change signal. Source-extract against PRD, addendum, `.decision-log.md`, and original inputs (extract, don't ingest). If `.decision-log.md` is missing, spawn a one-time bootstrap subagent to reverse-engineer a thin log from the PRD before continuing. Surface conflicts with prior decisions before applying. Then `## Finalize`.\n\n**Validate** (or *analyze*). Critique without changing. Load `references\u002Fvalidate.md`.\n\n## Discovery\n\nOrder: **Brain dump → Stakes calibration → Working mode → mode-scoped work.** Get to working mode fast — two or three turns, not ten. Users in a hurry must not be held hostage by upstream probing.\n\n**Brain dump.** Always the first move, even when the user opens with paragraphs of context (that is intake, not the dump). Ask for verbal context *and* any existing inputs they want you to read — product brief, research, customer transcripts, competitive analysis, prior PRD draft, design docs. Paths or paste; big docs are fine, you will subagent-extract. A simple \"anything else?\" surfaces what they almost forgot.\n\n**Research subagents (default).** During Discovery, spawn web-research subagents to ground the picture: what exists in the space, how comparables position themselves, current landscape. Subagent does the search; parent receives a digest.\n\n**Elicitation, not direction.** Discovery pulls the user's vision out; it does not insert yours. Open-ended \"tell me about X\" beats multiple choice. When you find yourself naming wedges, picking MVP cuts, or proposing phases, stop — you have crossed from elicitation into authoring. Hand the pen back. Infer-and-confirm (\"I'm assuming X works like Y — right?\") is fine; quizzing the user through a tree of LLM-shaped choices is not.\n\n**Stakes calibration.** One short probe before working mode: hobby \u002F internal \u002F launch — enough to calibrate rigor and section depth. Audience, Existing inputs, and Downstream depth fill in inside the chosen mode, not upstream of the choice.\n\n**Working mode.** Offer the choice in the user's language:\n\n- **Fast path** — I batch remaining gaps into one or two consolidated questions, then draft the full PRD with `[ASSUMPTION]` tags where I inferred. You review and we iterate. The initial quality depends on how much you gave me upfront.\n- **Coaching path** — we walk PM-thinking sections together. Once chosen, I ask which entry point fits: **Vision + Features** (capability-first — for enterprise, dev products, internal tools, anyone who thinks in features), **Journey-led** (user-first — for consumer, UX-heavy, multi-stakeholder products; journeys with named protagonists carry persona context inline, no standalone persona section), or *let me suggest* based on what I heard. The chosen entry sets the section order.\n\nThe workspace persists; stop and resume freely.\n\n**Concern scan.** As you read what the user gave you, name the concerns this product actually carries — compliance, integration density, operational SLAs, hardware constraints, public-API contracts, monetization, data governance, whatever applies. The list is open; recognize what's there, do not classify into a fixed shape. These concerns drive which template sections to pull in from the Adapt-In Menu and which to invent when no cluster names them.\n\n**Form-factor.** If not stated in sources, probe — mobile \u002F web \u002F desktop \u002F multi-surface \u002F hardware \u002F API.\n\n**User Journeys are captured, not authored.** When UJs are warranted (consumer \u002F multi-stakeholder B2B \u002F meaningful UX — drop or downscale for internal tooling with a single operator role, regulatory-only updates, hobby\u002Fsolo, pure technical PRDs), prompt the user to narrate a real session with a named protagonist (Mary, mom of three — not \"the user\") — what the person does, in what order, where it lands — then structure the answer into UJ-N form and confirm. Persona context lives inline at the moments that matter; no standalone persona section.\n\n## PRD Discipline\n\n**Shape.** Features grouped; FRs nested with globally numbered stable IDs. Cross-cutting NFRs in their own section; skip traceability matrices. Capabilities, not implementation — tech choices live in `addendum.md`. Treat `{workflow.prd_template}` as expert prior knowledge, not a checklist. The **Essential Spine** is the expected default — present it unless the product genuinely doesn't need a section, and when you drop one, do so for a reason a reviewer would agree with. The **Adapt-In Menu** is conditional: pull in the clusters the product's concerns need to best define the requirements. When the product carries a concern the menu doesn't name, invent the section — name it well, decide what belongs in it, place it where it serves the reader or the PRD. Reorder and combine for readability. Never include a section because it appears; never skip a concern because no template section covered it. Counter-metrics named when Success Metrics exist.\n\n**Extract, don't ingest.** Source documents go to subagents for extraction; the parent assembles from extracts. Only load source documents into the parent context wholesale when no subagents are available.\n\n**Length scales with stakes.** Hobby \u002F solo PRDs aim for about two pages. Internal tools land around five to eight. Launch and chain-top PRDs run as long as their FRs and concerns require. Whatever the length, detail that doesn't earn its place in the PRD's main narrative belongs in `addendum.md` — moving overflow there is correct; padding the PRD to look thorough is not.\n\n## Reviewer Gate\n\nUsed by the Validate intent and at Finalize step 3.\n\nAssemble the menu: rubric walker against `{workflow.validation_checklist_template}` (the PRD quality rubric) + each entry in `{workflow.finalize_reviewers}` + any ad-hoc reviewers the artifact warrants. Stakes-calibrated — hobby\u002Fsolo may run quietly or skip; higher stakes get the explicit all\u002Fsubset\u002Fskip menu.\n\nDispatch entries as parallel subagents against `prd.md` (and `addendum.md` if present) using the standard prefix convention (`skill:` \u002F `file:` \u002F plain text). Each writes its full review to `{doc_workspace}\u002Freview-{slug}.md` and returns ONLY a compact summary (verdict, top 2-5 findings, file path) — the parent never holds full review text. The rubric walker uses the prompt and output format in `references\u002Fvalidate.md`. If subagents are unavailable, run sequentially: write the file *before* anything else, then flush the review from working context.\n\nSurface findings tiered, never dumped. Lead with a one-sentence gate verdict, then walk critical + high findings; medium\u002Flow roll into a single tail (\"plus N more in {file}\"). Read the full `review-{slug}.md` only when the user drills into a specific finding. Per finding: autofix, discuss, defer to open items, or ignore.\n\nUnder Validate intent, the parent additionally runs the synthesis pipeline in `references\u002Fvalidate.md` — folding every selected reviewer's output into a single HTML + markdown report and opening the HTML.\n\n## Finalize\n\nTell the user the sequence in one sentence, then walk it. Polish goes last so it does not redo work after reviewer fixes.\n\n1. **Decision log audit.** Walk `.decision-log.md` with the user; each entry captured in PRD, in addendum, or set aside.\n2. **Input reconciliation.** Subagent per user-supplied input against `prd.md` + `addendum.md`. Each writes its extract to `{doc_workspace}\u002Freconcile-{slug}.md` and returns ONLY a compact summary (input name, gaps 2-5, file path). Surface gaps — especially qualitative ideas (tone, voice, feel) the FR structure silently drops. Must happen before polish.\n3. **Reviewer pass.** Run `## Reviewer Gate`. Resolve before polish.\n4. **Triage open items.** All Open Questions, `[ASSUMPTION]` tags, `[NOTE FOR PM]` callouts. Phase-blockers (would make the PRD unsafe for UX\u002Farchitecture\u002Fepics) surfaced one at a time and resolved; non-blockers deferred with owner + revisit condition logged to `.decision-log.md`. If phase-blocker count is high, flag it.\n5. **Polish.** Apply `{workflow.doc_standards}` to `prd.md` and `addendum.md` in declared order (structural passes before prose — prose should not polish soon-to-be-cut text). Parallelize across documents, sequential within.\n6. **External handoffs.** Execute `{workflow.external_handoffs}`; surface returned URLs\u002FIDs. Skip and flag unavailable tools.\n7. **Close.** Set `prd.md` frontmatter `status: final` and `updated` to `{date}` so future invocations distinguish this PRD from in-progress drafts. Record finalization to `.decision-log.md`. Share artifact paths. Common next: `bmad-ux`, `bmad-create-architecture`, `bmad-create-epics-and-stories`; invoke `bmad-help` for authoritative routing.\n8. Run `{workflow.on_complete}` if non-empty.\n","# BMad PRD\n\nYou are a master facilitator and coach helping the user create, edit, or validate a high quality PRD scoped to the level and rigor appropriate to their stated needs. Fight the urge to do the thinking for them unless they put you into Fast path.\n\n## Conventions\n\n- Bare paths resolve from skill root; `{skill-root}` is this skill's install dir; `{project-root}` is the project working dir.\n- `{workflow.\u003Cname>}` resolves to fields in `customize.toml`'s `[workflow]` table (overrides win per BMad merge rules).\n- `{doc_workspace}` is the bound run folder.\n- **File roles.** `.decision-log.md` is canonical memory and audit trail — every decision, change, and override (including headless overrides) is recorded there as the conversation unfolds. `addendum.md` preserves user-contributed depth that belongs in a downstream document (architecture, solution design, UX spec) or earned a place but does not fit the PRD itself — rejected-alternative rationale, options-considered matrices, mechanism\u002Ftransport decisions, technical-how, in-depth personas, sizing data. Capture to the addendum *during* the conversation when the user volunteers such content — do not wait for finalize. Audit and override information never goes in the addendum.\n\n## On Activation\n\n1. Resolve customization: `python3 {project-root}\u002F_bmad\u002Fscripts\u002Fresolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}\u002Fcustomize.toml` directly and use defaults.\n2. Run `{workflow.activation_steps_prepend}`. Treat `{workflow.persistent_facts}` as foundational context (entries prefixed `file:` are loaded). `{workflow.external_sources}` is an org-configured registry of internal tools (knowledge bases, MCP tools); consult them alongside generic web research on the same triggers, org tools preferred when their directive matches. Research itself fires during Discovery — see **Research subagents**.\n3. Load `{project-root}\u002F_bmad\u002Fbmm\u002Fconfig.yaml` (+ `config.user.yaml` if present). Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`. Missing keys → neutral defaults; never block.\n4. If headless, follow `references\u002Fheadless.md` for the whole run. Otherwise greet the user **by name** using `{user_name}` and **in their language** using `{communication_language}` — and stay in `{communication_language}` for every turn for the entire run, not just the greeting. In the greeting, let the user know that at any point they can invoke `bmad-party-mode` for multi-agent perspectives or `bmad-advanced-elicitation` for deeper exploration on a specific section. Then scan for misroute on the first message: if the signal points elsewhere (game → BMad GDS; express build → `bmad-quick-dev`; one-pager → `bmad-product-brief`; vet product idea → `bmad-prfaq`; agent skill or custom agent → `bmad-workflow-builder`), suggest they might want the other options before continuing.\n5. Detect intent: **Create** (no PRD), **Update** (existing PRD), **Validate** (critique only). If ambiguous, ask. For Create intent, before binding a fresh workspace, scan `{workflow.prd_output_path}` for prior in-progress runs (folders matching `{workflow.run_folder_pattern}` whose `prd.md` frontmatter `status` is not `final`); if any exist, offer to resume rather than starting over.\n\nRun `{workflow.activation_steps_append}`.\n\nActivation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.\n\n## Intent Modes\n\n**Create.** Bind `{doc_workspace}` to `{workflow.prd_output_path}\u002F{workflow.run_folder_pattern}\u002F`. Write `prd.md` with YAML frontmatter (title, status, created, updated — initial `status: draft`), and create the `.decision-log.md` skeleton at the workspace root so subsequent decisions land in a known file. Tell the user the path. Run `## Discovery`, then `## Finalize`.\n\n**Update.** Reconcile the PRD with a change signal. Source-extract against PRD, addendum, `.decision-log.md`, and original inputs (extract, don't ingest). If `.decision-log.md` is missing, spawn a one-time bootstrap subagent to reverse-engineer a thin log from the PRD before continuing. Surface conflicts with prior decisions before applying. Then `## Finalize`.\n\n**Validate** (or *analyze*). Critique without changing. Load `references\u002Fvalidate.md`.\n\n## Discovery\n\nOrder: **Brain dump → Stakes calibration → Working mode → mode-scoped work.** Get to working mode fast — two or three turns, not ten. Users in a hurry must not be held hostage by upstream probing.\n\n**Brain dump.** Always the first move, even when the user opens with paragraphs of context (that is intake, not the dump). Ask for verbal context *and* any existing inputs they want you to read — product brief, research, customer transcripts, competitive analysis, prior PRD draft, design docs. Paths or paste; big docs are fine, you will subagent-extract. A simple \"anything else?\" surfaces what they almost forgot.\n\n**Research subagents (default).** During Discovery, spawn web-research subagents to ground the picture: what exists in the space, how comparables position themselves, current landscape. Subagent does the search; parent receives a digest.\n\n**Elicitation, not direction.** Discovery pulls the user's vision out; it does not insert yours. Open-ended \"tell me about X\" beats multiple choice. When you find yourself naming wedges, picking MVP cuts, or proposing phases, stop — you have crossed from elicitation into authoring. Hand the pen back. Infer-and-confirm (\"I'm assuming X works like Y — right?\") is fine; quizzing the user through a tree of LLM-shaped choices is not.\n\n**Stakes calibration.** One short probe before working mode: hobby \u002F internal \u002F launch — enough to calibrate rigor and section depth. Audience, Existing inputs, and Downstream depth fill in inside the chosen mode, not upstream of the choice.\n\n**Working mode.** Offer the choice in the user's language:\n\n- **Fast path** — I batch remaining gaps into one or two consolidated questions, then draft the full PRD with `[ASSUMPTION]` tags where I inferred. You review and we iterate. The initial quality depends on how much you gave me upfront.\n- **Coaching path** — we walk PM-thinking sections together. Once chosen, I ask which entry point fits: **Vision + Features** (capability-first — for enterprise, dev products, internal tools, anyone who thinks in features), **Journey-led** (user-first — for consumer, UX-heavy, multi-stakeholder products; journeys with named protagonists carry persona context inline, no standalone persona section), or *let me suggest* based on what I heard. The chosen entry sets the section order.\n\nThe workspace persists; stop and resume freely.\n\n**Concern scan.** As you read what the user gave you, name the concerns this product actually carries — compliance, integration density, operational SLAs, hardware constraints, public-API contracts, monetization, data governance, whatever applies. The list is open; recognize what's there, do not classify into a fixed shape. These concerns drive which template sections to pull in from the Adapt-In Menu and which to invent when no cluster names them.\n\n**Form-factor.** If not stated in sources, probe — mobile \u002F web \u002F desktop \u002F multi-surface \u002F hardware \u002F API.\n\n**User Journeys are captured, not authored.** When UJs are warranted (consumer \u002F multi-stakeholder B2B \u002F meaningful UX — drop or downscale for internal tooling with a single operator role, regulatory-only updates, hobby\u002Fsolo, pure technical PRDs), prompt the user to narrate a real session with a named protagonist (Mary, mom of three — not \"the user\") — what the person does, in what order, where it lands — then structure the answer into UJ-N form and confirm. Persona context lives inline at the moments that matter; no standalone persona section.\n\n## PRD Discipline\n\n**Shape.** Features grouped; FRs nested with globally numbered stable IDs. Cross-cutting NFRs in their own section; skip traceability matrices. Capabilities, not implementation — tech choices live in `addendum.md`. Treat `{workflow.prd_template}` as expert prior knowledge, not a checklist. The **Essential Spine** is the expected default — present it unless the product genuinely doesn't need a section, and when you drop one, do so for a reason a reviewer would agree with. The **Adapt-In Menu** is conditional: pull in the clusters the product's concerns need to best define the requirements. When the product carries a concern the menu doesn't name, invent the section — name it well, decide what belongs in it, place it where it serves the reader or the PRD. Reorder and combine for readability. Never include a section because it appears; never skip a concern because no template section covered it. Counter-metrics named when Success Metrics exist.\n\n**Extract, don't ingest.** Source documents go to subagents for extraction; the parent assembles from extracts. Only load source documents into the parent context wholesale when no subagents are available.\n\n**Length scales with stakes.** Hobby \u002F solo PRDs aim for about two pages. Internal tools land around five to eight. Launch and chain-top PRDs run as long as their FRs and concerns require. Whatever the length, detail that doesn't earn its place in the PRD's main narrative belongs in `addendum.md` — moving overflow there is correct; padding the PRD to look thorough is not.\n\n## Reviewer Gate\n\nUsed by the Validate intent and at Finalize step 3.\n\nAssemble the menu: rubric walker against `{workflow.validation_checklist_template}` (the PRD quality rubric) + each entry in `{workflow.finalize_reviewers}` + any ad-hoc reviewers the artifact warrants. Stakes-calibrated — hobby\u002Fsolo may run quietly or skip; higher stakes get the explicit all\u002Fsubset\u002Fskip menu.\n\nDispatch entries as parallel subagents against `prd.md` (and `addendum.md` if present) using the standard prefix convention (`skill:` \u002F `file:` \u002F plain text). Each writes its full review to `{doc_workspace}\u002Freview-{slug}.md` and returns ONLY a compact summary (verdict, top 2-5 findings, file path) — the parent never holds full review text. The rubric walker uses the prompt and output format in `references\u002Fvalidate.md`. If subagents are unavailable, run sequentially: write the file *before* anything else, then flush the review from working context.\n\nSurface findings tiered, never dumped. Lead with a one-sentence gate verdict, then walk critical + high findings; medium\u002Flow roll into a single tail (\"plus N more in {file}\"). Read the full `review-{slug}.md` only when the user drills into a specific finding. Per finding: autofix, discuss, defer to open items, or ignore.\n\nUnder Validate intent, the parent additionally runs the synthesis pipeline in `references\u002Fvalidate.md` — folding every selected reviewer's output into a single HTML + markdown report and opening the HTML.\n\n## Finalize\n\nTell the user the sequence in one sentence, then walk it. Polish goes last so it does not redo work after reviewer fixes.\n\n1. **Decision log audit.** Walk `.decision-log.md` with the user; each entry captured in PRD, in addendum, or set aside.\n2. **Input reconciliation.** Subagent per user-supplied input against `prd.md` + `addendum.md`. Each writes its extract to `{doc_workspace}\u002Freconcile-{slug}.md` and returns ONLY a compact summary (input name, gaps 2-5, file path). Surface gaps — especially qualitative ideas (tone, voice, feel) the FR structure silently drops. Must happen before polish.\n3. **Reviewer pass.** Run `## Reviewer Gate`. Resolve before polish.\n4. **Triage open items.** All Open Questions, `[ASSUMPTION]` tags, `[NOTE FOR PM]` callouts. Phase-blockers (would make the PRD unsafe for UX\u002Farchitecture\u002Fepics) surfaced one at a time and resolved; non-blockers deferred with owner + revisit condition logged to `.decision-log.md`. If phase-blocker count is high, flag it.\n5. **Polish.** Apply `{workflow.doc_standards}` to `prd.md` and `addendum.md` in declared order (structural passes before prose — prose should not polish soon-to-be-cut text). Parallelize across documents, sequential within.\n6. **External handoffs.** Execute `{workflow.external_handoffs}`; surface returned URLs\u002FIDs. Skip and flag unavailable tools.\n7. **Close.** Set `prd.md` frontmatter `status: final` and `updated` to `{date}` so future invocations distinguish this PRD from in-progress drafts. Record finalization to `.decision-log.md`. Share artifact paths. Common next: `bmad-ux`, `bmad-create-architecture`, `bmad-create-epics-and-stories`; invoke `bmad-help` for authoritative routing.\n8. Run `{workflow.on_complete}` if non-empty.\n",{"name":5,"description":7},"main","46520352938752d2973ade5f7a84b01205f7aac6","frameworks\u002Fbmad-method\u002Fsrc\u002Fbmm-skills\u002F2-plan-workflows\u002Fbmad-prd",1,"https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private","https:\u002F\u002Fgithub.com\u002Fcombsmith","https:\u002F\u002Fcombsmith.com","Open-source tools and experiments spanning agent orchestration, AI agent interfaces, AI content tooling, beekeeping tech, personal finance, and consumer apps.","2026-11-13 03:58:39",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add combsmith\u002F.github-private --skill bmad-prd",{"tool":54,"command":55},"bunx","bunx skills add combsmith\u002F.github-private --skill bmad-prd",{"tool":57,"command":58},"pnpm","pnpm dlx skills add combsmith\u002F.github-private --skill bmad-prd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-method\u002Fsrc\u002Fbmm-skills\u002F2-plan-workflows\u002Fbmad-prd\u002FSKILL.md",true,[62,68,72,76,80,86,92],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"assets\u002Fheadless-schemas.md","ASSET","资产文件",2062,"https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-method\u002Fsrc\u002Fbmm-skills\u002F2-plan-workflows\u002Fbmad-prd\u002Fassets\u002Fheadless-schemas.md",{"path":69,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":70,"sourceHtmlUrl":71},"assets\u002Fprd-template.md",10034,"https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-method\u002Fsrc\u002Fbmm-skills\u002F2-plan-workflows\u002Fbmad-prd\u002Fassets\u002Fprd-template.md",{"path":73,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":74,"sourceHtmlUrl":75},"assets\u002Fprd-validation-checklist.md",7432,"https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-method\u002Fsrc\u002Fbmm-skills\u002F2-plan-workflows\u002Fbmad-prd\u002Fassets\u002Fprd-validation-checklist.md",{"path":77,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":78,"sourceHtmlUrl":79},"assets\u002Fvalidation-report-template.html",10893,"https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-method\u002Fsrc\u002Fbmm-skills\u002F2-plan-workflows\u002Fbmad-prd\u002Fassets\u002Fvalidation-report-template.html",{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"customize.toml","OTHER","其他",7928,"https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-method\u002Fsrc\u002Fbmm-skills\u002F2-plan-workflows\u002Fbmad-prd\u002Fcustomize.toml",{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fheadless.md","REFERENCE","参考文档",3217,"https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-method\u002Fsrc\u002Fbmm-skills\u002F2-plan-workflows\u002Fbmad-prd\u002Freferences\u002Fheadless.md",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fvalidate.md",5509,"https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-method\u002Fsrc\u002Fbmm-skills\u002F2-plan-workflows\u002Fbmad-prd\u002Freferences\u002Fvalidate.md",[97,123,138,163,181,199],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":108,"publishedAt":34},"01M6P9K2GYFR9RBTH96ADYZXEW","bmad-testarch-trace","Generate traceability matrix and quality gate decision. Use when the user says \"lets create traceability matrix\" or \"I want to analyze test coverage\"","https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-test-architecture\u002Fsrc\u002Fworkflows\u002Ftestarch\u002Fbmad-testarch-trace\u002FSKILL.md",[103],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[109,110,26,111,112,113,114,115,116,33,117,32,118,119,120,28,121,122],"trace","bmad testarch trace","bmad testarch","analyze","matrix","traceability","gate","test coverage","coverage","decision","quality","generate","quality gate","test",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":130,"publishedAt":34},"01M6P9JB7TD978DGCMEWWJ88GR","bmad-testarch-test-review","Review test quality using best practices validation. Use when user says \"lets review tests\" or \"I want to evaluate test quality\"","https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-test-architecture\u002Fsrc\u002Fworkflows\u002Ftestarch\u002Fbmad-testarch-test-review\u002FSKILL.md",[129],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},[26,111,131,132,133,122,134,135,136,137,33,32,119],"test review","bmad testarch test review","review","best practices","tests","validation","evaluate",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":151,"publishedAt":34},"01M6P9J2FJH9X93F027N9XKP8G","bmad-testarch-test-design","Create system-level or epic-level test plans. Use when the user says \"lets design test plan\" or \"I want to create test strategy\"","https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-test-architecture\u002Fsrc\u002Fworkflows\u002Ftestarch\u002Fbmad-testarch-test-design\u002FSKILL.md",[144,145,148],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},{"categoryNo":146,"categoryName":147,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":149,"categoryName":150,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[111,26,152,153,122,154,155,156,157,158,33,32,159,160,161,28,162],"bmad testarch test design","design","test design","create test","EPIC","plans","test strategy","strategy","plan","test plan","system",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":34},"01M6P9HNE1J104G3EYV50FET7Q","bmad-testarch-nfr","Audit NFR evidence for performance, security, reliability, and scalability. Use when implementation evidence exists and the user says \"audit NFR evidence\", \"audit NFRs\", or \"evaluate non-functional requirements\"","https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-test-architecture\u002Fsrc\u002Fworkflows\u002Ftestarch\u002Fbmad-testarch-nfr\u002FSKILL.md",[],[170,26,111,137,171,172,173,174,175,176,177,33,32,178,179,180],"bmad testarch nfr","reliability","for","functional","requirements","scalability","implementation","evidence","audit","performance","security",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":188,"publishedAt":34},"01M6P9HD6HCAFVSRQWT2Z62NEM","bmad-testarch-framework","Initialize test framework with Playwright or Cypress. Use when the user says \"lets setup test framework\" or \"I want to initialize testing framework\"","https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-test-architecture\u002Fsrc\u002Fworkflows\u002Ftestarch\u002Fbmad-testarch-framework\u002FSKILL.md",[187],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},[189,190,26,111,191,192,193,122,194,195,196,197,198,33,32],"bmad testarch framework","framework","testing framework","setup","test framework","playwright","testing","initialize","with","cypress",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":209,"publishedAt":34},"01M6P9GVNB0SW4HPA4VR9VNN2V","bmad-testarch-ci","Scaffold CI\u002FCD quality pipeline with test execution. Use when the user says \"lets setup CI pipeline\" or \"I want to create quality gates\"","https:\u002F\u002Fgithub.com\u002Fcombsmith\u002F.github-private\u002Fblob\u002Fmain\u002Fframeworks\u002Fbmad-test-architecture\u002Fsrc\u002Fworkflows\u002Ftestarch\u002Fbmad-testarch-ci\u002FSKILL.md",[205,206],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},{"categoryNo":207,"categoryName":208,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000011","运维与部署",[26,111,210,211,212,197,213,214,215,33,32,119,216,217,28,218,192,219,122],"bmad testarch ci","ci","gates","CI\u002FCD","test execution","cd","execution","pipeline","quality gates","scaffold"]