bmad-method 6.10.1-next.8 → 6.11.0

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

@@ -0,0 +1,28 @@
+# v6 Deprecation Shims
+
+Skills in this folder are deprecated skills kept for backward compatibility with v6 skill IDs.
+Some retain their full workflow, while others forward to the skill that replaced them, passing a
+stated intent and pre-resolved customization fields so the target skips its own intent inference.
+
+| Shim                       | Forwards to                          |
+| -------------------------- | ------------------------------------ |
+| `bmad-quick-dev`           | `bmad-build`                         |
+| `bmad-dev-auto`            | `bmad-build-auto`                    |
+| `bmad-create-story`        | Retained in full                     |
+| `bmad-dev-story`           | Retained in full                     |
+| `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)   |
+| `bmad-sprint-status`       | `bmad-sprint-planning` (status view) |
+
+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)
@@ -9,7 +9,7 @@ This skill was consolidated into `bmad-architecture`. It is retained as a thin c
 
 ## On Activation
 
-1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-create-architecture.toml` and `bmad-create-architecture.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+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-create-architecture.toml` and `bmad-create-architecture.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
 
 2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
 

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)
@@ -9,18 +9,18 @@ This skill was consolidated into `bmad-prd`. It is retained as a thin compatibil
 
 ## On Activation
 
-1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-create-prd.toml` and `bmad-create-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+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-create-prd.toml` and `bmad-create-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
 
 2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
 
 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/{4-implementation → v6-shims}/bmad-create-story/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bmad-create-story
-description: 'Creates a dedicated story file with all the context the agent will need to implement it later. Use when the user says "create the next story" or "create story [story identifier]"'
+description: "Deprecated: `bmad-build` is now the official implementation method. Only use this when explicitly invoked by name."
 ---
 
 # Create Story Workflow
@@ -30,7 +30,7 @@ If you need an explicit user instruction to run them, ask once now for the whole
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+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:
 
@@ -62,6 +62,8 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 
 Greet `{user_name}`, speaking in `{communication_language}`.
 
+<output>Deprecated: `bmad-build` is now the official implementation method. Only use this when explicitly invoked by name.</output>
+
 ### Step 6: Execute Append Steps
 
 Execute each entry in `{workflow.activation_steps_append}` in order.
@@ -426,7 +428,7 @@ Activation is complete. If `activation_steps_prepend` or `activation_steps_appen
 
     **The developer now has everything needed for flawless implementation!**
   </output>
-  <action>Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
+  <action>Run: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
 </step>
 
 </workflow>

package/src/bmm-skills/v6-shims/bmad-dev-auto/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: bmad-dev-auto
+description: "Deprecated: forwards to bmad-build-auto. Do not use unless invoked by name."
+---
+
+# Deprecated Build Auto Alias
+
+## On Activation
+
+1. Check whether either legacy customization file exists:
+   - `{project-root}/_bmad/custom/bmad-dev-auto.toml`
+   - `{project-root}/_bmad/custom/bmad-dev-auto.user.toml`
+2. If neither legacy file exists, output exactly `bmad-dev-auto is deprecated. Redirecting to bmad-build-auto. Please use bmad-build-auto in the future.`, invoke `bmad-build-auto` exactly once with the user's original input verbatim, then execute no further steps in this shim.
+3. For every legacy file that exists, use its matching new filename:
+   - `{project-root}/_bmad/custom/bmad-dev-auto.toml` becomes `{project-root}/_bmad/custom/bmad-build-auto.toml`.
+   - `{project-root}/_bmad/custom/bmad-dev-auto.user.toml` becomes `{project-root}/_bmad/custom/bmad-build-auto.user.toml`.
+4. If the matching new file does not exist, tell the user that the customization file uses the deprecated name and offer to rename it. Rename it only after explicit approval. If approval is declined or unavailable, or the rename fails, HALT and do not invoke any skill.
+5. If the matching new file already exists, do not overwrite it. Read both files, explain their differences, and propose the exact content for the new file. Resolve conflicting values with the user. Only after the user explicitly approves that content, save and verify the new file, then remove the legacy file. If approval is declined or unavailable, or any operation fails, HALT and do not invoke any skill.
+6. After every detected legacy file has been migrated successfully and no legacy file remains, output exactly `bmad-dev-auto is deprecated. Redirecting to bmad-build-auto. Please use bmad-build-auto in the future.`, invoke `bmad-build-auto` exactly once with the user's original input verbatim, then execute no further steps in this shim.

package/src/bmm-skills/{4-implementation → v6-shims}/bmad-dev-story/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bmad-dev-story
-description: 'Execute story implementation following a context filled story spec file. Use when the user says "dev this story [story file]" or "implement the next story in the sprint plan"'
+description: "Deprecated: `bmad-build` is now the official implementation method. Only use this when explicitly invoked by name."
 ---
 
 # Dev Story Workflow
@@ -27,7 +27,7 @@ description: 'Execute story implementation following a context filled story spec
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+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:
 
@@ -60,6 +60,8 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 
 Greet `{user_name}`, speaking in `{communication_language}`.
 
+<output>Deprecated: `bmad-build` is now the official implementation method. Only use this when explicitly invoked by name.</output>
+
 ### Step 6: Execute Append Steps
 
 Execute each entry in `{workflow.activation_steps_append}` in order.
@@ -494,7 +496,7 @@ Activation is complete. If `activation_steps_prepend` or `activation_steps_appen
       <action>Suggest checking {sprint_status} to see project progress</action>
     </check>
     <action>Remain flexible - allow user to choose their own path or ask for other assistance</action>
-  <action>Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
+  <action>Run: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
   </step>
 
 </workflow>

package/src/bmm-skills/{4-implementation → v6-shims}/bmad-dev-story/customize.toml

@@ -32,6 +32,9 @@ activation_steps_append = []
 
 persistent_facts = [
   "file:{project-root}/**/project-context.md",
+  "Never add epic or story references as inline code comments (e.g. # Epic: X, # Story: PROJ-42).",
+  "Code comments explain why, not what — no AI workflow metadata, planning refs, or story tracking in source code.",
+  "Generated code must be production-ready: clean, minimal, and free of AI-generated noise.",
 ]
 
 # Scalar: executed when the workflow reaches its final step,

package/src/bmm-skills/v6-shims/bmad-document-project/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: bmad-document-project
+description: 'Deprecated — forwards to bmad-project-context. Use when the user says "document this project" or "generate project docs"'
+---
+
+# DEPRECATED — forwards to bmad-project-context
+
+Tell the user two things.
+
+First: this skill is deprecated. Generating documentation volume about a codebase made agents worse, not better — agents read code more accurately than prose describing code, and the generated set was stale on arrival. `bmad-project-context` owns what remains useful: a small verified block in the repo's `AGENTS.md` carrying what the code cannot say — required policy, conventions that differ from defaults, what running the project takes that no config file states, and known pitfalls.
+
+Second, so they are not surprised by what they get: the deeper "explain this system, its rationale and its history" material is a different altitude and is not part of that block. It is coming as its own capability. If that is what they were after, say so plainly rather than producing a thin substitute.
+
+Then invoke `bmad-project-context` with **setup** intent, forwarding the user's original request and any paths or documents they supplied, verbatim. It takes the workflow from here.

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)
@@ -9,18 +9,18 @@ This skill was consolidated into `bmad-prd`. It is retained as a thin compatibil
 
 ## On Activation
 
-1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-edit-prd.toml` and `bmad-edit-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+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-edit-prd.toml` and `bmad-edit-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
 
 2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
 
 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-quick-dev/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: bmad-quick-dev
+description: "Deprecated: forwards to bmad-build. Do not use unless invoked by name."
+---
+
+# Deprecated Build Alias
+
+## On Activation
+
+1. Check whether either legacy customization file exists:
+   - `{project-root}/_bmad/custom/bmad-quick-dev.toml`
+   - `{project-root}/_bmad/custom/bmad-quick-dev.user.toml`
+2. If neither legacy file exists, output exactly `bmad-quick-dev is deprecated. Redirecting to bmad-build. Please use bmad-build in the future.`, invoke `bmad-build` exactly once with the user's original input verbatim, then execute no further steps in this shim.
+3. For every legacy file that exists, use its matching new filename:
+   - `{project-root}/_bmad/custom/bmad-quick-dev.toml` becomes `{project-root}/_bmad/custom/bmad-build.toml`.
+   - `{project-root}/_bmad/custom/bmad-quick-dev.user.toml` becomes `{project-root}/_bmad/custom/bmad-build.user.toml`.
+4. If the matching new file does not exist, tell the user that the customization file uses the deprecated name and offer to rename it. Rename it only after explicit approval. If approval is declined or unavailable, or the rename fails, HALT and do not invoke any skill.
+5. If the matching new file already exists, do not overwrite it. Read both files, explain their differences, and propose the exact content for the new file. Resolve conflicting values with the user. Only after the user explicitly approves that content, save and verify the new file, then remove the legacy file. If approval is declined or unavailable, or any operation fails, HALT and do not invoke any skill.
+6. After every detected legacy file has been migrated successfully and no legacy file remains, output exactly `bmad-quick-dev is deprecated. Redirecting to bmad-build. Please use bmad-build in the future.`, invoke `bmad-build` exactly once with the user's original input verbatim, then execute no further steps in this shim.

package/src/bmm-skills/v6-shims/bmad-sprint-status/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: bmad-sprint-status
+description: 'Deprecated — forwards to bmad-sprint-planning (status view).'
+---
+
+# DEPRECATED — forwards to bmad-sprint-planning (status view)
+
+This skill was consolidated into `bmad-sprint-planning`, which now owns the whole sprint-status artifact: gate it, generate it, view it. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-sprint-status.toml` override files keep working. New work should invoke `bmad-sprint-planning` directly — "show sprint status" routes straight to the status view.
+
+## 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-sprint-status.toml` and `bmad-sprint-status.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+
+2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
+
+3. Emit a deprecation notice to the user in `{communication_language}`:
+
+   > Notice: `bmad-sprint-status` is deprecated and will be removed in a future release. It now forwards to `bmad-sprint-planning`, whose status view covers everything this skill did. To silence this notice, invoke `bmad-sprint-planning` directly next time (e.g. "show sprint status") and migrate any `_bmad/custom/bmad-sprint-status.toml` overrides to `_bmad/custom/bmad-sprint-planning.toml`.
+
+4. Invoke `bmad-sprint-planning` with the following context. Pass these as the activating context so it honors them instead of resolving its own customization from scratch:
+
+   - **Intent:** `status view` — skip `bmad-sprint-planning`'s usual intent detection and its readiness gate.
+   - **Pre-resolved legacy customization** — use these in place of resolving from `bmad-sprint-planning`'s own `customize.toml` for the four legacy fields: `activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, and `on_complete` = the resolved values from step 1.
+   - **Original user input:** forward whatever the user said when invoking this skill verbatim.
+
+   `bmad-sprint-planning` 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)
@@ -9,18 +9,18 @@ This skill was consolidated into `bmad-prd`. It is retained as a thin compatibil
 
 ## On Activation
 
-1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-validate-prd.toml` and `bmad-validate-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+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-validate-prd.toml` and `bmad-validate-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
 
 2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
 
 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 = []