wizz-method 1.0.0 → 1.0.1

package/src/bmm-skills/2-plan-workflows/{bmad-ux → wizz-ux}/customize.toml

@@ -1,9 +1,9 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-ux.
+# Workflow customization surface for wizz-ux.
 # Overrides:
-#   {project-root}/_bmad/custom/bmad-ux.toml         (team)
-#   {project-root}/_bmad/custom/bmad-ux.user.toml    (personal)
+#   {project-root}/_wizz/custom/wizz-ux.toml         (team)
+#   {project-root}/_wizz/custom/wizz-ux.user.toml    (personal)
 # Merge rules: scalars override, arrays append.
 
 [workflow]
@@ -79,8 +79,8 @@ creative_tools = [
 # Entries: `skill:NAME`, `file:PATH`, or plain text directive.
 # Suggested order: structural → content/voice → prose mechanics.
 doc_standards = [
-  "skill:bmad-editorial-review-structure",
-  "skill:bmad-editorial-review-prose",
+  "skill:wizz-editorial-review-structure",
+  "skill:wizz-editorial-review-prose",
 ]
 
 # Information retrieval registry. Consulted on demand when the conversation

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

@@ -1,30 +1,30 @@
 ---
-name: bmad-validate-prd
-description: 'DEPRECATED — consolidated into bmad-prd validate intent - this skill will be removed in v7 in favor of `bmad-prd`.'
+name: wizz-validate-prd
+description: 'DEPRECATED — consolidated into wizz-prd validate intent - this skill will be removed in v7 in favor of `wizz-prd`.'
 ---
 
-# DEPRECATED — forwards to bmad-prd (validate intent)
+# DEPRECATED — forwards to wizz-prd (validate intent)
 
-This skill was consolidated into `bmad-prd`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-validate-prd.toml` override files keep working. New work should invoke `bmad-prd` directly — it detects create / update / validate intent from the conversation.
+This skill was consolidated into `wizz-prd`. It is retained as a thin compatibility shim so existing invocations by name and `_wizz/custom/wizz-validate-prd.toml` override files keep working. New work should invoke `wizz-prd` directly — it detects create / update / validate intent from the conversation.
 
 ## On Activation
 
-1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-validate-prd.toml` and `bmad-validate-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+1. Resolve customization: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_wizz/custom/wizz-validate-prd.toml` and `wizz-validate-prd.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
 
-2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
+2. Load `{project-root}/_wizz/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
 
 3. Emit a deprecation notice to the user in `{communication_language}`:
 
-   > Notice: `bmad-validate-prd` is deprecated and will be removed in a future release. It now forwards to `bmad-prd` with validate intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist`, `doc_standards`, `external_sources`, `external_handoffs`, `output_dir`, `output_folder_name`), migrate `_bmad/custom/bmad-validate-prd.toml` to `_bmad/custom/bmad-prd.toml` and invoke `bmad-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
+   > Notice: `wizz-validate-prd` is deprecated and will be removed in a future release. It now forwards to `wizz-prd` with validate intent. To silence this notice and access the full new customization surface (`prd_template`, `validation_checklist`, `doc_standards`, `external_sources`, `external_handoffs`, `output_dir`, `output_folder_name`), migrate `_wizz/custom/wizz-validate-prd.toml` to `_wizz/custom/wizz-prd.toml` and invoke `wizz-prd` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_wizz/custom/wizz-prd.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
 
-4. Invoke `bmad-prd` with the following context. Pass these as the activating context so `bmad-prd` honors them instead of resolving its own customization from scratch:
+4. Invoke `wizz-prd` with the following context. Pass these as the activating context so `wizz-prd` honors them instead of resolving its own customization from scratch:
 
-   - **Intent:** `validate` — skip `bmad-prd`'s usual intent detection step.
-   - **Pre-resolved legacy customization** — use these in place of resolving from `bmad-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist`, `validation_report_template`, `doc_standards`, `output_dir`, `output_folder_name`, `external_sources`, `external_handoffs`), use `bmad-prd`'s own defaults and overrides as normal:
+   - **Intent:** `validate` — skip `wizz-prd`'s usual intent detection step.
+   - **Pre-resolved legacy customization** — use these in place of resolving from `wizz-prd`'s own `customize.toml` for the four legacy fields. For everything else (`prd_template`, `validation_checklist`, `validation_report_template`, `doc_standards`, `output_dir`, `output_folder_name`, `external_sources`, `external_handoffs`), use `wizz-prd`'s own defaults and overrides as normal:
      - `activation_steps_prepend` = the resolved value from step 1
      - `activation_steps_append` = the resolved value from step 1
      - `persistent_facts` = the resolved value from step 1
      - `on_complete` = the resolved value from step 1
    - **Original user input:** forward whatever the user said when invoking this skill verbatim (the target PRD path, etc.).
 
-   `bmad-prd` takes the workflow from here. Do not execute any further steps in this shim.
+   `wizz-prd` takes the workflow from here. Do not execute any further steps in this shim.

package/src/bmm-skills/2-plan-workflows/{bmad-validate-prd → wizz-validate-prd}/customize.toml

@@ -1,6 +1,6 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-validate-prd. Mirrors the
+# Workflow customization surface for wizz-validate-prd. Mirrors the
 # agent customization shape under the [workflow] namespace.
 
 [workflow]
@@ -36,7 +36,7 @@ persistent_facts = [
 
 # Scalar: executed when the workflow reaches Step 13 (Validation Report Complete) and
 # the user exits via [X] Exit — not on [E] Use Edit Workflow (which chains to
-# bmad-edit-prd), [R] Review (which loops within), or [F] Fix (which loops within).
+# wizz-edit-prd), [R] Review (which loops within), or [F] Fix (which loops within).
 # Override wins. Leave empty for no custom post-completion behavior.
 
 on_complete = ""

package/src/bmm-skills/3-solutioning/{bmad-agent-architect → wizz-agent-architect}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-agent-architect
+name: wizz-agent-architect
 description: System architect and technical design leader. Use when the user asks to talk to Winston or requests the architect.
 ---
 
@@ -20,13 +20,13 @@ You are Winston, the System Architect. You turn product requirements and UX into
 
 ### Step 1: Resolve the Agent Block
 
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key agent`
+Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key agent`
 
 **If the script fails**, resolve the `agent` 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
+2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_wizz/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.
 
@@ -46,7 +46,7 @@ Treat every entry in `{agent.persistent_facts}` as foundational context you carr
 
 ### Step 5: Load Config
 
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+Load config from `{project-root}/_wizz/bmm/config.yaml` and resolve:
 - Use `{user_name}` for greeting
 - Use `{communication_language}` for all communications
 - Use `{document_output_language}` for output documents
@@ -55,7 +55,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 
 ### Step 6: Greet the User
 
-Greet `{user_name}` warmly by name as Winston, speaking in `{communication_language}`. Lead the greeting with `{agent.icon}` so the user can see at a glance which agent is speaking. Remind the user they can invoke the `bmad-help` skill at any time for advice.
+Greet `{user_name}` warmly by name as Winston, speaking in `{communication_language}`. Lead the greeting with `{agent.icon}` so the user can see at a glance which agent is speaking. Remind the user they can invoke the `wizz-help` skill at any time for advice.
 
 Continue to prefix your messages with `{agent.icon}` throughout the session so the active persona stays visually identifiable.
 
@@ -71,6 +71,6 @@ If the user's initial message already names an intent that clearly maps to a men
 
 Otherwise render `{agent.menu}` as a numbered table: `Code`, `Description`, `Action` (the item's `skill` name, or a short label derived from its `prompt` text). **Stop and wait for input.** Accept a number, menu `code`, or fuzzy description match.
 
-Dispatch on a clear match by invoking the item's `skill` or executing its `prompt`. Only pause to clarify when two or more items are genuinely close — one short question, not a confirmation ritual. When nothing on the menu fits, just continue the conversation; chat, clarifying questions, and `bmad-help` are always fair game.
+Dispatch on a clear match by invoking the item's `skill` or executing its `prompt`. Only pause to clarify when two or more items are genuinely close — one short question, not a confirmation ritual. When nothing on the menu fits, just continue the conversation; chat, clarifying questions, and `wizz-help` are always fair game.
 
 From here, Winston stays active — persona, persistent facts, `{agent.icon}` prefix, and `{communication_language}` carry into every turn until the user dismisses him.

package/src/bmm-skills/3-solutioning/{bmad-agent-architect → wizz-agent-architect}/customize.toml

@@ -37,6 +37,7 @@ activation_steps_append = []
 
 persistent_facts = [
   "file:{project-root}/**/project-context.md",
+  "If active_feature is set in {project-root}/_wizz/bmm/config.yaml, save every planning and implementation artifact under a subfolder named after it (e.g. {planning_artifacts}/{active_feature}/, {implementation_artifacts}/{active_feature}/). If it is empty or unset, write to the artifact roots as usual.",
 ]
 
 role = "Convert the PRD and UX into technical architecture decisions that keep implementation on track during the BMad Method solutioning phase."
@@ -57,9 +58,9 @@ principles = [
 [[agent.menu]]
 code = "CA"
 description = "Produce the architecture spine: the invariants that keep independently-built units consistent"
-skill = "bmad-architecture"
+skill = "wizz-architecture"
 
 [[agent.menu]]
 code = "IR"
 description = "Ensure the PRD, UX, Architecture and Epics and Stories List are all aligned"
-skill = "bmad-check-implementation-readiness"
+skill = "wizz-check-implementation-readiness"

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

@@ -1,5 +1,5 @@
 ---
-name: bmad-architecture
+name: wizz-architecture
 description: 'Produce the architecture: a lean spine of invariants that keeps everything built from it consistent, projected into whatever format the work needs. Use when the user says "create the architecture", "create technical architecture", "architecture spine", or "create a solution design".'
 ---
 # BMad Architecture
@@ -26,18 +26,18 @@ When the stack is open — greenfield, or a small/beginner project that could si
 
 ## Read the input to know the job
 
-The input itself tells you what kind of job this is — read it rather than quizzing the user about it. A spec package (`SPEC.md` + its memlog) is the richest start and the spine's home, so fold the spine back into it. But you'll also get a raw idea, a sprawling architecture document to distill down, an existing codebase to derive a spine *from* (ratify the conventions the code already shows — don't re-document them), the slice of one a new feature touches, or an existing spine to extend or pressure-test. Prefer a `.memlog.md` over re-reading the source it came from. Distill whatever you're given; mark real gaps as open questions instead of inventing answers. The spine's **altitude** mirrors what it augments and keeps the level below coherent — initiative→features, feature→epics, epic→stories. Inherit what's already settled — whether by the input (a spec, prd) or the standing `{workflow.persistent_facts}` — silently; don't re-decide or re-ask it. If the input is too thin to build on, suggest `bmad-spec` first; else capture the missing answers into a shared spec workspace through the same `memlog.py`, so `bmad-spec` can later derive `SPEC.md` without drift.
+The input itself tells you what kind of job this is — read it rather than quizzing the user about it. A spec package (`SPEC.md` + its memlog) is the richest start and the spine's home, so fold the spine back into it. But you'll also get a raw idea, a sprawling architecture document to distill down, an existing codebase to derive a spine *from* (ratify the conventions the code already shows — don't re-document them), the slice of one a new feature touches, or an existing spine to extend or pressure-test. Prefer a `.memlog.md` over re-reading the source it came from. Distill whatever you're given; mark real gaps as open questions instead of inventing answers. The spine's **altitude** mirrors what it augments and keeps the level below coherent — initiative→features, feature→epics, epic→stories. Inherit what's already settled — whether by the input (a spec, prd) or the standing `{workflow.persistent_facts}` — silently; don't re-decide or re-ask it. If the input is too thin to build on, suggest `wizz-spec` first; else capture the missing answers into a shared spec workspace through the same `memlog.py`, so `wizz-spec` can later derive `SPEC.md` without drift.
 
 **Inheriting a parent spine** (e.g. pointed at one epic of a spec whose feature/initiative spine already exists): load the parent `ARCHITECTURE-SPINE.md` first and treat its `AD`s, conventions, and paradigm as **binding, read-only** constraints — log each as a `constraint` entry, list them under the spine's *Inherited Invariants* (parent `AD` IDs, never renumbered), and don't re-derive them. Your job is only what the parent **left open**: its `Deferred` items plus the divergences this epic's stories could hit. A new `AD` that contradicts or weakens an inherited one is a **conflict to surface**, not a local override. An epic spine fixes the invariants the epic's stories must share — it does **not** expand per-story detail.
 
 ## How a run works
 
-The **memlog** (`.memlog.md`) is the run's working memory: every decision, constraint, version, assumption, and open question lands as one append-only line — for a decision, capture what it binds and the divergence it prevents. It is the shared canonical memlog (the same `{project-root}/_bmad/scripts/memlog.py` bmad-spec writes through), so it carries no lifecycle status — terminal moments are logged as `event` entries, not a frontmatter flag. The spine is **distilled from the memlog at the end**, not written as you go. Each surviving decision becomes an `AD-n` (stable ID, `Binds`/`Prevents`/`Rule`, `[ADOPTED]` when the user or existing reality already settled it); a decision that lives only in a diagram still gets logged. Resume a prior run by reloading its memlog.
+The **memlog** (`.memlog.md`) is the run's working memory: every decision, constraint, version, assumption, and open question lands as one append-only line — for a decision, capture what it binds and the divergence it prevents. It is the shared canonical memlog (the same `{project-root}/_wizz/scripts/memlog.py` wizz-spec writes through), so it carries no lifecycle status — terminal moments are logged as `event` entries, not a frontmatter flag. The spine is **distilled from the memlog at the end**, not written as you go. Each surviving decision becomes an `AD-n` (stable ID, `Binds`/`Prevents`/`Rule`, `[ADOPTED]` when the user or existing reality already settled it); a decision that lives only in a diagram still gets logged. Resume a prior run by reloading its memlog.
 
 Writes go through the shared script (don't read the file back except on resume):
 
-- `python3 {project-root}/_bmad/scripts/memlog.py init --workspace {doc_workspace} --field scope="…" --field purpose="…" --field altitude="…"`
-- `python3 {project-root}/_bmad/scripts/memlog.py append --workspace {doc_workspace} --type <decision|constraint|version|assumption|question|direction|event> --text "…"`
+- `python3 {project-root}/_wizz/scripts/memlog.py init --workspace {doc_workspace} --field scope="…" --field purpose="…" --field altitude="…"`
+- `python3 {project-root}/_wizz/scripts/memlog.py append --workspace {doc_workspace} --type <decision|constraint|version|assumption|question|direction|event> --text "…"`
 
 ## Resolution rules
 
@@ -48,11 +48,11 @@ Writes go through the shared script (don't read the file back except on resume):
 
 ## On Activation
 
-**Forwarded activation:** if a caller (e.g. the `bmad-create-architecture` shim) invoked you with a stated intent and pre-resolved customization fields, honor them verbatim — skip your own intent inference, use the supplied values for those named fields, and resolve only the remaining fields from your own `customize.toml`.
+**Forwarded activation:** if a caller (e.g. the `wizz-create-architecture` shim) invoked you with a stated intent and pre-resolved customization fields, honor them verbatim — skip your own intent inference, use the supplied values for those named fields, and resolve only the remaining fields from your own `customize.toml`.
 
-1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow` (on failure read `{skill-root}/customize.toml`, use defaults). Run `{workflow.activation_steps_prepend}`, then `{workflow.activation_steps_append}`. Hold `{workflow.persistent_facts}` as standing context — the default loads `project-context.md`, load-bearing for brownfield — and consult `{workflow.external_sources}` on demand.
-2. Load `{project-root}/_bmad/bmm/config.yaml` (+ `config.user.yaml`) for `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`; missing keys take neutral defaults, never block.
-3. Headless (no interactive user) → follow `references/headless.md` for the whole run. Otherwise greet `{user_name}` in `{communication_language}`. Detect the intent from the conversation and input — **create** (the default), **update** an existing spine, or **validate** one (see those sections). If the real ask is requirements / UX / a capability contract / epic breakdown / an agent, invoke the `bmad-prd`, `bmad-ux`, `bmad-spec`, `bmad-create-epics-and-stories`, or `bmad-workflow-builder` (if the BMad Builder module is installed) skill instead.
+1. Resolve customization: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow` (on failure read `{skill-root}/customize.toml`, use defaults). Run `{workflow.activation_steps_prepend}`, then `{workflow.activation_steps_append}`. Hold `{workflow.persistent_facts}` as standing context — the default loads `project-context.md`, load-bearing for brownfield — and consult `{workflow.external_sources}` on demand.
+2. Load `{project-root}/_wizz/bmm/config.yaml` (+ `config.user.yaml`) for `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`; missing keys take neutral defaults, never block.
+3. Headless (no interactive user) → follow `references/headless.md` for the whole run. Otherwise greet `{user_name}` in `{communication_language}`. Detect the intent from the conversation and input — **create** (the default), **update** an existing spine, or **validate** one (see those sections). If the real ask is requirements / UX / a capability contract / epic breakdown / an agent, invoke the `wizz-prd`, `wizz-ux`, `wizz-spec`, `wizz-create-epics-and-stories`, or `bmad-workflow-builder` (if the BMad Builder module is installed) skill instead.
 4. If a run folder for this target already exists under `{workflow.spine_output_path}`, offer to resume from its memlog rather than restart.
 5. Interactive create: offer the working mode in `{communication_language}` — **Coaching path** (default) or **Fast path** (see *How you work*) — before any drafting; default to Coaching unless the user asks for speed.
 6. **Mandatory, both paths, before drafting:** ask whether the spine is the only deliverable — and if not, draw out the *purpose and audience* rather than a document type. "An architecture doc" balloons into bloat; what they actually need might be a one-detail explainer for a single team or a non-technical vision piece for a board. Purpose right-sizes the artifact and may call for extra elicitation up front, not just a finale add-on.
@@ -72,8 +72,8 @@ Walk the sequence; reviewer fixes land before polish.
 3. **Reviewer pass.** Run the Reviewer Gate (`references/reviewer-gate.md`). Resolve before polish.
 4. **Triage.** Open questions and `[ASSUMPTION]` tags: blockers (unsafe for what's next) resolved one at a time; the rest deferred with a revisit condition in the memlog.
 5. **Renderings & polish.** The spine is the build deliverable; with it and the memlog now in place, produce any *additional* human-facing artifact the user needs, scoped to the purpose and audience drawn out up front. The up-front question already flagged whether one's needed; if it wasn't, still offer one here, seeding concrete options: an interactive HTML+SVG deck to walk a team through the architecture and drive discussion, a fuller HTML/md solution design, a C4 set, or a view of how the work splits across teams/epics. Build only what they pick, right-sized to that purpose; apply `{workflow.doc_standards}` polish to that prose only, never to the spine.
-6. **External handoffs.** Run `{workflow.external_handoffs}`; surface returned URLs/IDs. Offer to invoke the `bmad-spec` skill to adopt the spine as a companion, keeping `AD` IDs stable so downstream can cite them.
-7. **Close.** Set the spine's own frontmatter `status: final`, `updated: {date}`; log a `memlog.py append --type event --text "spine finalized"` (the memlog has no status field). Share paths. Next, **lead with `bmad-spec`** — recommend adopting/refreshing the spine as a spec companion (always the top recommendation when a spec was an input, and a useful next step even when it wasn't), then `bmad-create-epics-and-stories` or — epic altitude — `bmad-create-story`; or invoke `bmad-help` to route.
+6. **External handoffs.** Run `{workflow.external_handoffs}`; surface returned URLs/IDs. Offer to invoke the `wizz-spec` skill to adopt the spine as a companion, keeping `AD` IDs stable so downstream can cite them.
+7. **Close.** Set the spine's own frontmatter `status: final`, `updated: {date}`; log a `memlog.py append --type event --text "spine finalized"` (the memlog has no status field). Share paths. Next, **lead with `wizz-spec`** — recommend adopting/refreshing the spine as a spec companion (always the top recommendation when a spec was an input, and a useful next step even when it wasn't), then `wizz-create-epics-and-stories` or — epic altitude — `wizz-create-story`; or invoke `wizz-help` to route.
 8. Run `{workflow.on_complete}`.
 
 ## Update

package/src/bmm-skills/3-solutioning/{bmad-architecture → wizz-architecture}/customize.toml

@@ -1,10 +1,10 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-architecture.
+# Workflow customization surface for wizz-architecture.
 #
 # Override files (not edited here):
-#   {project-root}/_bmad/custom/bmad-architecture.toml         (team)
-#   {project-root}/_bmad/custom/bmad-architecture.user.toml    (personal)
+#   {project-root}/_wizz/custom/wizz-architecture.toml         (team)
+#   {project-root}/_wizz/custom/wizz-architecture.user.toml    (personal)
 
 [workflow]
 
@@ -24,7 +24,7 @@ activation_steps_append = []
 # Each entry is either a literal sentence, a skill prefixed with `skill:`, or a `file:`-prefixed
 # path/glob whose contents are loaded as facts.
 #
-# Default loads project-context.md if bmad-generate-project-context produced one — giving the
+# Default loads project-context.md if wizz-generate-project-context produced one — giving the
 # architect persistent awareness of the project's tech, domain, and conventions (load-bearing
 # for brownfield). Common opt-ins (set in team/user override TOML):
 #   "Our org is AWS-only -- do not propose GCP or Azure."
@@ -60,8 +60,8 @@ run_folder_pattern = "architecture-{project_name}-{date}"
 # design. Each entry is a `skill:`, `file:`, or plain-text directive applied before the user sees
 # the polished draft. Suggested order: structural passes first, prose mechanics last. Append-only.
 doc_standards = [
-  "skill:bmad-editorial-review-structure",
-  "skill:bmad-editorial-review-prose",
+  "skill:wizz-editorial-review-structure",
+  "skill:wizz-editorial-review-prose",
 ]
 
 # External-source registry. Natural-language directives describing knowledge bases, MCP tools, or

package/src/bmm-skills/3-solutioning/{bmad-architecture → wizz-architecture}/references/headless.md

@@ -2,7 +2,7 @@
 
 No interactive user: infer everything, ask nothing, but never invent — record inferences as `assumptions[]` and gaps that need a human as `open_questions[]`. Detect headless from a `headless: true` flag, a non-interactive / no-TTY invocation, an activation hook that declares it, or a first message that pre-supplies all inputs and asks for an artifact path back; when ambiguous, default to interactive.
 
-Drive the run from the payload in the first message — `intent`, `altitude`, `purpose`, the driving input (spec package / PRD / raw intent / brownfield path), a parent spine path at lower altitude, and `doc_workspace` if a specific folder is required. Infer anything absent from the inputs or workspace; don't invent stack, constraints, or scope to fill a gap. You still verify named tech on the web (you can't ask, but you can check) and still drive every write through the shared `{project-root}/_bmad/scripts/memlog.py`. Run the full Reviewer Gate (`references/reviewer-gate.md`) non-interactively: `scripts/lint_spine.py` plus **every `{workflow.finalize_reviewers}` lens as a parallel subagent** (and any ad-hoc lens the spine's criticality warrants). Headless skips only the human picking from the menu — never the reviewers themselves; apply the clear fixes and record anything unresolved in `open_questions[]`. For a true authority collision, list it in `conflicts_with_prior_decisions[]`. For the Validate intent, always write the report to `{doc_workspace}` and add `"offer_to_update": true`. If intent stays ambiguous after inference, halt blocked.
+Drive the run from the payload in the first message — `intent`, `altitude`, `purpose`, the driving input (spec package / PRD / raw intent / brownfield path), a parent spine path at lower altitude, and `doc_workspace` if a specific folder is required. Infer anything absent from the inputs or workspace; don't invent stack, constraints, or scope to fill a gap. You still verify named tech on the web (you can't ask, but you can check) and still drive every write through the shared `{project-root}/_wizz/scripts/memlog.py`. Run the full Reviewer Gate (`references/reviewer-gate.md`) non-interactively: `scripts/lint_spine.py` plus **every `{workflow.finalize_reviewers}` lens as a parallel subagent** (and any ad-hoc lens the spine's criticality warrants). Headless skips only the human picking from the menu — never the reviewers themselves; apply the clear fixes and record anything unresolved in `open_questions[]`. For a true authority collision, list it in `conflicts_with_prior_decisions[]`. For the Validate intent, always write the report to `{doc_workspace}` and add `"offer_to_update": true`. If intent stays ambiguous after inference, halt blocked.
 
 End with JSON only, omitting keys for artifacts not produced — the shape below is the fully-produced (`complete`) case; a `blocked` run produces no spine, so it omits `spine`, `memlog`, and `companions` entirely (see the note under the block):
 

package/src/bmm-skills/3-solutioning/{bmad-check-implementation-readiness → wizz-check-implementation-readiness}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-check-implementation-readiness
+name: wizz-check-implementation-readiness
 description: 'Validate PRD, UX, Architecture and Epics specs are complete. Use when the user says "check implementation readiness".'
 ---
 
@@ -49,13 +49,13 @@ description: 'Validate PRD, UX, Architecture and Epics specs are complete. Use w
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: `python3 {project-root}/_wizz/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
+2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_wizz/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.
 
@@ -69,7 +69,7 @@ Treat every entry in `{workflow.persistent_facts}` as foundational context you c
 
 ### Step 4: Load Config
 
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+Load config from `{project-root}/_wizz/bmm/config.yaml` and resolve:
 - Use `{user_name}` for greeting
 - Use `{communication_language}` for all communications
 - Use `{document_output_language}` for output documents

package/src/bmm-skills/3-solutioning/{bmad-check-implementation-readiness → wizz-check-implementation-readiness}/customize.toml

@@ -1,6 +1,6 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-check-implementation-readiness. Mirrors the
+# Workflow customization surface for wizz-check-implementation-readiness. Mirrors the
 # agent customization shape under the [workflow] namespace.
 
 [workflow]

package/src/bmm-skills/3-solutioning/{bmad-check-implementation-readiness → wizz-check-implementation-readiness}/steps/step-06-final-assessment.md

@@ -106,7 +106,7 @@ The assessment found [number] issues requiring attention. Review the detailed re
 
 The implementation readiness workflow is now complete. The report contains all findings and recommendations for the user to consider.
 
-Implementation Readiness complete. Invoke the `bmad-help` skill.
+Implementation Readiness complete. Invoke the `wizz-help` skill.
 
 ---
 
@@ -127,6 +127,6 @@ Implementation Readiness complete. Invoke the `bmad-help` skill.
 
 ## On Complete
 
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+Run: `python3 {project-root}/_wizz/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.

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

@@ -1,30 +1,30 @@
 ---
-name: bmad-create-architecture
-description: 'DEPRECATED — consolidated into bmad-architecture create intent - this skill will be removed in v7 in favor of `bmad-architecture`.'
+name: wizz-create-architecture
+description: 'DEPRECATED — consolidated into wizz-architecture create intent - this skill will be removed in v7 in favor of `wizz-architecture`.'
 ---
 
-# DEPRECATED — forwards to bmad-architecture (create intent)
+# DEPRECATED — forwards to wizz-architecture (create intent)
 
-This skill was consolidated into `bmad-architecture`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-create-architecture.toml` override files keep working. New work should invoke `bmad-architecture` directly — it detects create / update / validate intent from the conversation.
+This skill was consolidated into `wizz-architecture`. It is retained as a thin compatibility shim so existing invocations by name and `_wizz/custom/wizz-create-architecture.toml` override files keep working. New work should invoke `wizz-architecture` directly — it detects create / update / validate intent from the conversation.
 
 ## On Activation
 
-1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-create-architecture.toml` and `bmad-create-architecture.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+1. Resolve customization: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_wizz/custom/wizz-create-architecture.toml` and `wizz-create-architecture.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
 
-2. Load `{project-root}/_bmad/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
+2. Load `{project-root}/_wizz/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
 
 3. Emit a deprecation notice to the user in `{communication_language}`:
 
-   > Notice: `bmad-create-architecture` is deprecated and will be removed in a future release. It now forwards to `bmad-architecture` with create intent. To silence this notice and access the full new customization surface (`spine_template`, `spine_output_path`, `run_folder_pattern`, `doc_standards`, `external_sources`, `external_handoffs`, `finalize_reviewers`), migrate `_bmad/custom/bmad-create-architecture.toml` to `_bmad/custom/bmad-architecture.toml` and invoke `bmad-architecture` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_bmad/custom/bmad-architecture.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
+   > Notice: `wizz-create-architecture` is deprecated and will be removed in a future release. It now forwards to `wizz-architecture` with create intent. To silence this notice and access the full new customization surface (`spine_template`, `spine_output_path`, `run_folder_pattern`, `doc_standards`, `external_sources`, `external_handoffs`, `finalize_reviewers`), migrate `_wizz/custom/wizz-create-architecture.toml` to `_wizz/custom/wizz-architecture.toml` and invoke `wizz-architecture` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_wizz/custom/wizz-architecture.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
 
-4. Invoke `bmad-architecture` with the following context. Pass these as the activating context so `bmad-architecture` honors them instead of resolving its own customization from scratch:
+4. Invoke `wizz-architecture` with the following context. Pass these as the activating context so `wizz-architecture` honors them instead of resolving its own customization from scratch:
 
-   - **Intent:** `create` — skip `bmad-architecture`'s usual intent detection step.
-   - **Pre-resolved legacy customization** — use these in place of resolving from `bmad-architecture`'s own `customize.toml` for the four legacy fields. For everything else (`spine_template`, `spine_output_path`, `run_folder_pattern`, `doc_standards`, `external_sources`, `external_handoffs`, `finalize_reviewers`), use `bmad-architecture`'s own defaults and overrides as normal:
+   - **Intent:** `create` — skip `wizz-architecture`'s usual intent detection step.
+   - **Pre-resolved legacy customization** — use these in place of resolving from `wizz-architecture`'s own `customize.toml` for the four legacy fields. For everything else (`spine_template`, `spine_output_path`, `run_folder_pattern`, `doc_standards`, `external_sources`, `external_handoffs`, `finalize_reviewers`), use `wizz-architecture`'s own defaults and overrides as normal:
      - `activation_steps_prepend` = the resolved value from step 1
      - `activation_steps_append` = the resolved value from step 1
      - `persistent_facts` = the resolved value from step 1
      - `on_complete` = the resolved value from step 1
    - **Original user input:** forward whatever the user said when invoking this skill verbatim.
 
-   `bmad-architecture` takes the workflow from here. Do not execute any further steps in this shim.
+   `wizz-architecture` takes the workflow from here. Do not execute any further steps in this shim.

package/src/bmm-skills/3-solutioning/{bmad-create-architecture → wizz-create-architecture}/customize.toml

@@ -1,6 +1,6 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-create-architecture. Mirrors the
+# Workflow customization surface for wizz-create-architecture. Mirrors the
 # agent customization shape under the [workflow] namespace.
 
 [workflow]

package/src/bmm-skills/3-solutioning/{bmad-create-epics-and-stories → wizz-create-epics-and-stories}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-create-epics-and-stories
+name: wizz-create-epics-and-stories
 description: 'Break requirements into epics and user stories. Use when the user says "create the epics and stories list"'
 ---
 
@@ -51,13 +51,13 @@ This uses **step-file architecture** for disciplined execution:
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: `python3 {project-root}/_wizz/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
+2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_wizz/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.
 
@@ -71,7 +71,7 @@ Treat every entry in `{workflow.persistent_facts}` as foundational context you c
 
 ### Step 4: Load Config
 
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+Load config from `{project-root}/_wizz/bmm/config.yaml` and resolve:
 - Use `{user_name}` for greeting
 - Use `{communication_language}` for all communications
 - Use `{document_output_language}` for output documents

package/src/bmm-skills/3-solutioning/{bmad-create-epics-and-stories → wizz-create-epics-and-stories}/customize.toml

@@ -1,6 +1,6 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-create-epics-and-stories. Mirrors the
+# Workflow customization surface for wizz-create-epics-and-stories. Mirrors the
 # agent customization shape under the [workflow] namespace.
 
 [workflow]
@@ -35,7 +35,7 @@ persistent_facts = [
 ]
 
 # Scalar: executed when the workflow reaches Step 4 (Final Validation) and the
-# user confirms [C] Complete — after the epics.md is saved and bmad-help is invoked.
+# user confirms [C] Complete — after the epics.md is saved and wizz-help is invoked.
 # Override wins. Leave empty for no custom post-completion behavior.
 
 on_complete = ""

package/src/bmm-skills/3-solutioning/{bmad-create-epics-and-stories → wizz-create-epics-and-stories}/steps/step-01-validate-prerequisites.md

@@ -66,11 +66,11 @@ Search for required documents using these patterns (sharded means a large docume
 
 **UX Design Document Search (Optional):**
 
-1. `{planning_artifacts}/ux-designs/ux-*/DESIGN.md` and `{planning_artifacts}/ux-designs/ux-*/EXPERIENCE.md` (bmad-ux spine pair)
+1. `{planning_artifacts}/ux-designs/ux-*/DESIGN.md` and `{planning_artifacts}/ux-designs/ux-*/EXPERIENCE.md` (wizz-ux spine pair)
 2. `{planning_artifacts}/*ux*.md` (legacy whole document)
 3. `{planning_artifacts}/*ux*/index.md` (legacy sharded version)
 
-For each matching bmad-ux run folder, treat `DESIGN.md` and `EXPERIENCE.md` as one UX design contract:
+For each matching wizz-ux run folder, treat `DESIGN.md` and `EXPERIENCE.md` as one UX design contract:
 
 - Confirm and load both files together. `DESIGN.md` owns visual identity and design tokens; `EXPERIENCE.md` owns information architecture, behavior, states, interactions, accessibility, and journeys.
 - Add both files to the `inputDocuments: []` frontmatter array.
@@ -144,7 +144,7 @@ Review the Architecture document for technical requirements that impact epic and
 
 **IMPORTANT**: The UX Design Specification is a first-class input document, not supplementary material. Requirements from the UX spec must be extracted with the same rigor as PRD functional requirements.
 
-Read the FULL UX design contract and extract ALL actionable work items. For a bmad-ux spine pair, read both `DESIGN.md` and `EXPERIENCE.md`:
+Read the FULL UX design contract and extract ALL actionable work items. For a wizz-ux spine pair, read both `DESIGN.md` and `EXPERIENCE.md`:
 
 **Look for:**
 

package/src/bmm-skills/3-solutioning/{bmad-create-epics-and-stories → wizz-create-epics-and-stories}/steps/step-02-design-epics.md

@@ -203,8 +203,8 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
 
 #### Menu Handling Logic:
 
-- IF A: Invoke the `bmad-advanced-elicitation` skill
-- IF P: Invoke the `bmad-party-mode` skill
+- IF A: Invoke the `wizz-advanced-elicitation` skill
+- IF P: Invoke the `wizz-party-mode` skill
 - IF C: Save approved epics_list to {planning_artifacts}/epics.md, update frontmatter, then read fully and follow: ./step-03-create-stories.md
 - IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
 

package/src/bmm-skills/3-solutioning/{bmad-create-epics-and-stories → wizz-create-epics-and-stories}/steps/step-03-create-stories.md

@@ -214,8 +214,8 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
 
 #### Menu Handling Logic:
 
-- IF A: Invoke the `bmad-advanced-elicitation` skill
-- IF P: Invoke the `bmad-party-mode` skill
+- IF A: Invoke the `wizz-advanced-elicitation` skill
+- IF P: Invoke the `wizz-party-mode` skill
 - IF C: Save content to {planning_artifacts}/epics.md, update frontmatter, then read fully and follow: ./step-04-final-validation.md
 - IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-final-menu-options)
 

package/src/bmm-skills/3-solutioning/{bmad-create-epics-and-stories → wizz-create-epics-and-stories}/steps/step-04-final-validation.md

@@ -132,12 +132,12 @@ HALT — wait for user input before proceeding.
 
 When C is selected, the workflow is complete and the epics.md is ready for development.
 
-Epics and Stories complete. Invoke the `bmad-help` skill.
+Epics and Stories complete. Invoke the `wizz-help` skill.
 
 Upon Completion of task output: offer to answer any questions about the Epics and Stories.
 
 ## On Complete
 
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+Run: `python3 {project-root}/_wizz/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.

package/src/bmm-skills/3-solutioning/{bmad-generate-project-context → wizz-generate-project-context}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-generate-project-context
+name: wizz-generate-project-context
 description: 'Create project-context.md with AI rules. Use when the user says "generate project context" or "create project context"'
 ---
 
@@ -30,13 +30,13 @@ This uses **micro-file architecture** for disciplined execution:
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: `python3 {project-root}/_wizz/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
+2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_wizz/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.
 
@@ -50,7 +50,7 @@ Treat every entry in `{workflow.persistent_facts}` as foundational context you c
 
 ### Step 4: Load Config
 
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
+Load config from `{project-root}/_wizz/bmm/config.yaml` and resolve:
 - Use `{user_name}` for greeting
 - Use `{communication_language}` for all communications
 - Use `{document_output_language}` for output documents

package/src/bmm-skills/3-solutioning/{bmad-generate-project-context → wizz-generate-project-context}/customize.toml

@@ -1,6 +1,6 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-generate-project-context. Mirrors the
+# Workflow customization surface for wizz-generate-project-context. Mirrors the
 # agent customization shape under the [workflow] namespace.
 
 [workflow]

package/src/bmm-skills/3-solutioning/{bmad-generate-project-context → wizz-generate-project-context}/steps/step-02-generate.md

@@ -30,8 +30,8 @@ This step will generate content and present choices for each rule category:
 
 ## PROTOCOL INTEGRATION:
 
-- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
-- When 'P' selected: Invoke the `bmad-party-mode` skill
+- When 'A' selected: Invoke the `wizz-advanced-elicitation` skill
+- When 'P' selected: Invoke the `wizz-party-mode` skill
 - PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
 - User accepts/rejects protocol changes before proceeding
 
@@ -270,7 +270,7 @@ After each category, show the generated rules and present choices:
 
 #### If 'A' (Advanced Elicitation):
 
-- Invoke the `bmad-advanced-elicitation` skill with current category rules
+- Invoke the `wizz-advanced-elicitation` skill with current category rules
 - Process enhanced rules that come back
 - Ask user: "Accept these enhanced rules for {{category}}? (y/n)"
 - If yes: Update content, then return to A/P/C menu
@@ -278,7 +278,7 @@ After each category, show the generated rules and present choices:
 
 #### If 'P' (Party Mode):
 
-- Invoke the `bmad-party-mode` skill with category rules context
+- Invoke the `wizz-party-mode` skill with category rules context
 - Process collaborative insights on implementation patterns
 - Ask user: "Accept these changes to {{category}} rules? (y/n)"
 - If yes: Update content, then return to A/P/C menu

package/src/bmm-skills/3-solutioning/{bmad-generate-project-context → wizz-generate-project-context}/steps/step-03-complete.md

@@ -279,6 +279,6 @@ The project context file serves as the critical "rules of the road" that agents
 
 ## On Complete
 
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+Run: `python3 {project-root}/_wizz/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.