bmad-method 6.1.1-next.9 → 6.2.0

package/src/{bmm/workflows/2-plan-workflows/create-prd → core/tasks/bmad-create-prd}/steps-c/step-09-functional.md

@@ -1,16 +1,3 @@
----
-name: 'step-09-functional'
-description: 'Synthesize all discovery into comprehensive functional requirements'
-
-# File References
-nextStepFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-10-nonfunctional.md'
-outputFile: '{planning_artifacts}/prd.md'
-
-# Task References
-advancedElicitationTask: 'skill:bmad-advanced-elicitation'
-partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'
----
-
 # Step 9: Functional Requirements Synthesis
 
 **Progress: Step 9 of 11** - Next: Non-Functional Requirements
@@ -26,6 +13,7 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow
 - 💬 FOCUS on creating comprehensive capability inventory for the product
 - 🎯 CRITICAL: This is THE CAPABILITY CONTRACT for all downstream work
 - ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
 
 ## EXECUTION PROTOCOLS:
 
@@ -181,9 +169,9 @@ Present the functional requirements for review, then display menu:
 Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Non-Functional Requirements (Step 10 of 11)"
 
 #### Menu Handling Logic:
-- IF A: Read fully and follow: {advancedElicitationTask} with the current FR list, process the enhanced capability coverage that comes back, ask user if they accept the additions, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF P: Read fully and follow: {partyModeWorkflow} with the current FR list, process the collaborative capability validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
+- IF A: Invoke the `bmad-advanced-elicitation` skill with the current FR list, process the enhanced capability coverage that comes back, ask user if they accept the additions, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF P: Invoke the `bmad-party-mode` skill with the current FR list, process the collaborative capability validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-10-nonfunctional.md
 - IF Any other: help user respond, then redisplay menu
 
 #### EXECUTION RULES:
@@ -226,6 +214,6 @@ Emphasize to user: "This FR list is now binding. Any feature not listed here wil
 
 ## NEXT STEP:
 
-After user selects 'C' and content is saved to document, load {nextStepFile} to define non-functional requirements.
+After user selects 'C' and content is saved to document, load ./step-10-nonfunctional.md to define non-functional requirements.
 
 Remember: Do NOT proceed to step-10 until user explicitly selects 'C' from the A/P/C menu and content is saved!

package/src/{bmm/workflows/2-plan-workflows/create-prd → core/tasks/bmad-create-prd}/steps-c/step-10-nonfunctional.md

@@ -1,16 +1,3 @@
----
-name: 'step-10-nonfunctional'
-description: 'Define quality attributes that matter for this specific product'
-
-# File References
-nextStepFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md'
-outputFile: '{planning_artifacts}/prd.md'
-
-# Task References
-advancedElicitationTask: 'skill:bmad-advanced-elicitation'
-partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'
----
-
 # Step 10: Non-Functional Requirements
 
 **Progress: Step 10 of 12** - Next: Polish Document
@@ -26,6 +13,7 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow
 - 💬 FOCUS on quality attributes that matter for THIS specific product
 - 🎯 SELECTIVE: Only document NFRs that actually apply to the product
 - ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
 
 ## EXECUTION PROTOCOLS:
 
@@ -168,9 +156,9 @@ Present the non-functional requirements for review, then display menu:
 Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Polish Document (Step 11 of 12)"
 
 #### Menu Handling Logic:
-- IF A: Read fully and follow: {advancedElicitationTask} with the current NFR content, process the enhanced quality attribute insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF P: Read fully and follow: {partyModeWorkflow} with the current NFR list, process the collaborative technical validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
-- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
+- IF A: Invoke the `bmad-advanced-elicitation` skill with the current NFR content, process the enhanced quality attribute insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF P: Invoke the `bmad-party-mode` skill with the current NFR list, process the collaborative technical validation and additions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
+- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-11-polish.md
 - IF Any other: help user respond, then redisplay menu
 
 #### EXECUTION RULES:
@@ -237,6 +225,6 @@ When user selects 'C', append the content directly to the document using the str
 
 ## NEXT STEP:
 
-After user selects 'C' and content is saved to document, load {nextStepFile} to finalize the PRD and complete the workflow.
+After user selects 'C' and content is saved to document, load ./step-11-polish.md to finalize the PRD and complete the workflow.
 
 Remember: Do NOT proceed to step-11 until user explicitly selects 'C' from the A/P/C menu and content is saved!

package/src/{bmm/workflows/2-plan-workflows/create-prd → core/tasks/bmad-create-prd}/steps-c/step-11-polish.md

@@ -1,17 +1,3 @@
----
-name: 'step-11-polish'
-description: 'Optimize and polish the complete PRD document for flow, coherence, and readability'
-
-# File References
-nextStepFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-12-complete.md'
-outputFile: '{planning_artifacts}/prd.md'
-purposeFile: '{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/data/prd-purpose.md'
-
-# Task References
-advancedElicitationTask: 'skill:bmad-advanced-elicitation'
-partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow.md'
----
-
 # Step 11: Document Polish
 
 **Progress: Step 11 of 12** - Next: Complete PRD
@@ -26,6 +12,7 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/bmad-party-mode/workflow
 - 💬 PRESERVE user's voice and intent
 - 🎯 MAINTAIN all essential information while improving presentation
 - ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
 
 ## EXECUTION PROTOCOLS:
 
@@ -55,7 +42,7 @@ Optimize the complete PRD document for flow, coherence, and professional present
 
 **CRITICAL:** Load the PRD purpose document first:
 
-- Read `{purposeFile}` to understand what makes a great BMAD PRD
+- Read `../data/prd-purpose.md` to understand what makes a great BMAD PRD
 - Internalize the philosophy: information density, traceability, measurable requirements
 - Keep the dual-audience nature (humans + LLMs) in mind
 
@@ -185,9 +172,9 @@ Present the polished document for review, then display menu:
 Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Complete PRD (Step 12 of 12)"
 
 #### Menu Handling Logic:
-- IF A: Read fully and follow: {advancedElicitationTask} with the polished document, process the enhanced refinements that come back, ask user "Accept these polish improvements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
-- IF P: Read fully and follow: {partyModeWorkflow} with the polished document, process the collaborative refinements to flow and coherence, ask user "Accept these polish changes? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
-- IF C: Save the polished document to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: {nextStepFile}
+- IF A: Invoke the `bmad-advanced-elicitation` skill with the polished document, process the enhanced refinements that come back, ask user "Accept these polish improvements? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
+- IF P: Invoke the `bmad-party-mode` skill with the polished document, process the collaborative refinements to flow and coherence, ask user "Accept these polish changes? (y/n)", if yes update content with improvements then redisplay menu, if no keep original polish then redisplay menu
+- IF C: Save the polished document to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-12-complete.md
 - IF Any other: help user respond, then redisplay menu
 
 #### EXECUTION RULES:
@@ -229,6 +216,6 @@ When user selects 'C', replace the entire document content with the polished ver
 
 ## NEXT STEP:
 
-After user selects 'C' and polished document is saved, load `{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-12-complete.md` to complete the workflow.
+After user selects 'C' and polished document is saved, load `./step-12-complete.md` to complete the workflow.
 
 Remember: Do NOT proceed to step-12 until user explicitly selects 'C' from the A/P/C menu and polished document is saved!

package/src/{bmm/workflows/2-plan-workflows/create-prd → core/tasks/bmad-create-prd}/steps-c/step-12-complete.md

@@ -1,12 +1,3 @@
----
-name: 'step-12-complete'
-description: 'Complete the PRD workflow, update status files, and suggest next steps including validation'
-
-# File References
-outputFile: '{planning_artifacts}/prd.md'
-validationFlow: '../steps-v/step-v-01-discovery.md'
----
-
 # Step 12: Workflow Completion
 
 **Final Step - Complete the PRD**
@@ -60,8 +51,8 @@ Inform user that the PRD is complete and polished:
 
 Update the main workflow status file if there is one:
 
-- Load `{status_file}` from workflow configuration (if exists)
-- Update workflow_status["prd"] = "{default_output_file}"
+- Check workflow configuration for a status file (if one exists)
+- Update workflow_status["prd"] = "{outputFile}"
 - Save file, preserving all comments and structure
 - Mark current timestamp as completion time
 
@@ -71,7 +62,7 @@ Offer validation workflows to ensure PRD is ready for implementation:
 
 **Available Validation Workflows:**
 
-**Option 1: Check Implementation Readiness** (`{checkImplementationReadinessWorkflow}`)
+**Option 1: Check Implementation Readiness** (`skill:bmad-check-implementation-readiness`)
 - Validates PRD has all information needed for development
 - Checks epic coverage completeness
 - Reviews UX alignment with requirements

package/src/{bmm/workflows/2-plan-workflows/create-prd/workflow-create-prd.md → core/tasks/bmad-create-prd/workflow.md}

@@ -1,8 +1,6 @@
 ---
-name: create-prd
-description: 'Create a PRD from scratch. Use when the user says "lets create a product requirements document" or "I want to create a new PRD"'
 main_config: '{project-root}/_bmad/bmm/config.yaml'
-nextStep: './steps-c/step-01-init.md'
+outputFile: '{planning_artifacts}/prd.md'
 ---
 
 # PRD Create Workflow
@@ -55,9 +53,10 @@ Load and read full config from {main_config} and resolve:
 - `date` as system-generated current datetime
 
 ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
+✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
 
 ### 2. Route to Create Workflow
 
 "**Create Mode: Creating a new PRD from scratch.**"
 
-Read fully and follow: `{nextStep}` (steps-c/step-01-init.md)
+Read fully and follow: `./steps-c/step-01-init.md`

package/tools/cli/external-official-modules.yaml

@@ -2,15 +2,15 @@
 # allowing us to keep the source of these projects in separate repos.
 
 modules:
-  # bmad-builder:
-  #   url: https://github.com/bmad-code-org/bmad-builder
-  #   module-definition: src/module.yaml
-  #   code: bmb
-  #   name: "BMad Builder"
-  #   description: "Agent, Workflow and Module Builder"
-  #   defaultSelected: false
-  #   type: bmad-org
-  #   npmPackage: bmad-builder
+  bmad-builder:
+    url: https://github.com/bmad-code-org/bmad-builder
+    module-definition: src/module.yaml
+    code: bmb
+    name: "BMad Builder"
+    description: "Agent and Builder"
+    defaultSelected: false
+    type: bmad-org
+    npmPackage: bmad-builder
 
   bmad-creative-intelligence-suite:
     url: https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite

package/tools/cli/installers/lib/core/manifest.js

@@ -267,9 +267,11 @@ class Manifest {
    * @param {Object} options - Optional version info
    */
   async addModule(bmadDir, moduleName, options = {}) {
-    const manifest = await this._readRaw(bmadDir);
+    let manifest = await this._readRaw(bmadDir);
     if (!manifest) {
-      throw new Error('No manifest found');
+      // Bootstrap a minimal manifest if it doesn't exist yet
+      // (e.g., skill-only modules with no agents to compile)
+      manifest = { modules: [] };
     }
 
     if (!manifest.modules) {

package/tools/skill-validator.md

@@ -0,0 +1,322 @@
+# Skill Validator — Inference-Based
+
+An LLM-readable validation prompt for skills following the Agent Skills open standard.
+
+## How to Use
+
+1. You are given a **skill directory path** to validate.
+2. Read every file in the skill directory recursively.
+3. Apply every rule in the catalog below to every applicable file.
+4. Produce a findings report using the report template at the end.
+
+If no findings are generated, the skill passes validation.
+
+---
+
+## Definitions
+
+- **Skill directory**: the folder containing `SKILL.md` and all supporting files.
+- **Internal reference**: a file path from one file in the skill to another file in the same skill.
+- **External reference**: a file path from a skill file to a file outside the skill directory.
+- **Originating file**: the file that contains the reference (path resolution is relative to this file's location).
+- **Config variable**: a name-value pair whose value comes from the project config file (e.g., `planning_artifacts`, `implementation_artifacts`, `communication_language`).
+- **Runtime variable**: a name-value pair whose value is set during workflow execution (e.g., `spec_file`, `date`, `status`).
+- **Intra-skill path variable**: a frontmatter variable whose value is a path to another file within the same skill — this is an anti-pattern.
+
+---
+
+## Rule Catalog
+
+### SKILL-01 — SKILL.md Must Exist
+
+- **Severity:** CRITICAL
+- **Applies to:** skill directory
+- **Rule:** The skill directory must contain a file named `SKILL.md` (exact case).
+- **Detection:** Check for the file's existence.
+- **Fix:** Create `SKILL.md` as the skill entrypoint.
+
+### SKILL-02 — SKILL.md Must Have `name` in Frontmatter
+
+- **Severity:** CRITICAL
+- **Applies to:** `SKILL.md`
+- **Rule:** The YAML frontmatter must contain a `name` field.
+- **Detection:** Parse the `---` delimited frontmatter block and check for `name:`.
+- **Fix:** Add `name: <skill-name>` to the frontmatter.
+
+### SKILL-03 — SKILL.md Must Have `description` in Frontmatter
+
+- **Severity:** CRITICAL
+- **Applies to:** `SKILL.md`
+- **Rule:** The YAML frontmatter must contain a `description` field.
+- **Detection:** Parse the `---` delimited frontmatter block and check for `description:`.
+- **Fix:** Add `description: '<what it does and when to use it>'` to the frontmatter.
+
+### SKILL-04 — `name` Format
+
+- **Severity:** HIGH
+- **Applies to:** `SKILL.md`
+- **Rule:** The `name` value must use only lowercase letters, numbers, and hyphens. Max 64 characters. Must not contain "anthropic" or "claude".
+- **Detection:** Regex test: `^[a-z0-9][a-z0-9-]{0,62}[a-z0-9]$`. String search for forbidden substrings.
+- **Fix:** Rename to comply with the format.
+
+### SKILL-05 — `name` Must Match Directory Name
+
+- **Severity:** HIGH
+- **Applies to:** `SKILL.md`
+- **Rule:** The `name` value in SKILL.md frontmatter must exactly match the skill directory name. The directory name is the canonical identifier used by installers, manifests, and `skill:` references throughout the project.
+- **Detection:** Compare the `name:` frontmatter value against the basename of the skill directory (i.e., the immediate parent directory of `SKILL.md`).
+- **Fix:** Change the `name:` value to match the directory name, or rename the directory to match — prefer changing `name:` unless other references depend on the current value.
+
+### SKILL-06 — `description` Quality
+
+- **Severity:** MEDIUM
+- **Applies to:** `SKILL.md`
+- **Rule:** The `description` must state both what the skill does AND when to use it. Max 1024 characters.
+- **Detection:** Check length. Look for trigger phrases like "Use when" or "Use if" — their absence suggests the description only says _what_ but not _when_.
+- **Fix:** Append a "Use when..." clause to the description.
+
+---
+
+### WF-01 — workflow.md Must NOT Have `name` in Frontmatter
+
+- **Severity:** HIGH
+- **Applies to:** `workflow.md` (if it exists)
+- **Rule:** The `name` field belongs only in `SKILL.md`. If `workflow.md` has YAML frontmatter, it must not contain `name:`.
+- **Detection:** Parse frontmatter and check for `name:` key.
+- **Fix:** Remove the `name:` line from workflow.md frontmatter.
+
+### WF-02 — workflow.md Must NOT Have `description` in Frontmatter
+
+- **Severity:** HIGH
+- **Applies to:** `workflow.md` (if it exists)
+- **Rule:** The `description` field belongs only in `SKILL.md`. If `workflow.md` has YAML frontmatter, it must not contain `description:`.
+- **Detection:** Parse frontmatter and check for `description:` key.
+- **Fix:** Remove the `description:` line from workflow.md frontmatter.
+
+### WF-03 — workflow.md Frontmatter Variables Must Be Config or Runtime Only
+
+- **Severity:** HIGH
+- **Applies to:** `workflow.md` frontmatter
+- **Rule:** Every variable defined in workflow.md frontmatter must be either:
+  - A config variable (value references `{project-root}` or a config-derived variable like `{planning_artifacts}`)
+  - A runtime variable (value is empty, a placeholder, or set during execution)
+  - A legitimate external path expression (must not violate PATH-05 — no paths into another skill's directory)
+
+  It must NOT be a path to a file within the skill directory (see PATH-04), nor a path into another skill's directory (see PATH-05).
+- **Detection:** For each frontmatter variable, check if its value resolves to a file inside the skill (e.g., starts with `./`, `{installed_path}`, or is a bare relative path to a sibling file). If so, it is an intra-skill path variable. Also check if the value is a path into another skill's directory — if so, it violates PATH-05 and is not a legitimate external path.
+- **Fix:** Remove the variable. Use a hardcoded relative path inline where the file is referenced.
+
+---
+
+### PATH-01 — Internal References Must Be Relative From Originating File
+
+- **Severity:** CRITICAL
+- **Applies to:** all files in the skill
+- **Rule:** Any reference from one file in the skill to another file in the same skill must be a relative path resolved from the directory of the originating file. Use `./` prefix for siblings or children, `../` for parent traversal. Bare relative filenames in markdown links (e.g., `[text](sibling.md)`) are also acceptable.
+- **Detection:** Scan for file path references (in markdown links, frontmatter values, inline backtick paths, and prose instructions like "Read fully and follow"). Verify each internal reference uses relative notation (`./`, `../`, or bare filename). Always resolve the path from the originating file's directory — a reference to `./steps/step-01.md` from a file already inside `steps/` would resolve to `steps/steps/step-01.md`, which is wrong.
+- **Examples:**
+  - CORRECT: `./steps/step-01-init.md` (from workflow.md at skill root to a step)
+  - CORRECT: `./template.md` (from workflow.md to a sibling)
+  - CORRECT: `../template.md` (from steps/step-01.md to a skill-root file)
+  - CORRECT: `workflow.md` (bare relative filename for sibling)
+  - CORRECT: `./step-02-plan.md` (from steps/step-01.md to a sibling step)
+  - WRONG: `./steps/step-02-plan.md` (from a file already inside steps/ — resolves to steps/steps/)
+  - WRONG: `{installed_path}/template.md`
+  - WRONG: `{project-root}/.claude/skills/my-skill/template.md`
+  - WRONG: `/Users/someone/.claude/skills/my-skill/steps/step-01.md`
+  - WRONG: `~/.claude/skills/my-skill/file.md`
+
+### PATH-02 — No `installed_path` Variable
+
+- **Severity:** HIGH
+- **Applies to:** all files in the skill
+- **Rule:** The `installed_path` variable is an anti-pattern from the pre-skill workflow era. It must not be defined in any frontmatter, and `{installed_path}` must not appear anywhere in any file.
+- **Detection:** Search all files for:
+  - Frontmatter key `installed_path:`
+  - String `{installed_path}` anywhere in content
+  - Markdown/prose assigning `installed_path` (e.g., `` `installed_path` = `.` ``)
+- **Fix:** Remove all `installed_path` definitions. Replace every `{installed_path}/path` with `./path` (relative from the file that contains the reference). If the reference is in a step file and points to a skill-root file, use `../path` instead.
+
+### PATH-03 — External References Must Use `{project-root}` or Config Variables
+
+- **Severity:** HIGH
+- **Applies to:** all files in the skill
+- **Rule:** References to files outside the skill directory must use `{project-root}/...` or a config-derived variable path (e.g., `{planning_artifacts}/...`, `{implementation_artifacts}/...`).
+- **Detection:** Identify file references that point outside the skill. Verify they start with `{project-root}` or a known config variable. Flag absolute paths, home-relative paths (`~/`), or bare paths that resolve outside the skill.
+- **Fix:** Replace with `{project-root}/...` or the appropriate config variable.
+
+### PATH-05 — No File Path References Into Another Skill
+
+- **Severity:** HIGH
+- **Applies to:** all files in the skill
+- **Rule:** A skill must never reference any file inside another skill's directory by file path. Skill directories are encapsulated — their internal files (steps, templates, checklists, data files, workflow.md) are private implementation details. The only valid way to reference another skill is via `skill:skill-name` syntax, which invokes the skill as a unit. Reaching into another skill to cherry-pick an internal file (e.g., a template, a step, or even its workflow.md) breaks encapsulation and creates fragile coupling that breaks when the target skill is moved or reorganized.
+- **Detection:** For each external file reference (frontmatter values, markdown links, inline paths), check whether the resolved path points into a directory that is or contains a skill (has a `SKILL.md`). Patterns to flag:
+  - `{project-root}/_bmad/.../other-skill/anything.md`
+  - `{project-root}/_bmad/.../other-skill/steps/...`
+  - `{project-root}/_bmad/.../other-skill/templates/...`
+  - References to old pre-conversion locations that were skill directories (e.g., `core/workflows/skill-name/` when the skill has since moved to `core/skills/skill-name/`)
+- **Fix:**
+  - If the intent is to invoke the other skill: replace with `skill:skill-name`.
+  - If the intent is to use a shared resource (template, data file): the resource should be extracted to a shared location outside both skills (e.g., `core/data/`, `bmm/data/`, or a config-referenced path) — not reached into from across skill boundaries.
+
+### PATH-04 — No Intra-Skill Path Variables
+
+- **Severity:** MEDIUM
+- **Applies to:** all files (frontmatter AND body content)
+- **Rule:** Variables must not store paths to files within the same skill. These paths should be hardcoded as relative paths inline where used. This applies to YAML frontmatter variables AND markdown body variable assignments (e.g., `` `template` = `./template.md` `` under a `### Paths` section).
+- **Detection:** For each variable with a path-like value — whether defined in frontmatter or in body text — determine if the target is inside the skill directory. Indicators: value starts with `./`, `../`, `{installed_path}`, or is a bare filename of a file that exists in the skill. Exclude variables whose values are prefixed with a config variable like `{planning_artifacts}`, `{implementation_artifacts}`, `{project-root}`, or other config-derived paths — these are external references and are legitimate.
+- **Fix:** Remove the variable. Replace each `{variable_name}` usage with the direct relative path.
+- **Exception:** If a path variable is used in 4+ locations across multiple files and the path is non-trivial, a variable MAY be acceptable. Flag it as LOW instead and note the exception.
+
+---
+
+### STEP-01 — Step File Naming
+
+- **Severity:** MEDIUM
+- **Applies to:** files in `steps/` directory
+- **Rule:** Step files must be named `step-NN-description.md` where NN is a zero-padded two-digit number. An optional single-letter variant suffix is allowed for branching steps (e.g., `step-01b-continue.md`).
+- **Detection:** Regex: `^step-\d{2}[a-z]?-[a-z0-9-]+\.md$`
+- **Fix:** Rename to match the pattern.
+
+### STEP-02 — Step Must Have a Goal Section
+
+- **Severity:** HIGH
+- **Applies to:** step files
+- **Rule:** Each step must clearly state its goal. Look for a heading like `## YOUR TASK`, `## STEP GOAL`, `## INSTRUCTIONS`, `## INITIALIZATION`, `## EXECUTION`, `# Step N:`, or a frontmatter `goal:` field.
+- **Detection:** Scan for goal-indicating headings (including `# Step N: Title` as a top-level heading that names the step's purpose) or frontmatter.
+- **Fix:** Add a clear goal section.
+
+### STEP-03 — Step Must Reference Next Step
+
+- **Severity:** MEDIUM
+- **Applies to:** step files (except the final step)
+- **Rule:** Each non-terminal step must contain a reference to the next step file for sequential execution.
+- **Detection:** Look for `## NEXT` section or inline reference to a next step file. Remember to resolve the reference from the originating file's directory (PATH-01 applies here too).
+- **Fix:** Add a `## NEXT` section with the relative path to the next step.
+- **Note:** A terminal step is one that has no next-step reference and either contains completion/finalization language or is the highest-numbered step. If a workflow branches, there may be multiple terminal steps.
+
+### STEP-04 — Halt Before Menu
+
+- **Severity:** HIGH
+- **Applies to:** step files
+- **Rule:** Any step that presents a user menu (e.g., `[C] Continue`, `[A] Approve`, `[S] Split`) must explicitly HALT and wait for user response before proceeding.
+- **Detection:** Find menu patterns (bracketed letter options). Check that text within the same section (under the same heading) includes "HALT", "wait", "stop", "FORBIDDEN to proceed", or equivalent.
+- **Fix:** Add an explicit HALT instruction before or after the menu.
+
+### STEP-05 — No Forward Loading
+
+- **Severity:** HIGH
+- **Applies to:** step files
+- **Rule:** A step must not load or read future step files until the current step is complete. Just-in-time loading only.
+- **Detection:** Look for instructions to read multiple step files simultaneously, or unconditional references to step files with higher numbers than the current step. Exempt locations: `## NEXT` sections, navigation/dispatch sections that list valid resumption targets, and conditional routing branches.
+- **Fix:** Remove premature step loading. Ensure only the current step is active.
+
+### STEP-06 — Step File Frontmatter: No `name` or `description`
+
+- **Severity:** MEDIUM
+- **Applies to:** step files
+- **Rule:** Step files should not have `name:` or `description:` in their YAML frontmatter. These are metadata noise — the step's purpose is conveyed by its goal section and filename.
+- **Detection:** Parse step file frontmatter for `name:` or `description:` keys.
+- **Fix:** Remove `name:` and `description:` from step file frontmatter.
+
+### STEP-07 — Step Count
+
+- **Severity:** LOW
+- **Applies to:** workflow as a whole
+- **Rule:** A sharded workflow should have between 2 and 10 step files. More than 10 risks LLM context degradation.
+- **Detection:** Count files matching `step-*.md` in the `steps/` directory.
+- **Fix:** Consider consolidating steps if over 10.
+
+---
+
+### SEQ-01 — No Skip Instructions
+
+- **Severity:** HIGH
+- **Applies to:** all files
+- **Rule:** No file should instruct the agent to skip steps or optimize step order. Sequential execution is mandatory.
+- **Detection:** Scan for phrases like "skip to step", "jump to step", "skip ahead", "optimize the order", "you may skip". Exclude negation context (e.g., "do NOT skip steps", "NEVER skip") — these are enforcement instructions, not skip instructions.
+- **Exception:** Conditional routing (e.g., "if X, go to step N; otherwise step M") is valid workflow branching, not skipping.
+
+### SEQ-02 — No Time Estimates
+
+- **Severity:** LOW
+- **Applies to:** all files
+- **Rule:** Workflow files should not include time estimates. AI execution speed varies too much for estimates to be meaningful.
+- **Detection:** Scan for patterns like "takes X minutes", "~N min", "estimated time", "ETA".
+- **Fix:** Remove time estimates.
+
+---
+
+### REF-01 — Variable References Must Be Defined
+
+- **Severity:** HIGH
+- **Applies to:** all files
+- **Rule:** Every `{variable_name}` reference in any file (body text, frontmatter values, inline instructions) must resolve to a defined source. Valid sources are:
+  1. A frontmatter variable in the same file
+  2. A frontmatter variable in the skill's `workflow.md` (workflow-level variables are available to all steps)
+  3. A known config variable from the project config (e.g., `project-root`, `planning_artifacts`, `implementation_artifacts`, `communication_language`)
+  4. A known runtime variable set during execution (e.g., `date`, `status`, `project_name`, user-provided input variables)
+- **Detection:** Collect all `{...}` tokens in the file. For each, check whether it is defined in the file's own frontmatter, in `workflow.md` frontmatter, or is a recognized config/runtime variable. Flag any token that cannot be traced to a source. Use the config variable list from the project's `config.yaml` as the reference for recognized config variables. Runtime variables are those explicitly described as user-provided or set during execution in the workflow instructions.
+- **Exceptions:**
+  - Double-curly `{{variable}}` — these are template placeholders intended to survive into generated output (e.g., `{{project_name}}` in a template file). Do not flag these.
+  - Variables inside fenced code blocks that are clearly illustrative examples.
+- **Fix:** Either define the variable in the appropriate frontmatter, or replace the reference with a literal value. If the variable is a config variable that was misspelled, correct the spelling.
+
+### REF-02 — File References Must Resolve
+
+- **Severity:** HIGH
+- **Applies to:** all files
+- **Rule:** All file path references within the skill (markdown links, backtick paths, frontmatter values) should point to files that plausibly exist.
+- **Detection:** For internal references, verify the target file exists in the skill directory. For external references using config variables, verify the path structure is plausible (you cannot resolve config variables, but you can check that the path after the variable looks reasonable — e.g., `{planning_artifacts}/*.md` is plausible, `{planning_artifacts}/../../etc/passwd` is not).
+- **Fix:** Correct the path or remove the dead reference.
+
+### REF-03 — Skill Invocation Must Use "Invoke" Language
+
+- **Severity:** HIGH
+- **Applies to:** all files
+- **Rule:** When a skill references another skill by name, the surrounding instruction must use the word "invoke". The canonical form is `Invoke the \`skill-name\` skill`. Phrases like "Read fully and follow", "Execute", "Run", "Load", "Open", or "Follow" are invalid — they imply file-level operations on a document, not skill invocation. A skill is a unit that is invoked, not a file that is read.
+- **Detection:** Find all references to other skills by name (typically backtick-quoted skill names like \`bmad-foo\`). Check the surrounding instruction text (same sentence or directive) for file-oriented verbs: "read", "follow", "load", "execute", "run", "open". Flag any that do not use "invoke" (or a close synonym like "activate" or "launch").
+- **Fix:** Replace the instruction with `Invoke the \`skill-name\` skill`. Remove any "read fully and follow" or similar file-oriented phrasing. Do NOT add a `skill:` prefix to the name — use natural language.
+
+---
+
+## Report Template
+
+When reporting findings, use this format:
+
+```markdown
+# Skill Validation Report: {skill-name}
+
+**Directory:** {path}
+**Date:** {date}
+**Files scanned:** {count}
+
+## Summary
+
+| Severity | Count |
+|----------|-------|
+| CRITICAL | N |
+| HIGH     | N |
+| MEDIUM   | N |
+| LOW      | N |
+
+## Findings
+
+### {RULE-ID} — {Rule Title}
+
+- **Severity:** {severity}
+- **File:** `{relative-path-within-skill}`
+- **Line:** {line number or range, if identifiable}
+- **Detail:** {what was found}
+- **Fix:** {specific fix for this instance}
+
+---
+
+(repeat for each finding, grouped by rule ID)
+
+## Passed Rules
+
+(list rule IDs that produced no findings)
+```
+
+If zero findings: report "All {N} rules passed. No findings." and list all passed rule IDs.

package/src/bmm/workflows/1-analysis/research/bmad-skill-manifest.yaml

@@ -1,9 +0,0 @@
-workflow-market-research.md:
-  canonicalId: bmad-market-research
-  type: workflow
-  description: "Conduct market research on competition and customers. Use when the user says 'create a market research report about [business idea]'"
-
-workflow-technical-research.md:
-  canonicalId: bmad-technical-research
-  type: workflow
-  description: "Conduct technical research on technologies and architecture. Use when the user says 'create a technical research report on [topic]'"

package/src/bmm/workflows/2-plan-workflows/create-prd/bmad-skill-manifest.yaml

@@ -1,14 +0,0 @@
-workflow-create-prd.md:
-  canonicalId: bmad-create-prd
-  type: workflow
-  description: "Create a PRD from scratch. Use when the user says 'lets create a product requirements document' or 'I want to create a new PRD'"
-
-workflow-edit-prd.md:
-  canonicalId: bmad-edit-prd
-  type: workflow
-  description: "Edit an existing PRD. Use when the user says 'edit this PRD'"
-
-workflow-validate-prd.md:
-  canonicalId: bmad-validate-prd
-  type: workflow
-  description: "Validate a PRD against standards. Use when the user says 'validate this PRD' or 'run PRD validation'"

package/src/bmm/workflows/3-solutioning/check-implementation-readiness/bmad-skill-manifest.yaml

@@ -1,3 +0,0 @@
-canonicalId: bmad-check-implementation-readiness
-type: workflow
-description: "Validate PRD, UX, Architecture and Epics specs are complete"

package/src/bmm/workflows/3-solutioning/create-epics-and-stories/bmad-skill-manifest.yaml

@@ -1,3 +0,0 @@
-canonicalId: bmad-create-epics-and-stories
-type: workflow
-description: "Break requirements into epics and user stories"

package/src/bmm/workflows/4-implementation/code-review/bmad-skill-manifest.yaml

@@ -1,3 +0,0 @@
-canonicalId: bmad-code-review
-type: workflow
-description: "Perform adversarial code review finding specific issues"

package/src/bmm/workflows/4-implementation/code-review/checklist.md

@@ -1,23 +0,0 @@
-# Senior Developer Review - Validation Checklist
-
-- [ ] Story file loaded from `{{story_path}}`
-- [ ] Story Status verified as reviewable (review)
-- [ ] Epic and Story IDs resolved ({{epic_num}}.{{story_num}})
-- [ ] Story Context located or warning recorded
-- [ ] Epic Tech Spec located or warning recorded
-- [ ] Architecture/standards docs loaded (as available)
-- [ ] Tech stack detected and documented
-- [ ] MCP doc search performed (or web fallback) and references captured
-- [ ] Acceptance Criteria cross-checked against implementation
-- [ ] File List reviewed and validated for completeness
-- [ ] Tests identified and mapped to ACs; gaps noted
-- [ ] Code quality review performed on changed files
-- [ ] Security review performed on changed files and dependencies
-- [ ] Outcome decided (Approve/Changes Requested/Blocked)
-- [ ] Review notes appended under "Senior Developer Review (AI)"
-- [ ] Change Log updated with review entry
-- [ ] Status updated according to settings (if enabled)
-- [ ] Sprint status synced (if sprint tracking enabled)
-- [ ] Story saved successfully
-
-_Reviewer: {{user_name}} on {{date}}_