wizz-method 1.0.0 → 1.0.2

package/src/core-skills/{bmad-customize → wizz-customize}/scripts/list_customizable_skills.py

@@ -9,7 +9,7 @@ lives in, derived from __file__), finds every sibling directory containing a
 `customize.toml`, classifies each as agent and/or workflow based on its
 top-level blocks, reads the skill's SKILL.md frontmatter description for a
 one-liner, and checks whether override files already exist in
-`{project-root}/_bmad/custom/`.
+`{project-root}/_wizz/custom/`.
 
 Skills in BMad are loaded either from a project-local location (e.g. the
 project's `.claude/skills/` or `.cursor/skills/`) or from a user-global
@@ -44,7 +44,7 @@ FRONTMATTER_RE = re.compile(r"^---\s*\n(.*?)\n---\s*\n", re.DOTALL)
 def default_skills_root() -> Path:
     """Derive the skills root from this script's location.
 
-    Layout assumption: {skills_root}/bmad-customize/scripts/list_customizable_skills.py.
+    Layout assumption: {skills_root}/wizz-customize/scripts/list_customizable_skills.py.
     So the skills root is three parents up from this file.
     """
     return Path(__file__).resolve().parent.parent.parent
@@ -98,7 +98,7 @@ def scan_skills(
     errors: list[str] = []
     scanned_roots: list[str] = []
     seen_names: set[str] = set()
-    custom_dir = project_root / "_bmad" / "custom"
+    custom_dir = project_root / "_wizz" / "custom"
 
     for root in skills_roots:
         if not root.is_dir():
@@ -170,13 +170,13 @@ def parse_args(argv: list[str]) -> argparse.Namespace:
         description=(
             "List customizable BMad skills installed alongside this one, "
             "grouped by surface (agent vs workflow), with override status "
-            "looked up against {project-root}/_bmad/custom/."
+            "looked up against {project-root}/_wizz/custom/."
         )
     )
     parser.add_argument(
         "--project-root",
         required=True,
-        help="Absolute path to the project root (the folder containing _bmad/).",
+        help="Absolute path to the project root (the folder containing _wizz/).",
     )
     parser.add_argument(
         "--skills-root",

package/src/core-skills/{bmad-customize → wizz-customize}/scripts/tests/test_list_customizable_skills.py

@@ -9,7 +9,7 @@ Exercises the scanner against a synthesized install tree:
 - a workflow-only customize.toml
 - a customize.toml that exposes both surfaces
 - a skill directory with no customize.toml (ignored)
-- a pre-existing team override in _bmad/custom/
+- a pre-existing team override in _wizz/custom/
 - malformed TOML (surfaces as an error without aborting)
 - multiple skills roots (e.g. project-local + user-global mix)
 
@@ -54,7 +54,7 @@ class ScannerTest(unittest.TestCase):
         self.root = Path(self.tmp.name)
         self.skills = self.root / "skills"
         self.skills.mkdir(parents=True)
-        self.custom = self.root / "_bmad" / "custom"
+        self.custom = self.root / "_wizz" / "custom"
         self.custom.mkdir(parents=True)
 
     def tearDown(self):
@@ -63,15 +63,15 @@ class ScannerTest(unittest.TestCase):
     def test_agent_only_skill_detected(self):
         _make_skill(
             self.skills,
-            "bmad-agent-pm",
+            "wizz-agent-pm",
             "[agent]\nicon = \"🧠\"\n",
-            "---\nname: bmad-agent-pm\ndescription: Product manager.\n---\n",
+            "---\nname: wizz-agent-pm\ndescription: Product manager.\n---\n",
         )
         result = MODULE.scan_skills([self.skills], self.root)
         self.assertEqual(len(result["agents"]), 1)
         self.assertEqual(len(result["workflows"]), 0)
         entry = result["agents"][0]
-        self.assertEqual(entry["name"], "bmad-agent-pm")
+        self.assertEqual(entry["name"], "wizz-agent-pm")
         self.assertEqual(entry["surface"], "agent")
         self.assertEqual(entry["description"], "Product manager.")
         self.assertFalse(entry["has_team_override"])
@@ -80,9 +80,9 @@ class ScannerTest(unittest.TestCase):
     def test_workflow_only_skill_detected(self):
         _make_skill(
             self.skills,
-            "bmad-create-prd",
+            "wizz-create-prd",
             "[workflow]\npersistent_facts = []\n",
-            "---\nname: bmad-create-prd\ndescription: 'Create a PRD.'\n---\n",
+            "---\nname: wizz-create-prd\ndescription: 'Create a PRD.'\n---\n",
         )
         result = MODULE.scan_skills([self.skills], self.root)
         self.assertEqual(len(result["agents"]), 0)
@@ -113,11 +113,11 @@ class ScannerTest(unittest.TestCase):
     def test_existing_team_override_flagged(self):
         _make_skill(
             self.skills,
-            "bmad-agent-pm",
+            "wizz-agent-pm",
             "[agent]\nicon = \"x\"\n",
-            "---\nname: bmad-agent-pm\ndescription: PM.\n---\n",
+            "---\nname: wizz-agent-pm\ndescription: PM.\n---\n",
         )
-        (self.custom / "bmad-agent-pm.toml").write_text("[agent]\n")
+        (self.custom / "wizz-agent-pm.toml").write_text("[agent]\n")
         result = MODULE.scan_skills([self.skills], self.root)
         entry = result["agents"][0]
         self.assertTrue(entry["has_team_override"])
@@ -161,19 +161,19 @@ class ScannerTest(unittest.TestCase):
         extra_root.mkdir()
         _make_skill(
             self.skills,
-            "bmad-agent-pm",
+            "wizz-agent-pm",
             "[agent]\nicon = \"x\"\n",
-            "---\nname: bmad-agent-pm\ndescription: PM.\n---\n",
+            "---\nname: wizz-agent-pm\ndescription: PM.\n---\n",
         )
         _make_skill(
             extra_root,
-            "bmad-agent-dev",
+            "wizz-agent-dev",
             "[agent]\nicon = \"y\"\n",
-            "---\nname: bmad-agent-dev\ndescription: Dev.\n---\n",
+            "---\nname: wizz-agent-dev\ndescription: Dev.\n---\n",
         )
         result = MODULE.scan_skills([self.skills, extra_root], self.root)
         names = {a["name"] for a in result["agents"]}
-        self.assertEqual(names, {"bmad-agent-pm", "bmad-agent-dev"})
+        self.assertEqual(names, {"wizz-agent-pm", "wizz-agent-dev"})
         self.assertEqual(len(result["scanned_roots"]), 2)
 
     def test_duplicate_skill_name_across_roots_first_wins(self):
@@ -181,15 +181,15 @@ class ScannerTest(unittest.TestCase):
         extra_root.mkdir()
         _make_skill(
             self.skills,
-            "bmad-agent-pm",
+            "wizz-agent-pm",
             "[agent]\nicon = \"primary\"\n",
-            "---\nname: bmad-agent-pm\ndescription: Primary.\n---\n",
+            "---\nname: wizz-agent-pm\ndescription: Primary.\n---\n",
         )
         _make_skill(
             extra_root,
-            "bmad-agent-pm",
+            "wizz-agent-pm",
             "[agent]\nicon = \"duplicate\"\n",
-            "---\nname: bmad-agent-pm\ndescription: Duplicate.\n---\n",
+            "---\nname: wizz-agent-pm\ndescription: Duplicate.\n---\n",
         )
         result = MODULE.scan_skills([self.skills, extra_root], self.root)
         self.assertEqual(len(result["agents"]), 1)
@@ -206,9 +206,9 @@ class ScannerTest(unittest.TestCase):
     def test_cli_emits_valid_json_and_exits_zero(self):
         _make_skill(
             self.skills,
-            "bmad-agent-pm",
+            "wizz-agent-pm",
             "[agent]\nicon = \"x\"\n",
-            "---\nname: bmad-agent-pm\ndescription: PM.\n---\n",
+            "---\nname: wizz-agent-pm\ndescription: PM.\n---\n",
         )
         proc = subprocess.run(
             [

package/src/core-skills/{bmad-editorial-review-prose → wizz-editorial-review-prose}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-editorial-review-prose
+name: wizz-editorial-review-prose
 description: 'Clinical copy-editor that reviews text for communication issues. Use when user says review for prose or improve the prose'
 ---
 

package/src/core-skills/{bmad-editorial-review-structure → wizz-editorial-review-structure}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-editorial-review-structure
+name: wizz-editorial-review-structure
 description: 'Structural editor that proposes cuts, reorganization, and simplification while preserving comprehension. Use when user requests structural review or editorial review of structure'
 ---
 

package/src/core-skills/{bmad-help → wizz-help}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-help
+name: wizz-help
 description: 'Analyzes current state and user query to answer BMad questions or recommend the next skill(s) to use. Use when user asks for help, bmad help, what to do next, or what to start with in BMad.'
 ---
 
@@ -22,8 +22,8 @@ When this skill completes, the user should:
 
 ## Data Sources
 
-- **Catalog**: `{project-root}/_bmad/_config/bmad-help.csv` — assembled manifest of all installed module skills
-- **Config**: `config.yaml` and `user-config.yaml` files in `{project-root}/_bmad/` and its subfolders — resolve `output-location` variables, provide `communication_language` and `project_knowledge`
+- **Catalog**: `{project-root}/_wizz/_config/wizz-help.csv` — assembled manifest of all installed module skills
+- **Config**: `config.yaml` and `user-config.yaml` files in `{project-root}/_wizz/` and its subfolders — resolve `output-location` variables, provide `communication_language` and `project_knowledge`
 - **Artifacts**: Files matching `outputs` patterns at resolved `output-location` paths reveal which steps are possibly completed; their content may also provide grounding context for recommendations
 - **Project knowledge**: If `project_knowledge` resolves to an existing path, read it for grounding context. Never fabricate project-specific details.
 - **Module docs**: Rows with `_meta` in the `skill` column carry a URL or path in `output-location` pointing to the module's documentation (e.g., llms.txt). Fetch and use these to answer general questions about that module.
@@ -60,7 +60,7 @@ module,skill,display-name,menu-code,description,action,args,phase,preceded-by,fo
 
 For each recommended item, present:
 - `[menu-code]` **Display name** — e.g., "[PR] PRD"
-- Skill name in backticks — e.g., `bmad-prd`
+- Skill name in backticks — e.g., `wizz-prd`
 - For multi-action skills: action invocation context — e.g., "tech-writer lets create a mermaid diagram!"
 - Description if present in CSV; otherwise your existing knowledge of the skill suffices
 - Args if available

package/src/core-skills/{bmad-index-docs → wizz-index-docs}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-index-docs
+name: wizz-index-docs
 description: 'Generates or updates an index.md to reference all docs in the folder. Use if user requests to create or update an index of all files in a specific folder'
 ---
 

package/src/core-skills/{bmad-party-mode → wizz-party-mode}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-party-mode
+name: wizz-party-mode
 description: 'Orchestrates lively group discussions between installed BMAD agents or custom personas, and helps author custom parties. Use when the user requests party mode, a roundtable, or multiple agent perspectives — or wants to create/configure a party, define personas, or build an AI focus-group panel.'
 ---
 
@@ -7,7 +7,7 @@ description: 'Orchestrates lively group discussions between installed BMAD agent
 
 Run a round-table where BMAD agents talk to each other, and to the user, like a real group of distinct people in conversation. Your job as orchestrator is to make it feel like a genuine conversation: fast, in-character, opinionated, and fun. Everything below is an objective, not a script. Use whatever mechanism your model and harness make available to hit it.
 
-**Two intents.** Usually the user wants to *run* a party — that's everything below. If instead they want to *create or configure* one — invent a cast, add a persona, distill customer data into a focus-group panel, set a default, or **edit an existing custom party** (retune a member, add someone to a group) — load `references/create-party.md` and follow it. Detect which from how they invoke the skill; when it's unclear, ask. Neither intent has a headless contract: running a party is the live conversation itself, and the authoring path's only write goes through `bmad-customize`, which gates it.
+**Two intents.** Usually the user wants to *run* a party — that's everything below. If instead they want to *create or configure* one — invent a cast, add a persona, distill customer data into a focus-group panel, set a default, or **edit an existing custom party** (retune a member, add someone to a group) — load `references/create-party.md` and follow it. Detect which from how they invoke the skill; when it's unclear, ask. Neither intent has a headless contract: running a party is the live conversation itself, and the authoring path's only write goes through `wizz-customize`, which gates it.
 
 ## What "Good" Feels Like
 
@@ -24,8 +24,8 @@ If a round comes back feeling like four essays stapled together, you missed the
 
 ## Setup
 
-1. **Resolve customization:** `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly and use its defaults. Then run each `{workflow.activation_steps_prepend}` entry, and hold each `{workflow.persistent_facts}` entry as session-long context (`file:`-prefixed entries are paths/globs under `{project-root}` whose contents load as facts; `skill:`-prefixed entries name a skill to consult; all others are facts verbatim).
-2. Load `{project-root}/_bmad/core/config.yaml`: greet with `{user_name}`, speak in `{communication_language}`, and resolve `{output_folder}` and `{date}` for the wrap-up keepsake.
+1. **Resolve customization:** `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly and use its defaults. Then run each `{workflow.activation_steps_prepend}` entry, and hold each `{workflow.persistent_facts}` entry as session-long context (`file:`-prefixed entries are paths/globs under `{project-root}` whose contents load as facts; `skill:`-prefixed entries name a skill to consult; all others are facts verbatim).
+2. Load `{project-root}/_wizz/core/config.yaml`: greet with `{user_name}`, speak in `{communication_language}`, and resolve `{output_folder}` and `{date}` for the wrap-up keepsake.
 3. **Resolve the active roster:** `python3 {skill-root}/scripts/resolve_party.py --project-root {project-root} --skill {skill-root}`. It returns the active group's full member detail (the `{workflow.default_party}` group if set, else the installed agents), the other group names, and the resolved `{workflow.party_mode}`. If the group carries a `scene`, open already in it and let it shape how the room behaves (who's loose or hostile, who pushes hardest); the same members play differently from one scene to the next. If flagged `open_cast`, cast the room on the fly from the universe its `scene` names — choosing who fits the moment and varying them as the topic shifts; listed members, if any, anchor the room. If `installed_agents_resolved` is false or codes come back `unresolved`, tell the user and carry on with what returned.
 4. **Roster overrides:**
    - If the invocation names a cast or characters inline (e.g. "include the main cast of Cheers circa 1982"), that named cast *is* the roster for this session — conjure them from what you know, go straight into the party, and once it's rolling offer once to save them as a custom party (the `references/create-party.md` write path), without stalling. Ephemeral; this path skips the script.

package/src/core-skills/{bmad-party-mode → wizz-party-mode}/customize.toml

@@ -1,10 +1,10 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-party-mode.
+# Workflow customization surface for wizz-party-mode.
 #
 # Override files (not edited here):
-#   {project-root}/_bmad/custom/bmad-party-mode.toml         (team)
-#   {project-root}/_bmad/custom/bmad-party-mode.user.toml    (personal)
+#   {project-root}/_wizz/custom/wizz-party-mode.toml         (team)
+#   {project-root}/_wizz/custom/wizz-party-mode.user.toml    (personal)
 
 [workflow]
 

package/src/core-skills/{bmad-party-mode → wizz-party-mode}/references/create-party.md

@@ -1,10 +1,10 @@
 # Creating a Party
 
-A guided authoring flow that turns an idea — a themed cast, a one-off persona, or a pile of raw profile data — into custom party members and groups, written to the user's customize.toml override. The output is configuration; `bmad-customize` does the actual write.
+A guided authoring flow that turns an idea — a themed cast, a one-off persona, or a pile of raw profile data — into custom party members and groups, written to the user's customize.toml override. The output is configuration; `wizz-customize` does the actual write.
 
 ## What you're producing
 
-Sparse `[workflow]` override entries for `bmad-party-mode`:
+Sparse `[workflow]` override entries for `wizz-party-mode`:
 
 - `[[workflow.party_members]]` — one per persona: `code`, `name`, `icon`, `title`, `persona`, optional `capabilities`, optional `model`.
 - `[[workflow.party_groups]]` — when the personas form a named room: `id`, `name`, an optional freeform `scene`, and `members` (codes). `members` is optional: leave it off for an open-cast room whose `scene` names a pool the model casts from on the fly.
@@ -30,7 +30,7 @@ Ask which they're after if it isn't obvious, then proceed.
 
 ## Editing an existing party
 
-When the user wants to change a party that already exists (retune a member's persona, add someone to a group, swap the default), read the current state first so you change rather than clobber: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow` returns the merged `party_members`, `party_groups`, and `default_party`. Show the member or group being touched, capture only the delta with the user, and hand that sparse change to `bmad-customize` — it replaces a `party_members`/`party_groups` entry whose `code`/`id` matches and appends the rest, so an edit is just the changed entry, never a full rewrite.
+When the user wants to change a party that already exists (retune a member's persona, add someone to a group, swap the default), read the current state first so you change rather than clobber: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow` returns the merged `party_members`, `party_groups`, and `default_party`. Show the member or group being touched, capture only the delta with the user, and hand that sparse change to `wizz-customize` — it replaces a `party_members`/`party_groups` entry whose `code`/`id` matches and appends the rest, so an edit is just the changed entry, never a full rewrite.
 
 ## Distill from source data (when provided)
 
@@ -56,10 +56,10 @@ Keep pushing for specificity. "Skeptical CFO" is a placeholder; "won't approve a
 - Ask straight: **anything else about this party to specify** before you write it — a house dynamic, a missing voice, a member who should lead.
 - Ask whether **this group should be the default party going forward**. Yes → set `default_party` to the group's id. One-offs with no group can't be a default; skip the ask.
 
-## Write via bmad-customize
+## Write via wizz-customize
 
 **First, check for code collisions.** A custom member whose `code` matches an installed agent silently *overrides* that agent in the collective. Before composing, resolve the collective once — `python3 {skill-root}/scripts/resolve_party.py --project-root {project-root} --skill {skill-root}` — and check each new member's `code` against the returned members. On a collision, surface it ("`analyst` would override the installed Analyst — intended, or pick a different code?") and let the user confirm or rename. One check, not a gate.
 
-Compose the sparse override and hand it to `bmad-customize` to place, confirm, and write — target skill `bmad-party-mode`, `[workflow]` surface. Default to the **user** override (`bmad-party-mode.user.toml`); offer the **team** file when the party is meant to be shared. Hand it the exact entries: the `party_members` tables, any `party_groups` table, and `default_party` if the user opted in. Keep it sparse — only the new entries, never a copy of the base customize.toml. `bmad-customize` shows the TOML, waits for an explicit yes, writes, and verifies the merge; don't write the file yourself.
+Compose the sparse override and hand it to `wizz-customize` to place, confirm, and write — target skill `wizz-party-mode`, `[workflow]` surface. Default to the **user** override (`wizz-party-mode.user.toml`); offer the **team** file when the party is meant to be shared. Hand it the exact entries: the `party_members` tables, any `party_groups` table, and `default_party` if the user opted in. Keep it sparse — only the new entries, never a copy of the base customize.toml. `wizz-customize` shows the TOML, waits for an explicit yes, writes, and verifies the merge; don't write the file yourself.
 
 After it lands, tell the user how to use it: `--party <id>` to summon the group, or that it's now the default if they set it.

package/src/core-skills/{bmad-party-mode → wizz-party-mode}/scripts/resolve_party.py

@@ -59,7 +59,7 @@ def _run_json(cmd):
 
 def load_agents(project_root: Path):
     """Installed agents as {code: entry}. Empty dict (with a flag) on failure."""
-    script = project_root / "_bmad" / "scripts" / "resolve_config.py"
+    script = project_root / "_wizz" / "scripts" / "resolve_config.py"
     data = _run_json([sys.executable, str(script), "--project-root", str(project_root), "--key", "agents"])
     if data is None:
         return {}, False
@@ -68,7 +68,7 @@ def load_agents(project_root: Path):
 
 def load_workflow(project_root: Path, skill_root: Path):
     """Merged [workflow] table. Falls back to the skill's base customize.toml."""
-    script = project_root / "_bmad" / "scripts" / "resolve_customization.py"
+    script = project_root / "_wizz" / "scripts" / "resolve_customization.py"
     data = _run_json([sys.executable, str(script), "--skill", str(skill_root), "--key", "workflow"])
     if data is not None and "workflow" in data:
         return data["workflow"]
@@ -84,7 +84,7 @@ def load_workflow(project_root: Path, skill_root: Path):
 
 
 def _alias(code: str) -> str:
-    """Short alias for an installed agent code: bmad-agent-analyst -> analyst."""
+    """Short alias for an installed agent code: wizz-agent-analyst -> analyst."""
     for prefix in ("bmad-agent-", "bmad-"):
         if code.startswith(prefix):
             return code[len(prefix):]
@@ -208,7 +208,7 @@ def group_detail(g, collective, index):
 def main():
     ap = argparse.ArgumentParser(description="Resolve the party-mode roster, lazily.")
     ap.add_argument("--project-root", required=True)
-    ap.add_argument("--skill", required=True, help="Path to the bmad-party-mode skill dir")
+    ap.add_argument("--skill", required=True, help="Path to the wizz-party-mode skill dir")
     ap.add_argument("--party", help="Resolve full detail for this group id")
     ap.add_argument("--list-groups", action="store_true", help="Group names only")
     args = ap.parse_args()

package/src/core-skills/{bmad-party-mode → wizz-party-mode}/scripts/tests/test-resolve_party.py

@@ -12,14 +12,14 @@ sys.path.insert(0, str(Path(__file__).resolve().parent.parent))
 import resolve_party as rp  # noqa: E402
 
 AGENTS = {
-    "bmad-agent-analyst": {"name": "Mary", "icon": "📊", "title": "Analyst"},
-    "bmad-agent-pm": {"name": "John", "icon": "📋", "title": "PM"},
+    "wizz-agent-analyst": {"name": "Mary", "icon": "📊", "title": "Analyst"},
+    "wizz-agent-pm": {"name": "John", "icon": "📋", "title": "PM"},
 }
 
 
 class TestAlias(unittest.TestCase):
     def test_strips_known_prefixes(self):
-        self.assertEqual(rp._alias("bmad-agent-analyst"), "analyst")
+        self.assertEqual(rp._alias("wizz-agent-analyst"), "analyst")
         self.assertEqual(rp._alias("bmad-foo"), "foo")
 
     def test_passes_through_unprefixed(self):
@@ -29,11 +29,11 @@ class TestAlias(unittest.TestCase):
 class TestBuildCollective(unittest.TestCase):
     def test_installed_agents_indexed_by_code_alias_and_name(self):
         col, idx, _ = rp.build_collective(AGENTS, [])
-        self.assertEqual(set(col), {"bmad-agent-analyst", "bmad-agent-pm"})
-        self.assertEqual(idx["analyst"], "bmad-agent-analyst")      # alias
-        self.assertEqual(idx["mary"], "bmad-agent-analyst")         # name (ci)
-        self.assertEqual(idx["bmad-agent-pm"], "bmad-agent-pm")     # full code
-        self.assertEqual(col["bmad-agent-analyst"]["source"], "installed")
+        self.assertEqual(set(col), {"wizz-agent-analyst", "wizz-agent-pm"})
+        self.assertEqual(idx["analyst"], "wizz-agent-analyst")      # alias
+        self.assertEqual(idx["mary"], "wizz-agent-analyst")         # name (ci)
+        self.assertEqual(idx["wizz-agent-pm"], "wizz-agent-pm")     # full code
+        self.assertEqual(col["wizz-agent-analyst"]["source"], "installed")
 
     def test_custom_member_appends(self):
         col, _, _ = rp.build_collective(AGENTS, [{"code": "morpheus", "name": "Morpheus", "persona": "riddles"}])
@@ -45,12 +45,12 @@ class TestBuildCollective(unittest.TestCase):
         col, _, _ = rp.build_collective(AGENTS, [{"code": "analyst", "name": "Mary-Custom", "persona": "p"}])
         # Override lands on the canonical installed code, not a new "analyst" entry.
         self.assertNotIn("analyst", col)
-        self.assertEqual(col["bmad-agent-analyst"]["source"], "custom")
-        self.assertEqual(col["bmad-agent-analyst"]["name"], "Mary-Custom")
+        self.assertEqual(col["wizz-agent-analyst"]["source"], "custom")
+        self.assertEqual(col["wizz-agent-analyst"]["name"], "Mary-Custom")
 
     def test_member_without_code_skipped(self):
         col, _, _ = rp.build_collective(AGENTS, [{"name": "Nameless"}])
-        self.assertEqual(set(col), {"bmad-agent-analyst", "bmad-agent-pm"})
+        self.assertEqual(set(col), {"wizz-agent-analyst", "wizz-agent-pm"})
 
 
 class TestResolveMembers(unittest.TestCase):
@@ -59,7 +59,7 @@ class TestResolveMembers(unittest.TestCase):
 
     def test_resolves_in_listed_order_and_flags_unknowns(self):
         resolved, unresolved = rp.resolve_members(["morpheus", "analyst", "ghost"], self.col, self.idx)
-        self.assertEqual([m["code"] for m in resolved], ["morpheus", "bmad-agent-analyst"])
+        self.assertEqual([m["code"] for m in resolved], ["morpheus", "wizz-agent-analyst"])
         self.assertEqual(unresolved, ["ghost"])
 
     def test_empty(self):
@@ -127,11 +127,11 @@ class TestInstalledCodesIsDefaultRoom(unittest.TestCase):
         self.assertIn("morpheus", col)
         self.assertIn("sec-hawk", col)
         # ...but NOT in the default room.
-        self.assertEqual(installed, ["bmad-agent-analyst", "bmad-agent-pm"])
+        self.assertEqual(installed, ["wizz-agent-analyst", "wizz-agent-pm"])
         default_room = [col[c]["code"] for c in installed]
-        self.assertEqual(default_room, ["bmad-agent-analyst", "bmad-agent-pm"])
+        self.assertEqual(default_room, ["wizz-agent-analyst", "wizz-agent-pm"])
         # An override keeps its installed slot (and its custom content).
-        self.assertEqual(col["bmad-agent-analyst"]["name"], "Mary-Custom")
+        self.assertEqual(col["wizz-agent-analyst"]["name"], "Mary-Custom")
 
 
 if __name__ == "__main__":

package/src/core-skills/{bmad-review-adversarial-general → wizz-review-adversarial-general}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-review-adversarial-general
+name: wizz-review-adversarial-general
 description: 'Perform a Cynical Review and produce a findings report. Use when the user requests a critical review of something'
 ---
 

package/src/core-skills/{bmad-review-edge-case-hunter → wizz-review-edge-case-hunter}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-review-edge-case-hunter
+name: wizz-review-edge-case-hunter
 description: 'Walk every branching path and boundary condition in content, report only unhandled edge cases. Orthogonal to adversarial review - method-driven not attitude-driven. Use when you need exhaustive edge-case analysis of code, specs, or diffs.'
 ---
 

package/src/core-skills/{bmad-shard-doc → wizz-shard-doc}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-shard-doc
+name: wizz-shard-doc
 description: 'Splits large markdown documents into smaller, organized files based on level 2 (default) sections. Use if the user says perform shard document'
 ---
 

package/src/core-skills/{bmad-spec → wizz-spec}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-spec
+name: wizz-spec
 description: Distill any intent input into the SPEC kernel + companions — the canonical, preservation-validated machine contract for downstream work. Use when the user says "create a spec", "distill this into a spec", "validate this spec", or "update the spec".
 ---
 
@@ -18,10 +18,10 @@ Multiple skills may call to update the same spec over time.
 
 ## On Activation
 
-1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly.
+1. Resolve customization: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly.
 2. Run `{workflow.activation_steps_prepend}`. Treat `{workflow.persistent_facts}` as foundational context (`file:` entries are loaded).
-3. Load `{project-root}/_bmad/core/config.yaml` (and `config.user.yaml` if present), root level and `bmm` section. Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`.
-4. Detect mode. **Headless** when any of: no TTY, programmatic caller (another skill or non-interactive runner), or the first message pre-supplies all inputs and asks for an artifact path back. **Interactive** otherwise. In interactive mode, greet by `{user_name}` in `{communication_language}`, stay in that language, and mention that `bmad-party-mode` and `bmad-advanced-elicitation` are available for deeper exploration on any field.
+3. Load `{project-root}/_wizz/core/config.yaml` (and `config.user.yaml` if present), root level and `bmm` section. Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`.
+4. Detect mode. **Headless** when any of: no TTY, programmatic caller (another skill or non-interactive runner), or the first message pre-supplies all inputs and asks for an artifact path back. **Interactive** otherwise. In interactive mode, greet by `{user_name}` in `{communication_language}`, stay in that language, and mention that `wizz-party-mode` and `wizz-advanced-elicitation` are available for deeper exploration on any field.
 
 Run `{workflow.activation_steps_append}`.
 
@@ -53,12 +53,12 @@ Inside the spec folder:
 
 `.memlog.md` is canonical — an append-only, chronological record of every decision, constraint, capability (with its stable `CAP-N`), assumption, open question, and bit of user direction, one line each in the order it happened, never edited or reordered. `SPEC.md` and every spec-authored companion are **derived on each run** from the memlog (the decision-of-record) plus the sources it cites for raw content — never hand-patched.
 
-Deriving the contract from a living log instead of editing the contract in place is what lets the steps around the spec (PRD, UX, architecture, epics) run in any order and feed the same spec without merge drift: the log only accumulates, the artifact is re-rendered. So the spec is updated *only* by re-deriving it here — bmad-spec is its single writer; a hand-edit to `SPEC.md` from outside is unsupported and is overwritten on the next derive.
+Deriving the contract from a living log instead of editing the contract in place is what lets the steps around the spec (PRD, UX, architecture, epics) run in any order and feed the same spec without merge drift: the log only accumulates, the artifact is re-rendered. So the spec is updated *only* by re-deriving it here — wizz-spec is its single writer; a hand-edit to `SPEC.md` from outside is unsupported and is overwritten on the next derive.
 
-Writes go through the shared script — `{project-root}/_bmad/scripts/memlog.py`, the same location as `resolve_customization.py` (atomic; never read it back except to resume):
+Writes go through the shared script — `{project-root}/_wizz/scripts/memlog.py`, the same location as `resolve_customization.py` (atomic; never read it back except to resume):
 
-- `python3 {project-root}/_bmad/scripts/memlog.py init --workspace {spec-folder} --field topic="<what is being specced>"` — once, at create.
-- `python3 {project-root}/_bmad/scripts/memlog.py append --workspace {spec-folder} --type <decision|constraint|capability|assumption|question|direction|note|event> --text "<one-line gist, reason included>"` — as each lands.
+- `python3 {project-root}/_wizz/scripts/memlog.py init --workspace {spec-folder} --field topic="<what is being specced>"` — once, at create.
+- `python3 {project-root}/_wizz/scripts/memlog.py append --workspace {spec-folder} --type <decision|constraint|capability|assumption|question|direction|note|event> --text "<one-line gist, reason included>"` — as each lands.
 - Terminal moments (a validation verdict, "spec finalized") are `--type event` entries; the memlog carries no status field.
 
 ## The Operation
@@ -69,13 +69,13 @@ When the input is structured and pre-sorted (a PRD with an addendum, a GDD, a br
 
 Distill the input into the five-field kernel using `{workflow.spec_template}` as the skeleton. When input is rich, extract directly — no elicitation. When input is sparse, choose: **express** (best-effort distill, every gap becomes an `open_questions[]` entry) or **guided** (walk the five fields with the user one at a time). Headless defaults to express and logs the choice. Interactive asks.
 
-A recognized domain implication the input leaves unaddressed *is* such a gap — name it as an `open_questions[]` entry (healthcare input silent on PHI/HIPAA, payments silent on PCI, control systems silent on fail-safe) and move on. Flag it; never invent the answer or coach toward it. If these dominate, the input is too thin — suggest `bmad-prd`.
+A recognized domain implication the input leaves unaddressed *is* such a gap — name it as an `open_questions[]` entry (healthcare input silent on PHI/HIPAA, payments silent on PCI, control systems silent on fail-safe) and move on. Flag it; never invent the answer or coach toward it. If these dominate, the input is too thin — suggest `wizz-prd`.
 
 Write lean from the first pass: every sentence must earn its place. Decoration costs tokens and dilutes downstream readers.
 
 Log each decision, capability, constraint, and accepted change to `.memlog.md` as it is made — that running record is what the render reads. Because the log is append-only, a later entry supersedes an earlier one on the same point while the history stays intact. When two currently-live sources or companions disagree on the same field, or an either/or never got resolved, surface it to the user rather than silently choosing — the resolution is itself a new memlog entry.
 
-If the input is genuinely too thin to distill (e.g. "an app for hikers" with no surrounding context), stop and suggest `bmad-prd` (or sibling ceremony skill). This skill distills; it does not coach.
+If the input is genuinely too thin to distill (e.g. "an app for hikers" with no surrounding context), stop and suggest `wizz-prd` (or sibling ceremony skill). This skill distills; it does not coach.
 
 ## Load-bearing
 
@@ -89,8 +89,8 @@ When load-bearing content does not fit the five-field kernel, it lives in a comp
 
 Companions are either:
 
-- **Spec-authored** companions are written by bmad-spec and live as **siblings of SPEC.md** (e.g., `glossary.md`, `patron-archetypes.md`). bmad-spec owns them and may edit them on update operations.
-- **Adopted** companions are load-bearing artifacts written by an upstream skill that downstream still needs to read. bmad-spec references them into `companions:` by relative path but does NOT edit them (e.g., a `DESIGN.md` or `EXPERIENCE.md` from a UX run, an integration partner's API spec). The originating skill owns them.
+- **Spec-authored** companions are written by wizz-spec and live as **siblings of SPEC.md** (e.g., `glossary.md`, `patron-archetypes.md`). wizz-spec owns them and may edit them on update operations.
+- **Adopted** companions are load-bearing artifacts written by an upstream skill that downstream still needs to read. wizz-spec references them into `companions:` by relative path but does NOT edit them (e.g., a `DESIGN.md` or `EXPERIENCE.md` from a UX run, an integration partner's API spec). The originating skill owns them.
 
 Two rules govern companions:
 
@@ -141,5 +141,5 @@ Any update to the spec — resolved assumptions, answered open questions, other
 ## Frontmatter conventions
 
 - `companions:` array of `.md` files downstream MUST read alongside SPEC.md to have the full contract. Paths may point inside the spec folder (spec-authored companions like `glossary.md`) or outside it (adopted companions like `../planning-artifacts/ux-designs/ux-foo-bar-2026-05-23/DESIGN.md`). The split between spec-authored and adopted is implicit by path; downstream treats both the same.
-- `sources:` array of paths to files that were **fully absorbed** into the SPEC, with no remaining downstream value (e.g., a PRD whose every load-bearing claim is now in the kernel). Listed for audit and for bmad-spec to re-read on update. Downstream does NOT read these. Files that downstream still needs to read belong in `companions:`, not here.
+- `sources:` array of paths to files that were **fully absorbed** into the SPEC, with no remaining downstream value (e.g., a PRD whose every load-bearing claim is now in the kernel). Listed for audit and for wizz-spec to re-read on update. Downstream does NOT read these. Files that downstream still needs to read belong in `companions:`, not here.
 - **Do not list** the memlog, README files, organizational artifacts, or any operational record of how upstream skills produced their artifacts. Those are not source content; they are process metadata that downstream consumers don't need.

package/src/core-skills/{bmad-spec → wizz-spec}/assets/headless-schemas.md

@@ -8,9 +8,9 @@ The default invocation is headless: input goes in, JSON comes out. The contract
 {
   "status": "complete",
   "files": [
-    "_bmad-output/specs/spec-quarter-drop/SPEC.md",
-    "_bmad-output/specs/spec-quarter-drop/glossary.md",
-    "_bmad-output/specs/spec-quarter-drop/.memlog.md"
+    "_wizz-output/specs/spec-quarter-drop/SPEC.md",
+    "_wizz-output/specs/spec-quarter-drop/glossary.md",
+    "_wizz-output/specs/spec-quarter-drop/.memlog.md"
   ]
 }
 ```
@@ -23,7 +23,7 @@ The default invocation is headless: input goes in, JSON comes out. The contract
 {
   "status": "blocked",
   "error_code": "insufficient_intent",
-  "reason": "Input was a one-line idea with no surrounding context; too thin to distill. Suggest bmad-prd to draw the vision out first."
+  "reason": "Input was a one-line idea with no surrounding context; too thin to distill. Suggest wizz-prd to draw the vision out first."
 }
 ```
 

package/src/core-skills/{bmad-spec → wizz-spec}/customize.toml

@@ -1,10 +1,10 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-spec.
+# Workflow customization surface for wizz-spec.
 #
 # Override files (not edited here):
-#   {project-root}/_bmad/custom/bmad-spec.toml        (team)
-#   {project-root}/_bmad/custom/bmad-spec.user.toml   (personal)
+#   {project-root}/_wizz/custom/wizz-spec.toml        (team)
+#   {project-root}/_wizz/custom/wizz-spec.user.toml   (personal)
 
 [workflow]
 
@@ -21,7 +21,7 @@ activation_steps_append = []
 # Each entry is either a literal sentence, a skill prefixed with `skill:`,
 # or a `file:`-prefixed path/glob whose contents are loaded as facts.
 # Default points to a single top-level file; override in team/user TOML
-# to widen the scope (e.g. `_bmad/**/project-context.md`) if needed.
+# to widen the scope (e.g. `_wizz/**/project-context.md`) if needed.
 persistent_facts = [
   "file:{project-root}/project-context.md",
 ]
@@ -39,7 +39,7 @@ spec_template = "assets/spec-template.md"
 spec_filename = "SPEC.md"
 
 # Output path for spec folders. Lands directly under {output_folder}
-# so bmad-spec works in core-only installs and matches the
+# so wizz-spec works in core-only installs and matches the
 # long-term BMad direction of grouping artifacts as siblings under
 # {output_folder}/<type>/ rather than nested inside planning vs
 # implementation folders.

package/src/modules/wizz/README.md

@@ -21,7 +21,7 @@ Os papéis de dev/produto reusam os agentes BMAD (Mary, John, Winston, Amelia, S
 - **Encerramento** (`_shared/encerramento.md`): bloco ✅/➡️/🎯 ao terminar.
 - **Economia de token** (`_shared/token-economy.md`): graphify → cerebro → grep antes de ler arquivos; RTK reescreve shell.
 - **Cerebro** (`_shared/cerebro.md`): auto-load leve na ativação, lembrete de salvar no fim.
-- **Idioma**: escolhido no `wizz-init` (padrão Português (BR)), gravado em `_bmad/bmm/config.yaml`.
+- **Idioma**: escolhido no `wizz-init` (padrão Português (BR)), gravado em `_wizz/bmm/config.yaml`.
 - **Encadeamento**: modo confirmado. O maestro dispara o 1º agente; você confirma os próximos.
 
 ## Instalação
@@ -36,4 +36,4 @@ Os papéis de dev/produto reusam os agentes BMAD (Mary, John, Winston, Amelia, S
 
 ## Customização pessoal
 
-Os overrides em `overrides/*.toml` são escopo **time** e vão para `_bmad/custom/`. Para ajustes só seus, crie `_bmad/custom/<skill>.user.toml` — ele vence por cima.
+Os overrides em `overrides/*.toml` são escopo **time** e vão para `_wizz/custom/`. Para ajustes só seus, crie `_wizz/custom/<skill>.user.toml` — ele vence por cima.

package/src/modules/wizz/agents/wizz-ads/SKILL.md

@@ -9,11 +9,11 @@ description: Agente de Mídia Paga do Wizz Method. Use para campanhas de anúnci
 Você é o Ads do Wizz. Planeja campanhas, gera variações de criativo e acompanha métricas. Roteia para as skills globais via a ferramenta `Skill` e usa o MCP `meta-ads` quando for gestão real de campanhas Meta.
 
 ## Na ativação
-1. **Resolver bloco:** rode `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key agent`. Se falhar, mescle base → time → pessoal (`{skill-root}/customize.toml`, `{project-root}/_bmad/custom/{skill-name}.toml`, `.user.toml`).
+1. **Resolver bloco:** rode `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key agent`. Se falhar, mescle base → time → pessoal (`{skill-root}/customize.toml`, `{project-root}/_wizz/custom/{skill-name}.toml`, `.user.toml`).
 2. Execute `{agent.activation_steps_prepend}`.
 3. Persona: `{agent.role}`, `{agent.identity}`, `{agent.communication_style}`, `{agent.principles}`.
 4. Carregue `{agent.persistent_facts}`.
-5. Config: `{project-root}/_bmad/bmm/config.yaml` → `{user_name}`, `{communication_language}`.
+5. Config: `{project-root}/_wizz/bmm/config.yaml` → `{user_name}`, `{communication_language}`.
 6. Saúde com `{agent.icon}`.
 7. Execute `{agent.activation_steps_append}`.
 8. Menu/dispatch.

package/src/modules/wizz/agents/wizz-copy/SKILL.md

@@ -9,11 +9,11 @@ description: Copywriter do Wizz Method. Use para copy de venda, headlines, texto
 Você é o Copy do Wizz. Escreve textos que vendem, humaniza o que soa robótico e entrega variações prontas. Você roteia para as skills globais de copy via a ferramenta `Skill`.
 
 ## Na ativação
-1. **Resolver bloco:** rode `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key agent`. Se falhar, mescle base → time → pessoal: `{skill-root}/customize.toml`, `{project-root}/_bmad/custom/{skill-name}.toml`, `{project-root}/_bmad/custom/{skill-name}.user.toml`.
+1. **Resolver bloco:** rode `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key agent`. Se falhar, mescle base → time → pessoal: `{skill-root}/customize.toml`, `{project-root}/_wizz/custom/{skill-name}.toml`, `{project-root}/_wizz/custom/{skill-name}.user.toml`.
 2. Execute `{agent.activation_steps_prepend}`.
 3. Adote persona: `{agent.role}`, `{agent.identity}`, `{agent.communication_style}`, `{agent.principles}`.
 4. Carregue `{agent.persistent_facts}`.
-5. Config: `{project-root}/_bmad/bmm/config.yaml` → `{user_name}`, `{communication_language}`.
+5. Config: `{project-root}/_wizz/bmm/config.yaml` → `{user_name}`, `{communication_language}`.
 6. Saúde `{user_name}` em `{communication_language}` começando com `{agent.icon}`.
 7. Execute `{agent.activation_steps_append}`.
 8. Menu/dispatch.