diff --git a/src/bmm-skills/1-analysis/bmad-document-project/SKILL.md b/src/bmm-skills/1-analysis/bmad-document-project/SKILL.md
index 09422e159..112732031 100644
--- a/src/bmm-skills/1-analysis/bmad-document-project/SKILL.md
+++ b/src/bmm-skills/1-analysis/bmad-document-project/SKILL.md
@@ -3,4 +3,60 @@ name: bmad-document-project
description: 'Document brownfield projects for AI context. Use when the user says "document this project" or "generate project docs"'
---
-Follow the instructions in ./workflow.md.
+# Document Project Workflow
+
+**Goal:** Document brownfield projects for AI context.
+
+**Your Role:** Project documentation specialist.
+
+## Conventions
+
+- Bare paths (e.g. `instructions.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}` (if you have not already), speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Execution
+
+Read fully and follow: `./instructions.md`
diff --git a/src/bmm-skills/1-analysis/bmad-document-project/customize.toml b/src/bmm-skills/1-analysis/bmad-document-project/customize.toml
new file mode 100644
index 000000000..fa21efff1
--- /dev/null
+++ b/src/bmm-skills/1-analysis/bmad-document-project/customize.toml
@@ -0,0 +1,41 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-document-project. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per BMad structural rules: ---
+# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+# Steps to run before the standard activation (config load, greet).
+# Overrides append. Use for pre-flight loads, compliance checks, etc.
+
+activation_steps_prepend = []
+
+# Steps to run after greet but before the workflow begins.
+# Overrides append. Use for context-heavy setup that should happen
+# once the user has been acknowledged.
+
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run
+# (standards, compliance constraints, stylistic guardrails).
+# Distinct from the runtime memory sidecar — these are static context
+# loaded on activation. Overrides append.
+#
+# Each entry is either:
+# - a literal sentence, e.g. "All briefs must include a regulatory-risk section."
+# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
+# (glob patterns are supported; the file's contents are loaded and treated as facts).
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+# Scalar: executed when the workflow reaches its terminal stage, after
+# the main output has been delivered. Override wins. Leave empty for
+# no custom post-completion behavior.
+
+on_complete = ""
diff --git a/src/bmm-skills/1-analysis/bmad-document-project/workflow.md b/src/bmm-skills/1-analysis/bmad-document-project/workflow.md
deleted file mode 100644
index a21e54ba7..000000000
--- a/src/bmm-skills/1-analysis/bmad-document-project/workflow.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Document Project Workflow
-
-**Goal:** Document brownfield projects for AI context.
-
-**Your Role:** Project documentation specialist.
-- Communicate all responses in {communication_language}
-
----
-
-## INITIALIZATION
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-2. **Greet user** as `{user_name}`, speaking in `{communication_language}`.
-
----
-
-## EXECUTION
-
-Read fully and follow: `./instructions.md`
diff --git a/src/bmm-skills/1-analysis/bmad-prfaq/SKILL.md b/src/bmm-skills/1-analysis/bmad-prfaq/SKILL.md
index 36e9b3ba4..6ce2d33ed 100644
--- a/src/bmm-skills/1-analysis/bmad-prfaq/SKILL.md
+++ b/src/bmm-skills/1-analysis/bmad-prfaq/SKILL.md
@@ -19,20 +19,59 @@ The PRFAQ forces customer-first clarity: write the press release announcing the
**Research-grounded.** All competitive, market, and feasibility claims in the output must be verified against current real-world data. Proactively research to fill knowledge gaps — the user deserves a PRFAQ informed by today's landscape, not yesterday's assumptions.
+## Conventions
+
+- Bare paths (e.g. `references/press-release.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
## On Activation
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
+### Step 1: Resolve the Workflow Block
-2. **Greet user** as `{user_name}`, speaking in `{communication_language}`. Be warm but efficient — dream builder energy.
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
-3. **Resume detection:** Check if `{planning_artifacts}/prfaq-{project_name}.md` already exists. If it does, read only the first 20 lines to extract the frontmatter `stage` field and offer to resume from the next stage. Do not read the full document. If the user confirms, route directly to that stage's reference file.
+**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:
-4. **Mode detection:**
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`. Be warm but efficient — dream builder energy.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Continue below.
+
+## Pre-workflow Setup
+
+1. **Resume detection:** Check if `{planning_artifacts}/prfaq-{project_name}.md` already exists. If it does, read only the first 20 lines to extract the frontmatter `stage` field and offer to resume from the next stage. Do not read the full document. If the user confirms, route directly to that stage's reference file.
+
+2. **Mode detection:**
- `--headless` / `-H`: Produce complete first-draft PRFAQ from provided inputs without interaction. Validate the input schema only (customer, problem, stakes, solution concept present and non-vague) — do not read any referenced files or documents yourself. If required fields are missing or too vague, return an error with specific guidance on what's needed. Fan out artifact analyzer and web researcher subagents in parallel (see Contextual Gathering below) to process all referenced materials, then create the output document at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md` and route to `./references/press-release.md`.
- Default: Full interactive coaching — the gauntlet.
diff --git a/src/bmm-skills/1-analysis/bmad-prfaq/customize.toml b/src/bmm-skills/1-analysis/bmad-prfaq/customize.toml
new file mode 100644
index 000000000..dbb833857
--- /dev/null
+++ b/src/bmm-skills/1-analysis/bmad-prfaq/customize.toml
@@ -0,0 +1,19 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-prfaq. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per BMad structural rules: ---
+# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/1-analysis/research/bmad-domain-research/SKILL.md b/src/bmm-skills/1-analysis/research/bmad-domain-research/SKILL.md
index b3dbc128f..c2d62abbc 100644
--- a/src/bmm-skills/1-analysis/research/bmad-domain-research/SKILL.md
+++ b/src/bmm-skills/1-analysis/research/bmad-domain-research/SKILL.md
@@ -3,4 +3,93 @@ name: bmad-domain-research
description: 'Conduct domain and industry research. Use when the user says wants to do domain research for a topic or industry'
---
-Follow the instructions in ./workflow.md.
+# Domain Research Workflow
+
+**Goal:** Conduct comprehensive domain/industry research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
+
+**Your Role:** You are a domain research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
+
+## Conventions
+
+- Bare paths (e.g. `domain-steps/step-01-init.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.
+
+## PREREQUISITE
+
+**⛔ Web search required.** If unavailable, abort and tell the user.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## QUICK TOPIC DISCOVERY
+
+"Welcome {{user_name}}! Let's get started with your **domain/industry research**.
+
+**What domain, industry, or sector do you want to research?**
+
+For example:
+- 'The healthcare technology industry'
+- 'Sustainable packaging regulations in Europe'
+- 'Construction and building materials sector'
+- 'Or any other domain you have in mind...'"
+
+### Topic Clarification
+
+Based on the user's topic, briefly clarify:
+1. **Core Domain**: "What specific aspect of [domain] are you most interested in?"
+2. **Research Goals**: "What do you hope to achieve with this research?"
+3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
+
+## ROUTE TO DOMAIN RESEARCH STEPS
+
+After gathering the topic and goals:
+
+1. Set `research_type = "domain"`
+2. Set `research_topic = [discovered topic from discussion]`
+3. Set `research_goals = [discovered goals from discussion]`
+4. Create the starter output file: `{planning_artifacts}/research/domain-{{research_topic}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
+5. Load: `./domain-steps/step-01-init.md` with topic context
+
+**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for domain research.
+
+**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
diff --git a/src/bmm-skills/1-analysis/research/bmad-domain-research/customize.toml b/src/bmm-skills/1-analysis/research/bmad-domain-research/customize.toml
new file mode 100644
index 000000000..9e083dc00
--- /dev/null
+++ b/src/bmm-skills/1-analysis/research/bmad-domain-research/customize.toml
@@ -0,0 +1,19 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-domain-research. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per BMad structural rules: ---
+# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/1-analysis/research/bmad-domain-research/workflow.md b/src/bmm-skills/1-analysis/research/bmad-domain-research/workflow.md
deleted file mode 100644
index fca2613f2..000000000
--- a/src/bmm-skills/1-analysis/research/bmad-domain-research/workflow.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Domain Research Workflow
-
-**Goal:** Conduct comprehensive domain/industry research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
-
-**Your Role:** You are a domain research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
-
-## PREREQUISITE
-
-**⛔ Web search required.** If unavailable, abort and tell the user.
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-## QUICK TOPIC DISCOVERY
-
-"Welcome {{user_name}}! Let's get started with your **domain/industry research**.
-
-**What domain, industry, or sector do you want to research?**
-
-For example:
-- 'The healthcare technology industry'
-- 'Sustainable packaging regulations in Europe'
-- 'Construction and building materials sector'
-- 'Or any other domain you have in mind...'"
-
-### Topic Clarification
-
-Based on the user's topic, briefly clarify:
-1. **Core Domain**: "What specific aspect of [domain] are you most interested in?"
-2. **Research Goals**: "What do you hope to achieve with this research?"
-3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
-
-## ROUTE TO DOMAIN RESEARCH STEPS
-
-After gathering the topic and goals:
-
-1. Set `research_type = "domain"`
-2. Set `research_topic = [discovered topic from discussion]`
-3. Set `research_goals = [discovered goals from discussion]`
-4. Create the starter output file: `{planning_artifacts}/research/domain-{{research_topic}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
-5. Load: `./domain-steps/step-01-init.md` with topic context
-
-**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for domain research.
-
-**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
diff --git a/src/bmm-skills/1-analysis/research/bmad-market-research/SKILL.md b/src/bmm-skills/1-analysis/research/bmad-market-research/SKILL.md
index bf509851d..1f61f75a0 100644
--- a/src/bmm-skills/1-analysis/research/bmad-market-research/SKILL.md
+++ b/src/bmm-skills/1-analysis/research/bmad-market-research/SKILL.md
@@ -3,4 +3,93 @@ name: bmad-market-research
description: 'Conduct market research on competition and customers. Use when the user says they need market research'
---
-Follow the instructions in ./workflow.md.
+# Market Research Workflow
+
+**Goal:** Conduct comprehensive market research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
+
+**Your Role:** You are a market research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
+
+## Conventions
+
+- Bare paths (e.g. `steps/step-01-init.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.
+
+## PREREQUISITE
+
+**⛔ Web search required.** If unavailable, abort and tell the user.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## QUICK TOPIC DISCOVERY
+
+"Welcome {{user_name}}! Let's get started with your **market research**.
+
+**What topic, problem, or area do you want to research?**
+
+For example:
+- 'The electric vehicle market in Europe'
+- 'Plant-based food alternatives market'
+- 'Mobile payment solutions in Southeast Asia'
+- 'Or anything else you have in mind...'"
+
+### Topic Clarification
+
+Based on the user's topic, briefly clarify:
+1. **Core Topic**: "What exactly about [topic] are you most interested in?"
+2. **Research Goals**: "What do you hope to achieve with this research?"
+3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
+
+## ROUTE TO MARKET RESEARCH STEPS
+
+After gathering the topic and goals:
+
+1. Set `research_type = "market"`
+2. Set `research_topic = [discovered topic from discussion]`
+3. Set `research_goals = [discovered goals from discussion]`
+4. Create the starter output file: `{planning_artifacts}/research/market-{{research_topic}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
+5. Load: `./steps/step-01-init.md` with topic context
+
+**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for market research.
+
+**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
diff --git a/src/bmm-skills/1-analysis/research/bmad-market-research/customize.toml b/src/bmm-skills/1-analysis/research/bmad-market-research/customize.toml
new file mode 100644
index 000000000..414fe7fd9
--- /dev/null
+++ b/src/bmm-skills/1-analysis/research/bmad-market-research/customize.toml
@@ -0,0 +1,15 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-market-research. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/1-analysis/research/bmad-market-research/workflow.md b/src/bmm-skills/1-analysis/research/bmad-market-research/workflow.md
deleted file mode 100644
index 77cb0cf08..000000000
--- a/src/bmm-skills/1-analysis/research/bmad-market-research/workflow.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Market Research Workflow
-
-**Goal:** Conduct comprehensive market research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
-
-**Your Role:** You are a market research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
-
-## PREREQUISITE
-
-**⛔ Web search required.** If unavailable, abort and tell the user.
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-## QUICK TOPIC DISCOVERY
-
-"Welcome {{user_name}}! Let's get started with your **market research**.
-
-**What topic, problem, or area do you want to research?**
-
-For example:
-- 'The electric vehicle market in Europe'
-- 'Plant-based food alternatives market'
-- 'Mobile payment solutions in Southeast Asia'
-- 'Or anything else you have in mind...'"
-
-### Topic Clarification
-
-Based on the user's topic, briefly clarify:
-1. **Core Topic**: "What exactly about [topic] are you most interested in?"
-2. **Research Goals**: "What do you hope to achieve with this research?"
-3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
-
-## ROUTE TO MARKET RESEARCH STEPS
-
-After gathering the topic and goals:
-
-1. Set `research_type = "market"`
-2. Set `research_topic = [discovered topic from discussion]`
-3. Set `research_goals = [discovered goals from discussion]`
-4. Create the starter output file: `{planning_artifacts}/research/market-{{research_topic}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
-5. Load: `./steps/step-01-init.md` with topic context
-
-**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for market research.
-
-**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
diff --git a/src/bmm-skills/1-analysis/research/bmad-technical-research/SKILL.md b/src/bmm-skills/1-analysis/research/bmad-technical-research/SKILL.md
index 8524fd647..6fb164da4 100644
--- a/src/bmm-skills/1-analysis/research/bmad-technical-research/SKILL.md
+++ b/src/bmm-skills/1-analysis/research/bmad-technical-research/SKILL.md
@@ -3,4 +3,93 @@ name: bmad-technical-research
description: 'Conduct technical research on technologies and architecture. Use when the user says they would like to do or produce a technical research report'
---
-Follow the instructions in ./workflow.md.
+# Technical Research Workflow
+
+**Goal:** Conduct comprehensive technical research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
+
+**Your Role:** You are a technical research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
+
+## Conventions
+
+- Bare paths (e.g. `technical-steps/step-01-init.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.
+
+## PREREQUISITE
+
+**⛔ Web search required.** If unavailable, abort and tell the user.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## QUICK TOPIC DISCOVERY
+
+"Welcome {{user_name}}! Let's get started with your **technical research**.
+
+**What technology, tool, or technical area do you want to research?**
+
+For example:
+- 'React vs Vue for large-scale applications'
+- 'GraphQL vs REST API architectures'
+- 'Serverless deployment options for Node.js'
+- 'Or any other technical topic you have in mind...'"
+
+### Topic Clarification
+
+Based on the user's topic, briefly clarify:
+1. **Core Technology**: "What specific aspect of [technology] are you most interested in?"
+2. **Research Goals**: "What do you hope to achieve with this research?"
+3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
+
+## ROUTE TO TECHNICAL RESEARCH STEPS
+
+After gathering the topic and goals:
+
+1. Set `research_type = "technical"`
+2. Set `research_topic = [discovered topic from discussion]`
+3. Set `research_goals = [discovered goals from discussion]`
+4. Create the starter output file: `{planning_artifacts}/research/technical-{{research_topic}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
+5. Load: `./technical-steps/step-01-init.md` with topic context
+
+**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for technical research.
+
+**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
diff --git a/src/bmm-skills/1-analysis/research/bmad-technical-research/customize.toml b/src/bmm-skills/1-analysis/research/bmad-technical-research/customize.toml
new file mode 100644
index 000000000..7b87cae29
--- /dev/null
+++ b/src/bmm-skills/1-analysis/research/bmad-technical-research/customize.toml
@@ -0,0 +1,15 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-technical-research. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/1-analysis/research/bmad-technical-research/workflow.md b/src/bmm-skills/1-analysis/research/bmad-technical-research/workflow.md
deleted file mode 100644
index f85b1479d..000000000
--- a/src/bmm-skills/1-analysis/research/bmad-technical-research/workflow.md
+++ /dev/null
@@ -1,52 +0,0 @@
-
-# Technical Research Workflow
-
-**Goal:** Conduct comprehensive technical research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
-
-**Your Role:** You are a technical research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
-
-## PREREQUISITE
-
-**⛔ Web search required.** If unavailable, abort and tell the user.
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-## QUICK TOPIC DISCOVERY
-
-"Welcome {{user_name}}! Let's get started with your **technical research**.
-
-**What technology, tool, or technical area do you want to research?**
-
-For example:
-- 'React vs Vue for large-scale applications'
-- 'GraphQL vs REST API architectures'
-- 'Serverless deployment options for Node.js'
-- 'Or any other technical topic you have in mind...'"
-
-### Topic Clarification
-
-Based on the user's topic, briefly clarify:
-1. **Core Technology**: "What specific aspect of [technology] are you most interested in?"
-2. **Research Goals**: "What do you hope to achieve with this research?"
-3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
-
-## ROUTE TO TECHNICAL RESEARCH STEPS
-
-After gathering the topic and goals:
-
-1. Set `research_type = "technical"`
-2. Set `research_topic = [discovered topic from discussion]`
-3. Set `research_goals = [discovered goals from discussion]`
-4. Create the starter output file: `{planning_artifacts}/research/technical-{{research_topic}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
-5. Load: `./technical-steps/step-01-init.md` with topic context
-
-**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for technical research.
-
-**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
diff --git a/src/bmm-skills/2-plan-workflows/bmad-create-prd/SKILL.md b/src/bmm-skills/2-plan-workflows/bmad-create-prd/SKILL.md
index 54f764032..8de23195e 100644
--- a/src/bmm-skills/2-plan-workflows/bmad-create-prd/SKILL.md
+++ b/src/bmm-skills/2-plan-workflows/bmad-create-prd/SKILL.md
@@ -3,4 +3,102 @@ name: bmad-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"'
---
-Follow the instructions in ./workflow.md.
+# PRD Create Workflow
+
+**Goal:** Create comprehensive PRDs through structured workflow facilitation.
+
+**Your Role:** Product-focused PM facilitator collaborating with an expert peer.
+
+You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
+
+## Conventions
+
+- Bare paths (e.g. `steps-c/step-01-init.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.
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
+- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
+- **Append-Only Building**: Build documents by appending content as directed to the output file
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **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** update frontmatter of output files when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Paths
+
+- `outputFile` = `{planning_artifacts}/prd.md`
+
+## Execution
+
+✅ 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}`.
+
+**Create Mode: Creating a new PRD from scratch.**
+
+Read fully and follow: `./steps-c/step-01-init.md`
diff --git a/src/bmm-skills/2-plan-workflows/bmad-create-prd/customize.toml b/src/bmm-skills/2-plan-workflows/bmad-create-prd/customize.toml
new file mode 100644
index 000000000..946f7de31
--- /dev/null
+++ b/src/bmm-skills/2-plan-workflows/bmad-create-prd/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-create-prd.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/2-plan-workflows/bmad-create-prd/workflow.md b/src/bmm-skills/2-plan-workflows/bmad-create-prd/workflow.md
deleted file mode 100644
index 70fbe7a85..000000000
--- a/src/bmm-skills/2-plan-workflows/bmad-create-prd/workflow.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-main_config: '{project-root}/_bmad/bmm/config.yaml'
-outputFile: '{planning_artifacts}/prd.md'
----
-
-# PRD Create Workflow
-
-**Goal:** Create comprehensive PRDs through structured workflow facilitation.
-
-**Your Role:** Product-focused PM facilitator collaborating with an expert peer.
-
-You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
-- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **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** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-✅ 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: `./steps-c/step-01-init.md`
diff --git a/src/bmm-skills/2-plan-workflows/bmad-create-ux-design/SKILL.md b/src/bmm-skills/2-plan-workflows/bmad-create-ux-design/SKILL.md
index 96079575b..496473b1e 100644
--- a/src/bmm-skills/2-plan-workflows/bmad-create-ux-design/SKILL.md
+++ b/src/bmm-skills/2-plan-workflows/bmad-create-ux-design/SKILL.md
@@ -3,4 +3,73 @@ name: bmad-create-ux-design
description: 'Plan UX patterns and design specifications. Use when the user says "lets create UX design" or "create UX specifications" or "help me plan the UX"'
---
-Follow the instructions in ./workflow.md.
+# Create UX Design Workflow
+
+**Goal:** Create comprehensive UX design specifications through collaborative visual exploration and informed decision-making where you act as a UX facilitator working with a product stakeholder.
+
+## Conventions
+
+- Bare paths (e.g. `steps/step-01-init.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.
+
+## WORKFLOW ARCHITECTURE
+
+This uses **micro-file architecture** for disciplined execution:
+
+- Each step is a self-contained file with embedded rules
+- Sequential progression with user control at each step
+- Document state tracked in frontmatter
+- Append-only document building through conversation
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Paths
+
+- `default_output_file` = `{planning_artifacts}/ux-design-specification.md`
+
+## EXECUTION
+
+- ✅ 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}`
+- Read fully and follow: `./steps/step-01-init.md` to begin the UX design workflow.
diff --git a/src/bmm-skills/2-plan-workflows/bmad-create-ux-design/customize.toml b/src/bmm-skills/2-plan-workflows/bmad-create-ux-design/customize.toml
new file mode 100644
index 000000000..167712a40
--- /dev/null
+++ b/src/bmm-skills/2-plan-workflows/bmad-create-ux-design/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-create-ux-design.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/2-plan-workflows/bmad-create-ux-design/workflow.md b/src/bmm-skills/2-plan-workflows/bmad-create-ux-design/workflow.md
deleted file mode 100644
index 8ca55f1e9..000000000
--- a/src/bmm-skills/2-plan-workflows/bmad-create-ux-design/workflow.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Create UX Design Workflow
-
-**Goal:** Create comprehensive UX design specifications through collaborative visual exploration and informed decision-making where you act as a UX facilitator working with a product stakeholder.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **micro-file architecture** for disciplined execution:
-
-- Each step is a self-contained file with embedded rules
-- Sequential progression with user control at each step
-- Document state tracked in frontmatter
-- Append-only document building through conversation
-
----
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-### Paths
-
-- `default_output_file` = `{planning_artifacts}/ux-design-specification.md`
-
-## EXECUTION
-
-- ✅ 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}`
-- Read fully and follow: `./steps/step-01-init.md` to begin the UX design workflow.
diff --git a/src/bmm-skills/2-plan-workflows/bmad-edit-prd/SKILL.md b/src/bmm-skills/2-plan-workflows/bmad-edit-prd/SKILL.md
index b16498d39..0b7dd9718 100644
--- a/src/bmm-skills/2-plan-workflows/bmad-edit-prd/SKILL.md
+++ b/src/bmm-skills/2-plan-workflows/bmad-edit-prd/SKILL.md
@@ -3,4 +3,100 @@ name: bmad-edit-prd
description: 'Edit an existing PRD. Use when the user says "edit this PRD".'
---
-Follow the instructions in ./workflow.md.
+# PRD Edit Workflow
+
+**Goal:** Edit and improve existing PRDs through structured enhancement workflow.
+
+**Your Role:** PRD improvement specialist.
+
+You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
+
+## Conventions
+
+- Bare paths (e.g. `steps-e/step-e-01-discovery.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.
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
+- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
+- **Append-Only Building**: Build documents by appending content as directed to the output file
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **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** update frontmatter of output files when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Execution
+
+✅ 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}`.
+
+**Edit Mode: Improving an existing PRD.**
+
+Prompt for PRD path: "Which PRD would you like to edit? Please provide the path to the PRD.md file."
+
+Then read fully and follow: `./steps-e/step-e-01-discovery.md`
diff --git a/src/bmm-skills/2-plan-workflows/bmad-edit-prd/customize.toml b/src/bmm-skills/2-plan-workflows/bmad-edit-prd/customize.toml
new file mode 100644
index 000000000..78496ba2c
--- /dev/null
+++ b/src/bmm-skills/2-plan-workflows/bmad-edit-prd/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-edit-prd.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/2-plan-workflows/bmad-edit-prd/workflow.md b/src/bmm-skills/2-plan-workflows/bmad-edit-prd/workflow.md
deleted file mode 100644
index 23bd97c6f..000000000
--- a/src/bmm-skills/2-plan-workflows/bmad-edit-prd/workflow.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-main_config: '{project-root}/_bmad/bmm/config.yaml'
----
-
-# PRD Edit Workflow
-
-**Goal:** Edit and improve existing PRDs through structured enhancement workflow.
-
-**Your Role:** PRD improvement specialist.
-
-You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
-- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **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** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-✅ 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 Edit Workflow
-
-"**Edit Mode: Improving an existing PRD.**"
-
-Prompt for PRD path: "Which PRD would you like to edit? Please provide the path to the PRD.md file."
-
-Then read fully and follow: `./steps-e/step-e-01-discovery.md`
diff --git a/src/bmm-skills/2-plan-workflows/bmad-validate-prd/SKILL.md b/src/bmm-skills/2-plan-workflows/bmad-validate-prd/SKILL.md
index 77b523b81..d3cce314d 100644
--- a/src/bmm-skills/2-plan-workflows/bmad-validate-prd/SKILL.md
+++ b/src/bmm-skills/2-plan-workflows/bmad-validate-prd/SKILL.md
@@ -3,4 +3,102 @@ name: bmad-validate-prd
description: 'Validate a PRD against standards. Use when the user says "validate this PRD" or "run PRD validation"'
---
-Follow the instructions in ./workflow.md.
+# PRD Validate Workflow
+
+**Goal:** Validate existing PRDs against BMAD standards through comprehensive review.
+
+**Your Role:** Validation Architect and Quality Assurance Specialist.
+
+You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
+
+## Conventions
+
+- Bare paths (e.g. `steps-v/step-v-01-discovery.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.
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
+- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
+- **Append-Only Building**: Build documents by appending content as directed to the output file
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **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** update frontmatter of output files when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Paths
+
+- `validateWorkflow` = `./steps-v/step-v-01-discovery.md`
+
+## Execution
+
+✅ 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}`.
+
+**Validate Mode: Validating an existing PRD against BMAD standards.**
+
+Then read fully and follow: `{validateWorkflow}` (steps-v/step-v-01-discovery.md)
diff --git a/src/bmm-skills/2-plan-workflows/bmad-validate-prd/customize.toml b/src/bmm-skills/2-plan-workflows/bmad-validate-prd/customize.toml
new file mode 100644
index 000000000..ff8fcb852
--- /dev/null
+++ b/src/bmm-skills/2-plan-workflows/bmad-validate-prd/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-validate-prd.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/2-plan-workflows/bmad-validate-prd/workflow.md b/src/bmm-skills/2-plan-workflows/bmad-validate-prd/workflow.md
deleted file mode 100644
index 4fe8fcea9..000000000
--- a/src/bmm-skills/2-plan-workflows/bmad-validate-prd/workflow.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-main_config: '{project-root}/_bmad/bmm/config.yaml'
-validateWorkflow: './steps-v/step-v-01-discovery.md'
----
-
-# PRD Validate Workflow
-
-**Goal:** Validate existing PRDs against BMAD standards through comprehensive review.
-
-**Your Role:** Validation Architect and Quality Assurance Specialist.
-
-You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
-- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **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** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-✅ 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 Validate Workflow
-
-"**Validate Mode: Validating an existing PRD against BMAD standards.**"
-
-Then read fully and follow: `{validateWorkflow}` (steps-v/step-v-01-discovery.md)
diff --git a/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/SKILL.md b/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/SKILL.md
index d5ba0903f..f07b298af 100644
--- a/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/SKILL.md
+++ b/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/SKILL.md
@@ -3,4 +3,89 @@ name: bmad-check-implementation-readiness
description: 'Validate PRD, UX, Architecture and Epics specs are complete. Use when the user says "check implementation readiness".'
---
-Follow the instructions in ./workflow.md.
+# Implementation Readiness
+
+**Goal:** Validate that PRD, UX, Architecture, Epics and Stories are complete and aligned before Phase 4 implementation starts, with a focus on ensuring epics and stories are logical and have accounted for all requirements and planning.
+
+**Your Role:** You are an expert Product Manager, renowned and respected in the field of requirements traceability and spotting gaps in planning. Your success is measured in spotting the failures others have made in planning or preparation of epics and stories to produce the user's product vision.
+
+## Conventions
+
+- Bare paths (e.g. `steps/step-01-document-discovery.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.
+
+## WORKFLOW ARCHITECTURE
+
+### Core Principles
+
+- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
+- **Just-In-Time Loading**: Only 1 current step file will be loaded and followed to completion - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
+- **Append-Only Building**: Build documents by appending content as directed to the output file
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **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** update frontmatter of output files when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Execution
+
+Read fully and follow: `./steps/step-01-document-discovery.md` to begin the workflow.
diff --git a/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/customize.toml b/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/customize.toml
new file mode 100644
index 000000000..a54605784
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-check-implementation-readiness.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/workflow.md b/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/workflow.md
deleted file mode 100644
index 8f91d8cda..000000000
--- a/src/bmm-skills/3-solutioning/bmad-check-implementation-readiness/workflow.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Implementation Readiness
-
-**Goal:** Validate that PRD, Architecture, Epics and Stories are complete and aligned before Phase 4 implementation starts, with a focus on ensuring epics and stories are logical and have accounted for all requirements and planning.
-
-**Your Role:** You are an expert Product Manager, renowned and respected in the field of requirements traceability and spotting gaps in planning. Your success is measured in spotting the failures others have made in planning or preparation of epics and stories to produce the user's product vision.
-
-## WORKFLOW ARCHITECTURE
-
-### Core Principles
-
-- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
-- **Just-In-Time Loading**: Only 1 current step file will be loaded and followed to completion - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **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** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-2. First Step EXECUTION
-
-Read fully and follow: `./steps/step-01-document-discovery.md` to begin the workflow.
diff --git a/src/bmm-skills/3-solutioning/bmad-create-architecture/SKILL.md b/src/bmm-skills/3-solutioning/bmad-create-architecture/SKILL.md
index 27d4c7e66..ca89a71cf 100644
--- a/src/bmm-skills/3-solutioning/bmad-create-architecture/SKILL.md
+++ b/src/bmm-skills/3-solutioning/bmad-create-architecture/SKILL.md
@@ -3,4 +3,72 @@ name: bmad-create-architecture
description: 'Create architecture solution design decisions for AI agent consistency. Use when the user says "lets create architecture" or "create technical architecture" or "create a solution design"'
---
-Follow the instructions in ./workflow.md.
+# Architecture Workflow
+
+**Goal:** Create comprehensive architecture decisions through collaborative step-by-step discovery that ensures AI agents implement consistently.
+
+**Your Role:** You are an architectural facilitator collaborating with a peer. This is a partnership, not a client-vendor relationship. You bring structured thinking and architectural knowledge, while the user brings domain expertise and product vision. Work together as equals to make decisions that prevent implementation conflicts.
+
+## Conventions
+
+- Bare paths (e.g. `steps/step-01-init.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.
+
+## WORKFLOW ARCHITECTURE
+
+This uses **micro-file architecture** for disciplined execution:
+
+- Each step is a self-contained file with embedded rules
+- Sequential progression with user control at each step
+- Document state tracked in frontmatter
+- Append-only document building through conversation
+- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Execution
+
+Read fully and follow: `./steps/step-01-init.md` to begin the workflow.
+
+**Note:** Input document discovery and all initialization protocols are handled in step-01-init.md.
diff --git a/src/bmm-skills/3-solutioning/bmad-create-architecture/customize.toml b/src/bmm-skills/3-solutioning/bmad-create-architecture/customize.toml
new file mode 100644
index 000000000..9f80c0fe8
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-create-architecture/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-create-architecture.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/3-solutioning/bmad-create-architecture/workflow.md b/src/bmm-skills/3-solutioning/bmad-create-architecture/workflow.md
deleted file mode 100644
index 3dd945bd5..000000000
--- a/src/bmm-skills/3-solutioning/bmad-create-architecture/workflow.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Architecture Workflow
-
-**Goal:** Create comprehensive architecture decisions through collaborative step-by-step discovery that ensures AI agents implement consistently.
-
-**Your Role:** You are an architectural facilitator collaborating with a peer. This is a partnership, not a client-vendor relationship. You bring structured thinking and architectural knowledge, while the user brings domain expertise and product vision. Work together as equals to make decisions that prevent implementation conflicts.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **micro-file architecture** for disciplined execution:
-
-- Each step is a self-contained file with embedded rules
-- Sequential progression with user control at each step
-- Document state tracked in frontmatter
-- Append-only document building through conversation
-- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-2. EXECUTION
-
-Read fully and follow: `./steps/step-01-init.md` to begin the workflow.
-
-**Note:** Input document discovery and all initialization protocols are handled in step-01-init.md.
diff --git a/src/bmm-skills/3-solutioning/bmad-create-epics-and-stories/SKILL.md b/src/bmm-skills/3-solutioning/bmad-create-epics-and-stories/SKILL.md
index d092487dc..a8d987787 100644
--- a/src/bmm-skills/3-solutioning/bmad-create-epics-and-stories/SKILL.md
+++ b/src/bmm-skills/3-solutioning/bmad-create-epics-and-stories/SKILL.md
@@ -3,4 +3,91 @@ name: bmad-create-epics-and-stories
description: 'Break requirements into epics and user stories. Use when the user says "create the epics and stories list"'
---
-Follow the instructions in ./workflow.md.
+# Create Epics and Stories
+
+**Goal:** Transform PRD requirements and Architecture decisions into comprehensive stories organized by user value, creating detailed, actionable stories with complete acceptance criteria for the Developer agent.
+
+**Your Role:** In addition to your name, communication_style, and persona, you are also a product strategist and technical specifications writer collaborating with a product owner. This is a partnership, not a client-vendor relationship. You bring expertise in requirements decomposition, technical implementation context, and acceptance criteria writing, while the user brings their product vision, user needs, and business requirements. Work together as equals.
+
+## Conventions
+
+- Bare paths (e.g. `steps/step-01-validate-prerequisites.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.
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
+- **Just-In-Time Loading**: Only 1 current step file will be loaded and followed to completion - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
+- **Append-Only Building**: Build documents by appending content as directed to the output file
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **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** update frontmatter of output files when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Execution
+
+Read fully and follow: `./steps/step-01-validate-prerequisites.md` to begin the workflow.
diff --git a/src/bmm-skills/3-solutioning/bmad-create-epics-and-stories/customize.toml b/src/bmm-skills/3-solutioning/bmad-create-epics-and-stories/customize.toml
new file mode 100644
index 000000000..1f08e3b56
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-create-epics-and-stories/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-create-epics-and-stories.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/3-solutioning/bmad-create-epics-and-stories/workflow.md b/src/bmm-skills/3-solutioning/bmad-create-epics-and-stories/workflow.md
deleted file mode 100644
index 510e2736e..000000000
--- a/src/bmm-skills/3-solutioning/bmad-create-epics-and-stories/workflow.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Create Epics and Stories
-
-**Goal:** Transform PRD requirements and Architecture decisions into comprehensive stories organized by user value, creating detailed, actionable stories with complete acceptance criteria for the Developer agent.
-
-**Your Role:** In addition to your name, communication_style, and persona, you are also a product strategist and technical specifications writer collaborating with a product owner. This is a partnership, not a client-vendor relationship. You bring expertise in requirements decomposition, technical implementation context, and acceptance criteria writing, while the user brings their product vision, user needs, and business requirements. Work together as equals.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
-- **Just-In-Time Loading**: Only 1 current step file will be loaded and followed to completion - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **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** update frontmatter of output files when writing the final output for a specific step
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 📋 **NEVER** create mental todo lists from future steps
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-2. First Step EXECUTION
-
-Read fully and follow: `./steps/step-01-validate-prerequisites.md` to begin the workflow.
diff --git a/src/bmm-skills/3-solutioning/bmad-generate-project-context/SKILL.md b/src/bmm-skills/3-solutioning/bmad-generate-project-context/SKILL.md
index e54067b14..42fd2e8fc 100644
--- a/src/bmm-skills/3-solutioning/bmad-generate-project-context/SKILL.md
+++ b/src/bmm-skills/3-solutioning/bmad-generate-project-context/SKILL.md
@@ -3,4 +3,79 @@ name: bmad-generate-project-context
description: 'Create project-context.md with AI rules. Use when the user says "generate project context" or "create project context"'
---
-Follow the instructions in ./workflow.md.
+# Generate Project Context Workflow
+
+**Goal:** Create a concise, optimized `project-context.md` file containing critical rules, patterns, and guidelines that AI agents must follow when implementing code. This file focuses on unobvious details that LLMs need to be reminded of.
+
+**Your Role:** You are a technical facilitator working with a peer to capture the essential implementation rules that will ensure consistent, high-quality code generation across all AI agents working on the project.
+
+## Conventions
+
+- Bare paths (e.g. `steps/step-01-discover.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.
+
+## WORKFLOW ARCHITECTURE
+
+This uses **micro-file architecture** for disciplined execution:
+
+- Each step is a self-contained file with embedded rules
+- Sequential progression with user control at each step
+- Document state tracked in frontmatter
+- Focus on lean, LLM-optimized content generation
+- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Paths
+
+- `output_file` = `{output_folder}/project-context.md`
+
+## Execution
+
+- ✅ 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}`
+
+Load and execute `./steps/step-01-discover.md` to begin the workflow.
+
+**Note:** Input document discovery and initialization protocols are handled in step-01-discover.md.
diff --git a/src/bmm-skills/3-solutioning/bmad-generate-project-context/customize.toml b/src/bmm-skills/3-solutioning/bmad-generate-project-context/customize.toml
new file mode 100644
index 000000000..63274c4b5
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-generate-project-context/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-generate-project-context.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/3-solutioning/bmad-generate-project-context/workflow.md b/src/bmm-skills/3-solutioning/bmad-generate-project-context/workflow.md
deleted file mode 100644
index 590eeb544..000000000
--- a/src/bmm-skills/3-solutioning/bmad-generate-project-context/workflow.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Generate Project Context Workflow
-
-**Goal:** Create a concise, optimized `project-context.md` file containing critical rules, patterns, and guidelines that AI agents must follow when implementing code. This file focuses on unobvious details that LLMs need to be reminded of.
-
-**Your Role:** You are a technical facilitator working with a peer to capture the essential implementation rules that will ensure consistent, high-quality code generation across all AI agents working on the project.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **micro-file architecture** for disciplined execution:
-
-- Each step is a self-contained file with embedded rules
-- Sequential progression with user control at each step
-- Document state tracked in frontmatter
-- Focus on lean, LLM-optimized content generation
-- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
-
----
-
-## Activation
-
-1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
- - Use `{user_name}` for greeting
- - Use `{communication_language}` for all communications
- - Use `{document_output_language}` for output documents
- - Use `{planning_artifacts}` for output location and artifact scanning
- - Use `{project_knowledge}` for additional context scanning
-
-- ✅ 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}`
-
-- `output_file` = `{output_folder}/project-context.md`
-
- EXECUTION
-
-Load and execute `./steps/step-01-discover.md` to begin the workflow.
-
-**Note:** Input document discovery and initialization protocols are handled in step-01-discover.md.
diff --git a/src/bmm-skills/4-implementation/bmad-correct-course/SKILL.md b/src/bmm-skills/4-implementation/bmad-correct-course/SKILL.md
index 021c715f8..af7c1792c 100644
--- a/src/bmm-skills/4-implementation/bmad-correct-course/SKILL.md
+++ b/src/bmm-skills/4-implementation/bmad-correct-course/SKILL.md
@@ -3,4 +3,298 @@ name: bmad-correct-course
description: 'Manage significant changes during sprint execution. Use when the user says "correct course" or "propose sprint change"'
---
-Follow the instructions in ./workflow.md.
+# Correct Course - Sprint Change Management Workflow
+
+**Goal:** Manage significant changes during sprint execution by analyzing impact across all project artifacts and producing a structured Sprint Change Proposal.
+
+**Your Role:** You are a Developer navigating change management. Analyze the triggering issue, assess impact across PRD, epics, architecture, and UX artifacts, and produce an actionable Sprint Change Proposal with clear handoff.
+
+## Conventions
+
+- Bare paths (e.g. `checklist.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+
+- `project_name`, `user_name`
+- `communication_language`, `document_output_language`
+- `user_skill_level`
+- `implementation_artifacts`
+- `planning_artifacts`
+- `project_knowledge`
+- `date` as system-generated current datetime
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Language MUST be tailored to `{user_skill_level}`
+- Generate all documents in `{document_output_language}`
+- DOCUMENT OUTPUT: Updated epics, stories, or PRD sections. Clear, actionable changes. User skill level (`{user_skill_level}`) affects conversation style ONLY, not document updates.
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Paths
+
+- `default_output_file` = `{planning_artifacts}/sprint-change-proposal-{date}.md`
+
+## Input Files
+
+| Input | Path | Load Strategy |
+|-------|------|---------------|
+| PRD | `{planning_artifacts}/*prd*.md` (whole) or `{planning_artifacts}/*prd*/*.md` (sharded) | FULL_LOAD |
+| Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD |
+| Architecture | `{planning_artifacts}/*architecture*.md` (whole) or `{planning_artifacts}/*architecture*/*.md` (sharded) | FULL_LOAD |
+| UX Design | `{planning_artifacts}/*ux*.md` (whole) or `{planning_artifacts}/*ux*/*.md` (sharded) | FULL_LOAD |
+| Spec | `{planning_artifacts}/*spec-*.md` (whole) | FULL_LOAD |
+| Document Project | `{project_knowledge}/index.md` (sharded) | INDEX_GUIDED |
+
+## Execution
+
+### Document Discovery - Loading Project Artifacts
+
+**Strategy**: Course correction needs broad project context to assess change impact accurately. Load all available planning artifacts.
+
+**Discovery Process for FULL_LOAD documents (PRD, Epics, Architecture, UX Design, Spec):**
+
+1. **Search for whole document first** - Look for files matching the whole-document pattern (e.g., `*prd*.md`, `*epic*.md`, `*architecture*.md`, `*ux*.md`, `*spec-*.md`)
+2. **Check for sharded version** - If whole document not found, look for a directory with `index.md` (e.g., `prd/index.md`, `epics/index.md`)
+3. **If sharded version found**:
+ - Read `index.md` to understand the document structure
+ - Read ALL section files listed in the index
+ - Process the combined content as a single document
+4. **Priority**: If both whole and sharded versions exist, use the whole document
+
+**Discovery Process for INDEX_GUIDED documents (Document Project):**
+
+1. **Search for index file** - Look for `{project_knowledge}/index.md`
+2. **If found**: Read the index to understand available documentation sections
+3. **Selectively load sections** based on relevance to the change being analyzed — do NOT load everything, only sections that relate to the impacted areas
+4. **This document is optional** — skip if `{project_knowledge}` does not exist (greenfield projects)
+
+**Fuzzy matching**: Be flexible with document names — users may use variations like `prd.md`, `bmm-prd.md`, `product-requirements.md`, etc.
+
+**Missing documents**: Not all documents may exist. PRD and Epics are essential; Architecture, UX Design, Spec, and Document Project are loaded if available. HALT if PRD or Epics cannot be found.
+
+
+
+
+ Confirm change trigger and gather user description of the issue
+ Ask: "What specific issue or change has been identified that requires navigation?"
+ Verify access to required project documents:
+ - PRD (Product Requirements Document)
+ - Current Epics and Stories
+ - Architecture documentation
+ - UI/UX specifications
+ Ask user for mode preference:
+ - **Incremental** (recommended): Refine each edit collaboratively
+ - **Batch**: Present all changes at once for review
+ Store mode selection for use throughout workflow
+
+HALT: "Cannot navigate change without clear understanding of the triggering issue. Please provide specific details about what needs to change and why."
+
+HALT: "Need access to project documents (PRD, Epics, Architecture, UI/UX) to assess change impact. Please ensure these documents are accessible."
+
+
+
+ Read fully and follow the systematic analysis from: checklist.md
+ Work through each checklist section interactively with the user
+ Record status for each checklist item:
+ - [x] Done - Item completed successfully
+ - [N/A] Skip - Item not applicable to this change
+ - [!] Action-needed - Item requires attention or follow-up
+ Maintain running notes of findings and impacts discovered
+ Present checklist progress after each major section
+
+Identify blocking issues and work with user to resolve before continuing
+
+
+
+Based on checklist findings, create explicit edit proposals for each identified artifact
+
+For Story changes:
+
+- Show old → new text format
+- Include story ID and section being modified
+- Provide rationale for each change
+- Example format:
+
+ ```
+ Story: [STORY-123] User Authentication
+ Section: Acceptance Criteria
+
+ OLD:
+ - User can log in with email/password
+
+ NEW:
+ - User can log in with email/password
+ - User can enable 2FA via authenticator app
+
+ Rationale: Security requirement identified during implementation
+ ```
+
+For PRD modifications:
+
+- Specify exact sections to update
+- Show current content and proposed changes
+- Explain impact on MVP scope and requirements
+
+For Architecture changes:
+
+- Identify affected components, patterns, or technology choices
+- Describe diagram updates needed
+- Note any ripple effects on other components
+
+For UI/UX specification updates:
+
+- Reference specific screens or components
+- Show wireframe or flow changes needed
+- Connect changes to user experience impact
+
+
+ Present each edit proposal individually
+ Review and refine this change? Options: Approve [a], Edit [e], Skip [s]
+ Iterate on each proposal based on user feedback
+
+
+Collect all edit proposals and present together at end of step
+
+
+
+
+Compile comprehensive Sprint Change Proposal document with following sections:
+
+Section 1: Issue Summary
+
+- Clear problem statement describing what triggered the change
+- Context about when/how the issue was discovered
+- Evidence or examples demonstrating the issue
+
+Section 2: Impact Analysis
+
+- Epic Impact: Which epics are affected and how
+- Story Impact: Current and future stories requiring changes
+- Artifact Conflicts: PRD, Architecture, UI/UX documents needing updates
+- Technical Impact: Code, infrastructure, or deployment implications
+
+Section 3: Recommended Approach
+
+- Present chosen path forward from checklist evaluation:
+ - Direct Adjustment: Modify/add stories within existing plan
+ - Potential Rollback: Revert completed work to simplify resolution
+ - MVP Review: Reduce scope or modify goals
+- Provide clear rationale for recommendation
+- Include effort estimate, risk assessment, and timeline impact
+
+Section 4: Detailed Change Proposals
+
+- Include all refined edit proposals from Step 3
+- Group by artifact type (Stories, PRD, Architecture, UI/UX)
+- Ensure each change includes before/after and justification
+
+Section 5: Implementation Handoff
+
+- Categorize change scope:
+ - Minor: Direct implementation by Developer agent
+ - Moderate: Backlog reorganization needed (PO/DEV)
+ - Major: Fundamental replan required (PM/Architect)
+- Specify handoff recipients and their responsibilities
+- Define success criteria for implementation
+
+Present complete Sprint Change Proposal to user
+Write Sprint Change Proposal document to {default_output_file}
+Review complete proposal. Continue [c] or Edit [e]?
+
+
+
+Get explicit user approval for complete proposal
+Do you approve this Sprint Change Proposal for implementation? (yes/no/revise)
+
+
+ Gather specific feedback on what needs adjustment
+ Return to appropriate step to address concerns
+ If changes needed to edit proposals
+ If changes needed to overall proposal structure
+
+
+
+
+ Finalize Sprint Change Proposal document
+ Determine change scope classification:
+
+- **Minor**: Can be implemented directly by Developer agent
+- **Moderate**: Requires backlog reorganization and PO/DEV coordination
+- **Major**: Needs fundamental replan with PM/Architect involvement
+
+Provide appropriate handoff based on scope:
+
+
+
+
+ Route to: Developer agent for direct implementation
+ Deliverables: Finalized edit proposals and implementation tasks
+
+
+
+ Route to: Product Owner / Developer agents
+ Deliverables: Sprint Change Proposal + backlog reorganization plan
+
+
+
+ Route to: Product Manager / Solution Architect
+ Deliverables: Complete Sprint Change Proposal + escalation notice
+
+Confirm handoff completion and next steps with user
+Document handoff in workflow execution log
+
+
+
+
+
+Summarize workflow execution:
+ - Issue addressed: {{change_trigger}}
+ - Change scope: {{scope_classification}}
+ - Artifacts modified: {{list_of_artifacts}}
+ - Routed to: {{handoff_recipients}}
+
+Confirm all deliverables produced:
+
+- Sprint Change Proposal document
+- Specific edit proposals with before/after
+- Implementation handoff plan
+
+Report workflow completion to user with personalized message: "Correct Course workflow complete, {user_name}!"
+Remind user of success criteria and next steps for Developer agent
+
+
+
diff --git a/src/bmm-skills/4-implementation/bmad-correct-course/customize.toml b/src/bmm-skills/4-implementation/bmad-correct-course/customize.toml
new file mode 100644
index 000000000..2eb19ab5f
--- /dev/null
+++ b/src/bmm-skills/4-implementation/bmad-correct-course/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-correct-course.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/4-implementation/bmad-correct-course/workflow.md b/src/bmm-skills/4-implementation/bmad-correct-course/workflow.md
deleted file mode 100644
index 2b7cd7144..000000000
--- a/src/bmm-skills/4-implementation/bmad-correct-course/workflow.md
+++ /dev/null
@@ -1,267 +0,0 @@
-# Correct Course - Sprint Change Management Workflow
-
-**Goal:** Manage significant changes during sprint execution by analyzing impact across all project artifacts and producing a structured Sprint Change Proposal.
-
-**Your Role:** You are a Developer navigating change management. Analyze the triggering issue, assess impact across PRD, epics, architecture, and UX artifacts, and produce an actionable Sprint Change Proposal with clear handoff.
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `user_skill_level`
-- `implementation_artifacts`
-- `planning_artifacts`
-- `project_knowledge`
-- `date` as system-generated current datetime
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Language MUST be tailored to `{user_skill_level}`
-- Generate all documents in `{document_output_language}`
-- DOCUMENT OUTPUT: Updated epics, stories, or PRD sections. Clear, actionable changes. User skill level (`{user_skill_level}`) affects conversation style ONLY, not document updates.
-
-### Paths
-
-- `default_output_file` = `{planning_artifacts}/sprint-change-proposal-{date}.md`
-
-### Input Files
-
-| Input | Path | Load Strategy |
-|-------|------|---------------|
-| PRD | `{planning_artifacts}/*prd*.md` (whole) or `{planning_artifacts}/*prd*/*.md` (sharded) | FULL_LOAD |
-| Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD |
-| Architecture | `{planning_artifacts}/*architecture*.md` (whole) or `{planning_artifacts}/*architecture*/*.md` (sharded) | FULL_LOAD |
-| UX Design | `{planning_artifacts}/*ux*.md` (whole) or `{planning_artifacts}/*ux*/*.md` (sharded) | FULL_LOAD |
-| Spec | `{planning_artifacts}/*spec-*.md` (whole) | FULL_LOAD |
-| Document Project | `{project_knowledge}/index.md` (sharded) | INDEX_GUIDED |
-
-### Context
-
-- Load `**/project-context.md` if it exists
-
----
-
-## EXECUTION
-
-### Document Discovery - Loading Project Artifacts
-
-**Strategy**: Course correction needs broad project context to assess change impact accurately. Load all available planning artifacts.
-
-**Discovery Process for FULL_LOAD documents (PRD, Epics, Architecture, UX Design, Spec):**
-
-1. **Search for whole document first** - Look for files matching the whole-document pattern (e.g., `*prd*.md`, `*epic*.md`, `*architecture*.md`, `*ux*.md`, `*spec-*.md`)
-2. **Check for sharded version** - If whole document not found, look for a directory with `index.md` (e.g., `prd/index.md`, `epics/index.md`)
-3. **If sharded version found**:
- - Read `index.md` to understand the document structure
- - Read ALL section files listed in the index
- - Process the combined content as a single document
-4. **Priority**: If both whole and sharded versions exist, use the whole document
-
-**Discovery Process for INDEX_GUIDED documents (Document Project):**
-
-1. **Search for index file** - Look for `{project_knowledge}/index.md`
-2. **If found**: Read the index to understand available documentation sections
-3. **Selectively load sections** based on relevance to the change being analyzed — do NOT load everything, only sections that relate to the impacted areas
-4. **This document is optional** — skip if `{project_knowledge}` does not exist (greenfield projects)
-
-**Fuzzy matching**: Be flexible with document names — users may use variations like `prd.md`, `bmm-prd.md`, `product-requirements.md`, etc.
-
-**Missing documents**: Not all documents may exist. PRD and Epics are essential; Architecture, UX Design, Spec, and Document Project are loaded if available. HALT if PRD or Epics cannot be found.
-
-
-
-
- Load **/project-context.md for coding standards and project-wide patterns (if exists)
- Confirm change trigger and gather user description of the issue
- Ask: "What specific issue or change has been identified that requires navigation?"
- Verify access to required project documents:
- - PRD (Product Requirements Document)
- - Current Epics and Stories
- - Architecture documentation
- - UI/UX specifications
- Ask user for mode preference:
- - **Incremental** (recommended): Refine each edit collaboratively
- - **Batch**: Present all changes at once for review
- Store mode selection for use throughout workflow
-
-HALT: "Cannot navigate change without clear understanding of the triggering issue. Please provide specific details about what needs to change and why."
-
-HALT: "Need access to project documents (PRD, Epics, Architecture, UI/UX) to assess change impact. Please ensure these documents are accessible."
-
-
-
- Read fully and follow the systematic analysis from: checklist.md
- Work through each checklist section interactively with the user
- Record status for each checklist item:
- - [x] Done - Item completed successfully
- - [N/A] Skip - Item not applicable to this change
- - [!] Action-needed - Item requires attention or follow-up
- Maintain running notes of findings and impacts discovered
- Present checklist progress after each major section
-
-Identify blocking issues and work with user to resolve before continuing
-
-
-
-Based on checklist findings, create explicit edit proposals for each identified artifact
-
-For Story changes:
-
-- Show old → new text format
-- Include story ID and section being modified
-- Provide rationale for each change
-- Example format:
-
- ```
- Story: [STORY-123] User Authentication
- Section: Acceptance Criteria
-
- OLD:
- - User can log in with email/password
-
- NEW:
- - User can log in with email/password
- - User can enable 2FA via authenticator app
-
- Rationale: Security requirement identified during implementation
- ```
-
-For PRD modifications:
-
-- Specify exact sections to update
-- Show current content and proposed changes
-- Explain impact on MVP scope and requirements
-
-For Architecture changes:
-
-- Identify affected components, patterns, or technology choices
-- Describe diagram updates needed
-- Note any ripple effects on other components
-
-For UI/UX specification updates:
-
-- Reference specific screens or components
-- Show wireframe or flow changes needed
-- Connect changes to user experience impact
-
-
- Present each edit proposal individually
- Review and refine this change? Options: Approve [a], Edit [e], Skip [s]
- Iterate on each proposal based on user feedback
-
-
-Collect all edit proposals and present together at end of step
-
-
-
-
-Compile comprehensive Sprint Change Proposal document with following sections:
-
-Section 1: Issue Summary
-
-- Clear problem statement describing what triggered the change
-- Context about when/how the issue was discovered
-- Evidence or examples demonstrating the issue
-
-Section 2: Impact Analysis
-
-- Epic Impact: Which epics are affected and how
-- Story Impact: Current and future stories requiring changes
-- Artifact Conflicts: PRD, Architecture, UI/UX documents needing updates
-- Technical Impact: Code, infrastructure, or deployment implications
-
-Section 3: Recommended Approach
-
-- Present chosen path forward from checklist evaluation:
- - Direct Adjustment: Modify/add stories within existing plan
- - Potential Rollback: Revert completed work to simplify resolution
- - MVP Review: Reduce scope or modify goals
-- Provide clear rationale for recommendation
-- Include effort estimate, risk assessment, and timeline impact
-
-Section 4: Detailed Change Proposals
-
-- Include all refined edit proposals from Step 3
-- Group by artifact type (Stories, PRD, Architecture, UI/UX)
-- Ensure each change includes before/after and justification
-
-Section 5: Implementation Handoff
-
-- Categorize change scope:
- - Minor: Direct implementation by Developer agent
- - Moderate: Backlog reorganization needed (PO/DEV)
- - Major: Fundamental replan required (PM/Architect)
-- Specify handoff recipients and their responsibilities
-- Define success criteria for implementation
-
-Present complete Sprint Change Proposal to user
-Write Sprint Change Proposal document to {default_output_file}
-Review complete proposal. Continue [c] or Edit [e]?
-
-
-
-Get explicit user approval for complete proposal
-Do you approve this Sprint Change Proposal for implementation? (yes/no/revise)
-
-
- Gather specific feedback on what needs adjustment
- Return to appropriate step to address concerns
- If changes needed to edit proposals
- If changes needed to overall proposal structure
-
-
-
-
- Finalize Sprint Change Proposal document
- Determine change scope classification:
-
-- **Minor**: Can be implemented directly by Developer agent
-- **Moderate**: Requires backlog reorganization and PO/DEV coordination
-- **Major**: Needs fundamental replan with PM/Architect involvement
-
-Provide appropriate handoff based on scope:
-
-
-
-
- Route to: Developer agent for direct implementation
- Deliverables: Finalized edit proposals and implementation tasks
-
-
-
- Route to: Product Owner / Developer agents
- Deliverables: Sprint Change Proposal + backlog reorganization plan
-
-
-
- Route to: Product Manager / Solution Architect
- Deliverables: Complete Sprint Change Proposal + escalation notice
-
-Confirm handoff completion and next steps with user
-Document handoff in workflow execution log
-
-
-
-
-
-Summarize workflow execution:
- - Issue addressed: {{change_trigger}}
- - Change scope: {{scope_classification}}
- - Artifacts modified: {{list_of_artifacts}}
- - Routed to: {{handoff_recipients}}
-
-Confirm all deliverables produced:
-
-- Sprint Change Proposal document
-- Specific edit proposals with before/after
-- Implementation handoff plan
-
-Report workflow completion to user with personalized message: "Correct Course workflow complete, {user_name}!"
-Remind user of success criteria and next steps for Developer agent
-
-
-
diff --git a/src/bmm-skills/4-implementation/bmad-create-story/SKILL.md b/src/bmm-skills/4-implementation/bmad-create-story/SKILL.md
index 66119b062..dd5b44eee 100644
--- a/src/bmm-skills/4-implementation/bmad-create-story/SKILL.md
+++ b/src/bmm-skills/4-implementation/bmad-create-story/SKILL.md
@@ -3,4 +3,415 @@ 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]"'
---
-Follow the instructions in ./workflow.md.
+# Create Story Workflow
+
+**Goal:** Create a comprehensive story file that gives the dev agent everything needed for flawless implementation.
+
+**Your Role:** Story context engine that prevents LLM developer mistakes, omissions, or disasters.
+- Communicate all responses in {communication_language} and generate all documents in {document_output_language}
+- Your purpose is NOT to copy from epics - it's to create a comprehensive, optimized story file that gives the DEV agent EVERYTHING needed for flawless implementation
+- COMMON LLM MISTAKES TO PREVENT: reinventing wheels, wrong libraries, wrong file locations, breaking regressions, ignoring UX, vague implementations, lying about completion, not learning from past work
+- EXHAUSTIVE ANALYSIS REQUIRED: You must thoroughly analyze ALL artifacts to extract critical context - do NOT be lazy or skim! This is the most important function in the entire development process!
+- UTILIZE SUBPROCESSES AND SUBAGENTS: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different artifacts simultaneously and thoroughly
+- SAVE QUESTIONS: If you think of questions or clarifications during analysis, save them for the end after the complete story is written
+- ZERO USER INTERVENTION: Process should be fully automated except for initial epic/story selection or missing documents
+
+## Conventions
+
+- Bare paths (e.g. `discover-inputs.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+
+- `project_name`, `user_name`
+- `communication_language`, `document_output_language`
+- `user_skill_level`
+- `planning_artifacts`, `implementation_artifacts`
+- `date` as system-generated current datetime
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Paths
+
+- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
+- `epics_file` = `{planning_artifacts}/epics.md`
+- `prd_file` = `{planning_artifacts}/prd.md`
+- `architecture_file` = `{planning_artifacts}/architecture.md`
+- `ux_file` = `{planning_artifacts}/*ux*.md`
+- `story_title` = "" (will be elicited if not derivable)
+- `default_output_file` = `{implementation_artifacts}/{{story_key}}.md`
+
+## Input Files
+
+| Input | Description | Path Pattern(s) | Load Strategy |
+|-------|-------------|------------------|---------------|
+| prd | PRD (fallback - epics file should have most content) | whole: `{planning_artifacts}/*prd*.md`, sharded: `{planning_artifacts}/*prd*/*.md` | SELECTIVE_LOAD |
+| architecture | Architecture (fallback - epics file should have relevant sections) | whole: `{planning_artifacts}/*architecture*.md`, sharded: `{planning_artifacts}/*architecture*/*.md` | SELECTIVE_LOAD |
+| ux | UX design (fallback - epics file should have relevant sections) | whole: `{planning_artifacts}/*ux*.md`, sharded: `{planning_artifacts}/*ux*/*.md` | SELECTIVE_LOAD |
+| epics | Enhanced epics+stories file with BDD and source hints | whole: `{planning_artifacts}/*epic*.md`, sharded: `{planning_artifacts}/*epic*/*.md` | SELECTIVE_LOAD |
+
+## Execution
+
+
+
+
+
+ Parse user-provided story path: extract epic_num, story_num, story_title from format like "1-2-user-auth"
+ Set {{epic_num}}, {{story_num}}, {{story_key}} from user input
+ GOTO step 2a
+
+
+ Check if {{sprint_status}} file exists for auto discover
+
+
+
+ Choose option [1], provide epic-story number, path to story docs, or [q] to quit:
+
+
+ HALT - No work needed
+
+
+
+
+ HALT - User needs to run sprint-planning
+
+
+
+ Parse user input: extract epic_num, story_num, story_title
+ Set {{epic_num}}, {{story_num}}, {{story_key}} from user input
+ GOTO step 2a
+
+
+
+ Use user-provided path for story documents
+ GOTO step 2a
+
+
+
+
+
+ MUST read COMPLETE {sprint_status} file from start to end to preserve order
+ Load the FULL file: {{sprint_status}}
+ Read ALL lines from beginning to end - do not skip any content
+ Parse the development_status section completely
+
+ Find the FIRST story (by reading in order from top to bottom) where:
+ - Key matches pattern: number-number-name (e.g., "1-2-user-auth")
+ - NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
+ - Status value equals "backlog"
+
+
+
+
+ HALT
+
+
+ Extract from found story key (e.g., "1-2-user-authentication"):
+ - epic_num: first number before dash (e.g., "1")
+ - story_num: second number after first dash (e.g., "2")
+ - story_title: remainder after second dash (e.g., "user-authentication")
+
+ Set {{story_id}} = "{{epic_num}}.{{story_num}}"
+ Store story_key for later use (e.g., "1-2-user-authentication")
+
+
+ Check if this is the first story in epic {{epic_num}} by looking for {{epic_num}}-1-* pattern
+
+ Load {{sprint_status}} and check epic-{{epic_num}} status
+ If epic status is "backlog" → update to "in-progress"
+ If epic status is "contexted" (legacy status) → update to "in-progress" (backward compatibility)
+ If epic status is "in-progress" → no change needed
+
+
+
+
+
+
+ HALT - Cannot proceed
+
+
+
+
+
+ HALT - Cannot proceed
+
+
+
+
+ GOTO step 2a
+
+ Load the FULL file: {{sprint_status}}
+ Read ALL lines from beginning to end - do not skip any content
+ Parse the development_status section completely
+
+ Find the FIRST story (by reading in order from top to bottom) where:
+ - Key matches pattern: number-number-name (e.g., "1-2-user-auth")
+ - NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
+ - Status value equals "backlog"
+
+
+
+
+ HALT
+
+
+ Extract from found story key (e.g., "1-2-user-authentication"):
+ - epic_num: first number before dash (e.g., "1")
+ - story_num: second number after first dash (e.g., "2")
+ - story_title: remainder after second dash (e.g., "user-authentication")
+
+ Set {{story_id}} = "{{epic_num}}.{{story_num}}"
+ Store story_key for later use (e.g., "1-2-user-authentication")
+
+
+ Check if this is the first story in epic {{epic_num}} by looking for {{epic_num}}-1-* pattern
+
+ Load {{sprint_status}} and check epic-{{epic_num}} status
+ If epic status is "backlog" → update to "in-progress"
+ If epic status is "contexted" (legacy status) → update to "in-progress" (backward compatibility)
+ If epic status is "in-progress" → no change needed
+
+
+
+
+
+
+ HALT - Cannot proceed
+
+
+
+
+
+ HALT - Cannot proceed
+
+
+
+
+ GOTO step 2a
+
+
+
+ 🔬 EXHAUSTIVE ARTIFACT ANALYSIS - This is where you prevent future developer mistakes!
+
+
+ Read fully and follow `./discover-inputs.md` to load all input files
+ Available content: {epics_content}, {prd_content}, {architecture_content}, {ux_content},
+ {project_context}
+
+
+ From {epics_content}, extract Epic {{epic_num}} complete context: **EPIC ANALYSIS:** - Epic
+ objectives and business value - ALL stories in this epic for cross-story context - Our specific story's requirements, user story
+ statement, acceptance criteria - Technical requirements and constraints - Dependencies on other stories/epics - Source hints pointing to
+ original documents
+ Extract our story ({{epic_num}}-{{story_num}}) details: **STORY FOUNDATION:** - User story statement
+ (As a, I want, so that) - Detailed acceptance criteria (already BDD formatted) - Technical requirements specific to this story -
+ Business context and value - Success criteria
+
+ Find {{previous_story_num}}: scan {implementation_artifacts} for the story file in epic {{epic_num}} with the highest story number less than {{story_num}}
+ Load previous story file: {implementation_artifacts}/{{epic_num}}-{{previous_story_num}}-*.md **PREVIOUS STORY INTELLIGENCE:** -
+ Dev notes and learnings from previous story - Review feedback and corrections needed - Files that were created/modified and their
+ patterns - Testing approaches that worked/didn't work - Problems encountered and solutions found - Code patterns established Extract
+ all learnings that could impact current story implementation
+
+
+
+
+ Get last 5 commit titles to understand recent work patterns
+ Analyze 1-5 most recent commits for relevance to current story:
+ - Files created/modified
+ - Code patterns and conventions used
+ - Library dependencies added/changed
+ - Architecture decisions implemented
+ - Testing approaches used
+
+ Extract actionable insights for current story implementation
+
+
+
+
+ 🏗️ ARCHITECTURE INTELLIGENCE - Extract everything the developer MUST follow! **ARCHITECTURE DOCUMENT ANALYSIS:** Systematically
+ analyze architecture content for story-relevant requirements:
+
+
+
+ Load complete {architecture_content}
+
+
+ Load architecture index and scan all architecture files
+ **CRITICAL ARCHITECTURE EXTRACTION:** For
+ each architecture section, determine if relevant to this story: - **Technical Stack:** Languages, frameworks, libraries with
+ versions - **Code Structure:** Folder organization, naming conventions, file patterns - **API Patterns:** Service structure, endpoint
+ patterns, data contracts - **Database Schemas:** Tables, relationships, constraints relevant to story - **Security Requirements:**
+ Authentication patterns, authorization rules - **Performance Requirements:** Caching strategies, optimization patterns - **Testing
+ Standards:** Testing frameworks, coverage expectations, test patterns - **Deployment Patterns:** Environment configurations, build
+ processes - **Integration Patterns:** External service integrations, data flows Extract any story-specific requirements that the
+ developer MUST follow
+ Identify any architectural decisions that override previous patterns
+
+
+
+ 🌐 ENSURE LATEST TECH KNOWLEDGE - Prevent outdated implementations! **WEB INTELLIGENCE:** Identify specific
+ technical areas that require latest version knowledge:
+
+
+ From architecture analysis, identify specific libraries, APIs, or
+ frameworks
+ For each critical technology, research latest stable version and key changes:
+ - Latest API documentation and breaking changes
+ - Security vulnerabilities or updates
+ - Performance improvements or deprecations
+ - Best practices for current version
+
+ **EXTERNAL CONTEXT INCLUSION:** Include in story any critical latest information the developer needs:
+ - Specific library versions and why chosen
+ - API endpoints with parameters and authentication
+ - Recent security patches or considerations
+ - Performance optimization techniques
+ - Migration considerations if upgrading
+
+
+
+
+ 📝 CREATE ULTIMATE STORY FILE - The developer's master implementation guide!
+
+ Initialize from template.md:
+ {default_output_file}
+ story_header
+
+
+ story_requirements
+
+
+
+ developer_context_section **DEV AGENT GUARDRAILS:**
+ technical_requirements
+ architecture_compliance
+ library_framework_requirements
+
+ file_structure_requirements
+ testing_requirements
+
+
+
+ previous_story_intelligence
+
+
+
+
+ git_intelligence_summary
+
+
+
+
+ latest_tech_information
+
+
+
+ project_context_reference
+
+
+
+ story_completion_status
+
+
+ Set story Status to: "ready-for-dev"
+ Add completion note: "Ultimate
+ context engine analysis completed - comprehensive developer guide created"
+
+
+
+ Validate the newly created story file {default_output_file} against `./checklist.md` and apply any required fixes before finalizing
+ Save story document unconditionally
+
+
+
+ Update {{sprint_status}}
+ Load the FULL file and read all development_status entries
+ Find development_status key matching {{story_key}}
+ Verify current status is "backlog" (expected previous state)
+ Update development_status[{{story_key}}] = "ready-for-dev"
+ Update last_updated field to current date
+ Save file, preserving ALL comments and structure including STATUS DEFINITIONS
+
+
+ Report completion
+
+
+
+
diff --git a/src/bmm-skills/4-implementation/bmad-create-story/customize.toml b/src/bmm-skills/4-implementation/bmad-create-story/customize.toml
new file mode 100644
index 000000000..bdd6681a3
--- /dev/null
+++ b/src/bmm-skills/4-implementation/bmad-create-story/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-create-story.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/4-implementation/bmad-create-story/workflow.md b/src/bmm-skills/4-implementation/bmad-create-story/workflow.md
deleted file mode 100644
index 0acd8666b..000000000
--- a/src/bmm-skills/4-implementation/bmad-create-story/workflow.md
+++ /dev/null
@@ -1,380 +0,0 @@
-# Create Story Workflow
-
-**Goal:** Create a comprehensive story file that gives the dev agent everything needed for flawless implementation.
-
-**Your Role:** Story context engine that prevents LLM developer mistakes, omissions, or disasters.
-- Communicate all responses in {communication_language} and generate all documents in {document_output_language}
-- Your purpose is NOT to copy from epics - it's to create a comprehensive, optimized story file that gives the DEV agent EVERYTHING needed for flawless implementation
-- COMMON LLM MISTAKES TO PREVENT: reinventing wheels, wrong libraries, wrong file locations, breaking regressions, ignoring UX, vague implementations, lying about completion, not learning from past work
-- EXHAUSTIVE ANALYSIS REQUIRED: You must thoroughly analyze ALL artifacts to extract critical context - do NOT be lazy or skim! This is the most important function in the entire development process!
-- UTILIZE SUBPROCESSES AND SUBAGENTS: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different artifacts simultaneously and thoroughly
-- SAVE QUESTIONS: If you think of questions or clarifications during analysis, save them for the end after the complete story is written
-- ZERO USER INTERVENTION: Process should be fully automated except for initial epic/story selection or missing documents
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `user_skill_level`
-- `planning_artifacts`, `implementation_artifacts`
-- `date` as system-generated current datetime
-
-### Paths
-
-- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
-- `epics_file` = `{planning_artifacts}/epics.md`
-- `prd_file` = `{planning_artifacts}/prd.md`
-- `architecture_file` = `{planning_artifacts}/architecture.md`
-- `ux_file` = `{planning_artifacts}/*ux*.md`
-- `story_title` = "" (will be elicited if not derivable)
-- `project_context` = `**/project-context.md` (load if exists)
-- `default_output_file` = `{implementation_artifacts}/{{story_key}}.md`
-
-### Input Files
-
-| Input | Description | Path Pattern(s) | Load Strategy |
-|-------|-------------|------------------|---------------|
-| prd | PRD (fallback - epics file should have most content) | whole: `{planning_artifacts}/*prd*.md`, sharded: `{planning_artifacts}/*prd*/*.md` | SELECTIVE_LOAD |
-| architecture | Architecture (fallback - epics file should have relevant sections) | whole: `{planning_artifacts}/*architecture*.md`, sharded: `{planning_artifacts}/*architecture*/*.md` | SELECTIVE_LOAD |
-| ux | UX design (fallback - epics file should have relevant sections) | whole: `{planning_artifacts}/*ux*.md`, sharded: `{planning_artifacts}/*ux*/*.md` | SELECTIVE_LOAD |
-| epics | Enhanced epics+stories file with BDD and source hints | whole: `{planning_artifacts}/*epic*.md`, sharded: `{planning_artifacts}/*epic*/*.md` | SELECTIVE_LOAD |
-
----
-
-## EXECUTION
-
-
-
-
-
- Parse user-provided story path: extract epic_num, story_num, story_title from format like "1-2-user-auth"
- Set {{epic_num}}, {{story_num}}, {{story_key}} from user input
- GOTO step 2a
-
-
- Check if {{sprint_status}} file exists for auto discover
-
-
-
- Choose option [1], provide epic-story number, path to story docs, or [q] to quit:
-
-
- HALT - No work needed
-
-
-
-
- HALT - User needs to run sprint-planning
-
-
-
- Parse user input: extract epic_num, story_num, story_title
- Set {{epic_num}}, {{story_num}}, {{story_key}} from user input
- GOTO step 2a
-
-
-
- Use user-provided path for story documents
- GOTO step 2a
-
-
-
-
-
- MUST read COMPLETE {sprint_status} file from start to end to preserve order
- Load the FULL file: {{sprint_status}}
- Read ALL lines from beginning to end - do not skip any content
- Parse the development_status section completely
-
- Find the FIRST story (by reading in order from top to bottom) where:
- - Key matches pattern: number-number-name (e.g., "1-2-user-auth")
- - NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
- - Status value equals "backlog"
-
-
-
-
- HALT
-
-
- Extract from found story key (e.g., "1-2-user-authentication"):
- - epic_num: first number before dash (e.g., "1")
- - story_num: second number after first dash (e.g., "2")
- - story_title: remainder after second dash (e.g., "user-authentication")
-
- Set {{story_id}} = "{{epic_num}}.{{story_num}}"
- Store story_key for later use (e.g., "1-2-user-authentication")
-
-
- Check if this is the first story in epic {{epic_num}} by looking for {{epic_num}}-1-* pattern
-
- Load {{sprint_status}} and check epic-{{epic_num}} status
- If epic status is "backlog" → update to "in-progress"
- If epic status is "contexted" (legacy status) → update to "in-progress" (backward compatibility)
- If epic status is "in-progress" → no change needed
-
-
-
-
-
-
- HALT - Cannot proceed
-
-
-
-
-
- HALT - Cannot proceed
-
-
-
-
- GOTO step 2a
-
- Load the FULL file: {{sprint_status}}
- Read ALL lines from beginning to end - do not skip any content
- Parse the development_status section completely
-
- Find the FIRST story (by reading in order from top to bottom) where:
- - Key matches pattern: number-number-name (e.g., "1-2-user-auth")
- - NOT an epic key (epic-X) or retrospective (epic-X-retrospective)
- - Status value equals "backlog"
-
-
-
-
- HALT
-
-
- Extract from found story key (e.g., "1-2-user-authentication"):
- - epic_num: first number before dash (e.g., "1")
- - story_num: second number after first dash (e.g., "2")
- - story_title: remainder after second dash (e.g., "user-authentication")
-
- Set {{story_id}} = "{{epic_num}}.{{story_num}}"
- Store story_key for later use (e.g., "1-2-user-authentication")
-
-
- Check if this is the first story in epic {{epic_num}} by looking for {{epic_num}}-1-* pattern
-
- Load {{sprint_status}} and check epic-{{epic_num}} status
- If epic status is "backlog" → update to "in-progress"
- If epic status is "contexted" (legacy status) → update to "in-progress" (backward compatibility)
- If epic status is "in-progress" → no change needed
-
-
-
-
-
-
- HALT - Cannot proceed
-
-
-
-
-
- HALT - Cannot proceed
-
-
-
-
- GOTO step 2a
-
-
-
- 🔬 EXHAUSTIVE ARTIFACT ANALYSIS - This is where you prevent future developer mistakes!
-
-
- Read fully and follow `./discover-inputs.md` to load all input files
- Available content: {epics_content}, {prd_content}, {architecture_content}, {ux_content},
- {project_context}
-
-
- From {epics_content}, extract Epic {{epic_num}} complete context: **EPIC ANALYSIS:** - Epic
- objectives and business value - ALL stories in this epic for cross-story context - Our specific story's requirements, user story
- statement, acceptance criteria - Technical requirements and constraints - Dependencies on other stories/epics - Source hints pointing to
- original documents
- Extract our story ({{epic_num}}-{{story_num}}) details: **STORY FOUNDATION:** - User story statement
- (As a, I want, so that) - Detailed acceptance criteria (already BDD formatted) - Technical requirements specific to this story -
- Business context and value - Success criteria
-
- Find {{previous_story_num}}: scan {implementation_artifacts} for the story file in epic {{epic_num}} with the highest story number less than {{story_num}}
- Load previous story file: {implementation_artifacts}/{{epic_num}}-{{previous_story_num}}-*.md **PREVIOUS STORY INTELLIGENCE:** -
- Dev notes and learnings from previous story - Review feedback and corrections needed - Files that were created/modified and their
- patterns - Testing approaches that worked/didn't work - Problems encountered and solutions found - Code patterns established Extract
- all learnings that could impact current story implementation
-
-
-
-
- Get last 5 commit titles to understand recent work patterns
- Analyze 1-5 most recent commits for relevance to current story:
- - Files created/modified
- - Code patterns and conventions used
- - Library dependencies added/changed
- - Architecture decisions implemented
- - Testing approaches used
-
- Extract actionable insights for current story implementation
-
-
-
-
- 🏗️ ARCHITECTURE INTELLIGENCE - Extract everything the developer MUST follow! **ARCHITECTURE DOCUMENT ANALYSIS:** Systematically
- analyze architecture content for story-relevant requirements:
-
-
-
- Load complete {architecture_content}
-
-
- Load architecture index and scan all architecture files
- **CRITICAL ARCHITECTURE EXTRACTION:** For
- each architecture section, determine if relevant to this story: - **Technical Stack:** Languages, frameworks, libraries with
- versions - **Code Structure:** Folder organization, naming conventions, file patterns - **API Patterns:** Service structure, endpoint
- patterns, data contracts - **Database Schemas:** Tables, relationships, constraints relevant to story - **Security Requirements:**
- Authentication patterns, authorization rules - **Performance Requirements:** Caching strategies, optimization patterns - **Testing
- Standards:** Testing frameworks, coverage expectations, test patterns - **Deployment Patterns:** Environment configurations, build
- processes - **Integration Patterns:** External service integrations, data flows Extract any story-specific requirements that the
- developer MUST follow
- Identify any architectural decisions that override previous patterns
-
-
-
- 🌐 ENSURE LATEST TECH KNOWLEDGE - Prevent outdated implementations! **WEB INTELLIGENCE:** Identify specific
- technical areas that require latest version knowledge:
-
-
- From architecture analysis, identify specific libraries, APIs, or
- frameworks
- For each critical technology, research latest stable version and key changes:
- - Latest API documentation and breaking changes
- - Security vulnerabilities or updates
- - Performance improvements or deprecations
- - Best practices for current version
-
- **EXTERNAL CONTEXT INCLUSION:** Include in story any critical latest information the developer needs:
- - Specific library versions and why chosen
- - API endpoints with parameters and authentication
- - Recent security patches or considerations
- - Performance optimization techniques
- - Migration considerations if upgrading
-
-
-
-
- 📝 CREATE ULTIMATE STORY FILE - The developer's master implementation guide!
-
- Initialize from template.md:
- {default_output_file}
- story_header
-
-
- story_requirements
-
-
-
- developer_context_section **DEV AGENT GUARDRAILS:**
- technical_requirements
- architecture_compliance
- library_framework_requirements
-
- file_structure_requirements
- testing_requirements
-
-
-
- previous_story_intelligence
-
-
-
-
- git_intelligence_summary
-
-
-
-
- latest_tech_information
-
-
-
- project_context_reference
-
-
-
- story_completion_status
-
-
- Set story Status to: "ready-for-dev"
- Add completion note: "Ultimate
- context engine analysis completed - comprehensive developer guide created"
-
-
-
- Validate the newly created story file {default_output_file} against `./checklist.md` and apply any required fixes before finalizing
- Save story document unconditionally
-
-
-
- Update {{sprint_status}}
- Load the FULL file and read all development_status entries
- Find development_status key matching {{story_key}}
- Verify current status is "backlog" (expected previous state)
- Update development_status[{{story_key}}] = "ready-for-dev"
- Update last_updated field to current date
- Save file, preserving ALL comments and structure including STATUS DEFINITIONS
-
-
- Report completion
-
-
-
-
diff --git a/src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/SKILL.md b/src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/SKILL.md
index 5235f7b6c..8ae544220 100644
--- a/src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/SKILL.md
+++ b/src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/SKILL.md
@@ -3,4 +3,168 @@ name: bmad-qa-generate-e2e-tests
description: 'Generate end to end automated tests for existing features. Use when the user says "create qa automated tests for [feature]"'
---
-Follow the instructions in ./workflow.md.
+# QA Generate E2E Tests Workflow
+
+**Goal:** Generate automated API and E2E tests for implemented code.
+
+**Your Role:** You are a QA automation engineer. You generate tests ONLY — no code review or story validation (use the `bmad-code-review` skill for that).
+
+## Conventions
+
+- Bare paths (e.g. `checklist.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+
+- `project_name`, `user_name`
+- `communication_language`, `document_output_language`
+- `implementation_artifacts`
+- `date` as system-generated current datetime
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Paths
+
+- `test_dir` = `{project-root}/tests`
+- `source_dir` = `{project-root}`
+- `default_output_file` = `{implementation_artifacts}/tests/test-summary.md`
+
+## Execution
+
+### Step 0: Detect Test Framework
+
+Check project for existing test framework:
+
+- Look for `package.json` dependencies (playwright, jest, vitest, cypress, etc.)
+- Check for existing test files to understand patterns
+- Use whatever test framework the project already has
+- If no framework exists:
+ - Analyze source code to determine project type (React, Vue, Node API, etc.)
+ - Search online for current recommended test framework for that stack
+ - Suggest the meta framework and use it (or ask user to confirm)
+
+### Step 1: Identify Features
+
+Ask user what to test:
+
+- Specific feature/component name
+- Directory to scan (e.g., `src/components/`)
+- Or auto-discover features in the codebase
+
+### Step 2: Generate API Tests (if applicable)
+
+For API endpoints/services, generate tests that:
+
+- Test status codes (200, 400, 404, 500)
+- Validate response structure
+- Cover happy path + 1-2 error cases
+- Use project's existing test framework patterns
+
+### Step 3: Generate E2E Tests (if UI exists)
+
+For UI features, generate tests that:
+
+- Test user workflows end-to-end
+- Use semantic locators (roles, labels, text)
+- Focus on user interactions (clicks, form fills, navigation)
+- Assert visible outcomes
+- Keep tests linear and simple
+- Follow project's existing test patterns
+
+### Step 4: Run Tests
+
+Execute tests to verify they pass (use project's test command).
+
+If failures occur, fix them immediately.
+
+### Step 5: Create Summary
+
+Output markdown summary:
+
+```markdown
+# Test Automation Summary
+
+## Generated Tests
+
+### API Tests
+- [x] tests/api/endpoint.spec.ts - Endpoint validation
+
+### E2E Tests
+- [x] tests/e2e/feature.spec.ts - User workflow
+
+## Coverage
+- API endpoints: 5/10 covered
+- UI features: 3/8 covered
+
+## Next Steps
+- Run tests in CI
+- Add more edge cases as needed
+```
+
+## Keep It Simple
+
+**Do:**
+
+- Use standard test framework APIs
+- Focus on happy path + critical errors
+- Write readable, maintainable tests
+- Run tests to verify they pass
+
+**Avoid:**
+
+- Complex fixture composition
+- Over-engineering
+- Unnecessary abstractions
+
+**For Advanced Features:**
+
+If the project needs:
+
+- Risk-based test strategy
+- Test design planning
+- Quality gates and NFR assessment
+- Comprehensive coverage analysis
+- Advanced testing patterns and utilities
+
+> **Install Test Architect (TEA) module**:
+
+## Output
+
+Save summary to: `{default_output_file}`
+
+**Done!** Tests generated and verified. Validate against `./checklist.md`.
diff --git a/src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/customize.toml b/src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/customize.toml
new file mode 100644
index 000000000..0720cc693
--- /dev/null
+++ b/src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-qa-generate-e2e-tests.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/workflow.md b/src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/workflow.md
deleted file mode 100644
index c7159019c..000000000
--- a/src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests/workflow.md
+++ /dev/null
@@ -1,136 +0,0 @@
-# QA Generate E2E Tests Workflow
-
-**Goal:** Generate automated API and E2E tests for implemented code.
-
-**Your Role:** You are a QA automation engineer. You generate tests ONLY — no code review or story validation (use the `bmad-code-review` skill for that).
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `implementation_artifacts`
-- `date` as system-generated current datetime
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-
-### Paths
-
-- `test_dir` = `{project-root}/tests`
-- `source_dir` = `{project-root}`
-- `default_output_file` = `{implementation_artifacts}/tests/test-summary.md`
-
-### Context
-
-- `project_context` = `**/project-context.md` (load if exists)
-
----
-
-## EXECUTION
-
-### Step 0: Detect Test Framework
-
-Check project for existing test framework:
-
-- Look for `package.json` dependencies (playwright, jest, vitest, cypress, etc.)
-- Check for existing test files to understand patterns
-- Use whatever test framework the project already has
-- If no framework exists:
- - Analyze source code to determine project type (React, Vue, Node API, etc.)
- - Search online for current recommended test framework for that stack
- - Suggest the meta framework and use it (or ask user to confirm)
-
-### Step 1: Identify Features
-
-Ask user what to test:
-
-- Specific feature/component name
-- Directory to scan (e.g., `src/components/`)
-- Or auto-discover features in the codebase
-
-### Step 2: Generate API Tests (if applicable)
-
-For API endpoints/services, generate tests that:
-
-- Test status codes (200, 400, 404, 500)
-- Validate response structure
-- Cover happy path + 1-2 error cases
-- Use project's existing test framework patterns
-
-### Step 3: Generate E2E Tests (if UI exists)
-
-For UI features, generate tests that:
-
-- Test user workflows end-to-end
-- Use semantic locators (roles, labels, text)
-- Focus on user interactions (clicks, form fills, navigation)
-- Assert visible outcomes
-- Keep tests linear and simple
-- Follow project's existing test patterns
-
-### Step 4: Run Tests
-
-Execute tests to verify they pass (use project's test command).
-
-If failures occur, fix them immediately.
-
-### Step 5: Create Summary
-
-Output markdown summary:
-
-```markdown
-# Test Automation Summary
-
-## Generated Tests
-
-### API Tests
-- [x] tests/api/endpoint.spec.ts - Endpoint validation
-
-### E2E Tests
-- [x] tests/e2e/feature.spec.ts - User workflow
-
-## Coverage
-- API endpoints: 5/10 covered
-- UI features: 3/8 covered
-
-## Next Steps
-- Run tests in CI
-- Add more edge cases as needed
-```
-
-## Keep It Simple
-
-**Do:**
-
-- Use standard test framework APIs
-- Focus on happy path + critical errors
-- Write readable, maintainable tests
-- Run tests to verify they pass
-
-**Avoid:**
-
-- Complex fixture composition
-- Over-engineering
-- Unnecessary abstractions
-
-**For Advanced Features:**
-
-If the project needs:
-
-- Risk-based test strategy
-- Test design planning
-- Quality gates and NFR assessment
-- Comprehensive coverage analysis
-- Advanced testing patterns and utilities
-
-> **Install Test Architect (TEA) module**:
-
-## Output
-
-Save summary to: `{default_output_file}`
-
-**Done!** Tests generated and verified. Validate against `./checklist.md`.
diff --git a/src/bmm-skills/4-implementation/bmad-retrospective/SKILL.md b/src/bmm-skills/4-implementation/bmad-retrospective/SKILL.md
index bdc2b6d2a..7634c33bd 100644
--- a/src/bmm-skills/4-implementation/bmad-retrospective/SKILL.md
+++ b/src/bmm-skills/4-implementation/bmad-retrospective/SKILL.md
@@ -3,4 +3,1510 @@ name: bmad-retrospective
description: 'Post-epic review to extract lessons and assess success. Use when the user says "run a retrospective" or "lets retro the epic [epic]"'
---
-Follow the instructions in ./workflow.md.
+# Retrospective Workflow
+
+**Goal:** Post-epic review to extract lessons and assess success.
+
+**Your Role:** Developer facilitating retrospective.
+- No time estimates — NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed.
+- Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
+- Generate all documents in {document_output_language}
+- Document output: Retrospective analysis. Concise insights, lessons learned, action items. User skill level ({user_skill_level}) affects conversation style ONLY, not retrospective content.
+- Facilitation notes:
+ - Psychological safety is paramount - NO BLAME
+ - Focus on systems, processes, and learning
+ - Everyone contributes with specific examples preferred
+ - Action items must be achievable with clear ownership
+ - Two-part format: (1) Epic Review + (2) Next Epic Preparation
+- Party mode protocol:
+ - ALL agent dialogue MUST use format: "Name (Role): dialogue"
+ - Example: Amelia (Developer): "Let's begin..."
+ - Example: {user_name} (Project Lead): [User responds]
+ - Create natural back-and-forth with user actively participating
+ - Show disagreements, diverse perspectives, authentic team dynamics
+
+## Conventions
+
+- Bare paths resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+
+- `project_name`, `user_name`
+- `communication_language`, `document_output_language`
+- `user_skill_level`
+- `planning_artifacts`, `implementation_artifacts`
+- `date` as system-generated current datetime
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Paths
+
+- `sprint_status_file` = `{implementation_artifacts}/sprint-status.yaml`
+
+## Input Files
+
+| Input | Description | Path Pattern(s) | Load Strategy |
+|-------|-------------|------------------|---------------|
+| epics | The completed epic for retrospective | whole: `{planning_artifacts}/*epic*.md`, sharded_index: `{planning_artifacts}/*epic*/index.md`, sharded_single: `{planning_artifacts}/*epic*/epic-{{epic_num}}.md` | SELECTIVE_LOAD |
+| previous_retrospective | Previous epic's retrospective (optional) | `{implementation_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md` | SELECTIVE_LOAD |
+| architecture | System architecture for context | whole: `{planning_artifacts}/*architecture*.md`, sharded: `{planning_artifacts}/*architecture*/*.md` | FULL_LOAD |
+| prd | Product requirements for context | whole: `{planning_artifacts}/*prd*.md`, sharded: `{planning_artifacts}/*prd*/*.md` | FULL_LOAD |
+| document_project | Brownfield project documentation (optional) | sharded: `{planning_artifacts}/*.md` | INDEX_GUIDED |
+
+## Required Inputs
+
+- `agent_roster` = resolved via `python3 {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key agents` (merges four layers in order: `_bmad/config.toml`, `_bmad/config.user.toml`, `_bmad/custom/config.toml`, `_bmad/custom/config.user.toml`)
+
+## Execution
+
+
+
+
+
+Explain to {user_name} the epic discovery process using natural dialogue
+
+
+
+PRIORITY 1: Check {sprint_status_file} first
+
+Load the FULL file: {sprint_status_file}
+Read ALL development_status entries
+Find the highest epic number with at least one story marked "done"
+Extract epic number from keys like "epic-X-retrospective" or story keys like "X-Y-story-name"
+Set {{detected_epic}} = highest epic number found with completed stories
+
+
+ Present finding to user with context
+
+
+
+WAIT for {user_name} to confirm or correct
+
+
+ Set {{epic_number}} = {{detected_epic}}
+
+
+
+ Set {{epic_number}} = user-provided number
+
+
+
+
+
+ PRIORITY 2: Ask user directly
+
+
+
+WAIT for {user_name} to provide epic number
+Set {{epic_number}} = user-provided number
+
+
+
+ PRIORITY 3: Fallback to stories folder
+
+Scan {implementation_artifacts} for highest numbered story files
+Extract epic numbers from story filenames (pattern: epic-X-Y-story-name.md)
+Set {{detected_epic}} = highest epic number found
+
+
+
+WAIT for {user_name} to confirm or correct
+Set {{epic_number}} = confirmed number
+
+
+Once {{epic_number}} is determined, verify epic completion status
+
+Find all stories for epic {{epic_number}} in {sprint_status_file}:
+
+- Look for keys starting with "{{epic_number}}-" (e.g., "1-1-", "1-2-", etc.)
+- Exclude epic key itself ("epic-{{epic_number}}")
+- Exclude retrospective key ("epic-{{epic_number}}-retrospective")
+
+
+Count total stories found for this epic
+Count stories with status = "done"
+Collect list of pending story keys (status != "done")
+Determine if complete: true if all stories are done, false otherwise
+
+
+
+
+Continue with incomplete epic? (yes/no)
+
+
+
+ HALT
+
+
+Set {{partial_retrospective}} = true
+
+
+
+
+
+
+
+
+
+
+ Load input files according to the Input Files table above. For SELECTIVE_LOAD inputs, load only the epic matching {{epic_number}}. For FULL_LOAD inputs, load the complete document. For INDEX_GUIDED inputs, check the index first and load relevant sections. After discovery, these content variables are available: {epics_content} (selective load for this epic), {architecture_content}, {prd_content}, {document_project_content}
+ After discovery, these content variables are available: {epics_content} (selective load for this epic), {architecture_content}, {prd_content}, {document_project_content}
+
+
+
+
+
+
+For each story in epic {{epic_number}}, read the complete story file from {implementation_artifacts}/{{epic_number}}-{{story_num}}-*.md
+
+Extract and analyze from each story:
+
+**Dev Notes and Struggles:**
+
+- Look for sections like "## Dev Notes", "## Implementation Notes", "## Challenges", "## Development Log"
+- Identify where developers struggled or made mistakes
+- Note unexpected complexity or gotchas discovered
+- Record technical decisions that didn't work out as planned
+- Track where estimates were way off (too high or too low)
+
+**Review Feedback Patterns:**
+
+- Look for "## Review", "## Code Review", "## Dev Review" sections
+- Identify recurring feedback themes across stories
+- Note which types of issues came up repeatedly
+- Track quality concerns or architectural misalignments
+- Document praise or exemplary work called out in reviews
+
+**Lessons Learned:**
+
+- Look for "## Lessons Learned", "## Retrospective Notes", "## Takeaways" sections within stories
+- Extract explicit lessons documented during development
+- Identify "aha moments" or breakthroughs
+- Note what would be done differently
+- Track successful experiments or approaches
+
+**Technical Debt Incurred:**
+
+- Look for "## Technical Debt", "## TODO", "## Known Issues", "## Future Work" sections
+- Document shortcuts taken and why
+- Track debt items that affect next epic
+- Note severity and priority of debt items
+
+**Testing and Quality Insights:**
+
+- Look for "## Testing", "## QA Notes", "## Test Results" sections
+- Note testing challenges or surprises
+- Track bug patterns or regression issues
+- Document test coverage gaps
+
+Synthesize patterns across all stories:
+
+**Common Struggles:**
+
+- Identify issues that appeared in 2+ stories (e.g., "3 out of 5 stories had API authentication issues")
+- Note areas where team consistently struggled
+- Track where complexity was underestimated
+
+**Recurring Review Feedback:**
+
+- Identify feedback themes (e.g., "Error handling was flagged in every review")
+- Note quality patterns (positive and negative)
+- Track areas where team improved over the course of epic
+
+**Breakthrough Moments:**
+
+- Document key discoveries (e.g., "Story 3 discovered the caching pattern we used for rest of epic")
+- Note when team velocity improved dramatically
+- Track innovative solutions worth repeating
+
+**Velocity Patterns:**
+
+- Calculate average completion time per story
+- Note velocity trends (e.g., "First 2 stories took 3x longer than estimated")
+- Identify which types of stories went faster/slower
+
+**Team Collaboration Highlights:**
+
+- Note moments of excellent collaboration mentioned in stories
+- Track where pair programming or mob programming was effective
+- Document effective problem-solving sessions
+
+Store this synthesis - these patterns will drive the retrospective discussion
+
+
+
+
+
+
+
+Calculate previous epic number: {{prev_epic_num}} = {{epic_number}} - 1
+
+
+ Search for previous retrospectives using pattern: {implementation_artifacts}/epic-{{prev_epic_num}}-retro-*.md
+
+
+
+
+ Read the previous retrospectives
+
+ Extract key elements:
+ - **Action items committed**: What did the team agree to improve?
+ - **Lessons learned**: What insights were captured?
+ - **Process improvements**: What changes were agreed upon?
+ - **Technical debt flagged**: What debt was documented?
+ - **Team agreements**: What commitments were made?
+ - **Preparation tasks**: What was needed for this epic?
+
+ Cross-reference with current epic execution:
+
+ **Action Item Follow-Through:**
+ - For each action item from Epic {{prev_epic_num}} retro, check if it was completed
+ - Look for evidence in current epic's story records
+ - Mark each action item: ✅ Completed, ⏳ In Progress, ❌ Not Addressed
+
+ **Lessons Applied:**
+ - For each lesson from Epic {{prev_epic_num}}, check if team applied it in Epic {{epic_number}}
+ - Look for evidence in dev notes, review feedback, or outcomes
+ - Document successes and missed opportunities
+
+ **Process Improvements Effectiveness:**
+ - For each process change agreed to in Epic {{prev_epic_num}}, assess if it helped
+ - Did the change improve velocity, quality, or team satisfaction?
+ - Should we keep, modify, or abandon the change?
+
+ **Technical Debt Status:**
+ - For each debt item from Epic {{prev_epic_num}}, check if it was addressed
+ - Did unaddressed debt cause problems in Epic {{epic_number}}?
+ - Did the debt grow or shrink?
+
+ Prepare "continuity insights" for the retrospective discussion
+
+ Identify wins where previous lessons were applied successfully:
+ - Document specific examples of applied learnings
+ - Note positive impact on Epic {{epic_number}} outcomes
+ - Celebrate team growth and improvement
+
+ Identify missed opportunities where previous lessons were ignored:
+ - Document where team repeated previous mistakes
+ - Note impact of not applying lessons (without blame)
+ - Explore barriers that prevented application
+
+
+
+
+
+
+
+Set {{first_retrospective}} = true
+
+
+
+
+
+Set {{first_retrospective}} = true
+
+
+
+
+
+
+Calculate next epic number: {{next_epic_num}} = {{epic_number}} + 1
+
+
+
+Attempt to load next epic using selective loading strategy:
+
+**Try sharded first (more specific):**
+Check if file exists: {planning_artifacts}/epic*/epic-{{next_epic_num}}.md
+
+
+ Load {planning_artifacts}/*epic*/epic-{{next_epic_num}}.md
+ Set {{next_epic_source}} = "sharded"
+
+
+**Fallback to whole document:**
+
+Check if file exists: {planning_artifacts}/epic*.md
+
+
+ Load entire epics document
+ Extract Epic {{next_epic_num}} section
+ Set {{next_epic_source}} = "whole"
+
+
+
+
+ Analyze next epic for:
+ - Epic title and objectives
+ - Planned stories and complexity estimates
+ - Dependencies on Epic {{epic_number}} work
+ - New technical requirements or capabilities needed
+ - Potential risks or unknowns
+ - Business goals and success criteria
+
+Identify dependencies on completed work:
+
+- What components from Epic {{epic_number}} does Epic {{next_epic_num}} rely on?
+- Are all prerequisites complete and stable?
+- Any incomplete work that creates blocking dependencies?
+
+Note potential gaps or preparation needed:
+
+- Technical setup required (infrastructure, tools, libraries)
+- Knowledge gaps to fill (research, training, spikes)
+- Refactoring needed before starting next epic
+- Documentation or specifications to create
+
+Check for technical prerequisites:
+
+- APIs or integrations that must be ready
+- Data migrations or schema changes needed
+- Testing infrastructure requirements
+- Deployment or environment setup
+
+
+
+Set {{next_epic_exists}} = true
+
+
+
+
+
+Set {{next_epic_exists}} = false
+
+
+
+
+
+
+Load agent roster from {agent_roster}
+Identify which agents participated in Epic {{epic_number}} based on story records
+Ensure key roles present: Product Owner, Developer (facilitating), Testing/QA, Architect
+
+
+
+WAIT for {user_name} to respond or indicate readiness
+
+
+
+
+
+
+
+Amelia (Developer) naturally turns to {user_name} to engage them in the discussion
+
+
+
+WAIT for {user_name} to respond - this is a KEY USER INTERACTION moment
+
+After {user_name} responds, have 1-2 team members react to or build on what {user_name} shared
+
+
+
+Continue facilitating natural dialogue, periodically bringing {user_name} back into the conversation
+
+After covering successes, guide the transition to challenges with care
+
+
+
+WAIT for {user_name} to respond and help facilitate the conflict resolution
+
+Use {user_name}'s response to guide the discussion toward systemic understanding rather than blame
+
+
+
+Continue the discussion, weaving in patterns discovered from the deep story analysis (Step 2)
+
+
+
+WAIT for {user_name} to share their observations
+
+Continue the retrospective discussion, creating moments where:
+
+- Team members ask {user_name} questions directly
+- {user_name}'s input shifts the discussion direction
+- Disagreements arise naturally and get resolved
+- Quieter team members are invited to contribute
+- Specific stories are referenced with real examples
+- Emotions are authentic (frustration, pride, concern, hope)
+
+
+
+
+WAIT for {user_name} to respond
+
+Use the previous retro follow-through as a learning moment about commitment and accountability
+
+
+
+
+Allow team members to add any final thoughts on the epic review
+Ensure {user_name} has opportunity to add their perspective
+
+
+
+
+
+
+
+ Skip to Step 8
+
+
+
+
+WAIT for {user_name} to share their assessment
+
+Use {user_name}'s input to guide deeper exploration of preparation needs
+
+
+
+WAIT for {user_name} to provide direction on preparation approach
+
+Create space for debate and disagreement about priorities
+
+
+
+WAIT for {user_name} to validate or adjust the preparation strategy
+
+Continue working through preparation needs across all dimensions:
+
+- Dependencies on Epic {{epic_number}} work
+- Technical setup and infrastructure
+- Knowledge gaps and research needs
+- Documentation or specification work
+- Testing infrastructure
+- Refactoring or debt reduction
+- External dependencies (APIs, integrations, etc.)
+
+For each preparation area, facilitate team discussion that:
+
+- Identifies specific needs with concrete examples
+- Estimates effort realistically based on Epic {{epic_number}} experience
+- Assigns ownership to specific agents
+- Determines criticality and timing
+- Surfaces risks of NOT doing the preparation
+- Explores parallel work opportunities
+- Brings {user_name} in for key decisions
+
+
+
+WAIT for {user_name} final validation of preparation plan
+
+
+
+
+
+
+
+Synthesize themes from Epic {{epic_number}} review discussion into actionable improvements
+
+Create specific action items with:
+
+- Clear description of the action
+- Assigned owner (specific agent or role)
+- Timeline or deadline
+- Success criteria (how we'll know it's done)
+- Category (process, technical, documentation, team, etc.)
+
+Ensure action items are SMART:
+
+- Specific: Clear and unambiguous
+- Measurable: Can verify completion
+- Achievable: Realistic given constraints
+- Relevant: Addresses real issues from retro
+- Time-bound: Has clear deadline
+
+
+
+WAIT for {user_name} to help resolve priority discussions
+
+
+
+CRITICAL ANALYSIS - Detect if discoveries require epic updates
+
+Check if any of the following are true based on retrospective discussion:
+
+- Architectural assumptions from planning proven wrong during Epic {{epic_number}}
+- Major scope changes or descoping occurred that affects next epic
+- Technical approach needs fundamental change for Epic {{next_epic_num}}
+- Dependencies discovered that Epic {{next_epic_num}} doesn't account for
+- User needs significantly different than originally understood
+- Performance/scalability concerns that affect Epic {{next_epic_num}} design
+- Security or compliance issues discovered that change approach
+- Integration assumptions proven incorrect
+- Team capacity or skill gaps more severe than planned
+- Technical debt level unsustainable without intervention
+
+
+
+
+WAIT for {user_name} to decide on how to handle the significant changes
+
+Add epic review session to critical path if user agrees
+
+
+
+
+
+
+
+
+
+
+Give each agent with assignments a moment to acknowledge their ownership
+
+Ensure {user_name} approves the complete action plan
+
+
+
+
+
+
+
+Explore testing and quality state through natural conversation
+
+
+
+WAIT for {user_name} to describe testing status
+
+
+
+WAIT for {user_name} to assess quality readiness
+
+
+
+Add testing completion to critical path
+
+
+Explore deployment and release status
+
+
+
+WAIT for {user_name} to provide deployment status
+
+
+
+
+WAIT for {user_name} to clarify deployment timeline
+
+Add deployment milestone to critical path with agreed timeline
+
+
+Explore stakeholder acceptance
+
+
+
+WAIT for {user_name} to describe stakeholder acceptance status
+
+
+
+
+WAIT for {user_name} decision
+
+Add stakeholder acceptance to critical path if user agrees
+
+
+Explore technical health and stability
+
+
+
+WAIT for {user_name} to assess codebase health
+
+
+
+
+WAIT for {user_name} decision
+
+Add stability work to preparation sprint if user agrees
+
+
+Explore unresolved blockers
+
+
+
+WAIT for {user_name} to surface any blockers
+
+
+
+
+Assign blocker resolution to appropriate agent
+Add to critical path with priority and deadline
+
+
+Synthesize the readiness assessment
+
+
+
+WAIT for {user_name} to confirm or correct the assessment
+
+
+
+
+
+
+
+
+
+WAIT for {user_name} to share final reflections
+
+
+
+Prepare to save retrospective summary document
+
+
+
+
+
+Ensure retrospectives folder exists: {implementation_artifacts}
+Create folder if it doesn't exist
+
+Generate comprehensive retrospective summary document including:
+
+- Epic summary and metrics
+- Team participants
+- Successes and strengths identified
+- Challenges and growth areas
+- Key insights and learnings
+- Previous retro follow-through analysis (if applicable)
+- Next epic preview and dependencies
+- Action items with owners and timelines
+- Preparation tasks for next epic
+- Critical path items
+- Significant discoveries and epic update recommendations (if any)
+- Readiness assessment
+- Commitments and next steps
+
+Format retrospective document as readable markdown with clear sections
+Set filename: {implementation_artifacts}/epic-{{epic_number}}-retro-{date}.md
+Save retrospective document
+
+
+
+Update {sprint_status_file} to mark retrospective as completed
+
+Load the FULL file: {sprint_status_file}
+Find development_status key "epic-{{epic_number}}-retrospective"
+Verify current status (typically "optional" or "pending")
+Update development_status["epic-{{epic_number}}-retrospective"] = "done"
+Update last_updated field to current date
+Save file, preserving ALL comments and structure including STATUS DEFINITIONS
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+PARTY MODE REQUIRED: All agent dialogue uses "Name (Role): dialogue" format
+Amelia (Developer) maintains psychological safety throughout - no blame or judgment
+Focus on systems and processes, not individual performance
+Create authentic team dynamics: disagreements, diverse perspectives, emotions
+User ({user_name}) is active participant, not passive observer
+Encourage specific examples over general statements
+Balance celebration of wins with honest assessment of challenges
+Ensure every voice is heard - all agents contribute
+Action items must be specific, achievable, and owned
+Forward-looking mindset - how do we improve for next epic?
+Intent-based facilitation, not scripted phrases
+Deep story analysis provides rich material for discussion
+Previous retro integration creates accountability and continuity
+Significant change detection prevents epic misalignment
+Critical verification prevents starting next epic prematurely
+Document everything - retrospective insights are valuable for future reference
+Two-part structure ensures both reflection AND preparation
+
diff --git a/src/bmm-skills/4-implementation/bmad-retrospective/customize.toml b/src/bmm-skills/4-implementation/bmad-retrospective/customize.toml
new file mode 100644
index 000000000..ea2c660f8
--- /dev/null
+++ b/src/bmm-skills/4-implementation/bmad-retrospective/customize.toml
@@ -0,0 +1,14 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-retrospective.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+ "file:{project-root}/**/project-context.md",
+]
+
+on_complete = ""
diff --git a/src/bmm-skills/4-implementation/bmad-retrospective/workflow.md b/src/bmm-skills/4-implementation/bmad-retrospective/workflow.md
deleted file mode 100644
index 0815b5622..000000000
--- a/src/bmm-skills/4-implementation/bmad-retrospective/workflow.md
+++ /dev/null
@@ -1,1479 +0,0 @@
-# Retrospective Workflow
-
-**Goal:** Post-epic review to extract lessons and assess success.
-
-**Your Role:** Developer facilitating retrospective.
-- No time estimates — NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed.
-- Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
-- Generate all documents in {document_output_language}
-- Document output: Retrospective analysis. Concise insights, lessons learned, action items. User skill level ({user_skill_level}) affects conversation style ONLY, not retrospective content.
-- Facilitation notes:
- - Psychological safety is paramount - NO BLAME
- - Focus on systems, processes, and learning
- - Everyone contributes with specific examples preferred
- - Action items must be achievable with clear ownership
- - Two-part format: (1) Epic Review + (2) Next Epic Preparation
-- Party mode protocol:
- - ALL agent dialogue MUST use format: "Name (Role): dialogue"
- - Example: Amelia (Developer): "Let's begin..."
- - Example: {user_name} (Project Lead): [User responds]
- - Create natural back-and-forth with user actively participating
- - Show disagreements, diverse perspectives, authentic team dynamics
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `user_skill_level`
-- `planning_artifacts`, `implementation_artifacts`
-- `date` as system-generated current datetime
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-
-### Paths
-
-- `sprint_status_file` = `{implementation_artifacts}/sprint-status.yaml`
-
-### Input Files
-
-| Input | Description | Path Pattern(s) | Load Strategy |
-|-------|-------------|------------------|---------------|
-| epics | The completed epic for retrospective | whole: `{planning_artifacts}/*epic*.md`, sharded_index: `{planning_artifacts}/*epic*/index.md`, sharded_single: `{planning_artifacts}/*epic*/epic-{{epic_num}}.md` | SELECTIVE_LOAD |
-| previous_retrospective | Previous epic's retrospective (optional) | `{implementation_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md` | SELECTIVE_LOAD |
-| architecture | System architecture for context | whole: `{planning_artifacts}/*architecture*.md`, sharded: `{planning_artifacts}/*architecture*/*.md` | FULL_LOAD |
-| prd | Product requirements for context | whole: `{planning_artifacts}/*prd*.md`, sharded: `{planning_artifacts}/*prd*/*.md` | FULL_LOAD |
-| document_project | Brownfield project documentation (optional) | sharded: `{planning_artifacts}/*.md` | INDEX_GUIDED |
-
-### Required Inputs
-
-- `agent_roster` = resolved via `python3 {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key agents` (merges four layers in order: `_bmad/config.toml`, `_bmad/config.user.toml`, `_bmad/custom/config.toml`, `_bmad/custom/config.user.toml`)
-
-### Context
-
-- `project_context` = `**/project-context.md` (load if exists)
-
----
-
-## EXECUTION
-
-
-
-
-
-Load {project_context} for project-wide patterns and conventions (if exists)
-Explain to {user_name} the epic discovery process using natural dialogue
-
-
-
-PRIORITY 1: Check {sprint_status_file} first
-
-Load the FULL file: {sprint_status_file}
-Read ALL development_status entries
-Find the highest epic number with at least one story marked "done"
-Extract epic number from keys like "epic-X-retrospective" or story keys like "X-Y-story-name"
-Set {{detected_epic}} = highest epic number found with completed stories
-
-
- Present finding to user with context
-
-
-
-WAIT for {user_name} to confirm or correct
-
-
- Set {{epic_number}} = {{detected_epic}}
-
-
-
- Set {{epic_number}} = user-provided number
-
-
-
-
-
- PRIORITY 2: Ask user directly
-
-
-
-WAIT for {user_name} to provide epic number
-Set {{epic_number}} = user-provided number
-
-
-
- PRIORITY 3: Fallback to stories folder
-
-Scan {implementation_artifacts} for highest numbered story files
-Extract epic numbers from story filenames (pattern: epic-X-Y-story-name.md)
-Set {{detected_epic}} = highest epic number found
-
-
-
-WAIT for {user_name} to confirm or correct
-Set {{epic_number}} = confirmed number
-
-
-Once {{epic_number}} is determined, verify epic completion status
-
-Find all stories for epic {{epic_number}} in {sprint_status_file}:
-
-- Look for keys starting with "{{epic_number}}-" (e.g., "1-1-", "1-2-", etc.)
-- Exclude epic key itself ("epic-{{epic_number}}")
-- Exclude retrospective key ("epic-{{epic_number}}-retrospective")
-
-
-Count total stories found for this epic
-Count stories with status = "done"
-Collect list of pending story keys (status != "done")
-Determine if complete: true if all stories are done, false otherwise
-
-
-
-
-Continue with incomplete epic? (yes/no)
-
-
-
- HALT
-
-
-Set {{partial_retrospective}} = true
-
-
-
-
-
-
-
-
-
-
- Load input files according to the Input Files table in INITIALIZATION. For SELECTIVE_LOAD inputs, load only the epic matching {{epic_number}}. For FULL_LOAD inputs, load the complete document. For INDEX_GUIDED inputs, check the index first and load relevant sections. After discovery, these content variables are available: {epics_content} (selective load for this epic), {architecture_content}, {prd_content}, {document_project_content}
- After discovery, these content variables are available: {epics_content} (selective load for this epic), {architecture_content}, {prd_content}, {document_project_content}
-
-
-
-
-
-
-For each story in epic {{epic_number}}, read the complete story file from {implementation_artifacts}/{{epic_number}}-{{story_num}}-*.md
-
-Extract and analyze from each story:
-
-**Dev Notes and Struggles:**
-
-- Look for sections like "## Dev Notes", "## Implementation Notes", "## Challenges", "## Development Log"
-- Identify where developers struggled or made mistakes
-- Note unexpected complexity or gotchas discovered
-- Record technical decisions that didn't work out as planned
-- Track where estimates were way off (too high or too low)
-
-**Review Feedback Patterns:**
-
-- Look for "## Review", "## Code Review", "## Dev Review" sections
-- Identify recurring feedback themes across stories
-- Note which types of issues came up repeatedly
-- Track quality concerns or architectural misalignments
-- Document praise or exemplary work called out in reviews
-
-**Lessons Learned:**
-
-- Look for "## Lessons Learned", "## Retrospective Notes", "## Takeaways" sections within stories
-- Extract explicit lessons documented during development
-- Identify "aha moments" or breakthroughs
-- Note what would be done differently
-- Track successful experiments or approaches
-
-**Technical Debt Incurred:**
-
-- Look for "## Technical Debt", "## TODO", "## Known Issues", "## Future Work" sections
-- Document shortcuts taken and why
-- Track debt items that affect next epic
-- Note severity and priority of debt items
-
-**Testing and Quality Insights:**
-
-- Look for "## Testing", "## QA Notes", "## Test Results" sections
-- Note testing challenges or surprises
-- Track bug patterns or regression issues
-- Document test coverage gaps
-
-Synthesize patterns across all stories:
-
-**Common Struggles:**
-
-- Identify issues that appeared in 2+ stories (e.g., "3 out of 5 stories had API authentication issues")
-- Note areas where team consistently struggled
-- Track where complexity was underestimated
-
-**Recurring Review Feedback:**
-
-- Identify feedback themes (e.g., "Error handling was flagged in every review")
-- Note quality patterns (positive and negative)
-- Track areas where team improved over the course of epic
-
-**Breakthrough Moments:**
-
-- Document key discoveries (e.g., "Story 3 discovered the caching pattern we used for rest of epic")
-- Note when team velocity improved dramatically
-- Track innovative solutions worth repeating
-
-**Velocity Patterns:**
-
-- Calculate average completion time per story
-- Note velocity trends (e.g., "First 2 stories took 3x longer than estimated")
-- Identify which types of stories went faster/slower
-
-**Team Collaboration Highlights:**
-
-- Note moments of excellent collaboration mentioned in stories
-- Track where pair programming or mob programming was effective
-- Document effective problem-solving sessions
-
-Store this synthesis - these patterns will drive the retrospective discussion
-
-
-
-
-
-
-
-Calculate previous epic number: {{prev_epic_num}} = {{epic_number}} - 1
-
-
- Search for previous retrospectives using pattern: {implementation_artifacts}/epic-{{prev_epic_num}}-retro-*.md
-
-
-
-
- Read the previous retrospectives
-
- Extract key elements:
- - **Action items committed**: What did the team agree to improve?
- - **Lessons learned**: What insights were captured?
- - **Process improvements**: What changes were agreed upon?
- - **Technical debt flagged**: What debt was documented?
- - **Team agreements**: What commitments were made?
- - **Preparation tasks**: What was needed for this epic?
-
- Cross-reference with current epic execution:
-
- **Action Item Follow-Through:**
- - For each action item from Epic {{prev_epic_num}} retro, check if it was completed
- - Look for evidence in current epic's story records
- - Mark each action item: ✅ Completed, ⏳ In Progress, ❌ Not Addressed
-
- **Lessons Applied:**
- - For each lesson from Epic {{prev_epic_num}}, check if team applied it in Epic {{epic_number}}
- - Look for evidence in dev notes, review feedback, or outcomes
- - Document successes and missed opportunities
-
- **Process Improvements Effectiveness:**
- - For each process change agreed to in Epic {{prev_epic_num}}, assess if it helped
- - Did the change improve velocity, quality, or team satisfaction?
- - Should we keep, modify, or abandon the change?
-
- **Technical Debt Status:**
- - For each debt item from Epic {{prev_epic_num}}, check if it was addressed
- - Did unaddressed debt cause problems in Epic {{epic_number}}?
- - Did the debt grow or shrink?
-
- Prepare "continuity insights" for the retrospective discussion
-
- Identify wins where previous lessons were applied successfully:
- - Document specific examples of applied learnings
- - Note positive impact on Epic {{epic_number}} outcomes
- - Celebrate team growth and improvement
-
- Identify missed opportunities where previous lessons were ignored:
- - Document where team repeated previous mistakes
- - Note impact of not applying lessons (without blame)
- - Explore barriers that prevented application
-
-
-
-
-
-
-
-Set {{first_retrospective}} = true
-
-
-
-
-
-Set {{first_retrospective}} = true
-
-
-
-
-
-
-Calculate next epic number: {{next_epic_num}} = {{epic_number}} + 1
-
-
-
-Attempt to load next epic using selective loading strategy:
-
-**Try sharded first (more specific):**
-Check if file exists: {planning_artifacts}/epic*/epic-{{next_epic_num}}.md
-
-
- Load {planning_artifacts}/*epic*/epic-{{next_epic_num}}.md
- Set {{next_epic_source}} = "sharded"
-
-
-**Fallback to whole document:**
-
-Check if file exists: {planning_artifacts}/epic*.md
-
-
- Load entire epics document
- Extract Epic {{next_epic_num}} section
- Set {{next_epic_source}} = "whole"
-
-
-
-
- Analyze next epic for:
- - Epic title and objectives
- - Planned stories and complexity estimates
- - Dependencies on Epic {{epic_number}} work
- - New technical requirements or capabilities needed
- - Potential risks or unknowns
- - Business goals and success criteria
-
-Identify dependencies on completed work:
-
-- What components from Epic {{epic_number}} does Epic {{next_epic_num}} rely on?
-- Are all prerequisites complete and stable?
-- Any incomplete work that creates blocking dependencies?
-
-Note potential gaps or preparation needed:
-
-- Technical setup required (infrastructure, tools, libraries)
-- Knowledge gaps to fill (research, training, spikes)
-- Refactoring needed before starting next epic
-- Documentation or specifications to create
-
-Check for technical prerequisites:
-
-- APIs or integrations that must be ready
-- Data migrations or schema changes needed
-- Testing infrastructure requirements
-- Deployment or environment setup
-
-
-
-Set {{next_epic_exists}} = true
-
-
-
-
-
-Set {{next_epic_exists}} = false
-
-
-
-
-
-
-Load agent roster from {agent_roster}
-Identify which agents participated in Epic {{epic_number}} based on story records
-Ensure key roles present: Product Owner, Developer (facilitating), Testing/QA, Architect
-
-
-
-WAIT for {user_name} to respond or indicate readiness
-
-
-
-
-
-
-
-Amelia (Developer) naturally turns to {user_name} to engage them in the discussion
-
-
-
-WAIT for {user_name} to respond - this is a KEY USER INTERACTION moment
-
-After {user_name} responds, have 1-2 team members react to or build on what {user_name} shared
-
-
-
-Continue facilitating natural dialogue, periodically bringing {user_name} back into the conversation
-
-After covering successes, guide the transition to challenges with care
-
-
-
-WAIT for {user_name} to respond and help facilitate the conflict resolution
-
-Use {user_name}'s response to guide the discussion toward systemic understanding rather than blame
-
-
-
-Continue the discussion, weaving in patterns discovered from the deep story analysis (Step 2)
-
-
-
-WAIT for {user_name} to share their observations
-
-Continue the retrospective discussion, creating moments where:
-
-- Team members ask {user_name} questions directly
-- {user_name}'s input shifts the discussion direction
-- Disagreements arise naturally and get resolved
-- Quieter team members are invited to contribute
-- Specific stories are referenced with real examples
-- Emotions are authentic (frustration, pride, concern, hope)
-
-
-
-
-WAIT for {user_name} to respond
-
-Use the previous retro follow-through as a learning moment about commitment and accountability
-
-
-
-
-Allow team members to add any final thoughts on the epic review
-Ensure {user_name} has opportunity to add their perspective
-
-
-
-
-
-
-
- Skip to Step 8
-
-
-
-
-WAIT for {user_name} to share their assessment
-
-Use {user_name}'s input to guide deeper exploration of preparation needs
-
-
-
-WAIT for {user_name} to provide direction on preparation approach
-
-Create space for debate and disagreement about priorities
-
-
-
-WAIT for {user_name} to validate or adjust the preparation strategy
-
-Continue working through preparation needs across all dimensions:
-
-- Dependencies on Epic {{epic_number}} work
-- Technical setup and infrastructure
-- Knowledge gaps and research needs
-- Documentation or specification work
-- Testing infrastructure
-- Refactoring or debt reduction
-- External dependencies (APIs, integrations, etc.)
-
-For each preparation area, facilitate team discussion that:
-
-- Identifies specific needs with concrete examples
-- Estimates effort realistically based on Epic {{epic_number}} experience
-- Assigns ownership to specific agents
-- Determines criticality and timing
-- Surfaces risks of NOT doing the preparation
-- Explores parallel work opportunities
-- Brings {user_name} in for key decisions
-
-
-
-WAIT for {user_name} final validation of preparation plan
-
-
-
-
-
-
-
-Synthesize themes from Epic {{epic_number}} review discussion into actionable improvements
-
-Create specific action items with:
-
-- Clear description of the action
-- Assigned owner (specific agent or role)
-- Timeline or deadline
-- Success criteria (how we'll know it's done)
-- Category (process, technical, documentation, team, etc.)
-
-Ensure action items are SMART:
-
-- Specific: Clear and unambiguous
-- Measurable: Can verify completion
-- Achievable: Realistic given constraints
-- Relevant: Addresses real issues from retro
-- Time-bound: Has clear deadline
-
-
-
-WAIT for {user_name} to help resolve priority discussions
-
-
-
-CRITICAL ANALYSIS - Detect if discoveries require epic updates
-
-Check if any of the following are true based on retrospective discussion:
-
-- Architectural assumptions from planning proven wrong during Epic {{epic_number}}
-- Major scope changes or descoping occurred that affects next epic
-- Technical approach needs fundamental change for Epic {{next_epic_num}}
-- Dependencies discovered that Epic {{next_epic_num}} doesn't account for
-- User needs significantly different than originally understood
-- Performance/scalability concerns that affect Epic {{next_epic_num}} design
-- Security or compliance issues discovered that change approach
-- Integration assumptions proven incorrect
-- Team capacity or skill gaps more severe than planned
-- Technical debt level unsustainable without intervention
-
-
-
-
-WAIT for {user_name} to decide on how to handle the significant changes
-
-Add epic review session to critical path if user agrees
-
-
-
-
-
-
-
-
-
-
-Give each agent with assignments a moment to acknowledge their ownership
-
-Ensure {user_name} approves the complete action plan
-
-
-
-
-
-
-
-Explore testing and quality state through natural conversation
-
-
-
-WAIT for {user_name} to describe testing status
-
-
-
-WAIT for {user_name} to assess quality readiness
-
-
-
-Add testing completion to critical path
-
-
-Explore deployment and release status
-
-
-
-WAIT for {user_name} to provide deployment status
-
-
-
-
-WAIT for {user_name} to clarify deployment timeline
-
-Add deployment milestone to critical path with agreed timeline
-
-
-Explore stakeholder acceptance
-
-
-
-WAIT for {user_name} to describe stakeholder acceptance status
-
-
-
-
-WAIT for {user_name} decision
-
-Add stakeholder acceptance to critical path if user agrees
-
-
-Explore technical health and stability
-
-
-
-WAIT for {user_name} to assess codebase health
-
-
-
-
-WAIT for {user_name} decision
-
-Add stability work to preparation sprint if user agrees
-
-
-Explore unresolved blockers
-
-
-
-WAIT for {user_name} to surface any blockers
-
-
-
-
-Assign blocker resolution to appropriate agent
-Add to critical path with priority and deadline
-
-
-Synthesize the readiness assessment
-
-
-
-WAIT for {user_name} to confirm or correct the assessment
-
-
-
-
-
-
-
-
-
-WAIT for {user_name} to share final reflections
-
-
-
-Prepare to save retrospective summary document
-
-
-
-
-
-Ensure retrospectives folder exists: {implementation_artifacts}
-Create folder if it doesn't exist
-
-Generate comprehensive retrospective summary document including:
-
-- Epic summary and metrics
-- Team participants
-- Successes and strengths identified
-- Challenges and growth areas
-- Key insights and learnings
-- Previous retro follow-through analysis (if applicable)
-- Next epic preview and dependencies
-- Action items with owners and timelines
-- Preparation tasks for next epic
-- Critical path items
-- Significant discoveries and epic update recommendations (if any)
-- Readiness assessment
-- Commitments and next steps
-
-Format retrospective document as readable markdown with clear sections
-Set filename: {implementation_artifacts}/epic-{{epic_number}}-retro-{date}.md
-Save retrospective document
-
-
-
-Update {sprint_status_file} to mark retrospective as completed
-
-Load the FULL file: {sprint_status_file}
-Find development_status key "epic-{{epic_number}}-retrospective"
-Verify current status (typically "optional" or "pending")
-Update development_status["epic-{{epic_number}}-retrospective"] = "done"
-Update last_updated field to current date
-Save file, preserving ALL comments and structure including STATUS DEFINITIONS
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-PARTY MODE REQUIRED: All agent dialogue uses "Name (Role): dialogue" format
-Amelia (Developer) maintains psychological safety throughout - no blame or judgment
-Focus on systems and processes, not individual performance
-Create authentic team dynamics: disagreements, diverse perspectives, emotions
-User ({user_name}) is active participant, not passive observer
-Encourage specific examples over general statements
-Balance celebration of wins with honest assessment of challenges
-Ensure every voice is heard - all agents contribute
-Action items must be specific, achievable, and owned
-Forward-looking mindset - how do we improve for next epic?
-Intent-based facilitation, not scripted phrases
-Deep story analysis provides rich material for discussion
-Previous retro integration creates accountability and continuity
-Significant change detection prevents epic misalignment
-Critical verification prevents starting next epic prematurely
-Document everything - retrospective insights are valuable for future reference
-Two-part structure ensures both reflection AND preparation
-