wizz-method 2.0.0 → 2.1.1

package/src/bmm-skills/3-solutioning/wizz-architecture/SKILL.md

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

package/src/bmm-skills/3-solutioning/wizz-architecture/references/headless.md

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

package/src/bmm-skills/3-solutioning/wizz-check-implementation-readiness/SKILL.md

@@ -14,7 +14,6 @@ description: 'Validate PRD, UX, Architecture and Epics specs are complete. Use w
 - Bare paths (e.g. `steps/step-01-document-discovery.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## WORKFLOW ARCHITECTURE
 
@@ -49,13 +48,13 @@ description: 'Validate PRD, UX, Architecture and Epics specs are complete. Use w
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-check-implementation-readiness.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-check-implementation-readiness` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-check-implementation-readiness.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-check-implementation-readiness.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 

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

@@ -127,6 +127,6 @@ Implementation Readiness complete. Invoke the `wizz-help` skill.
 
 ## On Complete
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+Run: read `workflow.on_complete` from the `{project-root}/_wizz/_resolved/wizz-check-implementation-readiness.json` snapshot loaded in step 1
 
 If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/3-solutioning/wizz-create-architecture/SKILL.md

@@ -9,7 +9,7 @@ This skill was consolidated into `wizz-architecture`. It is retained as a thin c
 
 ## On Activation
 
-1. Resolve customization: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_wizz/custom/wizz-create-architecture.toml` and `wizz-create-architecture.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+1. Resolve customization: Read `{project-root}/_wizz/_resolved/wizz-create-architecture.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-create-architecture` from the project root and read the snapshot again.
 
 2. Load `{project-root}/_wizz/bmm/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
 

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

@@ -14,7 +14,6 @@ description: 'Break requirements into epics and user stories. Use when the user
 - Bare paths (e.g. `steps/step-01-validate-prerequisites.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## WORKFLOW ARCHITECTURE
 
@@ -51,13 +50,13 @@ This uses **step-file architecture** for disciplined execution:
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-create-epics-and-stories.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-create-epics-and-stories` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-create-epics-and-stories.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-create-epics-and-stories.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 

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

@@ -138,6 +138,6 @@ Upon Completion of task output: offer to answer any questions about the Epics an
 
 ## On Complete
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+Run: read `workflow.on_complete` from the `{project-root}/_wizz/_resolved/wizz-create-epics-and-stories.json` snapshot loaded in step 1
 
 If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/3-solutioning/wizz-generate-project-context/SKILL.md

@@ -14,7 +14,6 @@ description: 'Create project-context.md with AI rules. Use when the user says "g
 - Bare paths (e.g. `steps/step-01-discover.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## WORKFLOW ARCHITECTURE
 
@@ -30,13 +29,13 @@ This uses **micro-file architecture** for disciplined execution:
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-generate-project-context.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-generate-project-context` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-generate-project-context.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-generate-project-context.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 

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

@@ -284,6 +284,6 @@ The project context file serves as the critical "rules of the road" that agents
 
 ## On Complete
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+Run: read `workflow.on_complete` from the `{project-root}/_wizz/_resolved/wizz-generate-project-context.json` snapshot loaded in step 1
 
 If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/4-implementation/wizz-agent-dev/SKILL.md

@@ -14,19 +14,18 @@ You are Amelia, the Senior Software Engineer. You execute approved stories with
 - Bare paths (e.g. `references/guide.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## On Activation
 
 ### Step 1: Resolve the Agent Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key agent`
+Run: read `{project-root}/_wizz/_resolved/wizz-agent-dev.json` (subtree `agent`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-agent-dev` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `agent` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-agent-dev.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-agent-dev.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 

package/src/bmm-skills/4-implementation/wizz-checkpoint-preview/SKILL.md

@@ -14,19 +14,18 @@ description: 'LLM-assisted human-in-the-loop review. Make sense of a change, foc
 - Bare paths (e.g. `step-01-orientation.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## On Activation
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-checkpoint-preview.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-checkpoint-preview` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-checkpoint-preview.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-checkpoint-preview.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 

package/src/bmm-skills/4-implementation/wizz-checkpoint-preview/step-05-wrapup.md

@@ -25,6 +25,6 @@ HALT — do not proceed until the user makes their choice.
 
 ## On Complete
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+Run: read `workflow.on_complete` from the `{project-root}/_wizz/_resolved/wizz-checkpoint-preview.json` snapshot loaded in step 1
 
 If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/4-implementation/wizz-code-review/SKILL.md

@@ -17,19 +17,18 @@ If you need an explicit user instruction to run them, ask once now for the whole
 - Bare paths (e.g. `checklist.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## On Activation
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-code-review.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-code-review` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-code-review.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-code-review.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 

package/src/bmm-skills/4-implementation/wizz-code-review/customize.toml

@@ -53,16 +53,11 @@ name = "Blind Hunter"
 instruction = """
 Launch a context-free `wizz-exec-review` subagent with this prompt — pinned to the platform's Forte tier (`opus` in Claude Code), never inheriting the session model. Tell the user the tier and count of this dispatch.
 
-Conduct a review of CONTENT.
-Look for what's missing, not only what's wrong.
-Find at least ten issues to fix or improve.
-Output a Markdown list of findings only — no severity, priority, or ranking.
-If the content is empty, stop and say so.
-If you have zero findings, re-check and keep thinking; do not stop with an empty list.
+Read `{skill-root}/review-prompts/blind-hunter.md` completely and follow it as your review instructions.
 
-CONTENT: the unified diff at `{diff_file}`. Read that file — it is the content under review.
+Review content: the unified diff at `{diff_file}`. Read that file — it is the content under review.
 
-Do not invoke any skill, and do not spawn subagents of your own — you are the reviewer. Return your findings as text in your final message; do not route them through any findings-reporting tool the host may offer.
+Do not invoke any skill, and do not spawn subagents of your own — you are the reviewer. If the instruction file is unreadable, report that exact failure and stop. Return your findings as text in your final message; do not route them through any findings-reporting tool the host may offer.
 
 """
 

package/src/bmm-skills/4-implementation/wizz-code-review/review-prompts/blind-hunter.md

@@ -0,0 +1,20 @@
+# Blind Hunter Review
+
+**Goal:** Conduct a blind review of CONTENT — no project context, no spec, no triage. Hunt for what's missing, not only what's wrong.
+
+**Your method:**
+
+- Conduct a review of CONTENT.
+- Look for what's missing, not only what's wrong.
+- Find at least ten issues to fix or improve.
+- Output a Markdown list of findings only — no severity, priority, or ranking.
+- If the content is empty, stop and say so.
+- If you have zero findings, re-check and keep thinking; do not stop with an empty list.
+
+## OUTPUT FORMAT
+
+A Markdown list of findings only. One bullet per issue, description only — no severity, priority, or ranking.
+
+## CONTENT SOURCE
+
+"Review content:" in the message that launched you gives the content itself or a path to read it from. Read the file when it is a path; either way that is the content under review, and this instruction file never is. If no content is supplied, or it is empty or unreadable, stop and say so — never report a clean review for content you could not read.

package/src/bmm-skills/4-implementation/wizz-code-review/steps/step-04-present.md

@@ -129,6 +129,6 @@ Present the user with follow-up options:
 
 ## On Complete
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+Run: read `workflow.on_complete` from the `{project-root}/_wizz/_resolved/wizz-code-review.json` snapshot loaded in step 1
 
 If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/4-implementation/wizz-correct-course/SKILL.md

@@ -14,19 +14,18 @@ description: 'Manage significant changes during sprint execution. Use when the u
 - Bare paths (e.g. `checklist.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## On Activation
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-correct-course.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-correct-course` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-correct-course.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-correct-course.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 
@@ -295,7 +294,7 @@ Activation is complete. If `activation_steps_prepend` or `activation_steps_appen
 
 <action>Report workflow completion to user with personalized message: "Correct Course workflow complete, {user_name}!"</action>
 <action>Remind user of success criteria and next steps for Developer agent</action>
-<action>Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
+<action>Run: read `{project-root}/_wizz/_resolved/wizz-correct-course.json` (subtree `workflow.on_complete`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-correct-course` from the project root and read it again — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
 </step>
 
 </workflow>

package/src/bmm-skills/4-implementation/wizz-create-story/SKILL.md

@@ -24,19 +24,18 @@ If you need an explicit user instruction to run them, ask once now for the whole
 - Bare paths (e.g. `discover-inputs.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## On Activation
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-create-story.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-create-story` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-create-story.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-create-story.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 
@@ -426,7 +425,7 @@ Activation is complete. If `activation_steps_prepend` or `activation_steps_appen
 
     **The developer now has everything needed for flawless implementation!**
   </output>
-  <action>Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
+  <action>Run: read `{project-root}/_wizz/_resolved/wizz-create-story.json` (subtree `workflow.on_complete`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-create-story` from the project root and read it again — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
 </step>
 
 </workflow>

package/src/bmm-skills/4-implementation/wizz-dev-story/SKILL.md

@@ -22,19 +22,18 @@ description: 'Execute story implementation following a context filled story spec
 - Bare paths (e.g. `steps/step-01-init.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## On Activation
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-dev-story.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-dev-story` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-dev-story.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-dev-story.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 
@@ -495,7 +494,7 @@ Activation is complete. If `activation_steps_prepend` or `activation_steps_appen
       <action>Suggest checking {sprint_status} to see project progress</action>
     </check>
     <action>Remain flexible - allow user to choose their own path or ask for other assistance</action>
-  <action>Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
+  <action>Run: read `{project-root}/_wizz/_resolved/wizz-dev-story.json` (subtree `workflow.on_complete`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-dev-story` from the project root and read it again — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
   </step>
 
 </workflow>

package/src/bmm-skills/4-implementation/wizz-investigate/SKILL.md

@@ -52,7 +52,7 @@ After every outcome, present what was learned and pause for the user before cont
 
 ### Step 1: Resolve the workflow block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-investigate.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-investigate` from the project root and read the snapshot again
 
 If the script fails, stop and surface the error.
 

package/src/bmm-skills/4-implementation/wizz-qa-generate-e2e-tests/SKILL.md

@@ -14,19 +14,18 @@ description: 'Generate end to end automated tests for existing features. Use whe
 - Bare paths (e.g. `checklist.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## On Activation
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-qa-generate-e2e-tests.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-qa-generate-e2e-tests` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-qa-generate-e2e-tests.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-qa-generate-e2e-tests.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 
@@ -171,6 +170,6 @@ Save summary to: `{default_output_file}`
 
 ## On Complete
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
+Run: read `{project-root}/_wizz/_resolved/wizz-qa-generate-e2e-tests.json` (subtree `workflow.on_complete`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-qa-generate-e2e-tests` from the project root and read it again
 
 If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/4-implementation/wizz-quick-dev/SKILL.md

@@ -37,7 +37,7 @@ A specification should target a **single user-facing goal** within **900–1600
 
 You are the leaf: the maestro demotes here for pointed work (bug, tweak, single-goal feature). Re-check scope against the shared complexity signal (areas, steps, needs-planning?, artifact+memory?):
 
-**Dispatch rule:** IF 2+ areas → `wizz-maestro`, always. ELSE count the 3 remaining factors (multi-step, needs planning, produces a memorable artifact); 2+ factors → `wizz-maestro`.
+**Dispatch rule:** IF 2+ areas → `wizz-maestro`, always. ELSE count the 3 remaining factors (multi-step, needs planning, produces a memorable artifact); 2+ factors → `wizz-maestro`. The area clause decides on its own, without summing with anything else.
 
 - If clarification reveals the request is actually **multi-goal / multi-area** (2+ top-level shippable deliverables, or it spans several areas), do not silently absorb it. That is clause 1: escalate regardless of how light each individual part looks. Surface it and propose escalating to `wizz-maestro` to orchestrate the sequence. Proceed solo only if the user confirms a narrowed single goal.
 - If it is genuinely single-area but hits 2+ of the remaining factors (multi-step, needs planning, produces a memorable artifact), also escalate. Do not silently absorb heavy single-area work either.
@@ -52,19 +52,18 @@ If the request is a **new multi-step feature** and no story/PRD covers it (check
 - Bare paths (e.g. `step-01-clarify-and-route.md`) resolve from the skill root.
 - `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
 - `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
 
 ## On Activation
 
 ### Step 1: Resolve the Workflow Block
 
-Run: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`
+Run: read `{project-root}/_wizz/_resolved/wizz-quick-dev.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-quick-dev` from the project root and read the snapshot again
 
 **If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
 
 1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_wizz/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_wizz/custom/{skill-name}.user.toml` — personal overrides
+2. `{project-root}/_wizz/custom/wizz-quick-dev.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-quick-dev.user.toml` — personal overrides
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 

package/src/bmm-skills/4-implementation/wizz-quick-dev/customize.toml

@@ -51,16 +51,11 @@ name = "Blind Hunter"
 instruction = """
 Launch a context-free `wizz-exec-review` subagent with this prompt — pinned to the platform's Forte tier (`opus` in Claude Code), never inheriting the session model. Tell the user the tier and count of this dispatch.
 
-Conduct a review of CONTENT.
-Look for what's missing, not only what's wrong.
-Find at least ten issues to fix or improve.
-Output a Markdown list of findings only — no severity, priority, or ranking.
-If the content is empty, stop and say so.
-If you have zero findings, re-check and keep thinking; do not stop with an empty list.
+Read `{skill-root}/review-prompts/blind-hunter.md` completely and follow it as your review instructions.
 
-CONTENT: the unified diff at `{diff_file}`. Read that file — it is the content under review.
+Review content: the unified diff at `{diff_file}`. Read that file — it is the content under review.
 
-Do not invoke any skill, and do not spawn subagents of your own — you are the reviewer. Return your findings as text in your final message; do not route them through any findings-reporting tool the host may offer.
+Do not invoke any skill, and do not spawn subagents of your own — you are the reviewer. If the instruction file is unreadable, report that exact failure and stop. Return your findings as text in your final message; do not route them through any findings-reporting tool the host may offer.
 
 """
 
@@ -97,11 +92,10 @@ Do not invoke any skill, and do not spawn subagents of your own — you are the
 # Review layers for the one-shot route. Consumed by step-oneshot.md, the same way
 # step-04-review.md consumes review_layers above.
 #
-# Duplicacao conhecida (2026-09-10): o prompt do Blind Hunter existe em tres copias
-# (aqui, no review_layers acima e no customize.toml do wizz-code-review) e ainda numa
-# quarta, a skill core wizz-review-adversarial-general, que hoje nenhum workflow
-# invoca. Unificar isso num review-prompts/blind-hunter.md, como ja e feito com
-# edge-case-hunter e verification-gap, e decisao em aberto.
+# O prompt do Blind Hunter vive em review-prompts/blind-hunter.md (fonte única,
+# item 22 da auditoria de 2026-09-11), mesmo padrão de edge-case-hunter e
+# verification-gap. Uma cópia idêntica fica em wizz-code-review/review-prompts/
+# e um teste de paridade (test/test-blind-hunter-parity.js) trava as duas.
 
 [[workflow.oneshot_review_layers]]
 id = "blind-hunter"
@@ -109,16 +103,10 @@ name = "Blind Hunter"
 instruction = """
 Launch a context-free `wizz-exec-review` subagent with this prompt — pinned to the platform's Forte tier (`opus` in Claude Code), never inheriting the session model. Tell the user the tier and count of this dispatch.
 
-Conduct a review of CONTENT.
-Look for what's missing, not only what's wrong.
-Find at least ten issues to fix or improve.
-Output a Markdown list of findings only — no severity, priority, or ranking.
-If the content is empty, stop and say so.
-If you have zero findings, re-check and keep thinking; do not stop with an empty list.
+Read `{skill-root}/review-prompts/blind-hunter.md` completely and follow it as your review instructions.
 
-CONTENT:
-The changed files in the current worktree. Inspect them directly before reviewing.
+Review content: the changed files in the current worktree. Inspect them directly before reviewing.
 
-Do not invoke any skill, and do not spawn subagents of your own — you are the reviewer. Return your findings as text in your final message; do not route them through any findings-reporting tool the host may offer.
+Do not invoke any skill, and do not spawn subagents of your own — you are the reviewer. If the instruction file is unreadable, report that exact failure and stop. Return your findings as text in your final message; do not route them through any findings-reporting tool the host may offer.
 
 """