bmad-method-quarkus 1.0.0

package/src/bmm-skills/plan/bmad-prd/customize.toml

@@ -0,0 +1,149 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-prd.
+#
+# Override files (not edited here):
+#   {project-root}/_bmad/custom/bmad-prd.toml         (team)
+#   {project-root}/_bmad/custom/bmad-prd.user.toml    (personal)
+
+[workflow]
+
+# --- Configurable below. Overrides merge per BMad structural rules: ---
+#   scalars: override wins • arrays: append
+
+# Steps to run before the standard activation (config load, greet).
+# Use for pre-flight loads, compliance checks, etc.
+activation_steps_prepend = []
+
+# Steps to run after greet but before the workflow begins.
+# Use for context-heavy setup that should happen once the user has been acknowledged.
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run
+# (standards, compliance constraints, stylistic guardrails).
+# Each entry is either a literal sentence, a skill prefixed with `skill:`, or a `file:`-prefixed path/glob
+# whose contents are loaded as facts.
+#
+# Default loads project-context.md if bmad-generate-project-context has produced one — this gives
+# the facilitator persistent awareness of the project's tech, domain, and constraints without
+# re-asking. Common opt-ins (set in team/user override TOML):
+#   "skill:acme-co:terms-and-conditions"                                      # a skill that contains some relevant info
+#   "Investor PRDs must include a market sizing section."                    # generic agent instruction
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+# Executed when the workflow completes (after the user has been told the
+# PRD is ready). Accepts either a string scalar (single instruction)
+# or an array of instructions executed in order. Empty for none.
+on_complete = ""
+
+# Default PRD structure. Treated as a starting point — the LLM adapts it
+# to the product, project type, and domain. Override the path in team/user TOML
+# to enforce a different structure (e.g. regulated-industry, internal-tool, investor-input).
+prd_template = "assets/prd-template.md"
+
+# PRD quality rubric used at the Validate intent and at Finalize step 3.
+# A subagent walks the rubric against prd.md and writes a substantive review
+# organized by quality dimensions (decision-readiness, substance, strategic
+# coherence, etc.). Override the path in team/user TOML to enforce an
+# org-specific rubric (regulated-industry compliance, investor-pitch standards,
+# etc.). The filename "checklist" is retained for back-compat with override
+# files; the content is a judgment rubric, not a boolean checklist.
+validation_checklist_template = "assets/prd-validation-checklist.md"
+
+# HTML skeleton the synthesis pass fills directly when consolidating reviewer
+# outputs into a validation report. No substitution engine — the parent LLM
+# reads every {doc_workspace}/review-*.md, fills the skeleton's TEMPLATE_*
+# placeholders, and writes the result. Fully overridable to match org branding.
+# Uses inline CSS, no external dependencies, and native HTML <details> for
+# collapse — no JS.
+validation_report_template = "assets/validation-report-template.html"
+
+# Run folder location. The PRD, optional addendum, memlog, and optional
+# validation report all land inside `{prd_output_path}/{run_folder_pattern}/`.
+# Resume-check scans `{prd_output_path}` for prior unfinished runs.
+prd_output_path = "{planning_artifacts}/prds"
+run_folder_pattern = "prd-{project_name}-{date}"
+
+# Document standards applied to human-consumed docs at finalize. Each entry is
+# a `skill:`, `file:`, or plain-text directive; the parent LLM applies the
+# findings before the user sees the draft. Encodes standards, not options.
+#
+# Examples:
+#   "skill:bmad-review lenses=structure,prose"
+#   "file:{project-root}/_bmad/style-guides/company-voice.md"
+#   "Convert all dates to ISO 8601 format."
+#
+# Suggested order (broader passes first, narrower last):
+#   1. Structural (cuts, reorganization, section sizing)
+#   2. Content/voice/conventions (org standards, tone, terminology, compliance)
+#   3. Prose mechanics (grammar, clarity, typos)
+#
+# Override the array in team/user TOML to add additional standards. Append-only:
+# base entries cannot be removed or replaced (resolver has no removal mechanism).
+# The default entry runs bmad-review's two editorial lenses in order:
+# structure, then prose on top of the structure findings. The `lenses=` suffix
+# names them; drop it to let bmad-review pick what fits the content.
+doc_standards = [
+  "skill:bmad-review lenses=structure,prose",
+]
+
+# External-source registry. Natural-language directives describing knowledge
+# bases, MCP tools, or internal systems the LLM may consult during the workflow
+# when a relevant need surfaces. The LLM does NOT query these preemptively —
+# it consults them on demand (during Discovery, validation, drafting, etc.).
+# Each entry names the tool, the conditions for using it, and any fields the
+# tool needs. If a named MCP tool is unavailable at runtime, the LLM falls
+# back to standard behavior and notes the gap. Empty by default.
+#
+# Lifecycle note: distinct from persistent_facts. persistent_facts are loaded
+# once at activation and kept in mind for the whole run; external_sources are
+# a registry consulted on demand and only when the conversation surfaces a
+# matching need.
+#
+# Examples (set in team/user override TOML):
+#   "When researching internal product context, consult corp:kb_search (database='product-docs') before web search."
+#   "For competitive landscape during Discovery, query corp:competitive_db with category={project_name}."
+#   "When validating domain-compliance claims, cross-check against corp:hipaa_reference for healthcare or corp:pci_reference for fintech."
+external_sources = []
+
+# External-handoff routing. Natural-language directives the LLM applies at
+# Finalize to route outputs beyond local files (Confluence, Notion, Google
+# Drive, ticket systems, etc.). Each entry names the MCP tool, the destination,
+# and the fields the tool needs. Handoffs run after the artifact is polished
+# and before the final user-facing message. URLs or IDs returned by the
+# destination are captured and surfaced to the user. If a named tool is
+# unavailable at runtime, the handoff is skipped and flagged in the JSON
+# status; local files always exist regardless. Fires automatically — users
+# can opt out in their prompt for a specific run. Empty by default.
+#
+# Lifecycle note: distinct from persistent_facts and external_sources.
+# Fired once at Finalize step 6, never during Discovery or drafting.
+#
+# 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 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 = []

package/src/bmm-skills/plan/bmad-prd/references/headless.md

@@ -0,0 +1,39 @@
+# Headless Mode
+
+Load this file when bmad-prd is invoked headless (no interactive user). Follow it for the whole run.
+
+## Detection
+
+Headless mode is in effect when any of the following is true:
+
+- the invoking caller sets a `headless: true` flag (or equivalent argument the harness exposes),
+- the invocation is from another skill or a non-interactive runner (no TTY, no user message stream),
+- `{workflow.activation_steps_prepend}` includes an entry that explicitly declares headless,
+- the first message comes from an automation context that pre-supplies all inputs and asks for an artifact path back.
+
+When ambiguous, default to interactive.
+
+## Inputs the caller is expected to provide
+
+The caller passes inputs in their first message (free-form structured payload; no fixed schema, but every field below should be present when applicable):
+
+- `intent` — `"create"`, `"update"`, or `"validate"`. If absent, infer from the artifact set.
+- For **Create**: a brief or product spec the LLM works from (plain text, file path, or URL), plus any user/scope notes; `doc_workspace` if a specific run folder is required (otherwise the workflow binds the default).
+- For **Update**: the existing `prd.md` path (or a workspace path that contains one), and a change signal (the request: what to change and why).
+- For **Validate**: the existing `prd.md` path (or workspace path), and optionally a checklist override path. Workspace defaults to the PRD's containing directory.
+
+Anything the caller does not provide is either inferred from inputs/workspace or recorded as `assumptions[]` / `open_questions[]` in the JSON status. Do not invent user detail, success metrics, or scope decisions to fill gaps — record them.
+
+## General
+
+Do not ask. Complete the intent using what is provided, what exists in `{doc_workspace}`, or what you can discover yourself. If intent remains ambiguous after inference, halt with `status: "blocked"` and a `reason` field — do not prompt. Do not greet.
+
+Populate `assumptions[]` with every value you inferred without direct caller confirmation; populate `open_questions[]` with every gap that needs a human decision. Use `status: "partial"` when the artifact was produced but `open_questions[]` is non-empty or critical inputs were inferred (Create with no brief; Update with a vague signal acted on best-effort; Validate that could not load the checklist). `complete` = stands on its own; `partial` = caller should review before downstream use; `blocked` = no artifact produced.
+
+End with the JSON response (full schemas with examples in `assets/headless-schemas.md`). The `intent` field must match the detected intent. Omit keys for artifacts not produced.
+
+## Mode-specific overrides
+
+**Update.** Apply the change, log it via `uv run {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type change --text "<change + rationale>"`, and surface any conflict-with-prior-decision in `conflicts_with_prior_decisions[]` in the JSON status. Halt `blocked` if intent is ambiguous.
+
+**Validate.** Always write both `validation-report.html` and `validation-report.md` to `{doc_workspace}` regardless of finding count. Always include `"offer_to_update": true` in the JSON status. Skip the browser-open step in `references/validate.md` — write the artifacts and return.

package/src/bmm-skills/plan/bmad-prd/references/validate.md

@@ -0,0 +1,97 @@
+# Validate
+
+The Validate intent playbook. Standalone — this intent critiques an existing PRD without changing it and ends after the user has seen the report; it does not run Finalize. The synthesis pipeline below is also reused for mid-session report requests during Create/Update.
+
+## Orient
+
+Source-extract against `.memlog.md`, any original inputs, and the PRD/addendum themselves. Delegate to subagents per PRD Discipline → "Extract, don't ingest" (in SKILL.md); the parent assembles from extracts.
+
+## Run the Reviewer Gate
+
+Run the Reviewer Gate (see SKILL.md) against `prd.md` (and `addendum.md` if present). The rubric walker is the default entry in the gate menu; under Validate intent it additionally runs the synthesis pipeline below. The Finalize discipline pass during Create/Update does NOT render a report — findings stay in-conversation.
+
+## Rubric-walker pipeline
+
+The rubric walker is the primary review entry. Spawn it as a subagent with this prompt:
+
+> You are validating a PRD against the quality rubric at `{workflow.validation_checklist_template}`. Read the full rubric first, then read `prd.md` (and `addendum.md` if present). Form a judgment per dimension — *strong / adequate / thin / broken* — and write findings only where they add information. Cite specific PRD locations and quote phrases. Severity ranks impact on the PRD's usefulness, not how easy the fix is. Write your review to `{doc_workspace}/review-rubric.md` in the format the rubric specifies. Return ONLY a compact summary (overall verdict, dimension verdicts, finding counts by severity, file path).
+
+The Reviewer Gate may also dispatch additional reviewers from `{workflow.finalize_reviewers}` (adversarial-general by default) and any ad-hoc reviewers the parent judges warranted. Each writes its review to `{doc_workspace}/review-{slug}.md` and returns a compact summary. Run in parallel.
+
+## Synthesis pipeline
+
+Once every selected reviewer has returned, the parent synthesizes one consolidated report. **Do not skip this step under Validate intent** — it produces the persistent artifact the user opens.
+
+### Inputs
+
+- `{doc_workspace}/review-rubric.md` — primary, structured by the seven dimensions
+- Zero or more `{doc_workspace}/review-{slug}.md` files — extra reviewers (adversarial, etc.)
+- `{workflow.validation_report_template}` — the HTML skeleton
+
+### What the synthesis pass does
+
+1. Read every reviewer file in `{doc_workspace}/review-*.md`.
+2. Fill the HTML skeleton:
+   - **Header.** PRD name, path. Grade derived from the rubric verdicts and severity counts: *Excellent* = all dimensions strong/adequate, no high/critical findings · *Good* = ≤1 thin dimension, no critical findings · *Fair* = multiple thin dimensions or any high finding · *Poor* = any broken dimension or any critical finding. Set the matching `grade-excellent | grade-good | grade-fair | grade-poor` class.
+   - **Synthesis block.** Lift the rubric's *Overall verdict* paragraph as the lead; if adversarial or ad-hoc reviewers materially shift the picture, add a second paragraph that names what they surfaced.
+   - **Dimension summary cards.** One per dimension that was assessed. Colored verdict text. Skip dimensions the rubric marked n/a for this PRD (e.g. downstream usability for a standalone PRD).
+   - **Dimension sections.** One `<section class="dimension">` per assessed dimension, in rubric order. `<details open>` for *thin* and *broken*; closed for *strong* and *adequate*. Each contains the dimension judgment (the prose from review-rubric.md) and the findings list.
+   - **Reviewer sections.** One `<section class="reviewer-section">` per extra reviewer that ran. The source file path goes in the `<span class="reviewer-source">`. Closed by default. Adversarial findings keep their adversarial voice — do not soften.
+   - **Mechanical notes.** Bullet list from the rubric's "Mechanical notes" section. Skip the block if empty.
+   - **Footer.** Rubric path, ISO timestamp.
+3. Write the filled HTML to `{doc_workspace}/validation-report.html`.
+4. Write the markdown twin to `{doc_workspace}/validation-report.md` (same content, grouped by severity rather than by dimension — see format below; this is the canonical form for downstream re-reading).
+5. Open the HTML in the default browser with the platform opener — `open` on macOS, `xdg-open` on Linux, `start ""` on Windows — double-quoting the path:
+   ```bash
+   open "{doc_workspace}/validation-report.html"
+   ```
+   If the command fails, don't retry with another opener: tell the user the file path and move on. Skip the open step in headless mode (see `references/headless.md`).
+
+### Markdown twin format
+
+```markdown
+# Validation Report — {prd_name}
+
+- **PRD:** `{prd_path}`
+- **Rubric:** `{rubric_path}`
+- **Run at:** {ISO timestamp}
+- **Grade:** {Excellent | Good | Fair | Poor}
+
+## Overall verdict
+{synthesis paragraphs}
+
+## Dimension verdicts
+- Decision-readiness — {verdict}
+- Substance over theater — {verdict}
+- (etc. for each assessed dimension)
+
+## Findings by severity
+
+### Critical (n)
+**[Dimension or Reviewer]** — Title (§ location)
+{Note}
+Fix: {suggested fix}
+
+### High (n)
+...
+
+### Medium (n)
+...
+
+### Low (n)
+...
+
+## Mechanical notes
+- {bullet}
+
+## Reviewer files
+- `review-rubric.md`
+- `review-adversarial-general.md` (if present)
+- (etc.)
+```
+
+Re-running validation overwrites the consolidated report in place. The individual `review-*.md` files are preserved so the user can drill in.
+
+## Close
+
+Surface artifact paths; the rendered HTML/markdown is the persistent artifact. Always offer to roll findings into an Update.

package/src/bmm-skills/plan/bmad-prfaq/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: bmad-prfaq
+description: Working Backwards PRFAQ challenge that stress-tests a product concept customer-first. Use when the user requests to 'create a PRFAQ', 'work backwards', or 'run the PRFAQ challenge'.
+---
+
+# Working Backwards: The PRFAQ Challenge
+
+## Overview
+
+This skill forges product concepts through Amazon's Working Backwards methodology — the PRFAQ (Press Release / Frequently Asked Questions). Act as a relentless but constructive product coach who stress-tests every claim, challenges vague thinking, and refuses to let weak ideas pass unchallenged. The user walks in with an idea. They walk out with a battle-hardened concept — or the honest realization they need to go deeper. Both are wins.
+
+The PRFAQ forces customer-first clarity: write the press release announcing the finished product before building it. If you can't write a compelling press release, the product isn't ready. The customer FAQ validates the value proposition from the outside in. The internal FAQ addresses feasibility, risks, and hard trade-offs.
+
+**This is hardcore mode.** The coaching is direct, the questions are hard, and vague answers get challenged. But when users are stuck, offer concrete suggestions, reframings, and alternatives — tough love, not tough silence. The goal is to strengthen the concept, not to gatekeep it.
+
+**Args:** Accepts `--headless` / `-H` for autonomous first-draft generation from provided context.
+
+**Output:** A complete PRFAQ document + PRD distillate for downstream pipeline consumption.
+
+**Research-grounded.** All competitive, market, and feasibility claims in the output must be verified against current real-world data. Proactively research to fill knowledge gaps — the user deserves a PRFAQ informed by today's landscape, not yesterday's assumptions.
+
+## Conventions
+
+- Bare paths (e.g. `references/press-release.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`. Be warm but efficient — dream builder energy.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation 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.
+
+## Pre-workflow Setup
+
+1. **Resume detection:** Check if `{planning_artifacts}/prfaq-{project_name}.md` already exists. If it does, read only the first 20 lines to extract the frontmatter `stage` field and offer to resume from the next stage. Do not read the full document. If the user confirms, route directly to that stage's reference file.
+
+2. **Mode detection:**
+- `--headless` / `-H`: Produce complete first-draft PRFAQ from provided inputs without interaction. Validate the input schema only (customer, problem, stakes, solution concept present and non-vague) — do not read any referenced files or documents yourself. If required fields are missing or too vague, return an error with specific guidance on what's needed. Fan out artifact analyzer and web researcher subagents in parallel (see Contextual Gathering below) to process all referenced materials, then create the output document at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md` and route to `./references/press-release.md`.
+- Default: Full interactive coaching — the gauntlet.
+
+**Headless input schema:**
+- **Required:** customer (specific persona), problem (concrete), stakes (why it matters), solution (concept)
+- **Optional:** competitive context, technical constraints, team/org context, target market, existing research
+
+**Set the tone immediately.** This isn't a warm, exploratory greeting. Frame it as a challenge — the user is about to stress-test their thinking by writing the press release for a finished product before building anything. Convey that surviving this process means the concept is ready, and failing here saves wasted effort. Be direct and energizing.
+
+Then briefly ground the user on what a PRFAQ actually is — Amazon's Working Backwards method where you write the finished-product press release first, then answer the hardest customer and stakeholder questions. The point is forcing clarity before committing resources.
+
+Then proceed to Stage 1 below.
+
+## Stage 1: Ignition
+
+**Goal:** Get the raw concept on the table and immediately establish customer-first thinking. This stage ends when you have enough clarity on the customer, their problem, and the proposed solution to draft a press release headline.
+
+**Customer-first enforcement:**
+
+- If the user leads with a solution ("I want to build X"): redirect to the customer's problem. Don't let them skip the pain.
+- If the user leads with a technology ("I want to use AI/blockchain/etc"): challenge harder. Technology is a "how", not a "why" — push them to articulate the human problem. Strip away the buzzword and ask whether anyone still cares.
+- If the user leads with a customer problem: dig deeper into specifics — how they cope today, what they've tried, why it hasn't been solved.
+
+When the user gets stuck, offer concrete suggestions based on what they've shared so far. Draft a hypothesis for them to react to rather than repeating the question harder.
+
+**Concept type detection:** Early in the conversation, identify whether this is a commercial product, internal tool, open-source project, or community/nonprofit initiative. Store this as `{concept_type}` — it calibrates FAQ question generation in Stages 3 and 4. Non-commercial concepts don't have "unit economics" or "first 100 customers" — adapt the framing to stakeholder value, adoption paths, and sustainability instead.
+
+**Essentials to capture before progressing:**
+- Who is the customer/user? (specific persona, not "everyone")
+- What is their problem? (concrete and felt, not abstract)
+- Why does this matter to them? (stakes and consequences)
+- What's the initial concept for a solution? (even rough)
+
+**Fast-track:** If the user provides all four essentials in their opening message (or via structured input), acknowledge and confirm understanding, then move directly to document creation and Stage 2 without extended discovery.
+
+**Graceful redirect:** If after 2-3 exchanges the user can't articulate a customer or problem, don't force it. Point them upstream: `bmad-brainstorming` if they need to generate options, or `bmad-forge-idea` if they hold an idea that hasn't been pressure-tested into something sound yet.
+
+**Contextual Gathering:** Once you understand the concept, gather external context before drafting begins.
+
+1. **Ask about inputs:** Ask the user whether they have existing documents, research, brainstorming, or other materials to inform the PRFAQ. Collect paths for subagent scanning — do not read user-provided files yourself; that's the Artifact Analyzer's job.
+2. **Fan out subagents in parallel:**
+   - **Artifact Analyzer** (`./agents/artifact-analyzer.md`) — Scans `{planning_artifacts}` and `{project_knowledge}` for relevant documents, plus any user-provided paths. Receives the product intent summary so it knows what's relevant.
+   - **Web Researcher** (`./agents/web-researcher.md`) — Searches for competitive landscape, market context, and current industry data relevant to the concept. Receives the product intent summary.
+3. **Graceful degradation:** If subagents are unavailable, scan the most relevant 1-2 documents inline and do targeted web searches directly. Never block the workflow.
+4. **Merge findings** with what the user shared. Surface anything surprising that enriches or challenges their assumptions before proceeding.
+
+**Create the output document** at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md`. Write the frontmatter (populate `inputs` with any source documents used) and any initial content captured during Ignition. This document is the working artifact — update it progressively through all stages.
+
+**Coaching Notes Capture:** Before moving on, append a `<!-- coaching-notes-stage-1 -->` block to the output document: concept type and rationale, initial assumptions challenged, why this direction over alternatives discussed, key subagent findings that shaped the concept framing, and any user context captured that doesn't fit the PRFAQ itself.
+
+**When you have enough to draft a press release headline**, route to `./references/press-release.md`.
+
+## Stages
+
+| # | Stage | Purpose | Location |
+|---|-------|---------|----------|
+| 1 | Ignition | Raw concept, enforce customer-first thinking | SKILL.md (above) |
+| 2 | The Press Release | Iterative drafting with hard coaching | `./references/press-release.md` |
+| 3 | Customer FAQ | Devil's advocate customer questions | `./references/customer-faq.md` |
+| 4 | Internal FAQ | Skeptical stakeholder questions | `./references/internal-faq.md` |
+| 5 | The Verdict | Synthesis, strength assessment, final output | `./references/verdict.md` |

package/src/bmm-skills/plan/bmad-prfaq/agents/artifact-analyzer.md

@@ -0,0 +1,60 @@
+# Artifact Analyzer
+
+You are a research analyst. Your job is to scan project documents and extract information relevant to a product concept being stress-tested through the PRFAQ process.
+
+## Input
+
+You will receive:
+- **Product intent:** A summary of the concept — customer, problem, solution direction
+- **Scan paths:** Directories to search for relevant documents (e.g., planning artifacts, project knowledge folders)
+- **User-provided paths:** Any specific files the user pointed to
+
+## Process
+
+1. **Scan the provided directories** for documents that could be relevant:
+   - Brainstorming reports (`*brainstorm*`, `*ideation*`)
+   - Research documents (`*research*`, `*analysis*`, `*findings*`)
+   - Project context (`*context*`, `*overview*`, `*background*`)
+   - Existing briefs or summaries (`*brief*`, `*summary*`)
+   - Any markdown, text, or structured documents that look relevant
+
+2. **For sharded documents** (a folder with `index.md` and multiple files), read the index first to understand what's there, then read only the relevant parts.
+
+3. **For very large documents** (estimated >50 pages), read the table of contents, executive summary, and section headings first. Read only sections directly relevant to the stated product intent. Note which sections were skimmed vs read fully.
+
+4. **Read all relevant documents in parallel** — issue all Read calls in a single message rather than one at a time. Extract:
+   - Key insights that relate to the product intent
+   - Market or competitive information
+   - User research or persona information
+   - Technical context or constraints
+   - Ideas, both accepted and rejected (rejected ideas are valuable — they prevent re-proposing)
+   - Any metrics, data points, or evidence
+
+5. **Ignore documents that aren't relevant** to the stated product intent. Don't waste tokens on unrelated content.
+
+## Output
+
+Return ONLY the following JSON object. No preamble, no commentary. Keep total response under 1,500 tokens. Maximum 5 bullets per section — prioritize the most impactful findings.
+
+```json
+{
+  "documents_found": [
+    {"path": "file path", "relevance": "one-line summary"}
+  ],
+  "key_insights": [
+    "bullet — grouped by theme, each self-contained"
+  ],
+  "user_market_context": [
+    "bullet — users, market, competition found in docs"
+  ],
+  "technical_context": [
+    "bullet — platforms, constraints, integrations"
+  ],
+  "ideas_and_decisions": [
+    {"idea": "description", "status": "accepted|rejected|open", "rationale": "brief why"}
+  ],
+  "raw_detail_worth_preserving": [
+    "bullet — specific details, data points, quotes for the distillate"
+  ]
+}
+```

package/src/bmm-skills/plan/bmad-prfaq/agents/web-researcher.md

@@ -0,0 +1,49 @@
+# Web Researcher
+
+You are a market research analyst. Your job is to find current, relevant competitive, market, and industry context for a product concept being stress-tested through the PRFAQ process.
+
+## Input
+
+You will receive:
+- **Product intent:** A summary of the concept — customer, problem, solution direction, and the domain it operates in
+
+## Process
+
+1. **Identify search angles** based on the product intent:
+   - Direct competitors (products solving the same problem)
+   - Adjacent solutions (different approaches to the same pain point)
+   - Market size and trends for the domain
+   - Industry news or developments that create opportunity or risk
+   - User sentiment about existing solutions (what's frustrating people)
+
+2. **Execute 3-5 targeted web searches** — quality over quantity. Search for:
+   - "[problem domain] solutions comparison"
+   - "[competitor names] alternatives" (if competitors are known)
+   - "[industry] market trends [current year]"
+   - "[target user type] pain points [domain]"
+
+3. **Synthesize findings** — don't just list links. Extract the signal.
+
+## Output
+
+Return ONLY the following JSON object. No preamble, no commentary. Keep total response under 1,000 tokens. Maximum 5 bullets per section.
+
+```json
+{
+  "competitive_landscape": [
+    {"name": "competitor", "approach": "one-line description", "gaps": "where they fall short"}
+  ],
+  "market_context": [
+    "bullet — market size, growth trends, relevant data points"
+  ],
+  "user_sentiment": [
+    "bullet — what users say about existing solutions"
+  ],
+  "timing_and_opportunity": [
+    "bullet — why now, enabling shifts"
+  ],
+  "risks_and_considerations": [
+    "bullet — market risks, competitive threats, regulatory concerns"
+  ]
+}
+```

package/src/bmm-skills/plan/bmad-prfaq/assets/prfaq-template.md

@@ -0,0 +1,62 @@
+---
+title: "PRFAQ: {project_name}"
+status: "{status}"
+created: "{timestamp}"
+updated: "{timestamp}"
+stage: "{current_stage}"
+inputs: []
+---
+
+# {Headline}
+
+## {Subheadline — one sentence: who benefits and what changes for them}
+
+**{City, Date}** — {Opening paragraph: announce the product/initiative, state the user's problem, and the key benefit.}
+
+{Problem paragraph: the user's pain today. Specific, concrete, felt. No mention of the solution yet.}
+
+{Solution paragraph: what changes for the user. Benefits, not features. Outcomes, not implementation.}
+
+> "{Leader/founder quote — the vision beyond the feature list.}"
+> — {Name, Title/Role}
+
+### How It Works
+
+{The user experience, step by step. Written from THEIR perspective. How they discover it, start using it, and get value from it.}
+
+> "{User quote — what a real person would say after using this. Must sound human, not like marketing copy.}"
+> — {Name, Role}
+
+### Getting Started
+
+{Clear, concrete path to first value. How to access, try, adopt, or contribute.}
+
+---
+
+## Customer FAQ
+
+### Q: {Hardest customer question first}
+
+A: {Honest, specific answer}
+
+### Q: {Next question}
+
+A: {Answer}
+
+---
+
+## Internal FAQ
+
+### Q: {Hardest internal question first}
+
+A: {Honest, specific answer}
+
+### Q: {Next question}
+
+A: {Answer}
+
+---
+
+## The Verdict
+
+{Concept strength assessment — what's forged in steel, what needs more heat, what has cracks in the foundation.}

package/src/bmm-skills/plan/bmad-prfaq/bmad-manifest.json

@@ -0,0 +1,16 @@
+{
+  "module-code": "bmm",
+  "capabilities": [
+    {
+      "name": "working-backwards",
+      "menu-code": "WB",
+      "description": "Produces battle-tested PRFAQ document and optional LLM distillate for PRD input.",
+      "supports-headless": true,
+      "phase-name": "plan",
+      "preceded-by": ["brainstorming", "perform-research"],
+      "followed-by": ["create-prd"],
+      "is-required": false,
+      "output-location": "{planning_artifacts}"
+    }
+  ]
+}

package/src/bmm-skills/plan/bmad-prfaq/customize.toml

@@ -0,0 +1,41 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-prfaq. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per BMad structural rules: ---
+#   scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+#   arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+# Steps to run before the standard activation (config load, greet).
+# Overrides append. Use for pre-flight loads, compliance checks, etc.
+
+activation_steps_prepend = []
+
+# Steps to run after greet but before the workflow begins.
+# Overrides append. Use for context-heavy setup that should happen
+# once the user has been acknowledged.
+
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run
+# (standards, compliance constraints, stylistic guardrails).
+# Distinct from the runtime memory sidecar — these are static context
+# loaded on activation. Overrides append.
+#
+# Each entry is either:
+#   - a literal sentence, e.g. "All briefs must include a regulatory-risk section."
+#   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
+#     (glob patterns are supported; the file's contents are loaded and treated as facts).
+
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+# Scalar: executed when the workflow reaches its terminal stage (Stage 5: The Verdict),
+# after the PRFAQ and distillate have been delivered. Override wins. Leave empty for
+# no custom post-completion behavior.
+
+on_complete = ""