feat(workflows): adopt customize.toml pattern for workflow skills (#23)

* feat(workflows): adopt customize.toml pattern for workflow skills

Merge redirect-only SKILL.md with workflow.md content into a single
SKILL.md per workflow skill, add Conventions + On Activation (resolve
customization, prepend/append steps, persistent_facts, config load,
greet), and wire workflow.on_complete into each workflow's terminal
step. External-style workflows (steps-c/, steps-v/, steps-e/, etc.)
get the on_complete resolver appended to the final step file; inline
workflows get an <action> inside the final <step> block.

gds-sprint-status has three terminal branches (main flow step 5, data
mode step 20, validate mode step 30) — on_complete wired at each.
gds-document-project dispatches into instructions.md +
deep-dive-instructions.md + full-scan-instructions.md; on_complete
wired at all three terminal points so the hook fires regardless of
execution path.

Applies the same customization surface shipped for the GDS agent
skills in #22.

* fix(workflows): address PR review comments

- gds-e2e-scaffold, gds-document-project: fix `{skill_root}` typo
  (underscore) to `{skill-root}` (dash) in `installed_path` so
  downstream references like `{installed_path}/checklist.md` resolve
  correctly against the convention declared above.
- deep-dive-instructions.md: move the workflow.on_complete resolver
  from the end of Step 13a (area-selection confirmation loop) to
  Step 13g (Finish) so the hook only fires when the user actually
  exits the workflow, not during mid-workflow navigation.

* docs(changelog): record v0.4.0 — customize.toml pattern rollout

* docs(changelog): correct v0.4.0 release date

Author: bmadcode

.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "bmad-game-dev-studio",
       "source": "./",
       "description": "A comprehensive game development module with agents and workflows for preproduction, design, architecture, production, and testing across Unity, Unreal, and Godot. Part of the BMad Method ecosystem.",
-      "version": "0.3.0",
+      "version": "0.4.0",
       "author": {
         "name": "Brian (BMad) Madison"
       },

CHANGELOG.md

@@ -1,5 +1,25 @@
 # CHANGELOG
 
+## v0.4.0 - Apr 21, 2026 — customize.toml pattern across agents and workflows
+
+### Agent customization surface
+
+* All five agents (`gds-agent-game-architect`, `gds-agent-game-designer`, `gds-agent-game-dev`, `gds-agent-game-solo-dev`, `gds-agent-tech-writer`) adopt the BMAD-METHOD `customize.toml` pattern. Each agent's `SKILL.md` now runs a six-step On Activation block that resolves customization via `resolve_customization.py`, executes prepend/append hook steps, loads `persistent_facts`, reads config from `{project-root}/_bmad/gds/config.yaml`, and greets the user before the menu appears.
+* Added `[agent]` namespace in each agent's `customize.toml` exposing `role`, `identity`, `communication_style`, `principles`, `persistent_facts`, `activation_steps_prepend/append`, and the `[[agent.menu]]` entries. Overrides merge per BMad structural rules (scalars override, keyed arrays-of-tables replace-or-append, other arrays append).
+* Added an agent roster with essence descriptors in `src/module.yaml` so external skills (party-mode, retrospective, advanced-elicitation, help catalog) can route to, display, and embody GDS agents without reading each agent file.
+
+### Workflow customization surface
+
+* All 31 workflow skills converted from redirect-only `SKILL.md` + `workflow.md` split to a single integrated `SKILL.md`. The standalone `workflow.md` file is removed from every workflow skill.
+* Each workflow gains the same six-step On Activation block as agents (resolve customization → prepend → `persistent_facts` → config load → greet → append), plus a `Conventions` block declaring `{skill-root}`, `{project-root}`, and `{skill-name}`.
+* Each workflow's terminal step now invokes `resolve_customization.py --key workflow.on_complete` — external step-file workflows (`steps-c/`, `steps-v/`, `steps-e/`, `steps/`) get the hook appended to the final step file; inline workflows get an `<action>` inside the final `<step>`.
+* Branching terminals handled: `gds-sprint-status` wires `on_complete` at all three terminal steps (main flow step 5, data mode step 20, validate mode step 30); `gds-document-project` wires it at three terminal points across `instructions.md`, `deep-dive-instructions.md` (Step 13g Finish), and `full-scan-instructions.md` so the hook fires regardless of dispatch path.
+* Added `customize.toml` at every workflow skill root with a `[workflow]` namespace exposing `activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, and `on_complete`. Team and per-user overrides merge from `{project-root}/_bmad/custom/{skill-name}.toml` and `{skill-name}.user.toml`.
+
+### Fixes bundled with the rollout
+
+* `gds-e2e-scaffold`, `gds-document-project`: fix `{skill_root}` underscore typo to `{skill-root}` (dash) in `installed_path` declarations so downstream references resolve consistently with the `Conventions` block.
+
 ## v0.3.0 - Apr 14, 2026 — sync with BMAD-METHOD v6.3.0
 
 ### Phase 4 agent consolidation

package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-game-dev-studio",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "private": true,
   "description": "A BMad MEthod Core Module that offers a substantial stand alone module for Game Development across multiple supported platforms",
   "keywords": [

src/workflows/1-preproduction/gds-brainstorm-game/SKILL.md

@@ -3,4 +3,107 @@ name: gds-brainstorm-game
 description: 'Facilitate game brainstorming sessions with game-specific techniques. Use when the user says "brainstorm game" or "game ideas"'
 ---
 
-Follow the instructions in ./workflow.md.
+# Brainstorm Game Workflow
+
+**Goal:** Facilitate high-volume creative brainstorming for game ideas by applying game-specific techniques, context, and guided ideation to help users explore mechanics, themes, and experiences before committing to a concept.
+
+**Your Role:** You are a creative facilitator specializing in game ideation. This is a partnership, not a client-vendor relationship. Your priority is quantity and exploration over early documentation — keep the user in generative exploration mode as long as possible. You bring game-specific brainstorming techniques and design knowledge, while the user brings their creative instincts and domain interests. Work together as equals. 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. `template.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/gds/config.yaml` and resolve:
+
+- `user_name`
+- `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.
+
+## 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, load, read entire file, then execute 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
+- NEVER mention time estimates
+- ALWAYS wait for user input between steps
+- **Critical Mindset:** Keep the user in generative exploration mode. The best sessions push past obvious ideas into truly novel territory. When in doubt, ask another question, try another technique, or dig deeper into a promising thread
+- **Quantity Goal:** Aim for 100+ ideas before any organization — the first 20 are usually obvious; the magic happens in ideas 50-100
+
+
+## INITIALIZATION SEQUENCE
+
+### 1. Configuration Loading
+
+Load and read full config from {main_config} and resolve:
+
+- `project_name`, `output_folder`, `user_name`
+- `communication_language`, `document_output_language`, `game_dev_experience`
+- `date` as system-generated current datetime
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### 2. First Step EXECUTION
+
+Load, read the full file and then execute `steps/step-01-init.md` to begin the workflow.

src/workflows/1-preproduction/gds-brainstorm-game/customize.toml

@@ -0,0 +1,41 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for gds-brainstorm-game. 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. "Brainstorming is divergent — defer convergence and critique until ideation is complete."
+#   - 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 Step 4 (Complete Session),
+# after the final outputs are produced. Override wins.
+# Leave empty for no custom post-completion behavior.
+
+on_complete = ""

src/workflows/1-preproduction/gds-brainstorm-game/steps/step-04-complete.md

@@ -274,3 +274,9 @@ The Brainstorm Game workflow facilitates creative game ideation through 4 collab
 4. **Complete** - Summarize results and provide next steps
 
 This step-file architecture ensures consistent, creative brainstorming with user collaboration throughout.
+
+## On Complete
+
+Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+
+If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.