wizz-method 1.0.0 → 1.0.2

package/build/site/llms-full.txt

@@ -5,60 +5,60 @@
 > Repository: https://github.com/bmad-code-org/BMAD-METHOD
 
 <document path="index.md">
-O **Wizz Method** é um método de desenvolvimento e produção de agência orientado por IA, em PT-BR. Ele acompanha o trabalho do início ao fim: da ideia e do planejamento até a implementação assistida por agentes. Oferece agentes especializados, fluxos guiados e planejamento que se ajusta à complexidade do projeto, seja uma correção pequena ou uma plataforma inteira.
+The **Wizz Method** is an AI-driven agency development and production method. It follows the work from start to finish: from idea and planning all the way through agent-assisted implementation. It provides specialized agents, guided workflows, and planning that adapts to your project's complexity, whether you're shipping a small fix or an entire platform.
 
-Se você já trabalha com assistentes de IA como Claude, Cursor ou GitHub Copilot, está pronto para começar.
+If you're comfortable working with AI assistants like Claude, Cursor, or GitHub Copilot, you're ready to get started.
 
-:::note[Fork independente do BMad Method]
-O Wizz Method é um fork independente do [BMad Method](https://github.com/bmad-code-org/BMAD-METHOD), mantido pela Wizz! comms. O motor continua o BMAD (creditado no arquivo `TRADEMARK.md` do repositório); a camada Wizz adiciona linguagem fácil em PT-BR, encerramento padrão (✅ o que fiz, ➡️ próximo passo, 🎯 comando) e roteamento via `wizz-maestro` para as skills da agência.
+:::note[Independent fork of the BMad Method]
+The Wizz Method is an independent fork of the [BMad Method](https://github.com/bmad-code-org/BMAD-METHOD), maintained by Wizz! comms. The engine is still BMAD (credited in the repository's `TRADEMARK.md`); the Wizz layer adds agency routing through `wizz-maestro`, a standardized closeout (✅ what I did, ➡️ next step, 🎯 command), and Portuguese-friendly defaults for the agency's skills.
 :::
 
-## Começando
+## Getting Started
 
-O jeito mais rápido de entender o método é experimentar.
+The fastest way to understand the method is to try it.
 
-- **[Primeiros passos](./tutorials/getting-started.md)**: instale e entenda como o Wizz Method funciona.
-- **[Mapa de fluxos](./reference/workflow-map.md)**: visão geral das fases, dos fluxos e da gestão de contexto.
+- **[Get started](./tutorials/getting-started.md)**: install and understand how the Wizz Method works.
+- **[Workflow map](./reference/workflow-map.md)**: an overview of the phases, workflows, and context management.
 
-:::tip[Só quer mergulhar?]
-Instale o Wizz Method e invoque o `wizz-maestro`. Ele lê seu pedido e despacha o agente certo com base no projeto e nos módulos instalados.
+:::tip[Just want to dive in?]
+Install the Wizz Method and invoke `wizz-maestro`. It reads your request and dispatches the right agent based on your project and installed modules.
 :::
 
-## Como usar esta documentação
+## How to Use These Docs
 
-Os docs estão organizados em quatro seções, conforme o que você quer fazer:
+These docs are organized into four sections based on what you're trying to do:
 
-| Seção             | Para quê                                                                                              |
-| ----------------- | ----------------------------------------------------------------------------------------------------- |
-| **Tutoriais**     | Orientado a aprender. Passo a passo para construir algo. Comece aqui se for novo.                     |
-| **Guias práticos**| Orientado a tarefas. Soluções para problemas específicos. "Como personalizo um agente?" mora aqui.    |
-| **Explicação**    | Orientado a entender. Mergulhos em conceitos e arquitetura. Leia quando quiser saber o porquê.        |
-| **Referência**    | Orientado a informação. Especificações técnicas de agentes, fluxos e configuração.                    |
+| Section           | Purpose                                                                                                    |
+| ----------------- | ---------------------------------------------------------------------------------------------------------- |
+| **Tutorials**     | Learning-oriented. Step-by-step guides that walk you through building something. Start here if you're new. |
+| **How-To Guides** | Task-oriented. Practical guides for solving specific problems. "How do I customize an agent?" lives here.  |
+| **Explanation**   | Understanding-oriented. Deep dives into concepts and architecture. Read when you want to know *why*.       |
+| **Reference**     | Information-oriented. Technical specifications for agents, workflows, and configuration.                   |
 
-## Expandir e personalizar
+## Expand and Customize
 
-Quer estender o Wizz Method com agentes, fluxos ou módulos próprios? A personalização da agência fica no módulo `wizz` (agentes, overrides em PT-BR e o `wizz-init`). Ajustes pessoais ficam em `_bmad/custom/`, que tem prioridade sobre os padrões do time.
+Want to extend the Wizz Method with your own agents, workflows, or modules? The agency customization lives in the `wizz` module (agents, overrides, and `wizz-init`). Personal tweaks go in `_wizz/custom/`, which takes precedence over the team defaults.
 
-## O que você vai precisar
+## What You'll Need
 
-O Wizz Method funciona com qualquer assistente de IA que aceite system prompts ou contexto de projeto. Opções populares:
+The Wizz Method works with any AI assistant that supports system prompts or project context. Popular options include:
 
-- **[Claude Code](https://code.claude.com)**: a CLI da Anthropic (recomendada).
-- **[Cursor](https://cursor.sh)**: editor de código com IA.
-- **[Codex CLI](https://github.com/openai/codex)**: agente de terminal da OpenAI.
+- **[Claude Code](https://code.claude.com)**: Anthropic's CLI (recommended).
+- **[Cursor](https://cursor.sh)**: AI-first code editor.
+- **[Codex CLI](https://github.com/openai/codex)**: OpenAI's terminal coding agent.
 
-Convém ter familiaridade com conceitos básicos de desenvolvimento (controle de versão, estrutura de projeto, fluxos ágeis). Nenhuma experiência prévia com sistemas de agentes é necessária. É para isso que esta documentação existe.
+You should be comfortable with basic development concepts (version control, project structure, agile workflows). No prior experience with agent systems is required. That's what these docs are for.
 
-## Comunidade
+## Community
 
-Tire dúvidas, mostre o que está construindo ou contribua:
+Ask questions, show what you're building, or contribute:
 
-- **[GitHub](https://github.com/wizzcomms/wizz-method)**: código-fonte, issues e contribuições.
-- **[Wizz! comms.](https://wizzcomms.com)**: a agência por trás do método.
+- **[GitHub](https://github.com/wizzcomms/wizz-method)**: source code, issues, and contributions.
+- **[Wizz! comms.](https://wizzcomms.com)**: the agency behind the method.
 
-## Próximo passo
+## Next Step
 
-Pronto para começar? **[Primeiros passos](./tutorials/getting-started.md)** e construa seu primeiro projeto.
+Ready to dive in? **[Get started](./tutorials/getting-started.md)** and build your first project.
 </document>
 
 <document path="tutorials/getting-started.md">
@@ -66,8 +66,8 @@ Build software faster using AI-powered workflows with specialized agents that gu
 
 ## What You'll Learn
 
-- Install and initialize BMad Method for a new project
-- Use **BMad-Help** — your intelligent guide that knows what to do next
+- Install and initialize the Wizz Method for a new project
+- Use **Wizz-Help** — your intelligent guide that knows what to do next
 - Choose the right planning track for your project size
 - Progress through phases from requirements to working code
 - Use agents and workflows effectively
@@ -81,35 +81,35 @@ Build software faster using AI-powered workflows with specialized agents that gu
   :::
 
 :::tip[The Easiest Path]
-**Install** → `npx bmad-method install`
-**Ask** → `bmad-help what should I do first?`
-**Build** → Let BMad-Help guide you workflow by workflow
+**Install** → `npx wizz-method install`
+**Ask** → `wizz-help what should I do first?`
+**Build** → Let Wizz-Help guide you workflow by workflow
 :::
 
-## Meet BMad-Help: Your Intelligent Guide
+## Meet Wizz-Help: Your Intelligent Guide
 
-**BMad-Help is the fastest way to get started with BMad.** You don't need to memorize workflows or phases — just ask, and BMad-Help will:
+**Wizz-Help is the fastest way to get started with the Wizz Method.** You don't need to memorize workflows or phases. Just ask, and Wizz-Help will:
 
 - **Inspect your project** to see what's already been done
 - **Show your options** based on which modules you have installed
 - **Recommend what's next** — including the first required task
 - **Answer questions** like "I have a SaaS idea, where do I start?"
 
-### How to Use BMad-Help
+### How to Use Wizz-Help
 
 Run it in your AI IDE by invoking the skill:
 
 ```
-bmad-help
+wizz-help
 ```
 
 Or combine it with a question for context-aware guidance:
 
 ```
-bmad-help I have an idea for a SaaS product, I already know all the features I want. where do I get started?
+wizz-help I have an idea for a SaaS product, I already know all the features I want. where do I get started?
 ```
 
-BMad-Help will respond with:
+Wizz-Help will respond with:
 
 - What's recommended for your situation
 - What the first required task is
@@ -117,31 +117,31 @@ BMad-Help will respond with:
 
 ### It Powers Workflows Too
 
-BMad-Help doesn't just answer questions — **it automatically runs at the end of every workflow** to tell you exactly what to do next. No guessing, no searching docs — just clear guidance on the next required workflow.
+Wizz-Help doesn't just answer questions. **It automatically runs at the end of every workflow** to tell you exactly what to do next. No guessing, no searching docs. Just clear guidance on the next required workflow.
 
 :::tip[Start Here]
-After installing BMad, invoke the `bmad-help` skill immediately. It will detect what modules you have installed and guide you to the right starting point for your project.
+After installing the Wizz Method, invoke the `wizz-help` skill immediately. It will detect what modules you have installed and guide you to the right starting point for your project.
 :::
 
-## Understanding BMad
+## Understanding the Wizz Method
 
-BMad helps you build software through guided workflows with specialized AI agents. The process follows four phases:
+The Wizz Method helps you build software through guided workflows with specialized AI agents. The process follows four phases:
 
 | Phase | Name           | What Happens                                                 |
 | ----- | -------------- | ------------------------------------------------------------ |
 | 1     | Analysis       | Brainstorming, research, product brief or PRFAQ _(optional)_ |
 | 2     | Planning       | Create requirements (PRD or spec)                            |
-| 3     | Solutioning    | Design architecture _(BMad Method/Enterprise only)_          |
+| 3     | Solutioning    | Design architecture _(Wizz Method/Enterprise only)_          |
 | 4     | Implementation | Build epic by epic, story by story                           |
 
 **[Open the Workflow Map](../reference/workflow-map.md)** to explore phases, workflows, and context management.
 
-Based on your project's complexity, BMad offers three planning tracks:
+Based on your project's complexity, the Wizz Method offers three planning tracks:
 
 | Track           | Best For                                               | Documents Created                      |
 | --------------- | ------------------------------------------------------ | -------------------------------------- |
 | **Quick Flow**  | Bug fixes, simple features, clear scope (1-15 stories) | Tech-spec only                         |
-| **BMad Method** | Products, platforms, complex features (10-50+ stories) | PRD + Architecture + UX                |
+| **Wizz Method** | Products, platforms, complex features (10-50+ stories) | PRD + Architecture + UX                |
 | **Enterprise**  | Compliance, multi-tenant systems (30+ stories)         | PRD + Architecture + Security + DevOps |
 
 :::note
@@ -153,30 +153,30 @@ Story counts are guidance, not definitions. Choose your track based on planning
 Open a terminal in your project directory and run:
 
 ```bash
-npx bmad-method install
+npx wizz-method install
 ```
 
 If you want the newest prerelease build instead of the default release channel, use `npx bmad-method@next install`.
 
-When prompted to select modules, choose **BMad Method**.
+When prompted to select modules, choose **Wizz Method**.
 
 The installer creates two folders:
 
-- `_bmad/` — agents, workflows, tasks, and configuration
-- `_bmad-output/` — empty for now, but this is where your artifacts will be saved
+- `_wizz/` — agents, workflows, tasks, and configuration
+- `_wizz-output/` — empty for now, but this is where your artifacts will be saved
 
 :::tip[Your Next Step]
 Open your AI IDE in the project folder and run:
 
 ```
-bmad-help
+wizz-help
 ```
 
-BMad-Help will detect what you've completed and recommend exactly what to do next. You can also ask it questions like "What are my options?" or "I have a SaaS idea, where should I start?"
+Wizz-Help will detect what you've completed and recommend exactly what to do next. You can also ask it questions like "What are my options?" or "I have a SaaS idea, where should I start?"
 :::
 
 :::note[How to Load Agents and Run Workflows]
-Each workflow has a **skill** you invoke by name in your IDE (e.g., `bmad-prd`). Your AI tool will recognize the `bmad-*` name and run it — you don't need to load agents separately. You can also invoke an agent skill directly for general conversation (e.g., `bmad-agent-pm` for the PM agent).
+Each workflow has a **skill** you invoke by name in your IDE (e.g., `wizz-prd`). Your AI tool will recognize the `bmad-*` name and run it — you don't need to load agents separately. You can also invoke an agent skill directly for general conversation (e.g., `wizz-agent-pm` for the PM agent).
 :::
 
 :::caution[Fresh Chats]
@@ -190,26 +190,26 @@ Work through phases 1-3. **Use fresh chats for each workflow.**
 :::tip[Project Context (Optional)]
 Before starting, consider creating `project-context.md` to document your technical preferences and implementation rules. This ensures all AI agents follow your conventions throughout the project.
 
-Create it manually at `_bmad-output/project-context.md` or generate it after architecture using `bmad-generate-project-context`. [Learn more](../explanation/project-context.md).
+Create it manually at `_wizz-output/project-context.md` or generate it after architecture using `wizz-generate-project-context`. [Learn more](../explanation/project-context.md).
 :::
 
 ### Phase 1: Analysis (Optional)
 
 All workflows in this phase are optional. [**Not sure which to use?**](../explanation/analysis-phase.md)
 
-- **brainstorming** (`bmad-brainstorming`) — Guided ideation
-- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Market, domain, and technical research
-- **product-brief** (`bmad-product-brief`) — Recommended foundation document when your concept is clear
-- **prfaq** (`bmad-prfaq`) — Working Backwards challenge to stress-test and forge your product concept
+- **brainstorming** (`wizz-brainstorming`) — Guided ideation
+- **research** (`wizz-market-research` / `wizz-domain-research` / `wizz-technical-research`) — Market, domain, and technical research
+- **product-brief** (`wizz-product-brief`) — Recommended foundation document when your concept is clear
+- **prfaq** (`wizz-prfaq`) — Working Backwards challenge to stress-test and forge your product concept
 
 ### Phase 2: Planning (Required)
 
-**For BMad Method and Enterprise tracks:**
+**For Wizz Method and Enterprise tracks:**
 
-1. Run `bmad-prd` in a new chat — state your intent (Create / Update / Validate) or let the skill ask
+1. Run `wizz-prd` in a new chat — state your intent (Create / Update / Validate) or let the skill ask
 2. Output: `prd.md`, `addendum.md`, `decision-log.md`
 
-:::note[`bmad-prd` intents]
+:::note[`wizz-prd` intents]
 
 - **Create** — coached discovery from scratch; the skill names the workspace folder and guides you to a PRD you're proud of
 - **Update** — point it at an existing PRD and a change signal; it surfaces conflicts before applying changes
@@ -218,18 +218,18 @@ All workflows in this phase are optional. [**Not sure which to use?**](../explan
 
 **For Quick Flow track:**
 
-- Run `bmad-quick-dev` — it handles planning and implementation in a single workflow, skip to implementation
+- Run `wizz-quick-dev` — it handles planning and implementation in a single workflow, skip to implementation
 
 :::note[UX Design (Optional)]
-If your project has a user interface, invoke the **UX-Designer agent** (`bmad-agent-ux-designer`) and run the UX design workflow (`bmad-ux`) after creating your PRD.
+If your project has a user interface, invoke the **UX-Designer agent** (`wizz-agent-ux-designer`) and run the UX design workflow (`wizz-ux`) after creating your PRD.
 :::
 
-### Phase 3: Solutioning (BMad Method/Enterprise)
+### Phase 3: Solutioning (Wizz Method/Enterprise)
 
 **Create Architecture**
 
-1. Invoke the **Architect agent** (`bmad-agent-architect`) in a new chat
-2. Run `bmad-create-architecture` (`bmad-create-architecture`)
+1. Invoke the **Architect agent** (`wizz-agent-architect`) in a new chat
+2. Run `wizz-create-architecture` (`wizz-create-architecture`)
 3. Output: Architecture document with technical decisions
 
 **Create Epics and Stories**
@@ -238,14 +238,14 @@ If your project has a user interface, invoke the **UX-Designer agent** (`bmad-ag
 Epics and stories are now created _after_ architecture. This produces better quality stories because architecture decisions (database, API patterns, tech stack) directly affect how work should be broken down.
 :::
 
-1. Invoke the **PM agent** (`bmad-agent-pm`) in a new chat
-2. Run `bmad-create-epics-and-stories` (`bmad-create-epics-and-stories`)
+1. Invoke the **PM agent** (`wizz-agent-pm`) in a new chat
+2. Run `wizz-create-epics-and-stories` (`wizz-create-epics-and-stories`)
 3. The workflow uses both PRD and Architecture to create technically-informed stories
 
 **Implementation Readiness Check** _(Highly Recommended)_
 
-1. Invoke the **Architect agent** (`bmad-agent-architect`) in a new chat
-2. Run `bmad-check-implementation-readiness` (`bmad-check-implementation-readiness`)
+1. Invoke the **Architect agent** (`wizz-agent-architect`) in a new chat
+2. Run `wizz-check-implementation-readiness` (`wizz-check-implementation-readiness`)
 3. Validates cohesion across all planning documents
 
 ## Step 2: Build Your Project
@@ -254,7 +254,7 @@ Once planning is complete, move to implementation. **Each workflow should run in
 
 ### Initialize Sprint Planning
 
-Invoke the **Developer agent** (`bmad-agent-dev`) and run `bmad-sprint-planning` (`bmad-sprint-planning`). This creates `sprint-status.yaml` to track all epics and stories.
+Invoke the **Developer agent** (`wizz-agent-dev`) and run `wizz-sprint-planning` (`wizz-sprint-planning`). This creates `sprint-status.yaml` to track all epics and stories.
 
 ### The Build Cycle
 
@@ -262,17 +262,17 @@ For each story, repeat this cycle with fresh chats:
 
 | Step | Agent | Workflow            | Command             | Purpose                            |
 | ---- | ----- | ------------------- | ------------------- | ---------------------------------- |
-| 1    | DEV   | `bmad-create-story` | `bmad-create-story` | Create story file from epic        |
-| 2    | DEV   | `bmad-dev-story`    | `bmad-dev-story`    | Implement the story                |
-| 3    | DEV   | `bmad-code-review`  | `bmad-code-review`  | Quality validation _(recommended)_ |
+| 1    | DEV   | `wizz-create-story` | `wizz-create-story` | Create story file from epic        |
+| 2    | DEV   | `wizz-dev-story`    | `wizz-dev-story`    | Implement the story                |
+| 3    | DEV   | `wizz-code-review`  | `wizz-code-review`  | Quality validation _(recommended)_ |
 
-After completing all stories in an epic, invoke the **Developer agent** (`bmad-agent-dev`) and run `bmad-retrospective` (`bmad-retrospective`).
+After completing all stories in an epic, invoke the **Developer agent** (`wizz-agent-dev`) and run `wizz-retrospective` (`wizz-retrospective`).
 
 ## What You've Accomplished
 
-You've learned the foundation of building with BMad:
+You've learned the foundation of building with the Wizz Method:
 
-- Installed BMad and configured it for your IDE
+- Installed the Wizz Method and configured it for your IDE
 - Initialized a project with your chosen planning track
 - Created planning documents (PRD, Architecture, Epics & Stories)
 - Understood the build cycle for implementation
@@ -281,8 +281,8 @@ Your project now has:
 
 ```text
 your-project/
-├── _bmad/                                   # BMad configuration
-├── _bmad-output/
+├── _wizz/                                   # Wizz Method configuration
+├── _wizz-output/
 │   ├── planning-artifacts/
 │   │   ├── PRD.md                           # Your requirements document
 │   │   ├── architecture.md                  # Technical decisions
@@ -297,42 +297,42 @@ your-project/
 
 | Workflow                              | Command                               | Agent     | Purpose                                    |
 | ------------------------------------- | ------------------------------------- | --------- | ------------------------------------------ |
-| **`bmad-help`** ⭐                    | `bmad-help`                           | Any       | **Your intelligent guide — ask anything!** |
-| `bmad-prd`                            | `bmad-prd`                            | Any       | Create, update, or validate a PRD          |
-| `bmad-create-architecture`            | `bmad-create-architecture`            | Architect | Create architecture document               |
-| `bmad-generate-project-context`       | `bmad-generate-project-context`       | Analyst   | Create project context file                |
-| `bmad-create-epics-and-stories`       | `bmad-create-epics-and-stories`       | PM        | Break down PRD into epics                  |
-| `bmad-check-implementation-readiness` | `bmad-check-implementation-readiness` | Architect | Validate planning cohesion                 |
-| `bmad-sprint-planning`                | `bmad-sprint-planning`                | DEV       | Initialize sprint tracking                 |
-| `bmad-create-story`                   | `bmad-create-story`                   | DEV       | Create a story file                        |
-| `bmad-dev-story`                      | `bmad-dev-story`                      | DEV       | Implement a story                          |
-| `bmad-code-review`                    | `bmad-code-review`                    | DEV       | Review implemented code                    |
+| **`wizz-help`** ⭐                    | `wizz-help`                           | Any       | **Your intelligent guide — ask anything!** |
+| `wizz-prd`                            | `wizz-prd`                            | Any       | Create, update, or validate a PRD          |
+| `wizz-create-architecture`            | `wizz-create-architecture`            | Architect | Create architecture document               |
+| `wizz-generate-project-context`       | `wizz-generate-project-context`       | Analyst   | Create project context file                |
+| `wizz-create-epics-and-stories`       | `wizz-create-epics-and-stories`       | PM        | Break down PRD into epics                  |
+| `wizz-check-implementation-readiness` | `wizz-check-implementation-readiness` | Architect | Validate planning cohesion                 |
+| `wizz-sprint-planning`                | `wizz-sprint-planning`                | DEV       | Initialize sprint tracking                 |
+| `wizz-create-story`                   | `wizz-create-story`                   | DEV       | Create a story file                        |
+| `wizz-dev-story`                      | `wizz-dev-story`                      | DEV       | Implement a story                          |
+| `wizz-code-review`                    | `wizz-code-review`                    | DEV       | Review implemented code                    |
 
 ## Common Questions
 
 **Do I always need architecture?**
-Only for BMad Method and Enterprise tracks. Quick Flow skips from spec to implementation.
+Only for Wizz Method and Enterprise tracks. Quick Flow skips from spec to implementation.
 
 **Can I change my plan later?**
-Yes. The `bmad-correct-course` workflow handles scope changes mid-implementation.
+Yes. The `wizz-correct-course` workflow handles scope changes mid-implementation.
 
 **What if I want to brainstorm first?**
-Invoke the Analyst agent (`bmad-agent-analyst`) and run `bmad-brainstorming` (`bmad-brainstorming`) before starting your PRD.
+Invoke the Analyst agent (`wizz-agent-analyst`) and run `wizz-brainstorming` (`wizz-brainstorming`) before starting your PRD.
 
 **Do I need to follow a strict order?**
 Not strictly. Once you learn the flow, you can run workflows directly using the Quick Reference above.
 
 ## Getting Help
 
-:::tip[First Stop: BMad-Help]
-**Invoke `bmad-help` anytime** — it's the fastest way to get unstuck. Ask it anything:
+:::tip[First Stop: Wizz-Help]
+**Invoke `wizz-help` anytime** — it's the fastest way to get unstuck. Ask it anything:
 
 - "What should I do after installing?"
 - "I'm stuck on workflow X"
 - "What are my options for Y?"
 - "Show me what's been done so far"
 
-BMad-Help inspects your project, detects what you've completed, and tells you exactly what to do next.
+Wizz-Help inspects your project, detects what you've completed, and tells you exactly what to do next.
 :::
 
 - **During workflows** — Agents guide you with questions and explanations
@@ -342,20 +342,20 @@ BMad-Help inspects your project, detects what you've completed, and tells you ex
 
 :::tip[Remember These]
 
-- **Start with `bmad-help`** — Your intelligent guide that knows your project and options
+- **Start with `wizz-help`** — Your intelligent guide that knows your project and options
 - **Always use fresh chats** — Start a new chat for each workflow
-- **Track matters** — Quick Flow uses `bmad-quick-dev`; Method/Enterprise need PRD and architecture
-- **BMad-Help runs automatically** — Every workflow ends with guidance on what's next
+- **Track matters** — Quick Flow uses `wizz-quick-dev`; Method/Enterprise need PRD and architecture
+- **Wizz-Help runs automatically** — Every workflow ends with guidance on what's next
   :::
 
-Ready to start? Install BMad, invoke `bmad-help`, and let your intelligent guide lead the way.
+Ready to start? Install the Wizz Method, invoke `wizz-help`, and let your intelligent guide lead the way.
 </document>
 
 <document path="how-to/customize-bmad.md">
 Tailor agent personas, inject domain context, add capabilities, and configure workflow behavior -- all without modifying installed files. Your customizations survive every update.
 
-:::tip[Don't want to hand-author TOML? Use `bmad-customize`]
-The `bmad-customize` skill is a guided authoring helper for the **per-skill agent/workflow override surface** described in this doc. It scans what's customizable in your installation, helps you choose the right surface (agent vs workflow) for your intent, writes the override file for you, and verifies the merge landed. Central-config overrides (`_bmad/custom/config.toml`) are out of scope for v1 — hand-author those per the Central Configuration section below. Run the skill whenever you want to make a per-skill change; this doc is the reference for *what* each surface exposes and how merging works.
+:::tip[Don't want to hand-author TOML? Use `wizz-customize`]
+The `wizz-customize` skill is a guided authoring helper for the **per-skill agent/workflow override surface** described in this doc. It scans what's customizable in your installation, helps you choose the right surface (agent vs workflow) for your intent, writes the override file for you, and verifies the merge landed. Central-config overrides (`_wizz/custom/config.toml`) are out of scope for v1 — hand-author those per the Central Configuration section below. Run the skill whenever you want to make a per-skill change; this doc is the reference for *what* each surface exposes and how merging works.
 :::
 
 ## When to Use This
@@ -368,7 +368,7 @@ The `bmad-customize` skill is a guided authoring helper for the **per-skill agen
 
 :::note[Prerequisites]
 
-- BMad installed in your project (see [How to Install BMad](./install-bmad.md))
+- Wizz Method installed in your project (see [How to Install Wizz Method](./install-bmad.md))
 - Python 3.11+ on your PATH (for the resolver script -- uses stdlib `tomllib`, no `pip install`, no `uv`, no virtualenv)
 - A text editor for TOML files
 :::
@@ -380,12 +380,12 @@ Every customizable skill ships a `customize.toml` file with its defaults. This f
 ### Three-Layer Override Model
 
 ```text
-Priority 1 (wins): _bmad/custom/{skill-name}.user.toml  (personal, gitignored)
-Priority 2:        _bmad/custom/{skill-name}.toml        (team/org, committed)
+Priority 1 (wins): _wizz/custom/{skill-name}.user.toml  (personal, gitignored)
+Priority 2:        _wizz/custom/{skill-name}.toml        (team/org, committed)
 Priority 3 (last): skill's own customize.toml                    (defaults)
 ```
 
-The `_bmad/custom/` folder starts empty. Files only appear when someone actively customizes.
+The `_wizz/custom/` folder starts empty. Files only appear when someone actively customizes.
 
 ### Merge Rules (by shape, not by field name)
 
@@ -400,7 +400,7 @@ The resolver applies four structural rules. Field names are never special-cased
 
 **No removal mechanism.** Overrides cannot delete base items. If you need to suppress a default menu item, override it by `code` with a no-op description or prompt. If you need to restructure an array more deeply, fork the skill.
 
-**The `code` / `id` convention.** BMad uses `code` (short identifier like `"BP"` or `"R1"`) and `id` (longer stable identifier) as merge keys on arrays of tables. If you author a custom array-of-tables that should be replaceable-by-key rather than append-only, pick **one** convention (either `code` on every item, or `id` on every item) and stick with it across the whole array. Mixing `code` on some items and `id` on others falls back to append — the resolver won't guess which key to merge on.
+**The `code` / `id` convention.** The Wizz Method uses `code` (short identifier like `"BP"` or `"R1"`) and `id` (longer stable identifier) as merge keys on arrays of tables. If you author a custom array-of-tables that should be replaceable-by-key rather than append-only, pick **one** convention (either `code` on every item, or `id` on every item) and stick with it across the whole array. Mixing `code` on some items and `id` on others falls back to append — the resolver won't guess which key to merge on.
 
 ### Some agent fields are read-only
 
@@ -413,7 +413,7 @@ The resolver applies four structural rules. Field names are never special-cased
 Look at the skill's `customize.toml` in its installed directory. For example, the PM agent:
 
 ```text
-.claude/skills/bmad-agent-pm/customize.toml
+.claude/skills/wizz-agent-pm/customize.toml
 ```
 
 (Path varies by IDE -- Cursor uses `.cursor/skills/`, Cline uses `.cline/skills/`, and so on.)
@@ -422,12 +422,12 @@ This file is the canonical schema. Every field you see is customizable (excludin
 
 ### 2. Create Your Override File
 
-Create the `_bmad/custom/` directory in your project root if it doesn't exist. Then create a file named after the skill:
+Create the `_wizz/custom/` directory in your project root if it doesn't exist. Then create a file named after the skill:
 
 ```text
-_bmad/custom/
-  bmad-agent-pm.toml        # team overrides (committed to git)
-  bmad-agent-pm.user.toml   # personal preferences (gitignored)
+_wizz/custom/
+  wizz-agent-pm.toml        # team overrides (committed to git)
+  wizz-agent-pm.user.toml   # personal preferences (gitignored)
 ```
 
 :::caution[Do NOT copy the whole `customize.toml`]
@@ -439,7 +439,7 @@ Copying the full `customize.toml` into an override is actively harmful: the next
 **Example — changing the icon and adding one principle**:
 
 ```toml
-# _bmad/custom/bmad-agent-pm.toml
+# _wizz/custom/wizz-agent-pm.toml
 # Just the fields I'm changing. Everything else inherits.
 
 [agent]
@@ -453,12 +453,12 @@ This appends the new principle to the defaults (leaving the shipped principles i
 
 ### 3. Customize What You Need
 
-All examples below assume BMad's flat agent schema. Fields live directly under `[agent]` — no nested `metadata` or `persona` sub-tables.
+All examples below assume the Wizz Method's flat agent schema. Fields live directly under `[agent]` — no nested `metadata` or `persona` sub-tables.
 
 **Scalars (icon, role, identity, communication_style).** Scalar overrides win. You only need to set the fields you're changing:
 
 ```toml
-# _bmad/custom/bmad-agent-pm.toml
+# _wizz/custom/wizz-agent-pm.toml
 
 [agent]
 icon = "🏥"
@@ -480,7 +480,7 @@ persistent_facts = [
   "All PRDs require legal sign-off before engineering kickoff.",
   "Target users are clinicians, not patients -- frame examples accordingly.",
   "file:{project-root}/docs/compliance/hipaa-overview.md",
-  "file:{project-root}/_bmad/custom/company-glossary.md",
+  "file:{project-root}/_wizz/custom/company-glossary.md",
 ]
 
 # Adds to the agent's value system
@@ -499,13 +499,13 @@ activation_steps_prepend = [
 # Runs AFTER greet, BEFORE the menu. Use for context-heavy setup that should
 # happen once the user has been acknowledged.
 activation_steps_append = [
-  "Read {project-root}/_bmad/custom/company-glossary.md if it exists.",
+  "Read {project-root}/_wizz/custom/company-glossary.md if it exists.",
 ]
 ```
 
 **The two hooks do different jobs.** Prepend runs before greeting so the agent can load context it needs to personalize the greeting itself. Append runs after greeting so the user isn't staring at a blank terminal while heavy scans complete.
 
-**Menu customization (merge by `code`).** The menu is an array of tables. Each item has a `code` field (BMad convention), so the resolver merges by code: matching codes replace in place, new codes append.
+**Menu customization (merge by `code`).** The menu is an array of tables. Each item has a `code` field (Wizz Method convention), so the resolver merges by code: matching codes replace in place, new codes append.
 
 TOML array-of-tables syntax uses `[[agent.menu]]` for each item:
 
@@ -521,7 +521,7 @@ skill = "custom-create-epics"
 code = "RC"
 description = "Run compliance pre-check"
 prompt = """
-Read {project-root}/_bmad/custom/compliance-checklist.md
+Read {project-root}/_wizz/custom/compliance-checklist.md
 and scan all documents in {planning_artifacts} against it.
 Report any gaps and cite the relevant regulatory section.
 """
@@ -529,16 +529,16 @@ Report any gaps and cite the relevant regulatory section.
 
 Each menu item has exactly one of `skill` (invokes a registered skill) or `prompt` (executes the text directly). Items not listed in your override keep their defaults.
 
-**Referencing files.** When a field's text needs to point at a file (in `persistent_facts`, `activation_steps_prepend`/`activation_steps_append`, or a menu item's `prompt`), use a full path rooted at `{project-root}`. Even if the file sits next to your override in `_bmad/custom/`, spell out the full path: `{project-root}/_bmad/custom/info.md`. The agent resolves `{project-root}` at runtime.
+**Referencing files.** When a field's text needs to point at a file (in `persistent_facts`, `activation_steps_prepend`/`activation_steps_append`, or a menu item's `prompt`), use a full path rooted at `{project-root}`. Even if the file sits next to your override in `_wizz/custom/`, spell out the full path: `{project-root}/_wizz/custom/info.md`. The agent resolves `{project-root}` at runtime.
 
 ### 4. Personal vs Team
 
-**Team file** (`bmad-agent-pm.toml`): Committed to git. Shared across the org. Use for compliance rules, company persona, custom capabilities.
+**Team file** (`wizz-agent-pm.toml`): Committed to git. Shared across the org. Use for compliance rules, company persona, custom capabilities.
 
-**Personal file** (`bmad-agent-pm.user.toml`): Gitignored automatically. Use for tone adjustments, personal workflow preferences, and private facts the agent should keep in mind.
+**Personal file** (`wizz-agent-pm.user.toml`): Gitignored automatically. Use for tone adjustments, personal workflow preferences, and private facts the agent should keep in mind.
 
 ```toml
-# _bmad/custom/bmad-agent-pm.user.toml
+# _wizz/custom/wizz-agent-pm.user.toml
 
 [agent]
 persistent_facts = [
@@ -551,41 +551,41 @@ persistent_facts = [
 On activation, the agent's SKILL.md runs a shared Python script that does the three-layer merge and returns the resolved block as JSON. The script uses the Python standard library's `tomllib` module (no external dependencies), so plain `python3` is enough:
 
 ```bash
-python3 {project-root}/_bmad/scripts/resolve_customization.py \
+python3 {project-root}/_wizz/scripts/resolve_customization.py \
   --skill {skill-root} \
   --key agent
 ```
 
 **Requirements**: Python 3.11+ (earlier versions don't include `tomllib`). No `pip install`, no `uv`, no virtualenv. Check with `python3 --version`. Some platforms (macOS without Homebrew, Ubuntu 22.04) default `python3` to 3.10 or earlier, so you may need to install 3.11+ separately.
 
-`--skill` points at the skill's installed directory (where `customize.toml` lives). The skill name is derived from the directory's basename, and the script looks up `_bmad/custom/{skill-name}.toml` and `{skill-name}.user.toml` automatically.
+`--skill` points at the skill's installed directory (where `customize.toml` lives). The skill name is derived from the directory's basename, and the script looks up `_wizz/custom/{skill-name}.toml` and `{skill-name}.user.toml` automatically.
 
 Useful invocations:
 
 ```bash
 # Resolve the full agent block
-python3 {project-root}/_bmad/scripts/resolve_customization.py \
-  --skill /abs/path/to/bmad-agent-pm \
+python3 {project-root}/_wizz/scripts/resolve_customization.py \
+  --skill /abs/path/to/wizz-agent-pm \
   --key agent
 
 # Resolve a single field
-python3 {project-root}/_bmad/scripts/resolve_customization.py \
-  --skill /abs/path/to/bmad-agent-pm \
+python3 {project-root}/_wizz/scripts/resolve_customization.py \
+  --skill /abs/path/to/wizz-agent-pm \
   --key agent.icon
 
 # Full dump
-python3 {project-root}/_bmad/scripts/resolve_customization.py \
-  --skill /abs/path/to/bmad-agent-pm
+python3 {project-root}/_wizz/scripts/resolve_customization.py \
+  --skill /abs/path/to/wizz-agent-pm
 ```
 
 Output is always JSON. If the script is unavailable on a given platform, the SKILL.md tells the agent to read the three TOML files directly and apply the same merge rules.
 
 ## Workflow Customization
 
-Workflows (skills that drive multi-step processes like `bmad-product-brief`) share the same override mechanism as agents. Their customizable surface lives under `[workflow]` instead of `[agent]`:
+Workflows (skills that drive multi-step processes like `wizz-product-brief`) share the same override mechanism as agents. Their customizable surface lives under `[workflow]` instead of `[agent]`:
 
 ```toml
-# _bmad/custom/bmad-product-brief.toml
+# _wizz/custom/wizz-product-brief.toml
 
 [workflow]
 # Same prepend/append semantics as agents — runs before and after the workflow's
@@ -616,7 +616,7 @@ Customizable workflows run their activation in a fixed sequence so you know exac
 1. Resolve the `[workflow]` block (base → team → user merge)
 2. Execute `activation_steps_prepend` in order
 3. Load `persistent_facts` as foundational context for the run
-4. Load config (`_bmad/bmm/config.yaml`) and resolve standard variables (project name, languages, paths, date)
+4. Load config (`_wizz/bmm/config.yaml`) and resolve standard variables (project name, languages, paths, date)
 5. Greet the user
 6. Execute `activation_steps_append` in order
 
@@ -632,22 +632,22 @@ If you need a fine-grained knob that isn't exposed yet, either use `activation_s
 
 ## Central Configuration
 
-Per-skill `customize.toml` covers **deep behavior** (hooks, menus, persistent_facts, persona overrides for a single agent or workflow). A separate surface covers **cross-cutting state** — install answers and the agent roster that external skills like `bmad-party-mode`, `bmad-retrospective`, and `bmad-advanced-elicitation` consume. That surface lives in four TOML files at project root:
+Per-skill `customize.toml` covers **deep behavior** (hooks, menus, persistent_facts, persona overrides for a single agent or workflow). A separate surface covers **cross-cutting state** — install answers and the agent roster that external skills like `wizz-party-mode`, `wizz-retrospective`, and `wizz-advanced-elicitation` consume. That surface lives in four TOML files at project root:
 
 ```text
-_bmad/config.toml               (installer-owned)  team scope:   install answers + agent roster
-_bmad/config.user.toml          (installer-owned)  user scope:   user_name, language, skill level
-_bmad/custom/config.toml        (human-authored)   team overrides (committed to git)
-_bmad/custom/config.user.toml   (human-authored)   personal overrides (gitignored)
+_wizz/config.toml               (installer-owned)  team scope:   install answers + agent roster
+_wizz/config.user.toml          (installer-owned)  user scope:   user_name, language, skill level
+_wizz/custom/config.toml        (human-authored)   team overrides (committed to git)
+_wizz/custom/config.user.toml   (human-authored)   personal overrides (gitignored)
 ```
 
 ### Four-Layer Merge
 
 ```text
-Priority 1 (wins): _bmad/custom/config.user.toml
-Priority 2:        _bmad/custom/config.toml
-Priority 3:        _bmad/config.user.toml
-Priority 4 (base): _bmad/config.toml
+Priority 1 (wins): _wizz/custom/config.user.toml
+Priority 2:        _wizz/custom/config.toml
+Priority 3:        _wizz/config.user.toml
+Priority 4 (base): _wizz/config.toml
 ```
 
 Same structural rules as per-skill customize (scalars override, tables deep-merge, `code`/`id`-keyed arrays merge by key, other arrays append).
@@ -656,30 +656,30 @@ Same structural rules as per-skill customize (scalars override, tables deep-merg
 
 The installer partitions answers by the `scope:` declared on each prompt in `module.yaml`:
 
-- `[core]` and `[modules.<code>]` sections — install answers. Scope `team` lands in `_bmad/config.toml`; scope `user` lands in `_bmad/config.user.toml`.
+- `[core]` and `[modules.<code>]` sections — install answers. Scope `team` lands in `_wizz/config.toml`; scope `user` lands in `_wizz/config.user.toml`.
 - `[agents.<code>]` — agent essence (code, name, title, icon, description, team) distilled from each module's `module.yaml` `agents:` block. Always team-scoped.
 
 ### Editing Rules
 
-- `_bmad/config.toml` and `_bmad/config.user.toml` are **regenerated every install** from the answers collected during the installer flow. Treat them as read-only outputs — direct edits will be overwritten on the next install. To change an install answer durably, re-run the installer (it remembers your prior answers as defaults) or shadow the value in `_bmad/custom/config.toml`.
-- `_bmad/custom/config.toml` and `_bmad/custom/config.user.toml` are **never touched** by the installer. This is the correct surface for custom agents, agent descriptor overrides, team-enforced settings, and any value you want to pin regardless of install answers.
+- `_wizz/config.toml` and `_wizz/config.user.toml` are **regenerated every install** from the answers collected during the installer flow. Treat them as read-only outputs — direct edits will be overwritten on the next install. To change an install answer durably, re-run the installer (it remembers your prior answers as defaults) or shadow the value in `_wizz/custom/config.toml`.
+- `_wizz/custom/config.toml` and `_wizz/custom/config.user.toml` are **never touched** by the installer. This is the correct surface for custom agents, agent descriptor overrides, team-enforced settings, and any value you want to pin regardless of install answers.
 
 ### Example — Rebrand an Agent
 
 ```toml
-# _bmad/custom/config.toml (committed to git, applies to every developer)
+# _wizz/custom/config.toml (committed to git, applies to every developer)
 
-[agents.bmad-agent-pm]
+[agents.wizz-agent-pm]
 description = "Healthcare PM — regulatory-aware, stakeholder-driven, FDA-shaped questions first."
 icon = "🏥"
 ```
 
-The resolver merges over the installer-written `[agents.bmad-agent-pm]`. `bmad-party-mode` and any other roster consumer pick up the new description automatically.
+The resolver merges over the installer-written `[agents.wizz-agent-pm]`. `wizz-party-mode` and any other roster consumer pick up the new description automatically.
 
 ### Example — Add a Fictional Agent
 
 ```toml
-# _bmad/custom/config.user.toml (personal, gitignored)
+# _wizz/custom/config.user.toml (personal, gitignored)
 
 [agents.kirk]
 team = "startrek"
@@ -694,7 +694,7 @@ No skill folder required — the essence alone is enough for party-mode to spawn
 ### Example — Override Module Install Settings
 
 ```toml
-# _bmad/custom/config.toml
+# _wizz/custom/config.toml
 
 [modules.bmm]
 planning_artifacts = "/shared/org-planning-artifacts"
@@ -706,24 +706,24 @@ The override wins over whatever each developer answered during their local insta
 
 | Need | Use |
 |---|---|
-| Add MCP tool calls to every dev workflow | Per-skill: `_bmad/custom/bmad-agent-dev.toml` `persistent_facts` |
-| Add a menu item to an agent | Per-skill: `_bmad/custom/bmad-agent-{role}.toml` `[[agent.menu]]` |
-| Swap a workflow's output template | Per-skill: `_bmad/custom/{workflow}.toml` scalar override |
-| Rebrand an agent's public descriptor | **Central**: `_bmad/custom/config.toml` `[agents.<code>]` |
-| Add a custom or fictional agent to the roster | **Central**: `_bmad/custom/config.*.toml` new `[agents.<code>]` entry |
-| Pin team-enforced install settings | **Central**: `_bmad/custom/config.toml` `[modules.<code>]` or `[core]` |
+| Add MCP tool calls to every dev workflow | Per-skill: `_wizz/custom/wizz-agent-dev.toml` `persistent_facts` |
+| Add a menu item to an agent | Per-skill: `_wizz/custom/bmad-agent-{role}.toml` `[[agent.menu]]` |
+| Swap a workflow's output template | Per-skill: `_wizz/custom/{workflow}.toml` scalar override |
+| Rebrand an agent's public descriptor | **Central**: `_wizz/custom/config.toml` `[agents.<code>]` |
+| Add a custom or fictional agent to the roster | **Central**: `_wizz/custom/config.*.toml` new `[agents.<code>]` entry |
+| Pin team-enforced install settings | **Central**: `_wizz/custom/config.toml` `[modules.<code>]` or `[core]` |
 
 Use both surfaces in the same project as needed.
 
 ## Worked Examples
 
-For enterprise-oriented recipes (shaping an agent across every workflow it dispatches, enforcing org conventions, publishing outputs to Confluence and Jira, customizing the agent roster, and swapping in your own output templates), see [How to Expand BMad for Your Organization](./expand-bmad-for-your-org.md).
+For enterprise-oriented recipes (shaping an agent across every workflow it dispatches, enforcing org conventions, publishing outputs to Confluence and Jira, customizing the agent roster, and swapping in your own output templates), see [How to Expand the Wizz Method for Your Organization](./expand-bmad-for-your-org.md).
 
 ## Troubleshooting
 
 **Customization not appearing?**
 
-- Verify your file is in `_bmad/custom/` with the correct skill name
+- Verify your file is in `_wizz/custom/` with the correct skill name
 - Check TOML syntax: strings must be quoted, table headers use `[section]`, array-of-tables use `[[section]]`, and any scalar or array keys for a table must appear *before* any of that table's `[[subtables]]` in the file
 - For agents, customization lives under `[agent]` -- fields written below that header belong to `agent` until another table header begins
 - Remember `agent.name` and `agent.title` are read-only; overrides there have no effect
@@ -734,33 +734,33 @@ For enterprise-oriented recipes (shaping an agent across every workflow it dispa
 
 **Need to see what's customizable?**
 
-- Run the `bmad-customize` skill — it enumerates every customizable skill installed in your project, shows which ones already have overrides, and walks you through adding or updating one
+- Run the `wizz-customize` skill — it enumerates every customizable skill installed in your project, shows which ones already have overrides, and walks you through adding or updating one
 - Or read the skill's `customize.toml` directly — every field there is customizable (except `name` and `title`)
 
 **Need to reset?**
 
-- Delete your override file from `_bmad/custom/` -- the skill falls back to its built-in defaults
+- Delete your override file from `_wizz/custom/` -- the skill falls back to its built-in defaults
 </document>
 
 <document path="how-to/established-projects.md">
-Use BMad Method effectively when working on existing projects and legacy codebases.
+Use the Wizz Method effectively when working on existing projects and legacy codebases.
 
-This guide covers the essential workflow for onboarding to existing projects with BMad Method.
+This guide covers the essential workflow for onboarding to existing projects with the Wizz Method.
 
 :::note[Prerequisites]
 
-- BMad Method installed (`npx bmad-method install`)
+- Wizz Method installed (`npx wizz-method install`)
 - An existing codebase you want to work on
 - Access to an AI-powered IDE (Claude Code or Cursor)
   :::
 
 ## Step 1: Clean Up Completed Planning Artifacts
 
-If you have completed all PRD epics and stories through the BMad process, clean up those files. Archive them, delete them, or rely on version history if needed. Do not keep these files in:
+If you have completed all PRD epics and stories through the Wizz Method process, clean up those files. Archive them, delete them, or rely on version history if needed. Do not keep these files in:
 
 - `docs/`
-- `_bmad-output/planning-artifacts/`
-- `_bmad-output/implementation-artifacts/`
+- `_wizz-output/planning-artifacts/`
+- `_wizz-output/implementation-artifacts/`
 
 ## Step 2: Create Project Context
 
@@ -771,7 +771,7 @@ Generate `project-context.md` to capture your existing codebase patterns and con
 Run the generate project context workflow:
 
 ```bash
-bmad-generate-project-context
+wizz-generate-project-context
 ```
 
 This scans your codebase to identify:
@@ -782,7 +782,7 @@ This scans your codebase to identify:
 - Testing approaches
 - Framework-specific patterns
 
-You can review and refine the generated file, or create it manually at `_bmad-output/project-context.md` if you prefer.
+You can review and refine the generated file, or create it manually at `_wizz-output/project-context.md` if you prefer.
 
 [Learn more about project context](../explanation/project-context.md)
 
@@ -795,25 +795,25 @@ Your `docs/` folder should contain succinct, well-organized documentation that a
 - Architecture
 - Any other relevant project information
 
-For complex projects, consider using the `bmad-document-project` workflow. It offers runtime variants that will scan your entire project and document its actual current state.
+For complex projects, consider using the `wizz-document-project` workflow. It offers runtime variants that will scan your entire project and document its actual current state.
 
 ## Step 3: Get Help
 
-### BMad-Help: Your Starting Point
+### Wizz-Help: Your Starting Point
 
-**Run `bmad-help` anytime you're unsure what to do next.** This intelligent guide:
+**Run `wizz-help` anytime you're unsure what to do next.** This intelligent guide:
 
 - Inspects your project to see what's already been done
 - Shows options based on your installed modules
 - Understands natural language queries
 
 ```
-bmad-help I have an existing Rails app, where should I start?
-bmad-help What's the difference between quick-flow and full method?
-bmad-help Show me what workflows are available
+wizz-help I have an existing Rails app, where should I start?
+wizz-help What's the difference between quick-flow and full method?
+wizz-help Show me what workflows are available
 ```
 
-BMad-Help also **automatically runs at the end of every workflow**, providing clear guidance on exactly what to do next.
+Wizz-Help also **automatically runs at the end of every workflow**, providing clear guidance on exactly what to do next.
 
 ### Choosing Your Approach
 
@@ -821,8 +821,8 @@ You have two primary options depending on the scope of changes:
 
 | Scope                          | Recommended Approach                                                                                                                          |
 | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Small updates or additions** | Run `bmad-quick-dev` to clarify intent, plan, implement, and review in a single workflow. The full four-phase BMad Method is likely overkill. |
-| **Major changes or additions** | Start with the BMad Method, applying as much or as little rigor as needed.                                                                    |
+| **Small updates or additions** | Run `wizz-quick-dev` to clarify intent, plan, implement, and review in a single workflow. The full four-phase Wizz Method is likely overkill. |
+| **Major changes or additions** | Start with the Wizz Method, applying as much or as little rigor as needed.                                                                    |
 
 ### During PRD Creation
 
@@ -858,17 +858,17 @@ Pay close attention here to prevent reinventing the wheel or making decisions th
 </document>
 
 <document path="how-to/expand-bmad-for-your-org.md">
-BMad's customization surface lets an organization reshape behavior without editing installed files or forking skills. This guide walks through six recipes that cover most enterprise needs.
+The Wizz Method's customization surface lets an organization reshape behavior without editing installed files or forking skills. This guide walks through six recipes that cover most enterprise needs.
 
 :::note[Prerequisites]
 
-- BMad installed in your project (see [How to Install BMad](./install-bmad.md))
-- Familiarity with the customization model (see [How to Customize BMad](./customize-bmad.md))
+- Wizz Method installed in your project (see [How to Install Wizz Method](./install-bmad.md))
+- Familiarity with the customization model (see [How to Customize Wizz Method](./customize-bmad.md))
 - Python 3.11+ on PATH (for the resolver — stdlib only, no `pip install`)
 :::
 
 :::tip[Applying these recipes]
-The **per-skill recipes** below (Recipes 1–4) can be applied by running the `bmad-customize` skill and describing the intent — it will pick the right surface, author the override file, and verify the merge. Recipe 5 (central-config overrides to the agent roster) is out of scope for v1 of the skill and remains hand-authored. The recipes here are the source of truth for *what* to override; `bmad-customize` handles the *how* for the agent/workflow surface.
+The **per-skill recipes** below (Recipes 1–4) can be applied by running the `wizz-customize` skill and describing the intent — it will pick the right surface, author the override file, and verify the merge. Recipe 5 (central-config overrides to the agent roster) is out of scope for v1 of the skill and remains hand-authored. The recipes here are the source of truth for *what* to override; `wizz-customize` handles the *how* for the agent/workflow surface.
 :::
 
 ## The Three-Layer Mental Model
@@ -877,9 +877,9 @@ Before picking a recipe, know where your override lands:
 
 | Layer | Where overrides live | Scope |
 |---|---|---|
-| **Agent** (e.g. Amelia, Mary, John) | `[agent]` section of `_bmad/custom/bmad-agent-{role}.toml` | Travels with the persona into **every workflow the agent dispatches** |
-| **Workflow** (e.g. product-brief, create-prd) | `[workflow]` section of `_bmad/custom/{workflow-name}.toml` | Applies only to that workflow's run |
-| **Central config** | `[agents.*]`, `[core]`, `[modules.*]` in `_bmad/custom/config.toml` | Agent roster (who's available for party-mode, retrospective, elicitation), install-time settings pinned org-wide |
+| **Agent** (e.g. Amelia, Mary, John) | `[agent]` section of `_wizz/custom/bmad-agent-{role}.toml` | Travels with the persona into **every workflow the agent dispatches** |
+| **Workflow** (e.g. product-brief, create-prd) | `[workflow]` section of `_wizz/custom/{workflow-name}.toml` | Applies only to that workflow's run |
+| **Central config** | `[agents.*]`, `[core]`, `[modules.*]` in `_wizz/custom/config.toml` | Agent roster (who's available for party-mode, retrospective, elicitation), install-time settings pinned org-wide |
 
 Rule of thumb: if the rule should apply everywhere an engineer does dev work, customize the **dev agent**. If it applies only when someone writes a product brief, customize the **product-brief workflow**. If it changes *who's in the room* (rename an agent, add a custom voice, enforce a shared artifact path), edit **central config**.
 
@@ -890,7 +890,7 @@ Rule of thumb: if the rule should apply everywhere an engineer does dev work, cu
 **Example: Amelia (dev agent) always uses Context7 for library docs, and falls back to Linear when a story isn't found in the epics list.**
 
 ```toml
-# _bmad/custom/bmad-agent-dev.toml
+# _wizz/custom/wizz-agent-dev.toml
 
 [agent]
 
@@ -905,8 +905,8 @@ persistent_facts = [
 **Why this works:** Two sentences reshape every dev workflow in the org, with no per-workflow duplication and no source changes. Every new engineer who pulls the repo inherits the conventions automatically.
 
 **Team file vs personal file:**
-- `bmad-agent-dev.toml`: committed to git; applies to the whole team
-- `bmad-agent-dev.user.toml`: gitignored; personal preferences layered on top
+- `wizz-agent-dev.toml`: committed to git; applies to the whole team
+- `wizz-agent-dev.user.toml`: gitignored; personal preferences layered on top
 
 ## Recipe 2: Enforce Organizational Conventions Inside a Specific Workflow
 
@@ -915,7 +915,7 @@ persistent_facts = [
 **Example: every product brief must include compliance fields, and the agent knows about the org's publishing conventions.**
 
 ```toml
-# _bmad/custom/bmad-product-brief.toml
+# _wizz/custom/wizz-product-brief.toml
 
 [workflow]
 
@@ -935,7 +935,7 @@ persistent_facts = [
 **Example: briefs auto-publish to Confluence and offer optional Jira epic creation.**
 
 ```toml
-# _bmad/custom/bmad-product-brief.toml
+# _wizz/custom/wizz-product-brief.toml
 
 [workflow]
 
@@ -979,7 +979,7 @@ and ask the user to publish manually.
 **Example: point the product-brief workflow at an enterprise-owned template.**
 
 ```toml
-# _bmad/custom/bmad-product-brief.toml
+# _wizz/custom/wizz-product-brief.toml
 
 [workflow]
 brief_template = "{project-root}/docs/enterprise/brief-template.md"
@@ -988,22 +988,22 @@ brief_template = "{project-root}/docs/enterprise/brief-template.md"
 **How it works:** The workflow's `customize.toml` ships with `brief_template = "resources/brief-template.md"` (bare path, resolves from skill root). Your override points at a file under `{project-root}`, so the agent reads your template in Stage 4 instead of the shipped one.
 
 **Template authoring tips:**
-- Keep templates in `{project-root}/docs/` or `{project-root}/_bmad/custom/templates/` so they version alongside the override file
+- Keep templates in `{project-root}/docs/` or `{project-root}/_wizz/custom/templates/` so they version alongside the override file
 - Use the same structural conventions as the shipped template (section headings, frontmatter); the agent adapts to what's there
 - For multi-org repos, use `.user.toml` to let individual teams point at their own templates without touching the committed team file
 
 ## Recipe 5: Customize the Agent Roster
 
-**Use case:** Change *who's in the room* for roster-driven skills like `bmad-party-mode`, `bmad-retrospective`, and `bmad-advanced-elicitation`, without editing any source or forking. Three common variants follow.
+**Use case:** Change *who's in the room* for roster-driven skills like `wizz-party-mode`, `wizz-retrospective`, and `wizz-advanced-elicitation`, without editing any source or forking. Three common variants follow.
 
-### 5a. Rebrand a BMad Agent Org-Wide
+### 5a. Rebrand a Wizz Method Agent Org-Wide
 
 Every real agent has a descriptor the installer synthesizes from `module.yaml`. Override it to shift voice and framing across every roster consumer:
 
 ```toml
-# _bmad/custom/config.toml (committed — applies to every developer)
+# _wizz/custom/config.toml (committed — applies to every developer)
 
-[agents.bmad-agent-analyst]
+[agents.wizz-agent-analyst]
 description = "Mary the Regulatory-Aware Business Analyst — channels Porter and Minto, but lives and breathes FDA audit trails. Speaks like a forensic investigator presenting a case file."
 ```
 
@@ -1014,7 +1014,7 @@ Party-mode spawns Mary with the new description. The analyst activation itself s
 A full descriptor is enough for roster-based features, with no skill folder needed. Useful for personality variety in party mode or brainstorming sessions:
 
 ```toml
-# _bmad/custom/config.user.toml (personal — gitignored)
+# _wizz/custom/config.user.toml (personal — gitignored)
 
 [agents.spock]
 team = "startrek"
@@ -1031,14 +1031,14 @@ icon = "⚕️"
 description = "Country doctor's warmth, short fuse. 'Dammit Jim, I'm a doctor not a ___.' Ethics-driven counterweight to Spock."
 ```
 
-Ask party-mode to "invite the Enterprise crew." It filters by `team = "startrek"` and spawns Spock and McCoy with those descriptors. Real BMad agents (Mary, Amelia) can sit at the same table if you ask them to.
+Ask party-mode to "invite the Enterprise crew." It filters by `team = "startrek"` and spawns Spock and McCoy with those descriptors. Real Wizz Method agents (Mary, Amelia) can sit at the same table if you ask them to.
 
 ### 5c. Pin Team Install Settings
 
 The installer prompts each developer for values like `planning_artifacts` path. When the org needs one shared answer across the team, pin it in central config — any developer's local prompt answer gets overridden at resolution time:
 
 ```toml
-# _bmad/custom/config.toml
+# _wizz/custom/config.toml
 
 [modules.bmm]
 planning_artifacts = "{project-root}/shared/planning"
@@ -1048,13 +1048,13 @@ implementation_artifacts = "{project-root}/shared/implementation"
 document_output_language = "English"
 ```
 
-Personal settings like `user_name`, `communication_language`, or `user_skill_level` stay under each developer's own `_bmad/config.user.toml`. The team file shouldn't touch those.
+Personal settings like `user_name`, `communication_language`, or `user_skill_level` stay under each developer's own `_wizz/config.user.toml`. The team file shouldn't touch those.
 
 **Why central config vs per-agent customize.toml:** Per-agent files shape how *one* agent behaves when it activates. Central config shapes what roster consumers *see when they look at the field:* which agents exist, what they're called, what team they belong to, and the shared install settings the whole repo agrees on. Two surfaces, different jobs.
 
 ## Reinforce Global Rules in Your IDE's Session File
 
-BMad customizations load when a skill is activated. Many IDE tools also load a global instruction file at the **start of every session**, before any skill runs (`CLAUDE.md`, `AGENTS.md`, `.cursor/rules/`, `.github/copilot-instructions.md`, etc). For rules that should hold even outside BMad skills, restate the critical ones there too.
+Wizz Method customizations load when a skill is activated. Many IDE tools also load a global instruction file at the **start of every session**, before any skill runs (`CLAUDE.md`, `AGENTS.md`, `.cursor/rules/`, `.github/copilot-instructions.md`, etc). For rules that should hold even outside Wizz Method skills, restate the critical ones there too.
 
 **When to double up:**
 - A rule is important enough that a plain chat conversation (no skill active) should still follow it
@@ -1069,27 +1069,27 @@ BMad customizations load when a skill is activated. Many IDE tools also load a g
 before relying on training-data knowledge. -->
 ```
 
-One sentence, loaded every session. It pairs with the `bmad-agent-dev.toml` customization so the rule applies both inside Amelia's workflows and during ad-hoc chats with the assistant. Each layer owns its own scope:
+One sentence, loaded every session. It pairs with the `wizz-agent-dev.toml` customization so the rule applies both inside Amelia's workflows and during ad-hoc chats with the assistant. Each layer owns its own scope:
 
 | Layer | Scope | Use for |
 |---|---|---|
-| IDE session file (`CLAUDE.md` / `AGENTS.md`) | Every session, before any skill activates | Short, universal rules that should survive outside BMad |
-| BMad agent customization | Every workflow the agent dispatches | Agent-persona-specific behavior |
-| BMad workflow customization | One workflow run | Workflow-specific output shape, publishing hooks, templates |
-| BMad central config | Agent roster + shared install settings | Who's in the room and what shared paths the team uses |
+| IDE session file (`CLAUDE.md` / `AGENTS.md`) | Every session, before any skill activates | Short, universal rules that should survive outside the Wizz Method |
+| Wizz agent customization | Every workflow the agent dispatches | Agent-persona-specific behavior |
+| Wizz workflow customization | One workflow run | Workflow-specific output shape, publishing hooks, templates |
+| Wizz central config | Agent roster + shared install settings | Who's in the room and what shared paths the team uses |
 
 Keep the IDE file **succinct**. A dozen well-chosen lines are more effective than a sprawling list. Models read it every turn, and noise crowds out signal.
 
 ## Recipe 6: Advanced Integration Patterns
 
-Several BMad workflows expose a richer configuration surface beyond the basics covered in Recipes 1–5. These patterns — on-demand knowledge sources, automatic output publishing, finalize-time doc standards, and swappable templates — appear across multiple workflows. Check a workflow's `customize.toml` to see which fields it exposes; the examples below use `bmad-prd` because it exposes all of them, but the same patterns apply wherever the field appears.
+Several Wizz Method workflows expose a richer configuration surface beyond the basics covered in Recipes 1–5. These patterns — on-demand knowledge sources, automatic output publishing, finalize-time doc standards, and swappable templates — appear across multiple workflows. Check a workflow's `customize.toml` to see which fields it exposes; the examples below use `wizz-prd` because it exposes all of them, but the same patterns apply wherever the field appears.
 
 ### On-demand knowledge sources (`external_sources`)
 
 Connect the workflow to internal knowledge bases, competitive databases, or compliance references. The agent consults these on demand when the conversation surfaces a matching need — never preemptively.
 
 ```toml
-# _bmad/custom/bmad-prd.toml  (same pattern works in any workflow that exposes external_sources)
+# _wizz/custom/wizz-prd.toml  (same pattern works in any workflow that exposes external_sources)
 
 [workflow]
 external_sources = [
@@ -1105,7 +1105,7 @@ Each entry is a natural-language directive naming the MCP tool, the trigger cond
 Route completed artifacts to external systems of record after the workflow finalizes. Unlike `on_complete` (Recipe 3), `external_handoffs` is a dedicated append array — team entries stack, and each handoff fires independently with graceful degradation if a tool is unavailable.
 
 ```toml
-# _bmad/custom/bmad-prd.toml  (same pattern works in any workflow that exposes external_handoffs)
+# _wizz/custom/wizz-prd.toml  (same pattern works in any workflow that exposes external_handoffs)
 
 [workflow]
 external_handoffs = [
@@ -1121,7 +1121,7 @@ If a named tool is unavailable, the handoff is skipped and flagged — local fil
 Apply org writing standards to human-consumed documents at finalize, after content is complete but before the user sees the output. Each entry is a `skill:`, `file:`, or plain-text directive; passes run as parallel subagents.
 
 ```toml
-# _bmad/custom/bmad-prd.toml  (same pattern works in any workflow that exposes doc_standards)
+# _wizz/custom/wizz-prd.toml  (same pattern works in any workflow that exposes doc_standards)
 
 [workflow]
 doc_standards = [
@@ -1138,7 +1138,7 @@ doc_standards = [
 Workflows that produce structured documents typically expose template and checklist paths as overridable scalars. Point them at org-owned files under `{project-root}` to enforce a different structure without editing any source.
 
 ```toml
-# _bmad/custom/bmad-prd.toml
+# _wizz/custom/wizz-prd.toml
 
 [workflow]
 # Regulated-industry PRD structure
@@ -1148,14 +1148,14 @@ prd_template = "{project-root}/docs/enterprise/prd-template-hipaa.md"
 validation_checklist = "{project-root}/docs/enterprise/prd-checklist-regulated.md"
 ```
 
-The agent adapts to whatever structure the template defines. Keep templates under `{project-root}/docs/` or `{project-root}/_bmad/custom/templates/` so they version alongside the override file. For multi-org repos, use `.user.toml` to let teams point at their own templates without touching the committed team file.
+The agent adapts to whatever structure the template defines. Keep templates under `{project-root}/docs/` or `{project-root}/_wizz/custom/templates/` so they version alongside the override file. For multi-org repos, use `.user.toml` to let teams point at their own templates without touching the committed team file.
 
 ## Combining Recipes
 
-All six recipes compose. A realistic enterprise override for `bmad-product-brief` might set `persistent_facts` (Recipe 2), `on_complete` (Recipe 3), and `brief_template` (Recipe 4) in one file. The agent-level rule (Recipe 1) lives in a separate file under the agent's name, central config (Recipe 5) pins the shared roster and team settings, advanced integration patterns (Recipe 6) configure external sources and handoffs, and all layers apply in parallel.
+All six recipes compose. A realistic enterprise override for `wizz-product-brief` might set `persistent_facts` (Recipe 2), `on_complete` (Recipe 3), and `brief_template` (Recipe 4) in one file. The agent-level rule (Recipe 1) lives in a separate file under the agent's name, central config (Recipe 5) pins the shared roster and team settings, advanced integration patterns (Recipe 6) configure external sources and handoffs, and all layers apply in parallel.
 
 ```toml
-# _bmad/custom/bmad-product-brief.toml (workflow-level)
+# _wizz/custom/wizz-product-brief.toml (workflow-level)
 
 [workflow]
 persistent_facts = ["..."]
@@ -1164,17 +1164,17 @@ on_complete = """ ... """
 ```
 
 ```toml
-# _bmad/custom/bmad-agent-analyst.toml (agent-level — Mary dispatches product-brief)
+# _wizz/custom/wizz-agent-analyst.toml (agent-level — Mary dispatches product-brief)
 
 [agent]
 persistent_facts = ["Always include a 'Regulatory Review' section when the domain involves healthcare, finance, or children's data."]
 ```
 
-Result: Mary loads the regulatory-review rule at persona activation. When the user picks the product-brief menu item, the workflow loads its own conventions on top, writes to the enterprise template, and publishes to Confluence on completion. Every layer contributes, and none of them required editing BMad source.
+Result: Mary loads the regulatory-review rule at persona activation. When the user picks the product-brief menu item, the workflow loads its own conventions on top, writes to the enterprise template, and publishes to Confluence on completion. Every layer contributes, and none of them required editing Wizz Method source.
 
 ## Troubleshooting
 
-**Override not taking effect?** Check that the file is under `_bmad/custom/` with the exact skill directory name (e.g. `bmad-agent-dev.toml`, not `bmad-dev.toml`). See [How to Customize BMad](./customize-bmad.md#troubleshooting).
+**Override not taking effect?** Check that the file is under `_wizz/custom/` with the exact skill directory name (e.g. `wizz-agent-dev.toml`, not `bmad-dev.toml`). See [How to Customize Wizz Method](./customize-bmad.md#troubleshooting).
 
 **MCP tool name unknown?** Use the exact name the MCP server exposes in the current session. Ask Claude Code to list available MCP tools if unsure. Hardcoded names in `persistent_facts` or `on_complete` won't work if the MCP server isn't connected.
 
@@ -1182,32 +1182,32 @@ Result: Mary loads the regulatory-review rule at persona activation. When the us
 </document>
 
 <document path="how-to/get-answers-about-bmad.md">
-Use BMad's built-in help, source docs, or the community to get answers — from quickest to most thorough.
+Use the Wizz Method's built-in help, source docs, or the community to get answers, from quickest to most thorough.
 
-## 1. Ask BMad-Help
+## 1. Ask Wizz-Help
 
-The fastest way to get answers. The `bmad-help` skill is available directly in your AI session and handles over 80% of questions — it inspects your project, sees what you've completed, and tells you what to do next.
+The fastest way to get answers. The `wizz-help` skill is available directly in your AI session and handles over 80% of questions. It inspects your project, sees what you've completed, and tells you what to do next.
 
 ```
-bmad-help I have a SaaS idea and know all the features. Where do I start?
-bmad-help What are my options for UX design?
-bmad-help I'm stuck on the PRD workflow
+wizz-help I have a SaaS idea and know all the features. Where do I start?
+wizz-help What are my options for UX design?
+wizz-help I'm stuck on the PRD workflow
 ```
 
 :::tip
-You can also use `/bmad-help` or `$bmad-help` depending on your platform, but just `bmad-help` should work everywhere.
+You can also use `/wizz-help` or `$wizz-help` depending on your platform, but just `wizz-help` should work everywhere.
 :::
 
 ## 2. Go Deeper with Source
 
-BMad-Help draws on your installed configuration. For questions about BMad's internals, history, or architecture — or if you're researching BMad before installing — point your AI at the source directly.
+Wizz-Help draws on your installed configuration. For questions about the Wizz Method's internals, history, or architecture, or if you're researching the Wizz Method before installing, point your AI at the source directly.
 
-Clone or open the [BMAD-METHOD repo](https://github.com/bmad-code-org/BMAD-METHOD) and ask your AI about it. Any agent-capable tool (Claude Code, Cursor, Windsurf, etc.) can read the source and answer questions directly.
+Clone or open the [wizz-method repo](https://github.com/wizzcomms/wizz-method) and ask your AI about it. Any agent-capable tool (Claude Code, Cursor, Windsurf, etc.) can read the source and answer questions directly.
 
 :::note[Example]
-**Q:** "Tell me the fastest way to build something with BMad"
+**Q:** "Tell me the fastest way to build something with the Wizz Method"
 
-**A:** Use Quick Flow: Run `bmad-quick-dev` — it clarifies your intent, plans, implements, reviews, and presents results in a single workflow, skipping the full planning phases.
+**A:** Use Quick Flow: Run `wizz-quick-dev` — it clarifies your intent, plans, implements, reviews, and presents results in a single workflow, skipping the full planning phases.
 :::
 
 **Tips for better answers:**
@@ -1217,11 +1217,11 @@ Clone or open the [BMAD-METHOD repo](https://github.com/bmad-code-org/BMAD-METHO
 
 ### Not using an agent? Use the docs site
 
-If your AI can't read local files (ChatGPT, Claude.ai, etc.), fetch [llms-full.txt](https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt) into your session — it's a single-file snapshot of the BMad documentation.
+If your AI can't read local files (ChatGPT, Claude.ai, etc.), fetch the llms-full.txt from the wizz-method repo into your session. It's a single-file snapshot of the Wizz Method documentation.
 
 ## 3. Ask Someone
 
-If neither BMad-Help nor the source answered your question, you now have a much better question to ask.
+If neither Wizz-Help nor the source answered your question, you now have a much better question to ask.
 
 | Channel                 | Use For                    |
 | ----------------------- | -------------------------- |
@@ -1230,7 +1230,7 @@ If neither BMad-Help nor the source answered your question, you now have a much
 
 **Discord:** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
 
-**GitHub Issues:** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)
+**GitHub Issues:** [github.com/wizzcomms/wizz-method/issues](https://github.com/wizzcomms/wizz-method/issues)
 _You!_
 _Stuck_
 _in the queue—_
@@ -1258,11 +1258,11 @@ _—Claude_
 </document>
 
 <document path="how-to/install-bmad.md">
-Use `npx bmad-method install` to set up BMad in your project. One command handles first installs, upgrades, channel switching, and scripted CI runs. This page covers all of it.
+Use `npx wizz-method install` to set up the Wizz Method in your project. One command handles first installs, upgrades, channel switching, and scripted CI runs. This page covers all of it.
 
 ## When to Use This
 
-- Starting a new project with BMad
+- Starting a new project with the Wizz Method
 - Adding or removing modules on an existing install
 - Switching a module to main-HEAD or pinning to a specific release
 - Scripting installs for CI pipelines, Dockerfiles, or enterprise rollouts
@@ -1271,14 +1271,14 @@ Use `npx bmad-method install` to set up BMad in your project. One command handle
 
 - **Node.js** 20.12+ (the installer requires it)
 - **Git** (for cloning external modules)
-- **An AI tool** such as Claude Code or Cursor (run `npx bmad-method install --list-tools` to see all supported tools)
+- **An AI tool** such as Claude Code or Cursor (run `npx wizz-method install --list-tools` to see all supported tools)
 
 :::
 
 ## First-time install (the fast path)
 
 ```bash
-npx bmad-method install
+npx wizz-method install
 ```
 
 The interactive flow asks you five things:
@@ -1322,7 +1322,7 @@ The `bmad-method` npm package itself has two dist-tags:
 
 | Command                               | What you get                                                      |
 | ------------------------------------- | ----------------------------------------------------------------- |
-| `npx bmad-method install` (`@latest`) | Latest stable installer release                                   |
+| `npx wizz-method install` (`@latest`) | Latest stable installer release                                   |
 | `npx bmad-method@next install`        | Latest prerelease installer, auto-published on every push to main |
 
 **The installer binary determines your core and bmm versions.** Those two modules ship bundled inside the installer package rather than being cloned from separate repos.
@@ -1331,7 +1331,7 @@ The `bmad-method` npm package itself has two dist-tags:
 
 They're stapled to the installer binary you ran:
 
-- `npx bmad-method install` → latest stable core and bmm
+- `npx wizz-method install` → latest stable core and bmm
 - `npx bmad-method@next install` → prerelease core and bmm
 - `node /path/to/local-checkout/tools/installer/bmad-cli.js install` → whatever your local checkout has
 
@@ -1339,7 +1339,7 @@ They're stapled to the installer binary you ran:
 
 ## Updating an existing install
 
-Running `npx bmad-method install` in a directory that already contains `_bmad/` gives you a menu:
+Running `npx wizz-method install` in a directory that already contains `_wizz/` gives you a menu:
 
 | Choice             | What it does                                                                                                                                                |
 | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -1399,13 +1399,13 @@ Precedence when flags overlap: `--pin` beats `--next=` beats `--channel` / `--al
 **Default install — latest stable for everything:**
 
 ```bash
-npx bmad-method install --yes --modules bmm,bmb,cis --tools claude-code
+npx wizz-method install --yes --modules bmm,bmb,cis --tools claude-code
 ```
 
 **Enterprise pin — reproducible byte-for-byte:**
 
 ```bash
-npx bmad-method install --yes \
+npx wizz-method install --yes \
   --modules bmm,bmb,cis \
   --pin bmb=v1.7.0 --pin cis=v0.2.0 \
   --tools claude-code
@@ -1414,13 +1414,13 @@ npx bmad-method install --yes \
 **Bleeding edge — externals on main HEAD:**
 
 ```bash
-npx bmad-method install --yes --modules bmm,bmb --all-next --tools claude-code
+npx wizz-method install --yes --modules bmm,bmb --all-next --tools claude-code
 ```
 
 **Add a module to an existing install** (keep everything else):
 
 ```bash
-npx bmad-method install --yes --action update \
+npx wizz-method install --yes --action update \
   --modules bmm,bmb,gds
 ```
 
@@ -1429,19 +1429,19 @@ npx bmad-method install --yes --action update \
 **Mix channels — bmb on next, gds on stable:**
 
 ```bash
-npx bmad-method install --yes --action update \
+npx wizz-method install --yes --action update \
   --modules bmm,bmb,cis,gds \
   --next=bmb
 ```
 
 ### Module config overrides
 
-`--set <module>.<key>=<value>` lets you set any module config option non-interactively. It's repeatable and scales to every module — present and future. The flag is applied as a post-install patch: the installer runs its normal flow first, then `--set` upserts each value into `_bmad/config.toml` (team scope) or `_bmad/config.user.toml` (user scope), and into `_bmad/<module>/config.yaml` so declared values carry forward to the next install.
+`--set <module>.<key>=<value>` lets you set any module config option non-interactively. It's repeatable and scales to every module — present and future. The flag is applied as a post-install patch: the installer runs its normal flow first, then `--set` upserts each value into `_wizz/config.toml` (team scope) or `_wizz/config.user.toml` (user scope), and into `_wizz/<module>/config.yaml` so declared values carry forward to the next install.
 
 **Example — install bmm with explicit project knowledge and skill level:**
 
 ```bash
-npx bmad-method install --yes \
+npx wizz-method install --yes \
   --modules bmm \
   --tools claude-code \
   --set bmm.project_knowledge=research \
@@ -1451,7 +1451,7 @@ npx bmad-method install --yes \
 **Discover available keys for a module:**
 
 ```bash
-npx bmad-method install --list-options bmm
+npx wizz-method install --list-options bmm
 ```
 
 `--list-options` (no argument) lists every key the installer can find locally — built-in modules (`core`, `bmm`) plus any currently cached official modules. The cache is per-machine and can be cleared, so previously installed officials won't appear on a fresh checkout or an ephemeral CI worker until they're installed again. Community and custom modules aren't enumerated here; read the module's `module.yaml` directly to see what keys it declares.
@@ -1460,8 +1460,8 @@ npx bmad-method install --list-options bmm
 
 - **Routing.** The patch step looks for `[modules.<module>] <key>` (or `[core] <key>`) in `config.user.toml` first; if found there, it updates that file. Otherwise it writes to the team-scope `config.toml`. So user-scope keys (e.g. `core.user_name`, `bmm.user_skill_level`) end up in `config.user.toml` and team-scope keys end up in `config.toml`, matching the partition the installer uses.
 - **Verbatim values.** The value is written exactly as you provided it — no `result:` template rendering. To get the rendered form (e.g. `{project-root}/research`), pass it explicitly: `--set bmm.project_knowledge='{project-root}/research'`.
-- **Carry-forward, declared keys.** Values for keys declared in `module.yaml` survive subsequent installs because they're also written to `_bmad/<module>/config.yaml`, which the installer reads as the prompt default on the next run.
-- **Carry-forward, undeclared keys.** A value for a key the module's schema doesn't declare lands in `config.toml` for the current install but won't be re-emitted on the next install (the manifest writer's schema-strict partition drops unknown keys). Re-pass `--set` if you need it sticky, or edit `_bmad/config.toml` directly.
+- **Carry-forward, declared keys.** Values for keys declared in `module.yaml` survive subsequent installs because they're also written to `_wizz/<module>/config.yaml`, which the installer reads as the prompt default on the next run.
+- **Carry-forward, undeclared keys.** A value for a key the module's schema doesn't declare lands in `config.toml` for the current install but won't be re-emitted on the next install (the manifest writer's schema-strict partition drops unknown keys). Re-pass `--set` if you need it sticky, or edit `_wizz/config.toml` directly.
 - **No validation.** `single-select` values aren't checked against the allowed choices, and unknown keys aren't rejected — whatever you assert is written.
 - **Modules not in `--modules`.** Setting a value for a module you didn't include prints a warning and the value is dropped (no file gets created for an uninstalled module).
 
@@ -1479,7 +1479,7 @@ Set `GITHUB_TOKEN=<personal access token>` in the environment to raise the limit
 
 ## What got installed
 
-After any install, `_bmad/_config/manifest.yaml` records exactly what's on disk:
+After any install, `_wizz/_config/manifest.yaml` records exactly what's on disk:
 
 ```yaml
 modules:
@@ -1496,7 +1496,7 @@ The `sha` field is written for git-backed modules (external, community, and URL-
 For cross-machine reproducibility, don't rely on rerunning the same `--modules` command. Stable-channel installs resolve to the highest released tag **at install time**, so a later rerun lands on whatever has been released since. Convert the recorded tags from `manifest.yaml` into explicit `--pin` flags on the target machine, e.g.:
 
 ```bash
-npx bmad-method install --yes --modules bmb,cis \
+npx wizz-method install --yes --modules bmb,cis \
   --pin bmb=v1.7.0 --pin cis=v0.4.2 --tools claude-code
 ```
 
@@ -1512,7 +1512,7 @@ The tag you passed to `--pin` doesn't exist in the module's repo. Check the repo
 
 ### A pinned install keeps upgrading
 
-Pinned installs don't upgrade. Quick-update applies patches and minors on stable channel only; it won't touch `pinned` or `next`. If a pinned install changed, open `_bmad/_config/manifest.yaml` — `channel: pinned` plus a fixed `version` and `sha` should hold across runs unless you explicitly override via flags.
+Pinned installs don't upgrade. Quick-update applies patches and minors on stable channel only; it won't touch `pinned` or `next`. If a pinned install changed, open `_wizz/_config/manifest.yaml` — `channel: pinned` plus a fixed `version` and `sha` should hold across runs unless you explicitly override via flags.
 
 ### `--pin bmm=X` didn't do anything
 
@@ -1520,13 +1520,13 @@ bmm is a bundled module — `--pin` and `--next=` don't apply. Use `npx bmad-met
 </document>
 
 <document path="how-to/install-custom-modules.md">
-Use the BMad installer to add modules from the community registry, third-party Git repositories, or local file paths.
+Use the Wizz Method installer to add modules from the community registry, third-party Git repositories, or local file paths.
 
 ## When to Use This
 
-- Installing a community-contributed module from the BMad registry
+- Installing a community-contributed module from the Wizz Method registry
 - Installing a module from a third-party Git repository (GitHub, GitLab, Bitbucket, self-hosted)
-- Testing a module you are developing locally with BMad Builder
+- Testing a module you are developing locally with Wizz Builder
 - Installing modules from a private or self-hosted Git server
 
 :::note[Prerequisites]
@@ -1535,12 +1535,12 @@ Requires [Node.js](https://nodejs.org) v20.12+ and `npx` (included with npm). Cu
 
 ## Community Modules
 
-Community modules are curated in the [BMad plugins marketplace](https://github.com/bmad-code-org/bmad-plugins-marketplace). They are organized by category and are pinned to an approved commit for safety.
+Community modules are curated in the [Wizz Method plugins marketplace](https://github.com/wizzcomms/wizz-method). They are organized by category and are pinned to an approved commit for safety.
 
 ### 1. Run the Installer
 
 ```bash
-npx bmad-method install
+npx wizz-method install
 ```
 
 ### 2. Browse the Community Catalog
@@ -1596,7 +1596,7 @@ The installer clones the repository (for URLs) or reads directly from disk (for
 Use the `--custom-source` flag to install custom modules from the command line:
 
 ```bash
-npx bmad-method install \
+npx wizz-method install \
   --directory . \
   --custom-source /path/to/my-module \
   --tools claude-code \
@@ -1606,7 +1606,7 @@ npx bmad-method install \
 When `--custom-source` is provided without `--modules`, only core and the custom modules are installed. To include official modules as well, add `--modules`:
 
 ```bash
-npx bmad-method install \
+npx wizz-method install \
   --directory . \
   --modules bmm \
   --custom-source https://gitlab.com/myorg/my-module \
@@ -1637,10 +1637,10 @@ The `.claude-plugin/marketplace.json` path is a standard convention adopted acro
 
 ## Local Development Workflow
 
-If you are building a module with [BMad Builder](https://github.com/bmad-code-org/bmad-builder), you can install it directly from your working directory:
+If you are building a module with [Wizz Builder](https://github.com/wizzcomms/wizz-method), you can install it directly from your working directory:
 
 ```bash
-npx bmad-method install \
+npx wizz-method install \
   --directory ~/my-project \
   --custom-source ~/my-module-repo/skills \
   --tools claude-code \
@@ -1650,16 +1650,16 @@ npx bmad-method install \
 Local sources are referenced by path, not copied to a cache. When you update your module source and reinstall, the installer picks up the latest changes.
 
 :::caution[Source Removal]
-If you delete the local source directory after installation, the installed module files in `_bmad/` are preserved. The module will be skipped during updates until the source path is restored.
+If you delete the local source directory after installation, the installed module files in `_wizz/` are preserved. The module will be skipped during updates until the source path is restored.
 :::
 
 ## What You Get
 
-After installation, custom modules appear in `_bmad/` alongside official modules:
+After installation, custom modules appear in `_wizz/` alongside official modules:
 
 ```
 your-project/
-├── _bmad/
+├── _wizz/
 │   ├── core/              # Built-in core module
 │   ├── bmm/               # Official module (if selected)
 │   ├── my-module/         # Your custom module
@@ -1682,14 +1682,14 @@ Custom modules participate in the normal update flow:
 
 ## Creating Your Own Modules
 
-Use [BMad Builder](https://github.com/bmad-code-org/bmad-builder) to create modules that others can install:
+Use [Wizz Builder](https://github.com/wizzcomms/wizz-method) to create modules that others can install:
 
 1. Run `bmad-module-builder` to scaffold your module structure
 2. Add skills, agents, and workflows with the various bmad builder tools
 3. Publish to a Git repository or share the folder collection
 4. Others install with `--custom-source <your-repo-url>`
 
-For modules to support discovery mode, include a `.claude-plugin/marketplace.json` in your repository root (this is a cross-tool convention, not Claude-specific). See the [BMad Builder documentation](https://github.com/bmad-code-org/bmad-builder) for the marketplace.json format.
+For modules to support discovery mode, include a `.claude-plugin/marketplace.json` in your repository root (this is a cross-tool convention, not Claude-specific). See the [Wizz Builder documentation](https://github.com/wizzcomms/wizz-method) for the marketplace.json format.
 
 :::tip[Testing Locally First]
 During development, install your module with a local path to iterate quickly before publishing to a Git repository.
@@ -1698,7 +1698,7 @@ During development, install your module with a local path to iterate quickly bef
 
 <document path="how-to/non-interactive-installation.md">
 :::note[This page has moved]
-Headless and CI install flags, channel selection, and pinning now live in the unified [How to Install BMad](./install-bmad.md) guide. Jump to the [Headless / CI installs](./install-bmad.md#headless-ci-installs) section for the flag reference and copy-paste recipes.
+Headless and CI install flags, channel selection, and pinning now live in the unified [How to Install Wizz Method](./install-bmad.md) guide. Jump to the [Headless / CI installs](./install-bmad.md#headless-ci-installs) section for the flag reference and copy-paste recipes.
 :::
 </document>
 
@@ -1707,7 +1707,7 @@ Use the `project-context.md` file to ensure AI agents follow your project's tech
 
 :::note[Prerequisites]
 
-- BMad Method installed
+- Wizz Method installed
 - Understanding of your project's technology stack and conventions
   :::
 
@@ -1730,11 +1730,11 @@ Use the `project-context.md` file to ensure AI agents follow your project's tech
 
 ### Option A: Manual Creation
 
-Create the file at `_bmad-output/project-context.md`:
+Create the file at `_wizz-output/project-context.md`:
 
 ```bash
-mkdir -p _bmad-output
-touch _bmad-output/project-context.md
+mkdir -p _wizz-output
+touch _wizz-output/project-context.md
 ```
 
 Add your technology stack and implementation rules:
@@ -1779,7 +1779,7 @@ sections_completed: ['technology_stack', 'critical_rules']
 Run the workflow in a fresh chat:
 
 ```bash
-bmad-generate-project-context
+wizz-generate-project-context
 ```
 
 The workflow scans your architecture document and project files to generate a context file capturing the decisions made.
@@ -1789,7 +1789,7 @@ The workflow scans your architecture document and project files to generate a co
 For existing projects, run:
 
 ```bash
-bmad-generate-project-context
+wizz-generate-project-context
 ```
 
 The workflow analyzes your codebase to identify conventions, then generates a context file you can review and refine.
@@ -1821,7 +1821,7 @@ A `project-context.md` file that:
 - **Focus on the unobvious** — Document patterns agents might miss (e.g., "Use JSDoc on every public class"), not universal practices like "use meaningful variable names."
 - **Keep it lean** — This file is loaded by every implementation workflow. Long files waste context. Exclude content that only applies to narrow scope or specific stories.
 - **Update as needed** — Edit manually when patterns change, or re-generate after significant architecture changes.
-- Works for Quick Flow and full BMad Method projects alike.
+- Works for Quick Flow and full Wizz Method projects alike.
   :::
 
 ## Next Steps
@@ -1831,7 +1831,7 @@ A `project-context.md` file that:
 </document>
 
 <document path="how-to/quick-fixes.md">
-Use **Quick Dev** for bug fixes, refactorings, or small targeted changes that don't require the full BMad Method.
+Use **Quick Dev** for bug fixes, refactorings, or small targeted changes that don't require the full Wizz Method.
 
 ## When to Use This
 
@@ -1842,7 +1842,7 @@ Use **Quick Dev** for bug fixes, refactorings, or small targeted changes that do
 
 :::note[Prerequisites]
 
-- BMad Method installed (`npx bmad-method install`)
+- Wizz Method installed (`npx wizz-method install`)
 - An AI-powered IDE (Claude Code, Cursor, or similar)
   :::
 
@@ -1865,7 +1865,7 @@ run quick-dev — fix https://github.com/org/repo/issues/42
 ```
 
 ```text
-run quick-dev — implement the intent in _bmad-output/implementation-artifacts/my-intent.md
+run quick-dev — implement the intent in _wizz-output/implementation-artifacts/my-intent.md
 ```
 
 ```text
@@ -1913,17 +1913,17 @@ Check this file after a run — it's your backlog of things to come back to. Eac
 
 ## When to Upgrade to Formal Planning
 
-Consider using the full BMad Method when:
+Consider using the full Wizz Method when:
 
 - The change affects multiple systems or requires coordinated updates across many files
 - You are unsure about the scope and need requirements discovery first
 - You need documentation or architectural decisions recorded for the team
 
-See [Quick Dev](../explanation/quick-dev.md) for more on how Quick Dev fits into the BMad Method.
+See [Quick Dev](../explanation/quick-dev.md) for more on how Quick Dev fits into the Wizz Method.
 </document>
 
 <document path="how-to/shard-large-documents.md">
-Use the `bmad-shard-doc` tool if you need to split large markdown files into smaller, organized files for better context management.
+Use the `wizz-shard-doc` tool if you need to split large markdown files into smaller, organized files for better context management.
 
 :::caution[Deprecated]
 This is no longer recommended, and soon with updated workflows and most major LLMs and tools supporting subprocesses this will be unnecessary.
@@ -1941,11 +1941,11 @@ Document sharding splits large markdown files into smaller, organized files base
 
 ```text
 Before Sharding:
-_bmad-output/planning-artifacts/
+_wizz-output/planning-artifacts/
 └── PRD.md (large 50k token file)
 
 After Sharding:
-_bmad-output/planning-artifacts/
+_wizz-output/planning-artifacts/
 └── prd/
     ├── index.md                    # Table of contents with descriptions
     ├── overview.md                 # Section 1
@@ -1959,7 +1959,7 @@ _bmad-output/planning-artifacts/
 ### 1. Run the Shard-Doc Tool
 
 ```bash
-/bmad-shard-doc
+/wizz-shard-doc
 ```
 
 ### 2. Follow the Interactive Process
@@ -1980,7 +1980,7 @@ Agent: Sharding PRD.md...
 
 ## How Workflow Discovery Works
 
-BMad workflows use a **dual discovery system**:
+Wizz Method workflows use a **dual discovery system**:
 
 1. **Try whole document first** - Look for `document-name.md`
 2. **Check for sharded version** - Look for `document-name/index.md`
@@ -1997,18 +1997,18 @@ All BMM workflows support both formats:
 </document>
 
 <document path="how-to/upgrade-to-v6.md">
-Use the BMad installer to upgrade from v4 to v6, which includes automatic detection of legacy installations and migration assistance.
+Use the Wizz Method installer to upgrade from v4 to v6, which includes automatic detection of legacy installations and migration assistance.
 
 ## When to Use This
 
-- You have BMad v4 installed (`.bmad-method` folder)
+- You have Wizz Method v4 installed (`.bmad-method` folder)
 - You want to migrate to the new v6 architecture
 - You have existing planning artifacts to preserve
 
 :::note[Prerequisites]
 
 - Node.js 20.12+
-- Existing BMad v4 installation
+- Existing Wizz Method v4 installation
   :::
 
 ## Steps
@@ -2040,7 +2040,7 @@ The new v6 skills are installed to:
 
 **If you have planning documents (Brief/PRD/UX/Architecture):**
 
-Move them to `_bmad-output/planning-artifacts/` with descriptive names:
+Move them to `_wizz-output/planning-artifacts/` with descriptive names:
 
 - Include `PRD` in filename for PRD documents
 - Include `brief`, `architecture`, or `ux-design` accordingly
@@ -2053,8 +2053,8 @@ Move them to `_bmad-output/planning-artifacts/` with descriptive names:
 If you have stories created or implemented:
 
 1. Complete the v6 installation
-2. Place `epics.md` or `epics/epic*.md` in `_bmad-output/planning-artifacts/`
-3. Run the Developer's `bmad-sprint-planning` workflow
+2. Place `epics.md` or `epics/epic*.md` in `_wizz-output/planning-artifacts/`
+3. Run the Developer's `wizz-sprint-planning` workflow
 4. Tell the agent which epics/stories are already complete
 
 ## What You Get
@@ -2063,14 +2063,14 @@ If you have stories created or implemented:
 
 ```text
 your-project/
-├── _bmad/               # Single installation folder
+├── _wizz/               # Single installation folder
 │   ├── _config/         # Your customizations
 │   │   └── agents/      # Agent customization files
 │   ├── core/            # Universal core framework
-│   ├── bmm/             # BMad Method module
-│   ├── bmb/             # BMad Builder
+│   ├── bmm/             # Wizz Method module
+│   ├── bmb/             # Wizz Builder
 │   └── cis/             # Creative Intelligence Suite
-└── _bmad-output/        # Output folder (was doc folder in v4)
+└── _wizz-output/        # Output folder (was doc folder in v4)
 ```
 
 ## Module Migration
@@ -2087,8 +2087,8 @@ your-project/
 
 | Concept       | v4                                    | v6                                   |
 | ------------- | ------------------------------------- | ------------------------------------ |
-| **Core**      | `_bmad-core` was actually BMad Method | `_bmad/core/` is universal framework |
-| **Method**    | `_bmad-method`                        | `_bmad/bmm/`                         |
+| **Core**      | `_wizz-core` was actually Wizz Method | `_wizz/core/` is universal framework |
+| **Method**    | `_wizz-method`                        | `_wizz/bmm/`                         |
 | **Config**    | Modified files directly               | `config.yaml` per module             |
 | **Documents** | Sharded or unsharded required setup   | Fully flexible, auto-scanned         |
 </document>
@@ -2119,7 +2119,7 @@ Each bundle's `INSTRUCTIONS.md` (inside the ZIP) includes a **Persona Swap Examp
 
 ## What you get
 
-- A reusable Gem or Custom GPT scoped to one BMad planning capability.
+- A reusable Gem or Custom GPT scoped to one Wizz Method planning capability.
 - Polished artifacts (briefs, PRDs, research reports, UX specs) ready to drop into your IDE for implementation.
 - Planning conversation runs on your existing web LLM subscription instead of metered IDE tokens.
 
@@ -2129,7 +2129,7 @@ Web LLMs occasionally drop persona partway through long sessions. If the model s
 
 ## Building your own
 
-To turn an existing BMad skill into a web bundle, use the `bmad-os-skill-to-bundle` utility skill from [bmad-utility-skills](https://github.com/bmad-code-org/bmad-utility-skills). It produces the bundle files with persona inheritance from the owning agent and a swap-example contrast voice. Submit your bundle to the shelf by opening a PR on [BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) that adds the bundle directory and an entry in `web-bundles/bundles.json`.
+To turn an existing Wizz Method skill into a web bundle, use the `bmad-os-skill-to-bundle` utility skill. It produces the bundle files with persona inheritance from the owning agent and a swap-example contrast voice. Submit your bundle to the shelf by opening a PR on [wizz-method](https://github.com/wizzcomms/wizz-method) that adds the bundle directory and an entry in `web-bundles/bundles.json`.
 </document>
 
 <document path="explanation/advanced-elicitation.md">
@@ -2199,7 +2199,7 @@ Normal reviews suffer from confirmation bias. You skim the work, nothing jumps o
 
 ## Where It's Used
 
-Adversarial review appears throughout BMad workflows - code review, implementation readiness checks, spec validation, and others. Sometimes it's a required step, sometimes optional (like advanced elicitation or party mode). The pattern adapts to whatever artifact needs scrutiny.
+Adversarial review appears throughout Wizz Method workflows: code review, implementation readiness checks, spec validation, and others. Sometimes it's a required step, sometimes optional (like advanced elicitation or party mode). The pattern adapts to whatever artifact needs scrutiny.
 
 ## Human Filtering Required
 
@@ -2290,7 +2290,7 @@ See [Brainstorming](./brainstorming.md) for a deeper look at how sessions work.
 Product Brief and PRFAQ both produce input for the PRD — choose one based on how much challenge you want. The brief is collaborative discovery. The PRFAQ is a gauntlet. Both get you to the same destination; the PRFAQ tests whether your concept deserves to get there.
 
 :::tip[Not Sure?]
-Run `bmad-help` and describe your situation. It will recommend the right starting point based on what you've already done and what you're trying to accomplish.
+Run `wizz-help` and describe your situation. It will recommend the right starting point based on what you've already done and what you're trying to accomplish.
 :::
 
 ## What Happens After Analysis?
@@ -2303,7 +2303,7 @@ Unlock your creativity through guided exploration.
 
 ## What is Brainstorming?
 
-Run `bmad-brainstorming` and you've got a creative facilitator pulling ideas out of you - not generating them for you. The AI acts as coach and guide, using proven techniques to create conditions where your best thinking emerges.
+Run `wizz-brainstorming` and you've got a creative facilitator pulling ideas out of you - not generating them for you. The AI acts as coach and guide, using proven techniques to create conditions where your best thinking emerges.
 
 **Good for:**
 
@@ -2328,13 +2328,13 @@ Every idea comes from you. The workflow creates conditions for insight - you're
 </document>
 
 <document path="explanation/checkpoint-preview.md">
-`bmad-checkpoint-preview` is an interactive, LLM-assisted human-in-the-loop review workflow. It walks you through a code change — from purpose and context into details — so you can make an informed decision about whether to ship, rework, or dig deeper.
+`wizz-checkpoint-preview` is an interactive, LLM-assisted human-in-the-loop review workflow. It walks you through a code change — from purpose and context into details — so you can make an informed decision about whether to ship, rework, or dig deeper.
 
 ![Checkpoint Preview workflow diagram](/diagrams/checkpoint-preview-diagram.png)
 
 ## The Typical Flow
 
-You run `bmad-quick-dev`. It clarifies your intent, builds a spec, implements the change, and when it's done it appends a review trail to the spec file and opens it in your editor. You look at the spec and see the change touched 20 files across several modules.
+You run `wizz-quick-dev`. It clarifies your intent, builds a spec, implements the change, and when it's done it appends a review trail to the spec file and opens it in your editor. You look at the spec and see the change touched 20 files across several modules.
 
 You could eyeball the diff. But 20 files is where eyeballing starts to fail — you lose the thread, miss a connection between two distant changes, or approve something you didn't fully understand. So instead, you say "checkpoint" and the LLM walks you through it.
 
@@ -2400,7 +2400,7 @@ When no author-produced trail exists, the workflow generates one from the diff a
 
 ## When to Use It
 
-The primary scenario is the handoff from `bmad-quick-dev`: the implementation is done, the spec file is open in your editor with a review trail appended, and you need to decide whether to ship. Say "checkpoint" and go.
+The primary scenario is the handoff from `wizz-quick-dev`: the implementation is done, the spec file is open in your editor with a review trail appended, and you need to decide whether to ship. Say "checkpoint" and go.
 
 It also works standalone:
 
@@ -2416,7 +2416,7 @@ Checkpoint Preview is not a substitute for automated review. It does not run lin
 </document>
 
 <document path="explanation/forensic-investigation.md">
-You hand `bmad-investigate` a crash log, a stack trace, or just a "this used to work, now it doesn't". The skill takes
+You hand `wizz-investigate` a crash log, a stack trace, or just a "this used to work, now it doesn't". The skill takes
 over the investigator's discipline for the duration of the run. It does not start fixing. It opens a case file.
 
 Every finding gets graded. Every hypothesis gets a status. Wrong turns are kept, not erased. The deliverable is a
@@ -2512,7 +2512,7 @@ in the same case file. There is no mode switch.
 
 ## Methodology Lives in the Skill
 
-The investigator's discipline is a property of the skill itself. Whoever invokes `bmad-investigate` takes on the
+The investigator's discipline is a property of the skill itself. Whoever invokes `wizz-investigate` takes on the
 methodology and communication style for the run: clinical precision, evidence-first language, no hedging, case-file
 framing. When the skill ends, the caller returns to its prior voice. No persona swap, just a tone shift from the skill's
 principles.
@@ -2541,7 +2541,7 @@ That's the bar.
 Most "AI debugging" today blends evidence, reasoning, and code changes into one stream of plausible-looking text. The
 signal is hard to find, the dead ends repeat, and the case file, if there is one, is a chat log nobody wants to read.
 
-`bmad-investigate` treats investigation as a discipline with its own deliverable. Evidence has a grade. Hypotheses have
+`wizz-investigate` treats investigation as a discipline with its own deliverable. Evidence has a grade. Hypotheses have
 a status. Wrong turns are documented, not erased. The case file outlives the session.
 
 When the next bug shows up that looks like one you've seen before, you have somewhere to start that isn't a blank
@@ -2549,19 +2549,19 @@ prompt.
 </document>
 
 <document path="explanation/named-agents.md">
-You say "Hey Mary, let's brainstorm," and Mary activates. She greets you by name, in the language you configured, with her distinctive persona. She reminds you that `bmad-help` is always available. Then she skips the menu entirely and drops straight into brainstorming — because your intent was clear.
+You say "Hey Mary, let's brainstorm," and Mary activates. She greets you by name, in the language you configured, with her distinctive persona. She reminds you that `wizz-help` is always available. Then she skips the menu entirely and drops straight into brainstorming — because your intent was clear.
 
-This page explains what's actually happening and why BMad is designed this way.
+This page explains what's actually happening and why the Wizz Method is designed this way.
 
 ## The Three-Legged Stool
 
-BMad's agent model rests on three primitives that compose:
+The Wizz Method's agent model rests on three primitives that compose:
 
 | Primitive | What it provides | Where it lives |
 |---|---|---|
 | **Skill** | Capability — a discrete thing the assistant can do (brainstorm, draft a PRD, implement a story) | `.claude/skills/{skill-name}/SKILL.md` (or your IDE's equivalent) |
 | **Named agent** | Persona continuity — a recognizable identity that wraps a menu of related skills with consistent voice, principles, and visual cues | Skills whose directory starts with `bmad-agent-*` |
-| **Customization** | Makes it yours — overrides that reshape an agent's behavior, add MCP integrations, swap templates, layer in org conventions | `_bmad/custom/{skill-name}.toml` (committed team overrides) and `.user.toml` (personal, gitignored) |
+| **Customization** | Makes it yours — overrides that reshape an agent's behavior, add MCP integrations, swap templates, layer in org conventions | `_wizz/custom/{skill-name}.toml` (committed team overrides) and `.user.toml` (personal, gitignored) |
 
 Pull any leg away and the experience collapses:
 
@@ -2571,7 +2571,7 @@ Pull any leg away and the experience collapses:
 
 ## What Named Agents Buy You
 
-BMad ships six named agents, each anchored to a phase of the BMad Method:
+The Wizz Method ships six named agents, each anchored to a phase of the Wizz Method:
 
 | Agent | Phase | Module |
 |---|---|---|
@@ -2597,7 +2597,7 @@ When you invoke a named agent, eight steps run in order:
 7. **Execute append steps** — any post-greet setup the team configured
 8. **Dispatch or present the menu** — if your opening message maps to a menu item, go directly; otherwise render the menu and wait for input
 
-Step 8 is where intent meets capability. "Hey Mary, let's brainstorm" skips rendering because `bmad-brainstorming` is an obvious match for `BP` on Mary's menu. If you say something ambiguous, she asks once, briefly, not as a confirmation ritual. If nothing fits, she continues the conversation normally.
+Step 8 is where intent meets capability. "Hey Mary, let's brainstorm" skips rendering because `wizz-brainstorming` is an obvious match for `BP` on Mary's menu. If you say something ambiguous, she asks once, briefly, not as a confirmation ritual. If nothing fits, she continues the conversation normally.
 
 ## Why Not Just a Menu?
 
@@ -2611,25 +2611,25 @@ The menu is still there as a fallback — show it when you're exploring, skip it
 
 Blank prompts assume you know the magic words. "Help me brainstorm" might work, but "let's ideate on my SaaS idea" might not, and the results depend on how you phrased the ask. You become responsible for prompt engineering.
 
-Named agents add structure without closing off freedom. The persona stays consistent, the capabilities are discoverable, and `bmad-help` is always one command away. You don't have to guess what the agent can do, and you don't need a manual to use it either.
+Named agents add structure without closing off freedom. The persona stays consistent, the capabilities are discoverable, and `wizz-help` is always one command away. You don't have to guess what the agent can do, and you don't need a manual to use it either.
 
 ## Customization as a First-Class Citizen
 
 The customization model is what lets this scale beyond a single developer.
 
-Every agent ships a `customize.toml` with sensible defaults. Teams commit overrides to `_bmad/custom/bmad-agent-{role}.toml`. Individuals can layer personal preferences in `.user.toml` (gitignored). The resolver merges all three at activation time with predictable structural rules.
+Every agent ships a `customize.toml` with sensible defaults. Teams commit overrides to `_wizz/custom/bmad-agent-{role}.toml`. Individuals can layer personal preferences in `.user.toml` (gitignored). The resolver merges all three at activation time with predictable structural rules.
 
-Most users never hand-author these files. The `bmad-customize` skill walks through picking the target, choosing agent vs workflow scope, authoring the override, and verifying the merge — so the customization surface stays accessible to anyone who understands their intent, not just those fluent in TOML.
+Most users never hand-author these files. The `wizz-customize` skill walks through picking the target, choosing agent vs workflow scope, authoring the override, and verifying the merge — so the customization surface stays accessible to anyone who understands their intent, not just those fluent in TOML.
 
 Concrete example: a team commits a single file telling Amelia to always use the Context7 MCP tool for library docs and to fall back to Linear when a story isn't in the local epics list. Every dev workflow Amelia dispatches (dev-story, quick-dev, create-story, code-review) inherits that behavior, with no source edits or per-workflow duplication required.
 
-There's also a second customization surface for *cross-cutting* concerns: the central `_bmad/config.toml` and `_bmad/config.user.toml` (both installer-owned, rebuilt from each module's `module.yaml`) plus `_bmad/custom/config.toml` (team, committed) and `_bmad/custom/config.user.toml` (personal, gitignored) for overrides. This is where the **agent roster** lives — the lightweight descriptors that roster consumers like `bmad-party-mode`, `bmad-retrospective`, and `bmad-advanced-elicitation` read to know who's available and how to embody them. Rebrand an agent org-wide with a team override; add fictional voices (Kirk, Spock, a domain expert persona) as personal experiments via the `.user.toml` override — without touching any skill folder. The per-skill file shapes how Mary *behaves* when she activates; the central config shapes how other skills *see* her when they look at the field.
+There's also a second customization surface for *cross-cutting* concerns: the central `_wizz/config.toml` and `_wizz/config.user.toml` (both installer-owned, rebuilt from each module's `module.yaml`) plus `_wizz/custom/config.toml` (team, committed) and `_wizz/custom/config.user.toml` (personal, gitignored) for overrides. This is where the **agent roster** lives — the lightweight descriptors that roster consumers like `wizz-party-mode`, `wizz-retrospective`, and `wizz-advanced-elicitation` read to know who's available and how to embody them. Rebrand an agent org-wide with a team override; add fictional voices (Kirk, Spock, a domain expert persona) as personal experiments via the `.user.toml` override — without touching any skill folder. The per-skill file shapes how Mary *behaves* when she activates; the central config shapes how other skills *see* her when they look at the field.
 
 For the full customization surface and worked examples, see:
 
-- [How to Customize BMad](../how-to/customize-bmad.md) — the reference for what's customizable and how merge works
-- [How to Expand BMad for Your Organization](../how-to/expand-bmad-for-your-org.md) — five worked recipes spanning agent-wide rules, workflow conventions, external publishing, template swaps, and agent roster customization
-- `bmad-customize` skill — the guided authoring helper that turns intent into a correctly-placed, verified override file
+- [How to Customize Wizz Method](../how-to/customize-bmad.md) — the reference for what's customizable and how merge works
+- [How to Expand Wizz Method for Your Organization](../how-to/expand-bmad-for-your-org.md) — five worked recipes spanning agent-wide rules, workflow conventions, external publishing, template swaps, and agent roster customization
+- `wizz-customize` skill — the guided authoring helper that turns intent into a correctly-placed, verified override file
 
 ## The Bigger Idea
 
@@ -2643,7 +2643,7 @@ Party mode puts your AI agents in one room and lets them talk, to each other and
 
 ## What is Party Mode?
 
-Run `bmad-party-mode` and the BMad agents you already have installed gather in one conversation: the PM, Architect, Dev, UX Designer, and whoever else your selected modules bring. That installed lineup is your default party, ready with no setup. They answer in character, agree, disagree, and build on each other. You steer the room. Ask a follow-up, push back, pull one voice forward, or change the subject. The conversation runs until you end it.
+Run `wizz-party-mode` and the Wizz Method agents you already have installed gather in one conversation: the PM, Architect, Dev, UX Designer, and whoever else your selected modules bring. That installed lineup is your default party, ready with no setup. They answer in character, agree, disagree, and build on each other. You steer the room. Ask a follow-up, push back, pull one voice forward, or change the subject. The conversation runs until you end it.
 
 It works because the personas hold different priorities. The Architect guards the design, the PM guards scope, the Dev guards what's actually buildable. Put them in the same room and the tradeoff surfaces now, in the conversation, instead of three weeks into the sprint.
 
@@ -2672,13 +2672,13 @@ Invoke the skill and say what you want; it works out whether you mean to run a p
 
 | Goal | Type this |
 | --- | --- |
-| Start a party in the default mode | `/bmad-party-mode` |
-| Start in a specific mode | `/bmad-party-mode --mode auto` (also `session`, `subagent`, `agent-team`) |
-| Open a saved party | `/bmad-party-mode --party code-review-crew` |
+| Start a party in the default mode | `/wizz-party-mode` |
+| Start in a specific mode | `/wizz-party-mode --mode auto` (also `session`, `subagent`, `agent-team`) |
+| Open a saved party | `/wizz-party-mode --party code-review-crew` |
 | Conjure a cast on the spot | "party mode with the bridge crew of the Enterprise" |
 | Create or add a party | "party mode, create a new party" |
 | Edit an existing party | "party mode, edit the writers' room" |
-| Customize the skill | `/bmad-customize bmad-party-mode` |
+| Customize the skill | `/wizz-customize wizz-party-mode` |
 
 ## How a party runs
 
@@ -2701,9 +2701,9 @@ Start a party with `--mode subagent` (or `auto`, `agent-team`, `session`) to ove
 
 ## Custom parties
 
-Out of the box, a party uses your installed BMad agents. The larger use is building your own cast from any set of personas you can describe, then saving it to reuse. You author a party through the same skill. It detects whether you want to run one or build one, and writes the result to your overrides through [bmad-customize](../how-to/customize-bmad.md).
+Out of the box, a party uses your installed Wizz Method agents. The larger use is building your own cast from any set of personas you can describe, then saving it to reuse. You author a party through the same skill. It detects whether you want to run one or build one, and writes the result to your overrides through [wizz-customize](../how-to/customize-bmad.md).
 
-Party mode is customizable like every BMad skill. Run `/bmad-customize bmad-party-mode` to set its defaults directly: pin any group you've built as the default party so it loads without a flag, choose which mode it starts in, and set any house rules the room should hold for the whole session.
+Party mode is customizable like every Wizz Method skill. Run `/wizz-customize wizz-party-mode` to set its defaults directly: pin any group you've built as the default party so it loads without a flag, choose which mode it starts in, and set any house rules the room should hold for the whole session.
 
 Two ideas do most of the work.
 
@@ -2738,7 +2738,7 @@ These are starting points. Any set of voices you can describe becomes a party: w
 
 ## The Code Review Crew
 
-Your default party is the agents your installed modules provide. The Code Review Crew is a custom party BMad ships alongside that default — a working template to study before you build your own, not a replacement for it. It's a review panel: five lenses that attack a change from different angles and argue about what actually matters, instead of rubber-stamping it.
+Your default party is the agents your installed modules provide. The Code Review Crew is a custom party the Wizz Method ships alongside that default — a working template to study before you build your own, not a replacement for it. It's a review panel: five lenses that attack a change from different angles and argue about what actually matters, instead of rubber-stamping it.
 
 | Member | Lens |
 | --- | --- |
@@ -2878,7 +2878,7 @@ Common decisions that prevent conflicts:
 - Document decisions that cross epic boundaries
 - Focus on conflict-prone areas
 - Update architecture as you learn
-- Use `bmad-correct-course` for significant changes
+- Use `wizz-correct-course` for significant changes
 :::
 </document>
 
@@ -2899,12 +2899,12 @@ The `project-context.md` file solves this by documenting what agents need to kno
 Every implementation workflow automatically loads `project-context.md` if it exists. The architect workflow also loads it to respect your technical preferences when designing the architecture.
 
 **Loaded by these workflows:**
-- `bmad-create-architecture` — respects technical preferences during solutioning
-- `bmad-create-story` — informs story creation with project patterns
-- `bmad-dev-story` — guides implementation decisions
-- `bmad-code-review` — validates against project standards
-- `bmad-quick-dev` — applies patterns when implementing specs
-- `bmad-sprint-planning`, `bmad-retrospective`, `bmad-correct-course` — provides project-wide context
+- `wizz-create-architecture` — respects technical preferences during solutioning
+- `wizz-create-story` — informs story creation with project patterns
+- `wizz-dev-story` — guides implementation decisions
+- `wizz-code-review` — validates against project standards
+- `wizz-quick-dev` — applies patterns when implementing specs
+- `wizz-sprint-planning`, `wizz-retrospective`, `wizz-correct-course` — provides project-wide context
 
 ## When to Create It
 
@@ -2912,10 +2912,10 @@ The `project-context.md` file is useful at any stage of a project:
 
 | Scenario | When to Create | Purpose |
 |----------|----------------|---------|
-| **New project, before architecture** | Manually, before `bmad-create-architecture` | Document your technical preferences so the architect respects them |
-| **New project, after architecture** | Via `bmad-generate-project-context` or manually | Capture architecture decisions for implementation agents |
-| **Existing project** | Via `bmad-generate-project-context` | Discover existing patterns so agents follow established conventions |
-| **Quick Flow project** | Before or during `bmad-quick-dev` | Ensure quick implementation respects your patterns |
+| **New project, before architecture** | Manually, before `wizz-create-architecture` | Document your technical preferences so the architect respects them |
+| **New project, after architecture** | Via `wizz-generate-project-context` or manually | Capture architecture decisions for implementation agents |
+| **Existing project** | Via `wizz-generate-project-context` | Discover existing patterns so agents follow established conventions |
+| **Quick Flow project** | Before or during `wizz-quick-dev` | Ensure quick implementation respects your patterns |
 
 :::tip[Recommended]
 For new projects, create it manually before architecture if you have strong technical preferences. Otherwise, generate it after architecture to capture those decisions.
@@ -2973,32 +2973,32 @@ You have three options:
 
 ### Manual Creation
 
-Create the file at `_bmad-output/project-context.md` and add your rules:
+Create the file at `_wizz-output/project-context.md` and add your rules:
 
 ```bash
 # In your project root
-mkdir -p _bmad-output
-touch _bmad-output/project-context.md
+mkdir -p _wizz-output
+touch _wizz-output/project-context.md
 ```
 
 Edit it with your technology stack and implementation rules. The architect and implementation workflows will automatically find and load it.
 
 ### Generate After Architecture
 
-Run the `bmad-generate-project-context` workflow after completing your architecture:
+Run the `wizz-generate-project-context` workflow after completing your architecture:
 
 ```bash
-bmad-generate-project-context
+wizz-generate-project-context
 ```
 
 This scans your architecture document and project files to generate a context file capturing the decisions made.
 
 ### Generate for Existing Projects
 
-For existing projects, run `bmad-generate-project-context` to discover existing patterns:
+For existing projects, run `wizz-generate-project-context` to discover existing patterns:
 
 ```bash
-bmad-generate-project-context
+wizz-generate-project-context
 ```
 
 The workflow analyzes your codebase to identify conventions, then generates a context file you can review and refine.
@@ -3028,10 +3028,10 @@ The `project-context.md` file is a living document. Update it when:
 - Patterns evolve during implementation
 - You identify gaps from agent behavior
 
-You can edit it manually at any time, or re-run `bmad-generate-project-context` to update it after significant changes.
+You can edit it manually at any time, or re-run `wizz-generate-project-context` to update it after significant changes.
 
 :::note[File Location]
-The default location is `_bmad-output/project-context.md`. Workflows search for it there, and also check `**/project-context.md` anywhere in your project.
+The default location is `_wizz-output/project-context.md`. Workflows search for it there, and also check `**/project-context.md` anywhere in your project.
 :::
 </document>
 
@@ -3048,7 +3048,7 @@ Human-in-the-loop turns are necessary and expensive.
 
 Current LLMs still fail in predictable ways: they misread intent, fill gaps with confident guesses, drift into unrelated work, and generate noisy review output. At the same time, constant human intervention limits development velocity. Human attention is the bottleneck.
 
-`bmad-quick-dev` rebalances that tradeoff. It trusts the model to run unsupervised for longer stretches, but only after the workflow has created a strong enough boundary to make that safe.
+`wizz-quick-dev` rebalances that tradeoff. It trusts the model to run unsupervised for longer stretches, but only after the workflow has created a strong enough boundary to make that safe.
 
 ## The Core Design
 
@@ -3056,7 +3056,7 @@ Current LLMs still fail in predictable ways: they misread intent, fill gaps with
 
 The workflow starts by having the human and the model compress the request into one coherent goal. The input can begin as a rough expression of intent, but before the workflow runs autonomously it has to become small enough, clear enough, and contradiction-free enough to execute.
 
-Intent can come in many forms: a couple of phrases, a bug tracker link, output from plan mode, text copied from a chat session, or even a story number from BMAD's own `epics.md`. In that last case, the workflow will not understand BMAD story-tracking semantics, but it can still take the story itself and run with it.
+Intent can come in many forms: a couple of phrases, a bug tracker link, output from plan mode, text copied from a chat session, or even a story number from Wizz Method's own `epics.md`. In that last case, the workflow will not understand Wizz Method story-tracking semantics, but it can still take the story itself and run with it.
 
 This workflow does not eliminate human control. It relocates it to a small number of high-value moments:
 
@@ -3105,15 +3105,15 @@ That triage will sometimes be imperfect. That is acceptable. It is usually bette
 </document>
 
 <document path="explanation/web-bundles.md">
-Run the planning side of BMad in your web LLM subscription, then bring the artifacts into your IDE.
+Run the planning side of the Wizz Method in your web LLM subscription, then bring the artifacts into your IDE.
 
 ## What is a Web Bundle?
 
-A web bundle is a BMad skill repackaged for installation as a **Google Gemini Gem** or **ChatGPT Custom GPT**. Each bundle includes a `SKILL.md` protocol you upload as a knowledge file, an `INSTRUCTIONS.md` block you paste into the Gem or GPT instructions, and any data files the skill needs (CSVs, templates, validation checklists, additionally progressively disclosed content). The persona lives in the pasted instructions; the protocol lives in the knowledge file. Swap personas without touching the protocol.
+A web bundle is a Wizz Method skill repackaged for installation as a **Google Gemini Gem** or **ChatGPT Custom GPT**. Each bundle includes a `SKILL.md` protocol you upload as a knowledge file, an `INSTRUCTIONS.md` block you paste into the Gem or GPT instructions, and any data files the skill needs (CSVs, templates, validation checklists, additionally progressively disclosed content). The persona lives in the pasted instructions; the protocol lives in the knowledge file. Swap personas without touching the protocol.
 
 Setup is not one-click, but the steps are guided. **Install from [bmadcode.com/web-bundles](https://bmadcode.com/web-bundles/)**. The site lists every bundle in a card grid, shows you the Gemini and ChatGPT install steps inline, and hands you the ZIP download. That is the supported install path; the pattern is the same across the shelf, so once you've installed one the next one is mechanical.
 
-V4 of BMad shipped web bundles. V6 brings them back, rewritten for the current Gem and Custom GPT platforms with Canvas, Deep Research, and image generation in mind.
+V4 of the Wizz Method shipped web bundles. V6 brings them back, rewritten for the current Gem and Custom GPT platforms with Canvas, Deep Research, and image generation in mind.
 
 ## Why use them
 
@@ -3138,20 +3138,20 @@ The current set of bundles covers the analysis and planning phases:
 | Bundle | Phase | Persona lineage |
 | --- | --- | --- |
 | Brainstorming Coach | Analysis | Osborn (default), Minto (swap) |
-| Product Brief Coach | Analysis | Mary (BMad analyst) |
+| Product Brief Coach | Analysis | Mary (Wizz analyst) |
 | PRFAQ Coach | Analysis | Working Backwards (Bezos) |
 | PRD Coach | Planning | Cagan |
 | UX Coach | Planning | Norman |
 | Market & Industry Research | Analysis | Porter and Christensen |
 
-Each bundle carries a default persona inherited from its owning BMad agent (where one exists) and a contrasting swap example to demonstrate the voice change pattern.
+Each bundle carries a default persona inherited from its owning Wizz Method agent (where one exists) and a contrasting swap example to demonstrate the voice change pattern.
 
 ## How a session works
 
 1. **Open the Gem or Custom GPT.** Persona greets in character and opens conversational discovery.
 2. **Discover scope.** The persona asks what you're trying to do, what you have on hand, what constraints apply. No form fill.
 3. **Do the work in Canvas.** The protocol opens Canvas at session start and updates it continuously. Mermaid diagrams and HTML tables go in alongside the prose.
-4. **Hand off.** When you're done, you have a Canvas document you can export, paste into your repo, or feed to a BMad skill in your IDE for the next phase.
+4. **Hand off.** When you're done, you have a Canvas document you can export, paste into your repo, or feed to a Wizz Method skill in your IDE for the next phase.
 
 For bundles that integrate Deep Research (currently Market & Industry Research), the persona drafts a Deep Research brief mid-session for you to paste into Gemini's or ChatGPT's Deep Research mode, then ingests the returned report.
 
@@ -3179,7 +3179,7 @@ Persona swaps, default user name, team-specific guardrails, preferred phrasing:
 
 ## Building your own
 
-Web bundles are generated from BMad skills using the `bmad-os-skill-to-bundle` utility skill. Point it at any BMad skill folder and it produces the bundle files with persona inheritance from the owning agent.
+Web bundles are generated from Wizz Method skills using the `bmad-os-skill-to-bundle` utility skill. Point it at any Wizz Method skill folder and it produces the bundle files with persona inheritance from the owning agent.
 
 Install any bundle from [bmadcode.com/web-bundles](https://bmadcode.com/web-bundles/).
 </document>
@@ -3234,8 +3234,8 @@ This prevents:
 | Track | Solutioning Required? |
 |-------|----------------------|
 | Quick Flow | No - skip entirely |
-| BMad Method Simple | Optional |
-| BMad Method Complex | Yes |
+| Wizz Method Simple | Optional |
+| Wizz Method Complex | Yes |
 | Enterprise | Yes |
 
 :::tip[Rule of Thumb]
@@ -3259,22 +3259,22 @@ Catching alignment issues in solutioning is 10× faster than discovering them du
 <document path="reference/agents.md">
 ## Default Agents
 
-This page lists the default BMM (Agile suite) agents that install with BMad Method, along with their skill IDs, menu triggers, and primary workflows. Each agent is invoked as a skill.
+This page lists the default BMM (Agile suite) agents that install with the Wizz Method, along with their skill IDs, menu triggers, and primary workflows. Each agent is invoked as a skill.
 
 ## Notes
 
-- Each agent is available as a skill, generated by the installer. The skill ID (e.g., `bmad-agent-dev`) is used to invoke the agent.
+- Each agent is available as a skill, generated by the installer. The skill ID (e.g., `wizz-agent-dev`) is used to invoke the agent.
 - Triggers are the short menu codes (e.g., `PRD`) and fuzzy matches shown in each agent menu.
-- QA test generation is handled by the `bmad-qa-generate-e2e-tests` workflow skill, available through the Developer agent. The full Test Architect (TEA) lives in its own module.
+- QA test generation is handled by the `wizz-qa-generate-e2e-tests` workflow skill, available through the Developer agent. The full Test Architect (TEA) lives in its own module.
 
 | Agent                       | Skill ID             | Triggers                           | Primary workflows                                                                                   |
 | --------------------------- | -------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------- |
-| Analyst (Mary)              | `bmad-agent-analyst` | `BP`, `MR`, `DR`, `TR`, `CB`, `WB`, `DP` | Brainstorm, Market Research, Domain Research, Technical Research, Create Brief, PRFAQ Challenge, Document Project |
-| Product Manager (John)      | `bmad-agent-pm`      | `PRD`, `CE`, `IR`, `CC`            | Create/Update/Validate PRD, Create Epics and Stories, Implementation Readiness, Correct Course      |
-| Architect (Winston)         | `bmad-agent-architect` | `CA`, `IR`                       | Create Architecture, Implementation Readiness                                                       |
-| Developer (Amelia)          | `bmad-agent-dev`     | `DS`, `QD`, `QA`, `CR`, `SP`, `CS`, `ER`, `IN` | Dev Story, Quick Dev, QA Test Generation, Code Review, Sprint Planning, Create Story, Epic Retrospective, [Forensic Investigation](../explanation/forensic-investigation.md) |
-| UX Designer (Sally)         | `bmad-agent-ux-designer` | `CU`                           | Create UX Design                                                                                    |
-| Technical Writer (Paige)    | `bmad-agent-tech-writer` | `DP`, `WD`, `MG`, `VD`, `EC`   | Document Project, Write Document, Mermaid Generate, Validate Doc, Explain Concept                   |
+| Analyst (Mary)              | `wizz-agent-analyst` | `BP`, `MR`, `DR`, `TR`, `CB`, `WB`, `DP` | Brainstorm, Market Research, Domain Research, Technical Research, Create Brief, PRFAQ Challenge, Document Project |
+| Product Manager (John)      | `wizz-agent-pm`      | `PRD`, `CE`, `IR`, `CC`            | Create/Update/Validate PRD, Create Epics and Stories, Implementation Readiness, Correct Course      |
+| Architect (Winston)         | `wizz-agent-architect` | `CA`, `IR`                       | Create Architecture, Implementation Readiness                                                       |
+| Developer (Amelia)          | `wizz-agent-dev`     | `DS`, `QD`, `QA`, `CR`, `SP`, `CS`, `ER`, `IN` | Dev Story, Quick Dev, QA Test Generation, Code Review, Sprint Planning, Create Story, Epic Retrospective, [Forensic Investigation](../explanation/forensic-investigation.md) |
+| UX Designer (Sally)         | `wizz-agent-ux-designer` | `CU`                           | Create UX Design                                                                                    |
+| Technical Writer (Paige)    | `wizz-agent-tech-writer` | `DP`, `WD`, `MG`, `VD`, `EC`   | Document Project, Write Document, Mermaid Generate, Validate Doc, Explain Concept                   |
 
 ## Trigger Types
 
@@ -3307,22 +3307,22 @@ EC Explain how the module system works
 </document>
 
 <document path="reference/commands.md">
-Skills are pre-built prompts that load agents, run workflows, or execute tasks inside your IDE. The BMad installer generates them from your installed modules at install time. If you later add, remove, or change modules, re-run the installer to keep skills in sync (see [Troubleshooting](#troubleshooting)).
+Skills are pre-built prompts that load agents, run workflows, or execute tasks inside your IDE. The Wizz Method installer generates them from your installed modules at install time. If you later add, remove, or change modules, re-run the installer to keep skills in sync (see [Troubleshooting](#troubleshooting)).
 
 ## Skills vs. Agent Menu Triggers
 
-BMad offers two ways to start work, and they serve different purposes.
+The Wizz Method offers two ways to start work, and they serve different purposes.
 
 | Mechanism | How you invoke it | What happens |
 | --- | --- | --- |
-| **Skill** | Type the skill name (e.g. `bmad-help`) in your IDE | Directly loads an agent, runs a workflow, or executes a task |
+| **Skill** | Type the skill name (e.g. `wizz-help`) in your IDE | Directly loads an agent, runs a workflow, or executes a task |
 | **Agent menu trigger** | Load an agent first, then type a short code (e.g. `DS`) | The agent interprets the code and starts the matching workflow while staying in character |
 
 Agent menu triggers require an active agent session. Use skills when you know which workflow you want. Use triggers when you are already working with an agent and want to switch tasks without leaving the conversation.
 
 ## How Skills Are Generated
 
-When you run `npx bmad-method install`, the installer reads the manifests for every selected module and writes one skill per agent, workflow, task, and tool. Each skill is a directory containing a `SKILL.md` file that instructs the AI to load the corresponding source file and follow its instructions.
+When you run `npx wizz-method install`, the installer reads the manifests for every selected module and writes one skill per agent, workflow, task, and tool. Each skill is a directory containing a `SKILL.md` file that instructs the AI to load the corresponding source file and follow its instructions.
 
 The installer uses templates for each skill type:
 
@@ -3352,22 +3352,22 @@ Each skill is a directory containing a `SKILL.md` file. For example, a Claude Co
 
 ```text
 .claude/skills/
-├── bmad-help/
+├── wizz-help/
 │   └── SKILL.md
-├── bmad-prd/
+├── wizz-prd/
 │   └── SKILL.md
-├── bmad-agent-dev/
+├── wizz-agent-dev/
 │   └── SKILL.md
 └── ...
 ```
 
-The directory name determines the skill name in your IDE. For example, the directory `bmad-agent-dev/` registers the skill `bmad-agent-dev`.
+The directory name determines the skill name in your IDE. For example, the directory `wizz-agent-dev/` registers the skill `wizz-agent-dev`.
 
 ## How to Discover Your Skills
 
 Type the skill name in your IDE to invoke it. Some platforms require you to enable skills in settings before they appear.
 
-Run `bmad-help` for context-aware guidance on your next step.
+Run `wizz-help` for context-aware guidance on your next step.
 
 :::tip[Quick discovery]
 The generated skill directories in your project are the canonical list. Open them in your file explorer to see every skill with its description.
@@ -3381,9 +3381,9 @@ Agent skills load a specialized AI persona with a defined role, communication st
 
 | Example skill | Agent | Role |
 | --- | --- | --- |
-| `bmad-agent-dev` | Amelia (Developer) | Implements stories with strict adherence to specs |
-| `bmad-agent-pm` | John (Product Manager) | Creates and validates PRDs |
-| `bmad-agent-architect` | Winston (Architect) | Designs system architecture |
+| `wizz-agent-dev` | Amelia (Developer) | Implements stories with strict adherence to specs |
+| `wizz-agent-pm` | John (Product Manager) | Creates and validates PRDs |
+| `wizz-agent-architect` | Winston (Architect) | Designs system architecture |
 
 See [Agents](./agents.md) for the full list of default agents and their triggers.
 
@@ -3393,15 +3393,15 @@ Workflow skills run a structured, multi-step process without loading an agent pe
 
 | Example skill | Purpose |
 | --- | --- |
-| `bmad-product-brief` | Create or update a product brief — guided discovery when your concept is clear |
-| `bmad-prfaq` | [Working Backwards PRFAQ](../explanation/analysis-phase.md#prfaq-working-backwards) challenge to stress-test your product concept |
-| `bmad-prd` | Create, update, or validate a Product Requirements Document |
-| `bmad-ux` | Design user experience |
-| `bmad-create-architecture` | Design system architecture |
-| `bmad-create-epics-and-stories` | Create epics and stories |
-| `bmad-dev-story` | Implement a story |
-| `bmad-code-review` | Run a code review |
-| `bmad-quick-dev` | Unified quick flow — clarify intent, plan, implement, review, present |
+| `wizz-product-brief` | Create or update a product brief — guided discovery when your concept is clear |
+| `wizz-prfaq` | [Working Backwards PRFAQ](../explanation/analysis-phase.md#prfaq-working-backwards) challenge to stress-test your product concept |
+| `wizz-prd` | Create, update, or validate a Product Requirements Document |
+| `wizz-ux` | Design user experience |
+| `wizz-create-architecture` | Design system architecture |
+| `wizz-create-epics-and-stories` | Create epics and stories |
+| `wizz-dev-story` | Implement a story |
+| `wizz-code-review` | Run a code review |
+| `wizz-quick-dev` | Unified quick flow — clarify intent, plan, implement, review, present |
 
 See [Workflow Map](./workflow-map.md) for the complete workflow reference organized by phase.
 
@@ -3409,15 +3409,15 @@ See [Workflow Map](./workflow-map.md) for the complete workflow reference organi
 
 Tasks and tools are standalone operations that do not require an agent or workflow context.
 
-**BMad-Help: Your Intelligent Guide**
+**Wizz-Help: Your Intelligent Guide**
 
-`bmad-help` is your primary interface for discovering what to do next. It inspects your project, understands natural language queries, and recommends the next required or optional step based on your installed modules.
+`wizz-help` is your primary interface for discovering what to do next. It inspects your project, understands natural language queries, and recommends the next required or optional step based on your installed modules.
 
 :::note[Example]
 ```
-bmad-help
-bmad-help I have a SaaS idea and know all the features. Where do I start?
-bmad-help What are my options for UX design?
+wizz-help
+wizz-help I have a SaaS idea and know all the features. Where do I start?
+wizz-help What are my options for UX design?
 ```
 :::
 
@@ -3427,49 +3427,49 @@ The core module includes 12 built-in tools — specs, reviews, brainstorming, cu
 
 ## Naming Convention
 
-All skills use the `bmad-` prefix followed by a descriptive name (e.g., `bmad-agent-dev`, `bmad-prd`, `bmad-help`). See [Modules](./modules.md) for available modules.
+All skills use the `bmad-` prefix followed by a descriptive name (e.g., `wizz-agent-dev`, `wizz-prd`, `wizz-help`). See [Modules](./modules.md) for available modules.
 
 ## Troubleshooting
 
 **Skills not appearing after install.** Some platforms require skills to be explicitly enabled in settings. Check your IDE's documentation or ask your AI assistant how to enable skills. You may also need to restart your IDE or reload the window.
 
-**Expected skills are missing.** The installer only generates skills for modules you selected. Run `npx bmad-method install` again and verify your module selection. Check that the skill files exist in the expected directory.
+**Expected skills are missing.** The installer only generates skills for modules you selected. Run `npx wizz-method install` again and verify your module selection. Check that the skill files exist in the expected directory.
 
 **Skills from a removed module still appear.** The installer does not delete old skill files automatically. Remove the stale directories from your IDE's skills directory, or delete the entire skills directory and re-run the installer for a clean set.
 </document>
 
 <document path="reference/core-tools.md">
-Every BMad installation includes a set of core skills that can be used in conjunction with any anything you are doing — standalone tasks and workflows that work across all projects, all modules, and all phases. These are always available regardless of which optional modules you install.
+Every Wizz Method installation includes a set of core skills that can be used in conjunction with any anything you are doing — standalone tasks and workflows that work across all projects, all modules, and all phases. These are always available regardless of which optional modules you install.
 
 :::tip[Quick Path]
-Run any core tool by typing its skill name (e.g., `bmad-help`) in your IDE. No agent session required.
+Run any core tool by typing its skill name (e.g., `wizz-help`) in your IDE. No agent session required.
 :::
 
 ## Overview
 
 | Tool | Type | Purpose |
 | --- | --- | --- |
-| [`bmad-help`](#bmad-help) | Task | Get context-aware guidance on what to do next |
-| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | Facilitate interactive brainstorming sessions |
-| [`bmad-party-mode`](#bmad-party-mode) | Workflow | Orchestrate multi-agent group discussions |
-| [`bmad-spec`](#bmad-spec) | Workflow | Distill any intent input into a SPEC kernel and companions, the canonical contract for downstream work |
-| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Task | Push LLM output through iterative refinement methods |
-| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Task | Cynical review that finds what's missing and what's wrong |
-| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Task | Exhaustive branching-path analysis for unhandled edge cases |
-| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Task | Clinical copy-editing for communication clarity |
-| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Task | Structural editing — cuts, merges, and reorganization |
-| [`bmad-shard-doc`](#bmad-shard-doc) | Task | Split large markdown files into organized sections |
-| [`bmad-index-docs`](#bmad-index-docs) | Task | Generate or update an index of all docs in a folder |
-| [`bmad-customize`](#bmad-customize) | Task | Create and verify BMad customization overrides |
-
-## bmad-help
+| [`wizz-help`](#wizz-help) | Task | Get context-aware guidance on what to do next |
+| [`wizz-brainstorming`](#wizz-brainstorming) | Workflow | Facilitate interactive brainstorming sessions |
+| [`wizz-party-mode`](#wizz-party-mode) | Workflow | Orchestrate multi-agent group discussions |
+| [`wizz-spec`](#wizz-spec) | Workflow | Distill any intent input into a SPEC kernel and companions, the canonical contract for downstream work |
+| [`wizz-advanced-elicitation`](#wizz-advanced-elicitation) | Task | Push LLM output through iterative refinement methods |
+| [`wizz-review-adversarial-general`](#wizz-review-adversarial-general) | Task | Cynical review that finds what's missing and what's wrong |
+| [`wizz-review-edge-case-hunter`](#wizz-review-edge-case-hunter) | Task | Exhaustive branching-path analysis for unhandled edge cases |
+| [`wizz-editorial-review-prose`](#wizz-editorial-review-prose) | Task | Clinical copy-editing for communication clarity |
+| [`wizz-editorial-review-structure`](#wizz-editorial-review-structure) | Task | Structural editing — cuts, merges, and reorganization |
+| [`wizz-shard-doc`](#wizz-shard-doc) | Task | Split large markdown files into organized sections |
+| [`wizz-index-docs`](#wizz-index-docs) | Task | Generate or update an index of all docs in a folder |
+| [`wizz-customize`](#wizz-customize) | Task | Create and verify Wizz Method customization overrides |
+
+## wizz-help
 
 **Your intelligent guide to what comes next.** — Inspects your project state, detects what's been done, and recommends the next required or optional step.
 
 **Use it when:**
 
 - You finished a workflow and want to know what's next
-- You're new to BMad and need orientation
+- You're new to the Wizz Method and need orientation
 - You're stuck and want context-aware advice
 - You installed new modules and want to see what's available
 
@@ -3480,11 +3480,11 @@ Run any core tool by typing its skill name (e.g., `bmad-help`) in your IDE. No a
 3. Recommends next steps in priority order — required steps first, then optional
 4. Presents each recommendation with the skill command and a brief description
 
-**Input:** Optional query in natural language (e.g., `bmad-help I have a SaaS idea, where do I start?`)
+**Input:** Optional query in natural language (e.g., `wizz-help I have a SaaS idea, where do I start?`)
 
 **Output:** Prioritized list of recommended next steps with skill commands
 
-## bmad-brainstorming
+## wizz-brainstorming
 
 **Generate diverse ideas through interactive creative techniques.** — A facilitated brainstorming session that loads proven ideation methods from a technique library and guides you toward 100+ ideas before organizing.
 
@@ -3510,9 +3510,9 @@ Run any core tool by typing its skill name (e.g., `bmad-help`) in your IDE. No a
 The magic happens in ideas 50–100. The workflow encourages generating 100+ ideas before organization.
 :::
 
-## bmad-party-mode
+## wizz-party-mode
 
-**Orchestrate multi-agent group discussions.** — Loads all installed BMad agents and facilitates a natural conversation where each agent contributes from their unique expertise and personality.
+**Orchestrate multi-agent group discussions.** — Loads all installed Wizz Method agents and facilitates a natural conversation where each agent contributes from their unique expertise and personality.
 
 **Use it when:**
 
@@ -3532,7 +3532,7 @@ The magic happens in ideas 50–100. The workflow encourages generating 100+ ide
 
 **Output:** Real-time multi-agent conversation with maintained agent personalities
 
-## bmad-spec
+## wizz-spec
 
 **Distill any intent input into the canonical SPEC contract for downstream work.** Takes a brief, PRD, GDD, RFC, brain dump, transcript, UX folder, or mixed multi-source input and produces a `SPEC.md` carrying the five-field kernel (Why, Capabilities, Constraints, Non-goals, Success signal) plus companion files for load-bearing content that does not fit the kernel.
 
@@ -3560,10 +3560,10 @@ Spec Law enforces eight rules: capabilities carry both intent and success; inten
 **Output:** Spec folder containing `SPEC.md`, any companion files, and a `.decision-log.md`. Headless callers receive a JSON response with the result status and the list of files written or modified.
 
 :::note[Mutation contract]
-`bmad-spec` is the only writer of `SPEC.md` and of spec-authored companions. Other skills produce their own native artifacts and invoke `bmad-spec` headless when they need to express intent as the canonical contract or propose updates.
+`wizz-spec` is the only writer of `SPEC.md` and of spec-authored companions. Other skills produce their own native artifacts and invoke `wizz-spec` headless when they need to express intent as the canonical contract or propose updates.
 :::
 
-## bmad-advanced-elicitation
+## wizz-advanced-elicitation
 
 **Push LLM output through iterative refinement methods.** — Selects from a library of elicitation techniques to systematically improve content through multiple passes.
 
@@ -3585,7 +3585,7 @@ Spec Law enforces eight rules: capabilities carry both intent and success; inten
 
 **Output:** Enhanced version of the content with improvements applied
 
-## bmad-review-adversarial-general
+## wizz-review-adversarial-general
 
 **Cynical review that assumes problems exist and searches for them.** — Takes a skeptical, jaded reviewer perspective with zero patience for sloppy work. Looks for what's missing, not just what's wrong.
 
@@ -3609,7 +3609,7 @@ Spec Law enforces eight rules: capabilities carry both intent and success; inten
 
 **Output:** Markdown list of 10+ findings with descriptions
 
-## bmad-review-edge-case-hunter
+## wizz-review-edge-case-hunter
 
 **Walk every branching path and boundary condition, report only unhandled cases.** — Pure path-tracing methodology that mechanically derives edge classes. Orthogonal to adversarial review — method-driven, not attitude-driven.
 
@@ -3634,10 +3634,10 @@ Spec Law enforces eight rules: capabilities carry both intent and success; inten
 **Output:** JSON array of findings, each with `location`, `trigger_condition`, `guard_snippet`, and `potential_consequence`
 
 :::note[Complementary Reviews]
-Run both `bmad-review-adversarial-general` and `bmad-review-edge-case-hunter` together for orthogonal coverage. The adversarial review catches quality and completeness issues; the edge case hunter catches unhandled paths.
+Run both `wizz-review-adversarial-general` and `wizz-review-edge-case-hunter` together for orthogonal coverage. The adversarial review catches quality and completeness issues; the edge case hunter catches unhandled paths.
 :::
 
-## bmad-editorial-review-prose
+## wizz-editorial-review-prose
 
 **Clinical copy-editing focused on communication clarity.** — Reviews text for issues that impede comprehension. Applies Microsoft Writing Style Guide baseline. Preserves author voice.
 
@@ -3662,7 +3662,7 @@ Run both `bmad-review-adversarial-general` and `bmad-review-edge-case-hunter` to
 
 **Output:** Three-column markdown table: Original Text | Revised Text | Changes
 
-## bmad-editorial-review-structure
+## wizz-editorial-review-structure
 
 **Structural editing — proposes cuts, merges, moves, and condensing.** — Reviews document organization and proposes substantive changes to improve clarity and flow before copy editing.
 
@@ -3689,7 +3689,7 @@ Run both `bmad-review-adversarial-general` and `bmad-review-edge-case-hunter` to
 
 **Output:** Document summary, prioritized recommendation list, and estimated reduction
 
-## bmad-shard-doc
+## wizz-shard-doc
 
 **Split large markdown files into organized section files.** — Uses level-2 headers as split points to create a folder of self-contained section files with an index.
 
@@ -3710,7 +3710,7 @@ Run both `bmad-review-adversarial-general` and `bmad-review-edge-case-hunter` to
 
 **Output:** Folder with `index.md` and `01-{section}.md`, `02-{section}.md`, etc.
 
-## bmad-index-docs
+## wizz-index-docs
 
 **Generate or update an index of all documents in a folder.** — Scans a directory, reads each file to understand its purpose, and produces an organized `index.md` with links and descriptions.
 
@@ -3731,9 +3731,9 @@ Run both `bmad-review-adversarial-general` and `bmad-review-edge-case-hunter` to
 
 **Output:** `index.md` with organized file listings, relative links, and brief descriptions
 
-## bmad-customize
+## wizz-customize
 
-**Create and verify customization overrides.** — Helps you change how an installed BMad agent or workflow behaves without hand-authoring TOML.
+**Create and verify customization overrides.** — Helps you change how an installed Wizz Method agent or workflow behaves without hand-authoring TOML.
 
 **Use it when:**
 
@@ -3743,28 +3743,28 @@ Run both `bmad-review-adversarial-general` and `bmad-review-edge-case-hunter` to
 
 **How it works:**
 
-1. Scans installed BMad skills for customizable surfaces
+1. Scans installed Wizz Method skills for customizable surfaces
 2. Selects the right scope for your requested change
-3. Writes override files under `_bmad/custom/`
+3. Writes override files under `_wizz/custom/`
 4. Verifies the merged configuration
 
 **Input:** Natural language description of the customization you want
 
-**Output:** TOML override files under `_bmad/custom/`
+**Output:** TOML override files under `_wizz/custom/`
 
-For a detailed guide on customizing BMad, see [How to Customize BMad](../how-to/customize-bmad.md).
+For a detailed guide on customizing the Wizz Method, see [How to Customize Wizz Method](../how-to/customize-bmad.md).
 </document>
 
 <document path="reference/modules.md">
-BMad extends through official modules that you select during installation. These add-on modules provide specialized agents, workflows, and tasks for specific domains beyond the built-in core and BMM (Agile suite).
+The Wizz Method extends through official modules that you select during installation. These add-on modules provide specialized agents, workflows, and tasks for specific domains beyond the built-in core and BMM (Agile suite).
 
 :::tip[Installing Modules]
-Run `npx bmad-method install` and select the modules you want. The installer handles downloading, configuration, and IDE integration automatically.
+Run `npx wizz-method install` and select the modules you want. The installer handles downloading, configuration, and IDE integration automatically.
 :::
 
-## BMad Builder
+## Wizz Builder
 
-Create custom agents, workflows, and domain-specific modules with guided assistance. BMad Builder is the meta-module for extending the framework itself.
+Create custom agents, workflows, and domain-specific modules with guided assistance. Wizz Builder is the meta-module for extending the framework itself.
 
 - **Code:** `bmb`
 - **npm:** [`bmad-builder`](https://www.npmjs.com/package/bmad-builder)
@@ -3824,18 +3824,18 @@ Enterprise-grade test strategy, automation guidance, and release gate decisions
 
 ## Community Modules
 
-Community modules and a module marketplace are coming. Check the [BMad GitHub organization](https://github.com/bmad-code-org) for updates.
+Community modules and a module marketplace are coming. Check the [Wizz Method GitHub](https://github.com/wizzcomms/wizz-method) for updates.
 </document>
 
 <document path="reference/testing.md">
-BMad provides two testing paths: a built-in QA workflow for fast test generation and an installable Test Architect module for enterprise-grade test strategy.
+The Wizz Method provides two testing paths: a built-in QA workflow for fast test generation and an installable Test Architect module for enterprise-grade test strategy.
 
 ## Which Should You Use?
 
 | Factor | Built-in QA | TEA Module |
 | --- | --- | --- |
 | **Best for** | Small-medium projects, quick coverage | Large projects, regulated or complex domains |
-| **Setup** | Nothing to install -- included in BMM | Install separately via `npx bmad-method install` |
+| **Setup** | Nothing to install -- included in BMM | Install separately via `npx wizz-method install` |
 | **Approach** | Generate tests fast, iterate later | Plan first, then generate with traceability |
 | **Test types** | API and E2E tests | API, E2E, ATDD, NFR, and more |
 | **Strategy** | Happy path + critical edge cases | Risk-based prioritization (P0-P3) |
@@ -3847,9 +3847,9 @@ Most projects should start with the built-in QA workflow. If you later need test
 
 ## Built-in QA Workflow
 
-The built-in QA workflow (`bmad-qa-generate-e2e-tests`) is part of the BMM (Agile suite) module, available through the Developer agent. It generates working tests quickly using your project's existing test framework -- no configuration or additional installation required.
+The built-in QA workflow (`wizz-qa-generate-e2e-tests`) is part of the BMM (Agile suite) module, available through the Developer agent. It generates working tests quickly using your project's existing test framework -- no configuration or additional installation required.
 
-**Trigger:** `QA` (via the Developer agent) or `bmad-qa-generate-e2e-tests`
+**Trigger:** `QA` (via the Developer agent) or `wizz-qa-generate-e2e-tests`
 
 ### What It Does
 
@@ -3889,7 +3889,7 @@ The QA workflow generates tests only. For code review and story validation, use
 TEA is a standalone module that provides an expert agent (Murat) and nine structured workflows for enterprise-grade testing. It goes beyond test generation into test strategy, risk-based planning, quality gates, and requirements traceability.
 
 - **Documentation:** [TEA Module Docs](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
-- **Install:** `npx bmad-method install` and select the TEA module
+- **Install:** `npx wizz-method install` and select the TEA module
 - **npm:** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
 
 ### What TEA Provides
@@ -3918,11 +3918,11 @@ TEA also supports P0-P3 risk-based prioritization and optional integrations with
 
 ## How Testing Fits into Workflows
 
-The QA Automate workflow appears in Phase 4 (Implementation) of the BMad Method workflow map. It is designed to run **after a full epic is complete** — once all stories in an epic have been implemented and code-reviewed. A typical sequence:
+The QA Automate workflow appears in Phase 4 (Implementation) of the Wizz Method workflow map. It is designed to run **after a full epic is complete** — once all stories in an epic have been implemented and code-reviewed. A typical sequence:
 
 1. For each story in the epic: implement with Dev (`DS`), then validate with Code Review (`CR`)
 2. After the epic is complete: generate tests with `QA` (via the Developer agent) or TEA's Automate workflow
-3. Run retrospective (`bmad-retrospective`) to capture lessons learned
+3. Run retrospective (`wizz-retrospective`) to capture lessons learned
 
 The built-in QA workflow works directly from source code without loading planning documents (PRD, architecture). TEA workflows can integrate with upstream planning artifacts for traceability.
 
@@ -3930,7 +3930,7 @@ For more on where testing fits in the overall process, see the [Workflow Map](./
 </document>
 
 <document path="reference/workflow-map.md">
-The BMad Method (BMM) is a module in the BMad Ecosystem, targeted at following the best practices of context engineering
+The Wizz Method (BMM) is a module in the Wizz Ecosystem, targeted at following the best practices of context engineering
 and planning. AI agents work best with clear, structured context. The BMM system builds that context progressively
 across 4 distinct phases - each phase, and multiple workflows optionally within each phase, produce documents that
 inform the next, so agents always know what to build and why.
@@ -3938,16 +3938,16 @@ inform the next, so agents always know what to build and why.
 The rationale and concepts come from agile methodologies that have been used across the industry with great success as a
 mental framework.
 
-If at any time you are unsure what to do, the `bmad-help` skill will help you stay on track or know what to do next. You
-can always refer to this for reference also - but `bmad-help` is fully interactive and much quicker if you have already
-installed the BMad Method. Additionally, if you are using different modules that have extended the BMad Method or added
-other complementary non-extension modules - `bmad-help` evolves to know all that is available to give you the best
+If at any time you are unsure what to do, the `wizz-help` skill will help you stay on track or know what to do next. You
+can always refer to this for reference also - but `wizz-help` is fully interactive and much quicker if you have already
+installed the Wizz Method. Additionally, if you are using different modules that have extended the Wizz Method or added
+other complementary non-extension modules - `wizz-help` evolves to know all that is available to give you the best
 in-the-moment advice.
 
 Final important note: Every workflow below can be run directly with your tool of choice via skill or by loading an agent
 first and using the entry from the agents menu.
 
-<iframe src="/workflow-map-diagram.html" title="BMad Method Workflow Map Diagram" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
+<iframe src="/workflow-map-diagram.html" title="Wizz Method Workflow Map Diagram" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
 
 <p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
   <a href="/workflow-map-diagram.html" target="_blank" rel="noopener noreferrer">Open diagram in new tab ↗</a>
@@ -3960,10 +3960,10 @@ it**](../explanation/analysis-phase.md).
 
 | Workflow                                                                  | Purpose                                                                    | Produces                  |
 |---------------------------------------------------------------------------|----------------------------------------------------------------------------|---------------------------|
-| `bmad-brainstorming`                                                      | Brainstorm Project Ideas with guided facilitation of a brainstorming coach | `brainstorming-report.md` |
-| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validate market, technical, or domain assumptions                          | Research findings         |
-| `bmad-product-brief`                                                      | Capture strategic vision — best when your concept is clear                 | `product-brief.md`        |
-| `bmad-prfaq`                                                              | Working Backwards — stress-test and forge your product concept             | `prfaq-{project}.md`      |
+| `wizz-brainstorming`                                                      | Brainstorm Project Ideas with guided facilitation of a brainstorming coach | `brainstorming-report.md` |
+| `wizz-domain-research`, `wizz-market-research`, `wizz-technical-research` | Validate market, technical, or domain assumptions                          | Research findings         |
+| `wizz-product-brief`                                                      | Capture strategic vision — best when your concept is clear                 | `product-brief.md`        |
+| `wizz-prfaq`                                                              | Working Backwards — stress-test and forge your product concept             | `prfaq-{project}.md`      |
 
 ## Phase 2: Planning
 
@@ -3971,19 +3971,19 @@ Define what to build and for whom.
 
 | Workflow                | Purpose                                                                             | Produces                                          |
 |-------------------------|-------------------------------------------------------------------------------------|---------------------------------------------------|
-| `bmad-prd`              | Create, update, or validate a PRD — facilitated discovery, three intents in one skill | Create/Update: `prd.md`, `addendum.md`, `decision-log.md`; Validate: `validation-report.html` + `.md` |
-| `bmad-ux`               | Design user experience (when UX matters) — DESIGN.md (visual) + EXPERIENCE.md (behavioral) spine pair | `DESIGN.md`, `EXPERIENCE.md`, `.decision-log.md`  |
+| `wizz-prd`              | Create, update, or validate a PRD — facilitated discovery, three intents in one skill | Create/Update: `prd.md`, `addendum.md`, `decision-log.md`; Validate: `validation-report.html` + `.md` |
+| `wizz-ux`               | Design user experience (when UX matters) — DESIGN.md (visual) + EXPERIENCE.md (behavioral) spine pair | `DESIGN.md`, `EXPERIENCE.md`, `.decision-log.md`  |
 
 :::tip[Three intents in one skill]
-`bmad-prd` handles the full PRD lifecycle. State your intent when invoking or the skill will ask:
+`wizz-prd` handles the full PRD lifecycle. State your intent when invoking or the skill will ask:
 
 - **Create** — new PRD from scratch via coached discovery; produces `prd.md`, `addendum.md`, and `decision-log.md`
 - **Update** — reconcile an existing PRD with a change signal, surfacing conflicts before applying changes
 - **Validate** — critique a PRD against a configurable checklist and produce a structured HTML findings report
 :::
 
-:::tip[Upstream: `bmad-product-brief`]
-`bmad-product-brief` (Phase 1) produces a `product-brief.md` that `bmad-prd` can source-extract during Discovery, reducing re-explanation and keeping the two documents aligned. Neither skill requires the other — start with `bmad-prd` directly if you already know what you're building.
+:::tip[Upstream: `wizz-product-brief`]
+`wizz-product-brief` (Phase 1) produces a `product-brief.md` that `wizz-prd` can source-extract during Discovery, reducing re-explanation and keeping the two documents aligned. Neither skill requires the other — start with `wizz-prd` directly if you already know what you're building.
 :::
 
 ## Phase 3: Solutioning
@@ -3992,9 +3992,9 @@ Decide how to build it and break work into stories.
 
 | Workflow                              | Purpose                                    | Produces                    |
 |---------------------------------------|--------------------------------------------|-----------------------------|
-| `bmad-create-architecture`            | Make technical decisions explicit          | `architecture.md` with ADRs |
-| `bmad-create-epics-and-stories`       | Break requirements into implementable work | Epic files with stories     |
-| `bmad-check-implementation-readiness` | Gate check before implementation           | PASS/CONCERNS/FAIL decision |
+| `wizz-create-architecture`            | Make technical decisions explicit          | `architecture.md` with ADRs |
+| `wizz-create-epics-and-stories`       | Break requirements into implementable work | Epic files with stories     |
+| `wizz-check-implementation-readiness` | Gate check before implementation           | PASS/CONCERNS/FAIL decision |
 
 ## Phase 4: Implementation
 
@@ -4002,14 +4002,14 @@ Build it, one story at a time. Coming soon, full phase 4 automation!
 
 | Workflow               | Purpose                                                                       | Produces                                             |
 |------------------------|-------------------------------------------------------------------------------|------------------------------------------------------|
-| `bmad-sprint-planning` | Initialize tracking (once per project to sequence the dev cycle)              | `sprint-status.yaml`                                 |
-| `bmad-create-story`    | Prepare next story for implementation                                         | `story-[slug].md`                                    |
-| `bmad-dev-story`       | Implement the story                                                           | Working code + tests                                 |
-| `bmad-code-review`     | Validate implementation quality                                               | Approved or changes requested                        |
-| `bmad-correct-course`  | Handle significant mid-sprint changes                                         | Updated plan or re-routing                           |
-| `bmad-sprint-status`   | Track sprint progress and story status                                        | Sprint status update                                 |
-| `bmad-retrospective`   | Review after epic completion                                                  | Lessons learned                                      |
-| `bmad-investigate`     | Forensic case investigation with evidence-graded findings, calibrated to the input | `{slug}-investigation.md` |
+| `wizz-sprint-planning` | Initialize tracking (once per project to sequence the dev cycle)              | `sprint-status.yaml`                                 |
+| `wizz-create-story`    | Prepare next story for implementation                                         | `story-[slug].md`                                    |
+| `wizz-dev-story`       | Implement the story                                                           | Working code + tests                                 |
+| `wizz-code-review`     | Validate implementation quality                                               | Approved or changes requested                        |
+| `wizz-correct-course`  | Handle significant mid-sprint changes                                         | Updated plan or re-routing                           |
+| `wizz-sprint-status`   | Track sprint progress and story status                                        | Sprint status update                                 |
+| `wizz-retrospective`   | Review after epic completion                                                  | Lessons learned                                      |
+| `wizz-investigate`     | Forensic case investigation with evidence-graded findings, calibrated to the input | `{slug}-investigation.md` |
 
 ## Quick Flow (Parallel Track)
 
@@ -4017,7 +4017,7 @@ Skip phases 1-3 for small, well-understood work.
 
 | Workflow         | Purpose                                                                   | Produces           |
 |------------------|---------------------------------------------------------------------------|--------------------|
-| `bmad-quick-dev` | Unified quick flow — clarify intent, plan, implement, review, and present | `spec-*.md` + code |
+| `wizz-quick-dev` | Unified quick flow — clarify intent, plan, implement, review, and present | `spec-*.md` + code |
 
 ## Context Management
 
@@ -4036,8 +4036,8 @@ important to keep aligned with current conventions.
 
 **How to create it:**
 
-- **Manually** — Create `_bmad-output/project-context.md` with your technology stack and implementation rules
-- **Generate it** — Run `bmad-generate-project-context` to auto-generate from your architecture or codebase
+- **Manually** — Create `_wizz-output/project-context.md` with your technology stack and implementation rules
+- **Generate it** — Run `wizz-generate-project-context` to auto-generate from your architecture or codebase
 
 [**Learn more about project-context.md**](../explanation/project-context.md)
 </document>