feat(bmad-prd): reviewer pass redesign and consolidate facilitation

- finalize_reviewers TOML field replaces inline review lenses; entries
  follow the skill:/file:/plain-text prefix convention, resolved on-demand
  so reviewer data has zero context cost on runs that skip the pass.
- Subagent contract: reviewers write to {doc_workspace}/review-{slug}.md
  and return summary-only (verdict, top findings, file path); parent
  never holds full review text.
- Section-by-section walk-through UX at Finalize and Validate; user
  decides per finding whether to autofix, discuss, defer, or ignore.
- Finalize entry names the sequence in one sentence so users understand
  the polish-last order.
- Template philosophy moved from prd-template.md to SKILL.md PRD
  Discipline; template is now pure shape menu (preamble and Notes for
  facilitator stripped).
- facilitation-guide.md content folded into SKILL.md Discovery posture
  (story-shape UJ walk, four MVP types, state-inference-don't-quiz);
  guide file deleted.

src/bmm-skills/2-plan-workflows/bmad-prd/SKILL.md

@@ -34,11 +34,11 @@ How every turn runs, regardless of intent.
 
 ## Intent Operating Modes
 
-**Create.** A PRD the user is proud of, drawn out through real conversation. Discovery first, drafting second. Bind `{doc_workspace}` to a fresh folder at `{workflow.output_dir}/{workflow.output_folder_name}/` and write `prd.md` there with YAML frontmatter (title, created, updated); tell the user the workspace path. Version and state transitions live in `decision-log.md`. For Update and Validate, `{doc_workspace}` is the existing folder of the PRD being targeted. When drafting is complete, proceed to `## Finalize`.
+**Create.** A PRD the user is proud of, drawn out through real conversation. Discovery first, drafting second. Bind `{doc_workspace}` to a fresh folder at `{workflow.output_dir}/{workflow.output_folder_name}/` and write `prd.md` there with YAML frontmatter (title, created, updated); tell the user the workspace path. Version and state transitions live in `decision-log.md`. When drafting is complete, proceed to `## Finalize`.
 
-**Update.** Reconcile an existing PRD with a change signal. Orient via source extractors (see `## Constraints` → Extract, don't ingest) against the PRD, addendum, `decision-log.md`, and original inputs, then run the `## Discovery` posture against the change signal. Surface conflicts with prior decisions before changing: read `decision-log.md`, identify decisions touching the same area as the change, and for each, check whether the change reverses it, contradicts a stated assumption, or removes a non-goal; if so, raise it to the user before applying. If the change is fundamental (revises Vision or Target User), offer Create instead of patching. When changes are applied, proceed to `## Finalize`.
+**Update.** Reconcile an existing PRD with a change signal. Orient via source extractors (see `## Constraints` → Extract, don't ingest) against the PRD, addendum, `decision-log.md`, and original inputs, then run the `## Discovery` posture against the change signal. Surface conflicts with prior decisions before changing: read `decision-log.md`, identify decisions touching the same area as the change, and for each, check whether the change reverses it, contradicts a stated assumption, or removes a non-goal; if so, raise it to the user before applying. Once changes are applied, proceed to `## Finalize`.
 
-**Validate** (or *analyze*). Critique an existing PRD against `{workflow.validation_checklist}`. Standalone; does NOT enter `## Finalize`. Orient via source extractors against `decision-log.md` and any original inputs to give the validator context. Spawn the validator subagent against `prd.md` (and `addendum.md` if present); produce findings and a validation report per `references/validation-render.md`. Always offer to roll findings into an Update.
+**Validate** (or *analyze*). Critique an existing PRD. Standalone; does NOT enter `## Finalize`. Orient via source extractors against `decision-log.md` and any original inputs. Assemble the reviewer gate menu: structural checklist validator (against `{workflow.validation_checklist}`) + each entry in `{finalize_reviewers}` (resolved on-demand from `customize.toml`) + any ad-hoc reviewers warranted by the PRD content (composed as plain-text entries on the fly). Present the menu; user picks all, a subset, or skip. Spawn the selection as parallel subagents against `prd.md` (and `addendum.md` if present), dispatching by prefix: `skill:NAME` invokes the named skill; `file:PATH` spawns an adversarial subagent applying the loaded file as the review prompt; plain-text entries are used directly as the subagent's prompt. **Subagent contract:** each reviewer writes its full review to `{doc_workspace}/review-{slug}.md` and returns ONLY a compact summary (verdict, top 2-3 findings as one-liners, file path); the parent never holds full review text in context. The structural validator additionally produces a validation report per `references/validation-render.md`. List all artifact paths and summaries to the user; offer a section-by-section walk through findings if they want it. Always offer to roll findings into an Update.
 
 ## Discovery
 
@@ -48,6 +48,8 @@ Coach, do not quiz. Push hardest on PRD Discipline risks: unexamined assumptions
 
 Push for two to three named-persona user journeys even when the user does not propose them. UJs are how teams discover persona gaps, scope ambiguity, and missed failure handling. Solo/hobby scope can drop to one or none.
 
+Facilitation moves to keep handy. For User Journeys, walk the story shape: opening scene, rising action, climax (the moment value is delivered), resolution; real edge cases surface at the climax, not as invented error states. For MVP scope, ask which kind of MVP this is before listing in/out: problem-solving (proves the problem is solved), experience (proves the interaction model), platform (proves the base others build on), or revenue (proves willingness to pay); each implies different scope logic. For feature decisions, state the inference and invite correction rather than quizzing the user ("I'm assuming X works like Y, is that right?" beats "should X work like Y or Z?").
+
 Load `references/probing.md` for the seven probing categories, critical-assumption scans, and the PRD / solution-design boundary; apply in Discovery and Update.
 
 ### Brain dump
@@ -78,7 +80,7 @@ Surface these honestly and let the user choose; if they prefer this skill anyway
 Once the situational read is complete, offer the user a choice before proceeding (one sentence per option):
 
 - **Express:** resolve any remaining critical gaps in a short batch, then draft the full PRD at once.
-- **Facilitative:** work through the sections that require PM thinking before drafting, using the techniques in `references/facilitation-guide.md`. Capture all decisions in the log, section to section. Draft after the key sections are walked. The goal is that the user has authored the thinking, not just answered intake questions.
+- **Facilitative:** work through the sections that require PM thinking before drafting. Capture all decisions in the log, section to section. Draft after the key sections are walked. The goal is that the user has authored the thinking, not just answered intake questions.
 
 In both modes, resolve decisions conversationally rather than silently deferring them into `[ASSUMPTION]` tags. Only use `[ASSUMPTION]` when the answer requires research or external input the PM cannot provide in the moment.
 
@@ -88,7 +90,7 @@ In both modes, resolve decisions conversationally rather than silently deferring
 
 - **Features grouped, FRs nested.** Features open with behavioral description; FRs nested and numbered globally for stable IDs. Cross-cutting NFRs in their own section; skip traceability matrices.
 - **Capabilities, not implementation.** FRs describe what users or systems can do, not how. Tech choices go in addendum.
-- **Right-size to purpose.** Section depth and adapt-in clusters follow project type and stakes; the template's adapt-in menu names the standard clusters.
+- **Right-size to purpose.** Load `{workflow.prd_template}` as the shape menu. Treat it as a menu, not a skeleton: drop, reorder, combine, or rename sections as the PRD needs; never include a section just because it appears. The essential spine is the floor, not the ceiling — hobby keeps it short, enterprise layers in clusters from the template's adapt-in menu.
 - **Counter-metrics named.** When Success Metrics is present, name what NOT to optimize.
 
 ### Substance
@@ -113,9 +115,11 @@ In both modes, resolve decisions conversationally rather than silently deferring
 
 ## Finalize
 
+At entry, name the sequence for the user in one sentence: walk the decision log, reconcile inputs, run the reviewer pass, resolve open items, then polish over the final content. Polish goes last so it does not have to redo work after reviewer fixes.
+
 1. Decision log audit: walk `decision-log.md` with the user; each entry captured in PRD, in addendum, or set aside.
 2. Input reconciliation: subagent per user-supplied input against `prd.md` + `addendum.md`; surface gaps, especially qualitative ideas (tone, voice, feel) the FR structure silently drops. Must happen before polish.
-3. Discipline pass: validator subagent against `prd.md` with `{workflow.validation_checklist}`. Findings stay in-conversation; autofix obvious issues, ask on ambiguous ones. No report file is written. Resolve before polish.
+3. Reviewer pass. Assemble the gate menu: structural checklist validator (against `{workflow.validation_checklist}`) + each entry in `{finalize_reviewers}` (resolved on-demand from `customize.toml`) + any ad-hoc reviewers warranted by the PRD content (composed as plain-text entries on the fly). Gate UX is stakes-calibrated: hobby/solo scope may run defaults quietly or skip; higher stakes get the explicit menu with all, subset, or skip. Spawn the selection as parallel subagents against `prd.md`, dispatching by prefix: `skill:NAME` invokes the named skill; `file:PATH` spawns an adversarial subagent applying the loaded file as the review prompt; plain-text entries are used directly. **Subagent contract:** each reviewer writes its full review to `{doc_workspace}/review-{slug}.md` and returns ONLY a compact summary to the parent (verdict, top 2-3 findings as one-liners, file path). The parent never holds full review text in context. **Walk-through:** the parent groups findings by PRD section using each finding's location field (or by reviewer when section mapping is unclear); walks the user section by section, offering to open the full review document for any reviewer. Per finding, user picks autofix, discuss, defer to open items, or ignore. Hobby/solo scope can skip the walk and just print summaries. Resolve before polish.
 4. Open-items review: triage all Open Questions, `[ASSUMPTION]` tags, and `[NOTE FOR PM]` callouts. A phase-blocker is an open item that would make the PRD unsafe for the next phase of work (UX, architecture, epics); a non-blocker is deferrable to a later cycle with an owner and revisit condition. Surface only phase-blockers one at a time; resolve before calling the PRD ready. Log deferred items to `decision-log.md`. If phase-blocker count is high, flag it.
 5. Polish: apply `{workflow.doc_standards}` to `prd.md` and `addendum.md` via parallel subagents.
 6. External handoffs: execute `{workflow.external_handoffs}` entries; surface returned URLs/IDs. Skip and flag unavailable tools.

src/bmm-skills/2-plan-workflows/bmad-prd/assets/prd-template.md

@@ -1,8 +1,4 @@
-# PRD Template — A Menu, Not a Skeleton
-
-This is a menu of sections the facilitator picks from based on what the product, the stakes, the audience, and the existing inputs actually need. Hobby projects use the essential spine and stop. Enterprise initiatives, regulated submissions, and consumer launches add clusters from the adapt-in menu below. **Never include a section just because it appears here.** Drop, reorder, rename, combine — whatever the PRD needs.
-
----
+# PRD Template
 
 ## Essential Spine *(almost always present)*
 
@@ -169,17 +165,3 @@ updated: {YYYY-MM-DD}
 ### Small-scope all-inclusive *(use when scope is 1-2 stories' worth and the user wants a single captured artifact — chosen during the Right-skill check in Discovery)*
 - **Stories** — story-level specs listed inline at the end of the doc. Each story: *"As a [persona], I can [action] [under conditions]. Acceptance: [testable criteria]."* Numbered Story-1, Story-2, ... for reference. Pair with very lean §1 Vision, §2 Target User (often just JTBD + one UJ), §3 Glossary (handful of terms), §4 Features (often a single feature), §6 MVP Scope (in/out very tight). The whole doc fits on a page or two and captures intent + implementable stories in one place. If the user doesn't want the captured artifact at all, `bmad-quick-dev` is the better path — this cluster is only for "I want a doc *and* the stories."
 
----
-
-## Notes for the facilitator
-
-- **The essential spine is the floor, not the ceiling.** A hobby PRD might keep all ten sections short. An enterprise PRD layers many clusters from the adapt-in menu.
-- **§3 Glossary before §4 Features.** Mechanics never introduce a new domain noun without adding it to the Glossary in the same pass. Persona, JTBD, and Journeys may use Glossary terms before §3 formally defines them — context is inferable; the Glossary is for downstream anchoring.
-- **§2.4 Key User Journeys carry signal.** Default shape is named-persona mini-flow (persona, 3-5 steps, edge cases, optional capability surfacing). PMs can go deeper, including full UX-level detail, if they choose. Hobby/solo scope can collapse to one-liners. UJs are how teams discover persona gaps, scope ambiguity, and missed failure handling — push for two to three in any non-trivial scope.
-- **§4 Features pattern at every scale.** Description → FRs nested (each as `#### FR-N: Name` with testable consequences and optional per-FR Out of Scope) → optional feature-specific NFRs → optional notes. Hobby PRD: one short paragraph and three FRs per feature. Enterprise feature: multi-paragraph description, fifteen FRs, several feature-specific NFRs, open questions. Same shape, different depth.
-- **`[ASSUMPTION]`, `[NON-GOAL]`, `[v2 — out of MVP]`, `[NOTE FOR PM]` callouts are first-class.** They signal to downstream readers and the next session of work. Every `[ASSUMPTION]` lands in §9 Assumptions Index.
-- **When UX is *input* to the PRD** (journeys already designed elsewhere): §2.4 mirrors the UX UJ IDs and points to the source doc. The PRD references, does not duplicate. Personas in §2.1 also mirror what the UX doc defined.
-- **When UX is *output* of the PRD** (no UX work yet, may go to `bmad-create-ux-design` later): §2.4 carries the PM's understanding of the journeys with enough flow detail to be extractable downstream. UX elaboration adds screens, IA, and micro-interactions on top.
-- **§7 Success Metrics scales with stakes** but is always present. Counter-metrics matter as much as primary metrics — they shape what NOT to optimize.
-- **Small-scope all-inclusive option.** When scope is genuinely 1-2 stories and the user wants a single artifact instead of running a separate `bmad-create-story` workflow, add the adapt-in *Stories* cluster: lean §1-§6 plus inline §Stories at the end. The whole doc fits on a page or two. This is a valid PRD shape for tiny work — don't apologize for it.
-- **Adapt the section numbering.** The spine uses 0-9; adapt-in additions slot in wherever they read best (e.g., Aesthetic & Tone before §3 if branding is foundational, Compliance after §5 Non-Goals, Constraints & Guardrails between Features and Non-Goals, Stories at the very end after Assumptions Index).

src/bmm-skills/2-plan-workflows/bmad-prd/customize.toml

@@ -111,3 +111,26 @@ external_sources = []
 #   "Mirror the PRD to Notion via notion:create_page (database_id='abc123', title='PRD: '+{project_name})."
 #   "When the PRD references a parent initiative, link via corp:jira_link on the epic key in frontmatter."
 external_handoffs = []
+
+# --- Finalize reviewers ---
+# Reviewers spawned at Finalize step 3 (and at the Validate intent) alongside
+# the structural checklist validator. The authoring skill assembles the gate
+# menu (validator + these reviewers + any ad-hoc reviewers it judges warranted
+# by the artifact content) and lets the user pick all, a subset, or skip. Gate
+# UX is stakes-calibrated: hobby/solo scope may run defaults quietly or skip;
+# higher stakes get the explicit menu.
+#
+# Entries follow the standard prefix convention (same as persistent_facts and
+# doc_standards):
+#   "skill:NAME"   invoke the named review skill as a subagent against prd.md
+#   "file:PATH"    load the file as a review prompt; spawn an adversarial
+#                  subagent applying that prompt to prd.md
+#   plain text     use the text directly as the subagent's review prompt
+#
+# Override TOML may append additional reviewers. Arrays append per BMad rules.
+#
+# Resolved on-demand by the authoring skill (not pulled at activation): only
+# when entering the Validate intent or assembling the gate at Finalize step 3.
+finalize_reviewers = [
+  "skill:bmad-review-adversarial-general",
+]

src/bmm-skills/2-plan-workflows/bmad-prd/references/facilitation-guide.md

@@ -1,81 +0,0 @@
-# PRD Facilitation Guide
-
-Per-section conversation techniques for facilitative mode. Each entry names the coaching move that makes the section's conversation productive — not a checklist, a posture. Skip sections the PM has already resolved; spend more time where thinking is thin.
-
-For symptom-based probes that apply across sections, load `references/probing.md` alongside this guide.
-
----
-
-## Users and Personas
-
-**The move:** Ground personas in real people, not archetypes.
-
-Ask the PM to describe a specific person they have observed or talked to — not a type, an actual human. "Who is the clerk at your store? Tell me about them." Invented detail (name, age, backstory from nowhere) is persona theater — the team builds for a fiction. If the PM says "someone like..." push gently: "Is there a real person you're thinking of?"
-
-Once grounded: what does that person want to accomplish in the time they interact with this product? What would make them say this is easier than what they do today? What would make them abandon it?
-
-For the remote user or secondary persona: same grounding, different question — what question do they need answered in under ten seconds, and what do they do if they can't get it?
-
-Mark anything the PM could not ground in observation as `[ILLUSTRATIVE]` — and note it's a hypothesis to validate, not a spec to build for.
-
----
-
-## Core User Journeys
-
-**The move:** Story structure, not use-case list.
-
-For each primary journey, walk through four beats:
-
-- **Opening scene** — where do we meet this person, what is their situation right now, what pain or need is present?
-- **Rising action** — what steps do they take, what do they discover or decide along the way?
-- **Climax** — the moment the product delivers real value; the thing they could not do before
-- **Resolution** — what is their new reality; how is their situation different?
-
-After each journey: what could go wrong at the climax? What is the recovery path? This is where edge cases that matter surface — not invented error states, but real failure modes for this person.
-
-Explicitly name what capability each journey reveals. "This journey requires the operator to log an entry with no internet — which means we need a decision on whether that's in or out of MVP." Journeys produce capability requirements; make the link visible.
-
----
-
-## Key Feature Decisions
-
-**The move:** Surface the assumptions that would otherwise be silent.
-
-Before the draft exists, there are decisions the agent would silently make and the PM would never know were made. These are the ones worth a thirty-second conversation:
-
-- Decisions that drive the core UX model (e.g., one record per day vs. many; who can edit vs. view; what happens when the expected input doesn't exist)
-- Decisions where the "obvious" choice has real consequences the PM may not have considered
-- Decisions that, if wrong, require structural changes to fix later
-
-For each: state what you inferred, name the alternative, ask which is right. Do not present options as a quiz — present your inference and invite correction. "I'm assuming one sales tally per day replaces rather than adds. Is that right, or should the operator be able to log multiple?" Resolve and move on. Only tag as `[ASSUMPTION]` when the answer requires external input or research the PM cannot provide now.
-
----
-
-## Scope Boundary
-
-**The move:** Establish MVP philosophy before listing features.
-
-Before asking what is in or out, ask what kind of MVP this is:
-
-- **Problem-solving MVP** — the minimum that proves the core problem is solved; rough edges acceptable
-- **Experience MVP** — the minimum that proves the interaction model works; quality matters
-- **Platform MVP** — the minimum infrastructure other things can build on; completeness of the base matters
-- **Revenue MVP** — the minimum someone will pay for; business viability is the test
-
-The answer changes what "minimum" means. A problem-solving MVP for a personal-use tool has different scope logic than an experience MVP aimed at non-tech-savvy users who will bounce at the first confusion.
-
-Once the philosophy is named, non-goals do as much work as in-scope items. Probe for the things the PM is tempted to add. "What keeps almost making it onto the list?" For each: is it truly out of MVP, or does it need to be in because the MVP fails without it?
-
----
-
-## Success Metrics
-
-**The move:** Push every adjective to a measurement.
-
-"Users will love it" — what does that mean in behavior? "It'll be fast" — fast at what, for whom, measured how? "Good adoption" — what percentage, by when, doing what? Every quality claim needs a measurement or it is not a success criterion, it is a wish.
-
-For each metric surfaced: connect it back to the product's differentiator. If the differentiator is simplicity for non-tech users, the primary metric should measure whether non-tech users successfully complete the core action without help — not session count or feature usage breadth.
-
-Name counter-metrics explicitly — what this product should *not* optimize for. These prevent the wrong thing being built: more entries per day is not better if the goal is accurate daily records; longer dashboard sessions may indicate a broken IA, not high engagement. Counter-metrics are as load-bearing as primary metrics for downstream readers.
-
-For low-stakes or personal-use products: one sentence is enough. "Success: I use this daily and it replaces the notebook within a month." Do not impose metric rigor where the stakes do not warrant it.