bmad-method 6.10.1-next.2 → 6.10.1-next.21

package/src/bmm-skills/4-implementation/bmad-quick-dev/step-oneshot.md

@@ -1,35 +1,34 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
 # Step One-Shot: Implement, Review, Present
 
 ## RULES
 
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- **Language** — Speak in `{{.communication_language}}`. Write any file output in `{{.document_output_language}}`.
 - NEVER auto-push.
 - All review subagents must run at the same model capability as the current session.
+- Run subagents synchronously: launch them together, then wait for all results before continuing.
 
 ## INSTRUCTIONS
 
 ### Implement
 
-Follow `./sync-sprint-status.md` with `{target_status}` = `in-progress`.
+Follow `./sync-sprint-status.md` with `target_status` = `in-progress`.
 
 Implement the clarified intent directly.
 
 ### Review
 
-Launch Blind Hunter without prior conversation context. If no subagents are available, generate one review prompt file in `{implementation_artifacts}` and HALT. Ask the human to run it in a separate session and paste back the findings.
+Execute these review layers in parallel wherever their execution methods allow, following each layer's instruction verbatim after substituting any runtime placeholders:
+
+{workflow.oneshot_review_layers}
 
-- **Blind Hunter** — prompt: "Invoke the `bmad-review-adversarial-general` skill on the changed files."
+If a layer's instruction requires subagents and none are available, generate one review prompt file per such layer in `{{.implementation_artifacts}}` and HALT. Ask the human to run each in a separate session and paste back the findings.
 
 ### Classify
 
 Deduplicate all review findings. Three categories only:
 
 - **patch** — trivially fixable. Auto-fix immediately.
-- **defer** — pre-existing issue not caused by this change. Append one new entry to `{deferred_work_file}` using this format. Do not modify existing entries or look for duplicates.
+- **defer** — pre-existing issue not caused by this change. Append one new entry to `{{.deferred_work_file}}` using this format. Do not modify existing entries or look for duplicates.
   ```markdown
   - source_spec: `{spec_file}`
     summary: <one sentence>
@@ -41,7 +40,7 @@ If a finding is caused by this change but too significant for a trivial patch, H
 
 ### Generate Spec Trace
 
-Set `{title}` = a concise title derived from the clarified intent.
+Set `title` = a concise title derived from the clarified intent.
 
 Write `{spec_file}` using `./spec-template.md`. Fill only these sections — delete all others:
 
@@ -49,7 +48,7 @@ Write `{spec_file}` using `./spec-template.md`. Fill only these sections — del
 2. **Title and Intent** — `# {title}` heading and `## Intent` with **Problem** and **Approach** lines. Reuse the summary you already generated for the terminal.
 3. **Suggested Review Order** — append after Intent. Build using the same convention as `./step-05-present.md` § "Generate Suggested Review Order" (spec-file-relative links, concern-based ordering, ultra-concise framing).
 
-Follow `./sync-sprint-status.md` with `{target_status}` = `review`.
+Follow `./sync-sprint-status.md` with `target_status` = `review`.
 
 ### Commit
 
@@ -74,6 +73,6 @@ Workflow complete.
 
 ## On Complete
 
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+If anything appears below, follow it as the final terminal instruction before exiting; otherwise exit normally.
 
-If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.
+{workflow.on_complete}

package/src/bmm-skills/4-implementation/bmad-quick-dev/sync-sprint-status.md

@@ -1,19 +1,19 @@
 # Sync Sprint Status
 
-Shared sub-step for updating `sprint-status.yaml` during quick-dev. Called from any route (plan-code-review, one-shot, future routes) with a `{target_status}` parameter.
+Shared sub-step for updating `sprint-status.yaml` during quick-dev. Called from any route (plan-code-review, one-shot, future routes) with a `target_status` parameter.
 
 ## Preconditions
 
 Skip this entire file (return to caller) if ANY of:
-- `{story_key}` is unset
-- `{sprint_status}` does not exist on disk
+- `story_key` is unset
+- `{{.sprint_status}}` does not exist on disk
 
 ## Instructions
 
-1. Load the FULL `{sprint_status}` file.
+1. Load the FULL `{{.sprint_status}}` file.
 2. Find the `development_status` entry matching `{story_key}`. If not found, warn the user once (`"{story_key} not found in sprint-status; skipping sprint sync"`) and return to caller.
-3. **Idempotency check.** If `development_status[{story_key}]` is already at `{target_status}` or a later state (`review` is later than `in-progress`; `done` is later than both), return to caller — no write needed. Never regress a story's status.
+3. **Idempotency check.** If `development_status[{story_key}]` is already at `target_status` or a later state (`review` is later than `in-progress`; `done` is later than both), return to caller — no write needed. Never regress a story's status.
 4. Set `development_status[{story_key}]` to `{target_status}`.
-5. **Epic lift (only when `{target_status}` = `in-progress`).** Derive the parent epic key as `epic-{N}` from the leading numeric segment of `{story_key}` (e.g., `3-2-digest-delivery` → `epic-3`). If that entry exists and is `backlog`, set it to `in-progress`. Leave it alone otherwise. Skip this sub-step entirely when `{target_status}` is not `in-progress`.
+5. **Epic lift (only when `target_status` = `in-progress`).** Derive the parent epic key as `epic-{N}` from the leading numeric segment of `{story_key}` (e.g., `3-2-digest-delivery` → `epic-3`). If that entry exists and is `backlog`, set it to `in-progress`. Leave it alone otherwise. Skip this sub-step entirely when `target_status` is not `in-progress`.
 6. Refresh `last_updated` to the current date.
 7. Save the file, preserving ALL comments and structure including STATUS DEFINITIONS and WORKFLOW NOTES.

package/src/bmm-skills/4-implementation/bmad-quick-dev/workflow.md

@@ -0,0 +1,85 @@
+# Quick Dev New Preview Workflow
+
+**Goal:** Turn user intent into a hardened, reviewable artifact.
+
+**CRITICAL:** If a step says "read fully and follow step-XX", you read and follow step-XX. No exceptions.
+
+Subagents, when the capability is available, are an important part of this workflow. Use them as directed by the workflow steps.
+If you need an explicit user instruction to run them, ask once now for the whole workflow run.
+
+## READY FOR DEVELOPMENT STANDARD
+
+A specification is "Ready for Development" when:
+
+- **Actionable**: Every task has a file path and specific action.
+- **Logical**: Tasks ordered by dependency.
+- **Testable**: All ACs use Given/When/Then.
+- **Complete**: No placeholders or TBDs.
+- **Sufficient**: No known requirement, acceptance, dependency, or implementation gaps remain unresolved.
+- **Coherent**: No unresolved ambiguities or internal contradictions.
+
+## SCOPE STANDARD
+
+A specification should target a **single user-facing goal** within **900–1600 tokens**:
+
+- **Single goal**: One cohesive feature, even if it spans multiple layers/files. Multi-goal means >=2 **top-level independent shippable deliverables** — each could be reviewed, tested, and merged as a separate PR without breaking the others. Never count surface verbs, "and" conjunctions, or noun phrases. Never split cross-layer implementation details inside one user goal.
+  - Split: "add dark mode toggle AND refactor auth to JWT AND build admin dashboard"
+  - Don't split: "add validation and display errors" / "support drag-and-drop AND paste AND retry"
+- **900–1600 tokens**: Optimal range for LLM consumption. Below 900 risks ambiguity; above 1600 risks context-rot in implementation agents.
+- **Neither limit is a gate.** Both are proposals with user override.
+
+## Conventions
+
+- Bare paths (e.g. `step-01-clarify-and-route.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: Execute Prepend Steps
+
+Execute each of these steps in order before proceeding (`_None._` means skip):
+
+{workflow.activation_steps_prepend}
+
+### Step 2: Load Persistent Facts
+
+Treat every entry below 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 (`_None._` means none):
+
+{workflow.persistent_facts}
+
+### Step 3: Execute Append Steps
+
+Execute each of these steps in order (`_None._` means skip):
+
+{workflow.activation_steps_append}
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+- **Micro-file Design**: Each step is self-contained and followed exactly
+- **Just-In-Time Loading**: Only load the current step file
+- **Sequential Enforcement**: Complete steps in order, no skipping
+- **State Tracking**: Persist progress via spec frontmatter and in-memory variables
+- **Append-Only Building**: Build artifacts incrementally
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Read the entire step file before acting
+2. **FOLLOW SEQUENCE**: Execute sections in order
+3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
+4. **LOAD NEXT**: When directed, read fully and follow the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- **NEVER** load multiple step files simultaneously
+- **ALWAYS** read entire step file before execution
+- **NEVER** skip steps or optimize the sequence
+- **ALWAYS** follow the exact instructions in the step file
+- **ALWAYS** halt at checkpoints and wait for human input
+
+## FIRST STEP
+
+Read fully and follow: `./step-01-clarify-and-route.md` to begin the workflow.

package/src/bmm-skills/module-help.csv

@@ -3,16 +3,14 @@ BMad Method,_meta,,,,,,,,,false,https://docs.bmad-method.org/llms.txt,
 BMad Method,bmad-document-project,Document Project,DP,Analyze an existing project to produce useful documentation.,,,anytime,,,false,project-knowledge,*
 BMad Method,bmad-generate-project-context,Generate Project Context,GPC,Scan existing codebase to generate a lean LLM-optimized project-context.md. Essential for brownfield projects.,,,anytime,,,false,output_folder,project context
 BMad Method,bmad-quick-dev,Quick Dev,QQ,Unified intent-in code-out workflow: clarify plan implement review and present.,,,anytime,,,false,implementation_artifacts,spec and project implementation
+BMad Method,bmad-spec,Spec,SPC,"Use to distill any intent input (brief, PRD, transcript, brain dump, design folder, mixed multi-source) into a succinct, no-fluff SPEC.md contract + companions that downstream work derives from. Locks the WHAT before the HOW. Works for software, game design, research, editorial, policy, business, anything intent-bearing. Validation mode also available.",,[path],anytime,,,false,{output_folder}/specs/spec-{slug},SPEC.md + companion files
 BMad Method,bmad-correct-course,Correct Course,CC,Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories.,,,anytime,,,false,planning_artifacts,change proposal
 BMad Method,bmad-agent-tech-writer,Write Document,WD,"Describe in detail what you want, and the agent will follow documentation best practices. Multi-turn conversation with subprocess for research/review.",write,,anytime,,,false,project-knowledge,document
 BMad Method,bmad-agent-tech-writer,Update Standards,US,Update agent memory documentation-standards.md with your specific preferences if you discover missing document conventions.,update-standards,,anytime,,,false,_bmad/_memory/tech-writer-sidecar,standards
 BMad Method,bmad-agent-tech-writer,Mermaid Generate,MG,Create a Mermaid diagram based on user description. Will suggest diagram types if not specified.,mermaid,,anytime,,,false,planning_artifacts,mermaid diagram
 BMad Method,bmad-agent-tech-writer,Validate Document,VD,Review the specified document against documentation standards and best practices. Returns specific actionable improvement suggestions organized by priority.,validate,[path],anytime,,,false,planning_artifacts,validation report
 BMad Method,bmad-agent-tech-writer,Explain Concept,EC,Create clear technical explanations with examples and diagrams for complex concepts.,explain,[topic],anytime,,,false,project_knowledge,explanation
-BMad Method,bmad-brainstorming,Brainstorm Project,BP,Expert guided facilitation through a single or multiple techniques.,,,1-analysis,,,false,planning_artifacts,brainstorming session
-BMad Method,bmad-market-research,Market Research,MR,Market analysis competitive landscape customer needs and trends.,,,1-analysis,,,false,planning_artifacts|project-knowledge,research documents
-BMad Method,bmad-domain-research,Domain Research,DR,Industry domain deep dive subject matter expertise and terminology.,,,1-analysis,,,false,planning_artifacts|project_knowledge,research documents
-BMad Method,bmad-technical-research,Technical Research,TR,Technical feasibility architecture options and implementation approaches.,,,1-analysis,,,false,planning_artifacts|project_knowledge,research documents
+BMad Method,bmad-brainstorming,Brainstorm Project,BP,Expert guided facilitation through a single or multiple techniques.,,,1-analysis,,,false,{output_folder}/brainstorming,brainstorming session
 BMad Method,bmad-product-brief,Create Brief,CB,An expert guided experience to nail down your product idea in a brief. a gentler approach than PRFAQ when you are already sure of your concept and nothing will sway you.,,-A,1-analysis,,,false,planning_artifacts,product brief
 BMad Method,bmad-prfaq,PRFAQ Challenge,WB,Working Backwards guided experience to forge and stress-test your product concept to ensure you have a great product that users will love and need through the PRFAQ gauntlet to determine feasibility and alignment with user needs. alternative to product brief.,,-H,1-analysis,,,false,planning_artifacts,prfaq document
 BMad Method,bmad-prd,Create Edit and Review PRD,PRD,"Facilitated PRD workflow — create a new PRD via coached discovery, update an existing one against a change signal, or validate a finished PRD against a checklist with an HTML findings report.",,,2-planning,bmad-product-brief,,true,planning_artifacts,prd

package/src/bmm-skills/module.yaml

@@ -40,11 +40,8 @@ project_knowledge: # Artifacts from research, document-project output, other lon
   default: "docs"
   result: "{project-root}/{value}"
 
-# Directories to create during installation (declarative, no code execution)
-directories:
-  - "{planning_artifacts}"
-  - "{implementation_artifacts}"
-  - "{project_knowledge}"
+# No pre-created directories: planning_artifacts, implementation_artifacts, and
+# project_knowledge are created lazily by whichever skill first writes to them.
 
 # Agent roster — essence only. External skills (party-mode, retrospective,
 # advanced-elicitation, help catalog) read these descriptors to route, display,

package/src/bmm-skills/v6-shims/README.md

@@ -0,0 +1,24 @@
+# v6 Deprecation Shims
+
+Skills in this folder are forwarders kept for backward compatibility with v6 skill IDs.
+Each one holds no logic of its own — it forwards to the skill that replaced it, passing a
+stated intent and pre-resolved customization fields so the target skips its own intent
+inference.
+
+| Shim                       | Forwards to                          |
+| -------------------------- | ------------------------------------ |
+| `bmad-create-prd`          | `bmad-prd` (create intent)           |
+| `bmad-edit-prd`            | `bmad-prd` (update intent)           |
+| `bmad-validate-prd`        | `bmad-prd` (validate intent)         |
+| `bmad-create-architecture` | `bmad-architecture` (create intent)  |
+| `bmad-market-research`     | `bmad-deep-recon` (market type)      |
+| `bmad-domain-research`     | `bmad-deep-recon` (domain type)      |
+| `bmad-technical-research`  | `bmad-deep-recon` (technical type)   |
+
+Enterprise users may still depend on these IDs, so they ship by default. Removal rides the
+v7 cut — never a 6.x minor.
+
+The folder is grouping only: the installer discovers skills recursively and installs each
+one under its own `name`, so nesting here does not change any installed path or skill ID.
+A future install option will let users include or exclude this folder before it is removed
+outright.

package/src/bmm-skills/{3-solutioning → v6-shims}/bmad-create-architecture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bmad-create-architecture
-description: 'DEPRECATED — consolidated into bmad-architecture create intent - this skill will be removed in v7 in favor of `bmad-architecture`.'
+description: 'Deprecated — forwards to bmad-architecture (create intent).'
 ---
 
 # DEPRECATED — forwards to bmad-architecture (create intent)

package/src/bmm-skills/{2-plan-workflows → v6-shims}/bmad-create-prd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bmad-create-prd
-description: 'DEPRECATED — consolidated into bmad-prd create intent - this skill will be removed in v7 in favor of `bmad-prd`.'
+description: 'Deprecated — forwards to bmad-prd (create intent).'
 ---
 
 # DEPRECATED — forwards to bmad-prd (create intent)
@@ -15,12 +15,12 @@ This skill was consolidated into `bmad-prd`. It is retained as a thin compatibil
 
 3. Emit a deprecation notice to the user in `{communication_language}`:
 
-   > Notice: `bmad-create-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with create intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist`, `doc_standards`, `external_sources`, `external_handoffs`, `output_dir`, `output_folder_name`), migrate `_bmad/custom/bmad-create-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
+   > Notice: `bmad-create-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with create intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist_template`, `validation_report_template`, `doc_standards`, `finalize_reviewers`, `external_sources`, `external_handoffs`, `prd_output_path`, `run_folder_pattern`), migrate `_bmad/custom/bmad-create-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
 
 4. Invoke `bmad-prd` with the following context. Pass these as the activating context so `bmad-prd` honors them instead of resolving its own customization from scratch:
 
    - **Intent:** `create` — skip `bmad-prd`'s usual intent detection step.
-   - **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist`, `validation_report_template`, `doc_standards`, `output_dir`, `output_folder_name`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
+   - **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist_template`, `validation_report_template`, `doc_standards`, `finalize_reviewers`, `prd_output_path`, `run_folder_pattern`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
      - `activation_steps_prepend` = the resolved value from step 1
      - `activation_steps_append` = the resolved value from step 1
      - `persistent_facts` = the resolved value from step 1

package/src/bmm-skills/v6-shims/bmad-domain-research/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: bmad-domain-research
+description: 'Deprecated — forwards to bmad-deep-recon (domain type).'
+---
+
+# DEPRECATED — forwards to bmad-deep-recon (domain type)
+
+This skill was consolidated into `bmad-deep-recon`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-domain-research.toml` override files keep working. New work should invoke `bmad-deep-recon` directly — it drafts deep-research prompts for outside tools, processes finished reports into downstream-ready summaries, and runs research directly, across market, domain, technical, competitive, user-voice, and academic-lit types (plus a select shape for choose-between decisions and custom types).
+
+## On Activation
+
+1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-domain-research.toml` and `bmad-domain-research.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+2. Emit a deprecation notice to the user (in their configured communication language): `bmad-domain-research` is deprecated and forwards to `bmad-deep-recon` with the domain type. To silence this notice and access the full new surface (draft/process/run modes, research types, verification levels, HTML briefing, handoffs), migrate `_bmad/custom/bmad-domain-research.toml` to `_bmad/custom/bmad-deep-recon.toml` and invoke `bmad-deep-recon` directly.
+3. Invoke `bmad-deep-recon` with: **research type** `domain` (skip its type inference), the four legacy fields above as pre-resolved values, and the user's original input verbatim. `bmad-deep-recon` takes the workflow from here — do not execute any further steps in this shim.

package/src/bmm-skills/{2-plan-workflows → v6-shims}/bmad-edit-prd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bmad-edit-prd
-description: 'DEPRECATED — consolidated into bmad-prd update intent - this skill will be removed in v7 in favor of `bmad-prd`.'
+description: 'Deprecated — forwards to bmad-prd (update intent).'
 ---
 
 # DEPRECATED — forwards to bmad-prd (update intent)
@@ -15,12 +15,12 @@ This skill was consolidated into `bmad-prd`. It is retained as a thin compatibil
 
 3. Emit a deprecation notice to the user in `{communication_language}`:
 
-   > Notice: `bmad-edit-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with update intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist`, `doc_standards`, `external_sources`, `external_handoffs`, `output_dir`, `output_folder_name`), migrate `_bmad/custom/bmad-edit-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
+   > Notice: `bmad-edit-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with update intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist_template`, `validation_report_template`, `doc_standards`, `finalize_reviewers`, `external_sources`, `external_handoffs`, `prd_output_path`, `run_folder_pattern`), migrate `_bmad/custom/bmad-edit-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
 
 4. Invoke `bmad-prd` with the following context. Pass these as the activating context so `bmad-prd` honors them instead of resolving its own customization from scratch:
 
    - **Intent:** `update` — skip `bmad-prd`'s usual intent detection step.
-   - **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist`, `validation_report_template`, `doc_standards`, `output_dir`, `output_folder_name`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
+   - **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist_template`, `validation_report_template`, `doc_standards`, `finalize_reviewers`, `prd_output_path`, `run_folder_pattern`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
      - `activation_steps_prepend` = the resolved value from step 1
      - `activation_steps_append` = the resolved value from step 1
      - `persistent_facts` = the resolved value from step 1

package/src/bmm-skills/v6-shims/bmad-market-research/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: bmad-market-research
+description: 'Deprecated — forwards to bmad-deep-recon (market type).'
+---
+
+# DEPRECATED — forwards to bmad-deep-recon (market type)
+
+This skill was consolidated into `bmad-deep-recon`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-market-research.toml` override files keep working. New work should invoke `bmad-deep-recon` directly — it drafts deep-research prompts for outside tools, processes finished reports into downstream-ready summaries, and runs research directly, across market, domain, technical, competitive, user-voice, and academic-lit types (plus a select shape for choose-between decisions and custom types).
+
+## On Activation
+
+1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-market-research.toml` and `bmad-market-research.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+2. Emit a deprecation notice to the user (in their configured communication language): `bmad-market-research` is deprecated and forwards to `bmad-deep-recon` with the market type. To silence this notice and access the full new surface (draft/process/run modes, research types, verification levels, HTML briefing, handoffs), migrate `_bmad/custom/bmad-market-research.toml` to `_bmad/custom/bmad-deep-recon.toml` and invoke `bmad-deep-recon` directly.
+3. Invoke `bmad-deep-recon` with: **research type** `market` (skip its type inference), the four legacy fields above as pre-resolved values, and the user's original input verbatim. `bmad-deep-recon` takes the workflow from here — do not execute any further steps in this shim.

package/src/bmm-skills/v6-shims/bmad-technical-research/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: bmad-technical-research
+description: 'Deprecated — forwards to bmad-deep-recon (technical type).'
+---
+
+# DEPRECATED — forwards to bmad-deep-recon (technical type)
+
+This skill was consolidated into `bmad-deep-recon`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-technical-research.toml` override files keep working. New work should invoke `bmad-deep-recon` directly — it drafts deep-research prompts for outside tools, processes finished reports into downstream-ready summaries, and runs research directly, across market, domain, technical, competitive, user-voice, and academic-lit types (plus a select shape for choose-between decisions and custom types).
+
+## On Activation
+
+1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-technical-research.toml` and `bmad-technical-research.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+2. Emit a deprecation notice to the user (in their configured communication language): `bmad-technical-research` is deprecated and forwards to `bmad-deep-recon` with the technical type. To silence this notice and access the full new surface (draft/process/run modes, research types, verification levels, HTML briefing, handoffs), migrate `_bmad/custom/bmad-technical-research.toml` to `_bmad/custom/bmad-deep-recon.toml` and invoke `bmad-deep-recon` directly.
+3. Invoke `bmad-deep-recon` with: **research type** `technical` (skip its type inference), the four legacy fields above as pre-resolved values, and the user's original input verbatim. `bmad-deep-recon` takes the workflow from here — do not execute any further steps in this shim.

package/src/bmm-skills/{2-plan-workflows → v6-shims}/bmad-validate-prd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bmad-validate-prd
-description: 'DEPRECATED — consolidated into bmad-prd validate intent - this skill will be removed in v7 in favor of `bmad-prd`.'
+description: 'Deprecated — forwards to bmad-prd (validate intent).'
 ---
 
 # DEPRECATED — forwards to bmad-prd (validate intent)
@@ -15,12 +15,12 @@ This skill was consolidated into `bmad-prd`. It is retained as a thin compatibil
 
 3. Emit a deprecation notice to the user in `{communication_language}`:
 
-   > Notice: `bmad-validate-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with validate intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist`, `doc_standards`, `external_sources`, `external_handoffs`, `output_dir`, `output_folder_name`), migrate `_bmad/custom/bmad-validate-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
+   > Notice: `bmad-validate-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with validate intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist_template`, `validation_report_template`, `doc_standards`, `finalize_reviewers`, `external_sources`, `external_handoffs`, `prd_output_path`, `run_folder_pattern`), migrate `_bmad/custom/bmad-validate-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
 
 4. Invoke `bmad-prd` with the following context. Pass these as the activating context so `bmad-prd` honors them instead of resolving its own customization from scratch:
 
    - **Intent:** `validate` — skip `bmad-prd`'s usual intent detection step.
-   - **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist`, `validation_report_template`, `doc_standards`, `output_dir`, `output_folder_name`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
+   - **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist_template`, `validation_report_template`, `doc_standards`, `finalize_reviewers`, `prd_output_path`, `run_folder_pattern`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
      - `activation_steps_prepend` = the resolved value from step 1
      - `activation_steps_append` = the resolved value from step 1
      - `persistent_facts` = the resolved value from step 1

package/src/core-skills/bmad-advanced-elicitation/SKILL.md

@@ -5,72 +5,39 @@ description: 'Push the LLM to reconsider, refine, and improve its recent output.
 
 # Advanced Elicitation
 
-**Goal:** Push the LLM to reconsider, refine, and improve its recent output.
+You are BMad's shared refinement checkpoint: other skills invoke you at natural pauses to pressure the piece of work they just produced, and users call you directly on anything recent. The target is the most recent output in the conversation — a section, plan, draft, or decision — unless the caller or user points at something else. You offer a short menu of elicitation methods, run the chosen ones against the target, and hand back the improved version so the invoking flow resumes exactly where it paused. Work in the surrounding session's communication language.
 
----
-
-## CRITICAL LLM INSTRUCTIONS
+## Conventions
 
-- **MANDATORY:** Execute ALL steps in the flow section IN EXACT ORDER
-- DO NOT skip steps or change the sequence
-- HALT immediately when halt-conditions are met
-- Each action within a step is a REQUIRED action to complete that step
-- Sections outside flow (validation, output, critical-context) provide essential context - review and apply throughout execution
-- **YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the `communication_language`**
-
----
+- Bare paths (e.g. `assets/methods.csv`) resolve from `{skill-root}` (where `customize.toml` lives); `{project-root}`-prefixed paths from the project working directory.
+- `{workflow.<name>}` resolves to fields in the merged `customize.toml` `[workflow]` table.
 
-## INTEGRATION (When Invoked Indirectly)
+## On Activation
 
-When invoked from another prompt or process:
-
-1. Receive or review the current section content that was just generated
-2. Apply elicitation methods iteratively to enhance that specific content
-3. Return the enhanced version back when user selects 'x' to proceed and return back
-4. The enhanced content replaces the original section content in the output document
-
----
+1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly and use defaults.
+2. Hold every `{workflow.preferences}` entry for the whole session, fix the target, and serve the first menu.
 
-## FLOW
+## Serving the Catalog
 
-### Step 1: Method Registry Loading
-
-**Action:** Load `./methods.csv` for elicitation methods. If party-mode may participate, resolve the agent roster via:
+`scripts/pick_methods.py` serves the method catalog (num, category, method_name, description, output_pattern) so it never enters context whole — the one exception is [a], where the user asked for all of it. Invoke as:
 
 ```bash
-python3 {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key agents
+uv run {skill-root}/scripts/pick_methods.py --file {workflow.methods_file} <command>
 ```
 
-The resolver merges four layers in order: `_bmad/config.toml` (installer base, team-scoped), `_bmad/config.user.toml` (installer base, user-scoped), `_bmad/custom/config.toml` (team overrides), and `_bmad/custom/config.user.toml` (personal overrides). Each entry under `agents` is keyed by the agent's `code` and carries `name`, `title`, `icon`, `description`, `module`, and `team`.
-
-#### CSV Structure
-
-- **category:** Method grouping (core, structural, risk, etc.)
-- **method_name:** Display name for the method
-- **description:** Rich explanation of what the method does, when to use it, and why it's valuable
-- **output_pattern:** Flexible flow guide using arrows (e.g., "analysis -> insights -> action")
-
-#### Context Analysis
-
-- Use conversation history
-- Analyze: content type, complexity, stakeholder needs, risk level, and creative potential
-
-#### Smart Selection
+If `{workflow.additional_methods}` is non-empty, add `--extra '<its entries as a JSON array>'` (or a path to a JSON file holding them) on every call, so custom methods are first-class in menus, reshuffles, and listings.
 
-1. Analyze context: Content type, complexity, stakeholder needs, risk level, creative potential
-2. Parse descriptions: Understand each method's purpose from the rich descriptions in CSV
-3. Select 5 methods: Choose methods that best match the context based on their descriptions
-4. Balance approach: Include mix of foundational and specialized techniques as appropriate
+- `categories` — category names + counts, the cheap map.
+- `list --category <cat> [--category <cat>]` — the index for chosen categories; `--all` dumps the whole catalog, only for [a].
+- `show <name-or-num> [...]` — full rows by name or num.
+- `random -n 5 --spread [--exclude <name>]...` — a category-diverse random draw.
 
----
-
-### Step 2: Present Options and Handle Responses
+**First menu:** run `categories`, pick the 2–4 categories that fit the target (risk before a launch, technical for code, collaboration when stakeholders compete, creative when the content is flat), `list` them, and hand-pick five methods that attack the target from different angles — honoring `{workflow.preferences}`. **Reshuffle:** `random -n 5 --spread`, excluding everything already offered.
 
-#### Display Format
+## The Menu
 
 ```
 **Advanced Elicitation Options**
-_If party mode is active, agents will join in._
 Choose a number (1-5), [r] to Reshuffle, [a] List All, or [x] to Proceed:
 
 1. [Method Name]
@@ -83,60 +50,16 @@ a. List all methods with descriptions
 x. Proceed / No Further Actions
 ```
 
-#### Response Handling
-
-**Case 1-5 (User selects a numbered method):**
-
-- Execute the selected method using its description from the CSV
-- Adapt the method's complexity and output format based on the current context
-- Apply the method creatively to the current section content being enhanced
-- Display the enhanced version showing what the method revealed or improved
-- **CRITICAL:** Ask the user if they would like to apply the changes to the doc (y/n/other) and HALT to await response.
-- **CRITICAL:** ONLY if Yes, apply the changes. IF No, discard your memory of the proposed changes. If any other reply, try best to follow the instructions given by the user.
-- **CRITICAL:** Re-present the same 1-5,r,x prompt to allow additional elicitations
-
-**Case r (Reshuffle):**
-
-- Select 5 random methods from methods.csv, present new list with same prompt format
-- When selecting, try to think and pick a diverse set of methods covering different categories and approaches, with 1 and 2 being potentially the most useful for the document or section being discovered
-
-**Case x (Proceed):**
+This menu is the interface other skills and their users rely on — keep its options and behavior stable. When party mode is active in the session, add `_Party mode is active — agents will join in._` under the heading. Handle the response:
 
-- Complete elicitation and proceed
-- Return the fully enhanced content back to the invoking skill
-- The enhanced content becomes the final version for that section
-- Signal completion back to the invoking skill to continue with next section
+- **1–5** — run that method (several numbers: in sequence), then re-present the menu.
+- **r** — reshuffle as above and re-present.
+- **a** — show the full catalog (`list --all`) as a compact table; a pick by name or number runs like a numbered choice.
+- **x** — done. The current enhanced version is final for this content: hand it back to the invoking skill as the replacement for what it had, and signal completion so it continues. If anything shown was never accepted, confirm what should carry over before returning.
+- **Anything else** — treat as direction: apply it to the target and re-present the menu.
 
-**Case a (List All):**
+## Running a Method
 
-- List all methods with their descriptions from the CSV in a compact table
-- Allow user to select any method by name or number from the full list
-- After selection, execute the method as described in the Case 1-5 above
-
-**Case: Direct Feedback:**
-
-- Apply changes to current section content and re-present choices
-
-**Case: Multiple Numbers:**
-
-- Execute methods in sequence on the content, then re-offer choices
-
----
+Use the method's description as its intent and its output_pattern as a flexible flow guide; scale depth to the target — a paragraph gets a light pass, an architecture decision gets the full treatment. Each application works on the current enhanced version, so refinements compound. Show what the method revealed and the changes it proposes, then ask whether to apply them (y/n/other) and wait — never change the work without a yes; on no, drop the proposal entirely; any other reply is instruction to follow.
 
-### Step 3: Execution Guidelines
-
-- **Method execution:** Use the description from CSV to understand and apply each method
-- **Output pattern:** Use the pattern as a flexible guide (e.g., "paths -> evaluation -> selection")
-- **Dynamic adaptation:** Adjust complexity based on content needs (simple to sophisticated)
-- **Creative application:** Interpret methods flexibly based on context while maintaining pattern consistency
-- Focus on actionable insights
-- **Stay relevant:** Tie elicitation to specific content being analyzed (the current section from the document being created unless user indicates otherwise)
-- **Identify personas:** For single or multi-persona methods, clearly identify viewpoints, and use party members if available in memory already
-- **Critical loop behavior:** Always re-offer the 1-5,r,a,x choices after each method execution
-- Continue until user selects 'x' to proceed with enhanced content, confirm or ask the user what should be accepted from the session
-- Each method application builds upon previous enhancements
-- **Content preservation:** Track all enhancements made during elicitation
-- **Iterative enhancement:** Each selected method (1-5) should:
-  1. Apply to the current enhanced version of the content
-  2. Show the improvements made
-  3. Return to the prompt for additional elicitations or completion
+When a method casts personas (round tables, panels, debates), reuse party members already in the session if party mode is active; otherwise resolve installed agents on demand via `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key agents` (a four-layer merge of `_bmad/config.toml`, `config.user.toml`, and the two `_bmad/custom/` overrides; each entry keyed by agent code carries name, title, icon, description). If neither yields a fit, invent named viewpoints suited to the content.

package/src/core-skills/bmad-advanced-elicitation/customize.toml

@@ -0,0 +1,54 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-advanced-elicitation.
+#
+# Override files (not edited here):
+#   {project-root}/_bmad/custom/bmad-advanced-elicitation.toml         (team)
+#   {project-root}/_bmad/custom/bmad-advanced-elicitation.user.toml    (personal)
+
+[workflow]
+
+# --- Configurable below. Overrides merge per BMad structural rules: ---
+#   scalars: override wins • plain arrays: append
+#   arrays of tables keyed by `code`: matching key replaces, new keys append
+
+# The elicitation method catalog served by scripts/pick_methods.py
+# (columns: num,category,method_name,description,output_pattern). Swap the path
+# in team/user TOML to ship a different catalog. Kept `{skill-root}`-anchored so
+# it resolves regardless of the working directory (pick_methods.py is always
+# invoked with `--file {workflow.methods_file}`).
+methods_file = "{skill-root}/assets/methods.csv"
+
+# Persistent preferences the refiner honors for every session — methods to
+# favor or avoid, how pushback should land, house rules for applying changes.
+# Literal sentences; append-merges, so team and personal preferences both apply.
+#
+# Examples (set in team/user override TOML):
+#   preferences = [
+#     "Lead with a risk-category method for anything touching production systems.",
+#     "Never offer roleplay or persona methods.",
+#   ]
+preferences = []
+
+# Extra methods — and whole new categories — merged into the catalog without
+# editing the shipped CSV. Passed to pick_methods.py via --extra, so custom
+# methods are first-class in every menu, reshuffle, and listing.
+#
+# Two keys, two jobs — keep them aligned:
+#   `code` is only the TOML merge key across override layers: a personal entry
+#     with the same code replaces the team one; new codes append.
+#   `method_name` is the catalog identity: an entry whose method_name matches a
+#     shipped method replaces it (retune its description or pattern; it keeps
+#     the shipped num), others append with new nums.
+#   To override another layer's entry, reuse its `code`. Two entries with
+#     different codes but the same method_name both survive the TOML merge, and
+#     only the later one reaches the catalog.
+#
+# Example (set in team/user override TOML):
+#   [[workflow.additional_methods]]
+#   code = "regulatory-inversion"
+#   category = "domain-specific"
+#   method_name = "Regulatory Inversion"
+#   description = "Start from the compliance constraint and ask what becomes possible only because of it - turns the rule into a generative frame"
+#   output_pattern = "constraint → possibilities → design"
+additional_methods = []