feat(bmad-prd): open-items gate, drop distillate, persona discipline, decision-log metadata

- Add Finalize "Open-items review" step (new step 4): counts OQs / [ASSUMPTION] / [NOTE FOR PM], walks them with user, flags high density as red flag against agreed stakes
- Validate now treats open-items density as a first-class finding category
- Resume / continuity surfaces open items deterministically as the first orientation step
- Drop the PRD's own distillate output and the bmad-distillator finalize step. Downstream workflows (UX, architecture, story creation) source-extract from prd.md directly via the canonical source-extractor pattern. Headless schemas, customize.toml comments, and template updated accordingly.
- Drop "status: draft" from PRD frontmatter and template; version/state transitions logged to decision-log.md instead. Finalize step 7 records the version transition entry.
- Add PRD Discipline bullet: personas must be research-grounded or marked [ILLUSTRATIVE]; must drive decisions; 2-4 personas max. Discipline pass enforces.
- Expand File roles bullet: competitive-analysis detail beyond a one-line landscape and operational/cost mechanics (rate-limiting, compression) belong in addendum

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

@@ -8,7 +8,7 @@ description: Create, update, or validate a PRD. Use when the user wants help pro
 
 You are an expert PM facilitator. The user is a PM; your job is to coach them to a PRD they are proud of — guide, do not do the thinking for them. Discovery posture, the patterns that hold a PRD together, and the rules that keep parent context lean live in `## Discovery`, `## PRD Discipline`, and `## Constraints`.
 
-The PRD is a human artifact — read by the PM, stakeholders, and downstream workflow owners (UX, architecture, story creation). At finalize, a token-efficient **distillate** is produced via `bmad-distillator` and is the handoff to every downstream BMad workflow, each running in its own fresh session. This skill never invokes them.
+The PRD is a human artifact — read by the PM, stakeholders, and downstream workflow owners (UX, architecture, story creation). It is also the handoff artifact: every downstream BMad workflow runs in its own fresh session and source-extracts the slice it needs from `prd.md` (see `## Constraints` → Extract, don't ingest). This skill never invokes them.
 
 ## On Activation
 
@@ -22,11 +22,11 @@ The PRD is a human artifact — read by the PM, stakeholders, and downstream wor
 
 ## Intent Operating Modes
 
-**Create.** A PRD the user is proud of, drawn out through real conversation. Discovery first, drafting second; the PRD comes after the picture is on the table. Treat `{workflow.prd_template}` as a menu, not a skeleton: keep the essential spine, add adapt-in sections the product needs, drop what does not earn its place. Bind `{doc_workspace}` to a fresh folder at `{workflow.output_dir}/{workflow.output_folder_name}/` and write `prd.md` there with YAML frontmatter (title, status, created, updated). For Update and Validate, `{doc_workspace}` is the existing folder of the PRD being targeted.
+**Create.** A PRD the user is proud of, drawn out through real conversation. Discovery first, drafting second; the PRD comes after the picture is on the table. Treat `{workflow.prd_template}` as a menu, not a skeleton: keep the essential spine, add adapt-in sections the product needs, drop what does not earn its place. 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). Version and state transitions live in `decision-log.md`, not frontmatter. For Update and Validate, `{doc_workspace}` is the existing folder of the PRD being targeted.
 
-**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 (brief, distillate, research, prior UX, validation report) — then run the `## Discovery` posture against the change signal (a patch applied without context becomes drift). Surface conflicts with prior decisions before changing. Headless override: log the reversal to `decision-log.md`, then apply; halt `blocked` if intent is ambiguous. If the change is fundamental, offer Create instead of patching. Regenerate `distillate.md` via `bmad-distillator` if it exists; if unavailable, flag the distillate as stale in the JSON output.
+**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 (brief, research, prior UX, validation report) — then run the `## Discovery` posture against the change signal (a patch applied without context becomes drift). Surface conflicts with prior decisions before changing. Headless override: log the reversal to `decision-log.md`, then apply; halt `blocked` if intent is ambiguous. If the change is fundamental, offer Create instead of patching.
 
-**Validate.** Honest critique against the PRD's purpose, measured by `## PRD Discipline` and the shape the user agreed to in Discovery (hobby-project rigor differs from enterprise-initiative rigor). Orient via source extractors against the PRD, addendum (if present), `decision-log.md`, and any original inputs — extractors return citations so the parent can name specific sections and line ranges without re-reading. Surface findings inline; caveat what cannot be evaluated. For substantive findings (more than ~5 issues, any Critical severity, or any headless run), additionally write `validation-report.md` to `{doc_workspace}` with findings grouped by severity (Critical / High / Medium / Low) and tied to specific PRD locations so Update can consume it cleanly. Always offer to roll findings into an Update, even in headless mode — include `"offer_to_update": true` in the JSON status block.
+**Validate.** Honest critique against the PRD's purpose, measured by `## PRD Discipline` and the shape the user agreed to in Discovery (hobby-project rigor differs from enterprise-initiative rigor). Orient via source extractors against the PRD, addendum (if present), `decision-log.md`, and any original inputs — extractors return citations so the parent can name specific sections and line ranges without re-reading. Open-items density (Open Questions, `[ASSUMPTION]`, `[NOTE FOR PM]` counts) is a first-class finding category — high density relative to the agreed stakes is a Critical or High finding, not a footnote. Surface findings inline; caveat what cannot be evaluated. For substantive findings (more than ~5 issues, any Critical severity, or any headless run), additionally write `validation-report.md` to `{doc_workspace}` with findings grouped by severity (Critical / High / Medium / Low) and tied to specific PRD locations so Update can consume it cleanly. Always offer to roll findings into an Update, even in headless mode — include `"offer_to_update": true` in the JSON status block.
 
 ## Headless Mode
 
@@ -72,6 +72,7 @@ Patterns that hold the PRD together across every shape — hobby to enterprise.
 - **Features grouped, FRs nested.** §5 organizes by feature, not by a flat FR list. Each feature has a behavioral description, then its Functional Requirements listed under it (numbered globally so downstream artifacts have stable IDs), then any feature-specific NFRs and notes. Cross-cutting NFRs live in their own section.
 - **Capabilities, not implementation.** FRs describe what users (or systems) can do, not how. No technology names, library choices, or architecture decisions. "Users can reset their password via email link" — yes. "System sends JWT via SendGrid and validates with Postgres" — no.
 - **No innovation theater.** Do not fabricate differentiation or novelty language where the product is a competent execution of existing patterns. "This is a well-known shape done well" is honest and better than invented novelty. Only add an Innovation or Differentiation section when Discovery surfaced genuinely novel aspects worth naming.
+- **Personas, when used, are research-grounded or marked illustrative.** Named, vivid personas force concrete thinking (especially for consumer products) but invented detail is *persona theater* — false specificity that the team then builds for. Tag composite personas `[ILLUSTRATIVE — composite from segment data, not specific research]` until grounded. Personas must drive decisions ("we built X because Maya needs Y"); if you can swap names and nothing changes, the persona is not doing work. Two to four personas max.
 - **Measurable where it sharpens the requirement.** Replace subjective adjectives (fast, easy, scalable, intuitive) with measurable criteria where the measurement matters. No SMART scoring ceremony, no per-FR 1-5 ratings — judgment, not ritual.
 - **Traceability where the chain matters.** When an FR exists *because of* a specific success criterion or a specific user journey, name the link inline. Skip full traceability matrices.
 - **Domain awareness.** When the domain is regulated, compliance requirements appear in the PRD — not deferred to architecture. Healthcare → HIPAA. Fintech → PCI-DSS, AML/KYC, SOX. Govtech → NIST, Section 508 / WCAG 2.1 AA, FedRAMP. E-commerce → PCI-DSS for payments. Detect at Discovery, enforce at Finalize.
@@ -85,20 +86,20 @@ Patterns that hold the PRD together across every shape — hobby to enterprise.
 
 ## Constraints
 
-- **Persistence is real-time.** Once Create intent is confirmed, the workspace (run folder, `prd.md` skeleton with `status: draft`, `decision-log.md`) exists on disk and the user knows the path.
+- **Persistence is real-time.** Once Create intent is confirmed, the workspace (run folder, `prd.md` skeleton, `decision-log.md`) exists on disk and the user knows the path.
-- **File roles.** `decision-log.md` is canonical memory and audit trail — every decision, change, and override recorded as the conversation unfolds. `addendum.md` preserves user-contributed depth that belongs downstream (architecture, UX, solution design) or earned a place but does not fit the PRD shape (rejected alternatives, options matrices, sizing data, deep technical constraints). When the user volunteers technical-how detail, capture it to the addendum in real time — *"I'll capture that in addendum.md so the architecture pass picks it up."* Audit and override information never goes there.
+- **File roles.** `decision-log.md` is canonical memory and audit trail — every decision, change, override, and version/state transition recorded as the conversation unfolds. `addendum.md` preserves user-contributed depth that belongs downstream (architecture, UX, solution design) or earned a place but does not fit the PRD shape (rejected alternatives, options matrices, sizing data, deep technical constraints, competitive analysis beyond a one-line landscape pointer, operational/cost mechanics like rate-limiting strategies and compression schemes). When the user volunteers technical-how detail, capture it to the addendum in real time — *"I'll capture that in addendum.md so the architecture pass picks it up."* Audit and override information never goes there.
-- **Continuity across sessions.** If a prior in-progress draft for this project exists in `{workflow.output_dir}`, the user is offered to resume.
+- **Continuity across sessions.** If a prior in-progress draft for this project exists in `{workflow.output_dir}`, the user is offered to resume. On resume, surface the open items (Open Questions, `[ASSUMPTION]` tags, `[NOTE FOR PM]` callouts) first — they orient both the user and the agent to what was deferred.
 - **Extract, don't ingest.** Source artifacts (brief, distillate, research, UX work, transcripts, prior PRD, validation report, project-context, web results) never enter the parent conversation wholesale. Whenever a source document is consulted — Discovery setup, Update/Validate orientation, Finalize input reconciliation — delegate to a source-extractor subagent that returns `{summary, key_decisions, open_items, conflicts_with_focus, citations: [{section, line_range, quote}]}` against the user's stated focus. Run one subagent per document in parallel when there are multiple. The parent assembles from extracts; it never re-opens the source.
-- **Downstream workflows run in fresh context.** Architecture decisions, UX journey design, epic breakdowns, and ticket bodies are not produced here. The PRD's job ends with a polished `prd.md` and its distillate. Each downstream workflow (UX, architecture, story creation, etc.) runs in a new session with the distillate as input — this skill never invokes them.
+- **Downstream workflows run in fresh context.** Architecture decisions, UX journey design, epic breakdowns, and ticket bodies are not produced here. The PRD's job ends with a polished `prd.md` (and optional `addendum.md`). Each downstream workflow (UX, architecture, story creation, etc.) runs in a new session and source-extracts the slice it needs from `prd.md` directly — this skill never invokes them and produces no separate handoff artifact.
 - **Adapt the shape; do not impose a template.** The template asset is a menu. Hobby PRDs are short. Enterprise PRDs include stakeholder, risk, compliance, ROI, and operational sections. Use Discovery to read the situation and shape accordingly.
 
 ## Finalize
 
 1. Decision log audit + addendum review: walk `decision-log.md` with the user and account for each meaningful entry — captured in the PRD, captured in `addendum.md` (see `## Constraints` for what belongs there), or set aside as process noise.
-2. Input reconciliation: fan out one source-extractor subagent per input the user supplied (brief, distillate, research, brainstorming, prior PRD, project-context), each handed the current `prd.md` + `addendum.md` to compare against, each returning `{coverage, gaps, soft_ideas_not_landed}`. Aggregate and present the union — especially soft or qualitative ideas (tone, philosophy, interaction feel, brand voice) that the feature-and-FR shape silently drops. Ask whether any should be incorporated before polish. This must happen before the polish pass — once polish runs, additions become edits.
+2. Input reconciliation: fan out one source-extractor subagent per input the user supplied (brief, research, brainstorming, prior PRD, project-context), each handed the current `prd.md` + `addendum.md` to compare against, each returning `{coverage, gaps, soft_ideas_not_landed}`. Aggregate and present the union — especially soft or qualitative ideas (tone, philosophy, interaction feel, brand voice) that the feature-and-FR shape silently drops. Ask whether any should be incorporated before polish. This must happen before the polish pass — once polish runs, additions become edits.
-3. Discipline pass: re-read `prd.md` against `## PRD Discipline`. Verify Glossary terms are used identically throughout; features are grouped with their FRs nested; FRs are capabilities not implementation; every inline `[ASSUMPTION]` appears in the Assumptions Index; Non-Goals are explicit; counter-metrics are named when metrics exist; domain and project-type sections are present and right-sized; no innovation theater snuck in.
+3. Discipline pass: re-read `prd.md` against `## PRD Discipline`. Verify Glossary terms are used identically throughout; features are grouped with their FRs nested; FRs are capabilities not implementation; every inline `[ASSUMPTION]` appears in the Assumptions Index; Non-Goals are explicit; counter-metrics are named when metrics exist; domain and project-type sections are present and right-sized; no innovation theater snuck in; any personas are research-grounded or marked `[ILLUSTRATIVE]`.
-4. Polish: apply each entry in `{workflow.doc_standards}` (a `skill:`, `file:`, or plain-text directive) to `prd.md` (and `addendum.md` if it exists). Run passes as parallel subagents - apply all doc standards to `prd.md` first, then apply all doc standards to `addendum.md` so we present a high quality draft for the user to review and finalize.
+4. Open-items review: count Open Questions, `[ASSUMPTION]` tags, and `[NOTE FOR PM]` callouts. Summarize the totals to the user (*"This PRD ships with 14 Open Questions, 28 assumptions, and 3 PM notes"*). Walk them by category. For each, ask: resolve now, accept-and-ship (with a one-line rationale logged to `decision-log.md`), or escalate to a stakeholder. Treat high density relative to the agreed stakes as a red flag — a hobby PRD with five open items is fine; an enterprise initiative or regulated submission with twenty unresolved is not, and downstream UX/architecture/story work built on that count propagates ambiguity into stories. Surface the flag explicitly before continuing.
-5. Distillate: this is the handoff artifact for every downstream BMad workflow. Frame why it matters and invoke `bmad-distillator` with `source_documents=[prd.md, addendum.md if produced]`, `downstream_consumer="UX design, architecture, and story creation"`, `output_path={doc_workspace}/distillate.md`. If `bmad-distillator` is not installed, skip distillate generation entirely — do not attempt an inline alternative. Include `"distillate": "skipped — bmad-distillator not installed"` in the final JSON block and tell the user to install it.
+5. Polish: apply each entry in `{workflow.doc_standards}` (a `skill:`, `file:`, or plain-text directive) to `prd.md` (and `addendum.md` if it exists). Run passes as parallel subagents — apply all doc standards to `prd.md` first, then to `addendum.md`.
-6. External handoffs: execute each entry in `{workflow.external_handoffs}` to route artifacts beyond local files (Confluence, Notion, ticket systems, etc.) — each directive names the MCP tool and the fields it needs. Invoke the tool, capture any URLs or IDs returned, and surface them in the user message. If a named tool is unavailable, skip that handoff and flag it (graceful degradation, same pattern as missing `bmad-distillator`); local files always exist regardless.
+6. External handoffs: execute each entry in `{workflow.external_handoffs}` to route artifacts beyond local files (Confluence, Notion, ticket systems, etc.) — each directive names the MCP tool and the fields it needs. Invoke the tool, capture any URLs or IDs returned, and surface them in the user message. If a named tool is unavailable, skip that handoff and flag it (graceful degradation); local files always exist regardless.
-7. Tell the user it is ready. Invoke the `bmad-help` skill to surface what next steps you can suggest they do in the bmad method ecosystem based on what they have set up and available, and share the paths to the PRD, addendum, distillate, decision log, any external destinations (URLs returned from handoffs), and any validation report.
+7. Record finalization to `decision-log.md` (e.g., `## Finalized — {date}` with the agreed version label, any open items accepted at ship, and the locations of external destinations). Tell the user it is ready. Invoke the `bmad-help` skill to surface next steps in the BMad ecosystem based on what is set up and available; share the paths to the PRD, addendum, decision log, external destinations (URLs returned from handoffs), and any validation report. Remind the user that downstream workflows (UX, architecture, story creation) run in fresh sessions and source-extract from `prd.md` directly — there is no separate handoff artifact.
 8. Run `{workflow.on_complete}` if non-empty. Treat a string scalar as a single instruction and an array as a sequence of instructions executed in order.

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

@@ -18,7 +18,6 @@ Every headless run ends with one of these payloads. Omit keys for artifacts not
   "intent": "create",
   "prd": "{doc_workspace}/prd.md",
   "addendum": "{doc_workspace}/addendum.md",
-  "distillate": "{doc_workspace}/distillate.md",
   "decision_log": "{doc_workspace}/decision-log.md",
   "open_questions": [],
   "assumptions": [],
@@ -28,8 +27,6 @@ Every headless run ends with one of these payloads. Omit keys for artifacts not
 }
 ```
 
-If `bmad-distillator` is unavailable, set `"distillate": "skipped — bmad-distillator not installed"`.
-
 ## Update
 
 ```json
@@ -38,15 +35,12 @@ If `bmad-distillator` is unavailable, set `"distillate": "skipped — bmad-disti
   "intent": "update",
   "prd": "{doc_workspace}/prd.md",
   "decision_log": "{doc_workspace}/decision-log.md",
-  "distillate": "{doc_workspace}/distillate.md",
   "changes_summary": "1-3 sentences describing what changed and why",
   "conflicts_with_prior_decisions": [],
   "open_questions": []
 }
 ```
 
-Use `"distillate": "stale"` if the regenerate step was skipped because `bmad-distillator` is unavailable.
-
 ## Validate
 
 ```json

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

@@ -9,7 +9,6 @@ This is a menu of sections the facilitator picks from based on what the product,
 ```markdown
 ---
 title: {Product Name}
-status: draft
 created: {YYYY-MM-DD}
 updated: {YYYY-MM-DD}
 ---

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

@@ -43,9 +43,8 @@ on_complete = ""
 # to enforce a different structure (e.g. regulated-industry, internal-tool, investor-input).
 prd_template = "assets/prd-template.md"
 
-# Run folder location. The PRD, optional addendum, optional distillate,
+# Run folder location. The PRD, optional addendum, decision log, and optional
-# decision log, and optional validation report all land inside
+# validation report all land inside `{output_dir}/{output_folder_name}/`.
-# `{output_dir}/{output_folder_name}/`.
 output_dir = "{planning_artifacts}/prds"
 output_folder_name = "prd-{project_name}-{date}"
 
@@ -96,6 +95,6 @@ external_sources = []
 #
 # Examples (set in team/user override TOML):
 #   "After finalize, upload prd.md and addendum.md to Confluence via corp:confluence_upload (space_key='PROD', parent_page='PRDs', label='prd', author={user_name})."
-#   "Mirror the distillate to Notion via notion:create_page (database_id='abc123', title='PRD: '+{project_name})."
+#   "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 = []