wizz-method 1.19.0 → 2.1.0

package/src/bmm-skills/1-analysis/wizz-agent-tech-writer/SKILL.md

@@ -14,19 +14,18 @@ You are Paige, the Technical Writer. You transform complex concepts into accessi
 - 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-tech-writer.json` (subtree `agent`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-agent-tech-writer` 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-tech-writer.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-agent-tech-writer.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/1-analysis/wizz-document-project/SKILL.md

@@ -14,19 +14,18 @@ description: 'Document brownfield projects for AI context. Use when the user say
 - Bare paths (e.g. `instructions.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-document-project.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-document-project` 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-document-project.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-document-project.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/1-analysis/wizz-document-project/workflows/deep-dive-instructions.md

@@ -291,7 +291,7 @@ These comprehensive docs are now ready for:
 
 Thank you for using the document-project workflow!
 </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 `workflow.on_complete` from the `{project-root}/_wizz/_resolved/wizz-document-project.json` snapshot loaded in step 1 — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
 <action>Exit workflow</action>
 </action>
 </step>

package/src/bmm-skills/1-analysis/wizz-document-project/workflows/full-scan-instructions.md

@@ -1103,6 +1103,6 @@ When ready to plan new features, run the PRD workflow and provide this index as
   </action>
 
 <action>Display: "State file saved: {{project_knowledge}}/project-scan-report.json"</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 `workflow.on_complete` from the `{project-root}/_wizz/_resolved/wizz-document-project.json` snapshot loaded in step 1 — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
 
 </workflow>

package/src/bmm-skills/1-analysis/wizz-prfaq/SKILL.md

@@ -24,19 +24,18 @@ The PRFAQ forces customer-first clarity: write the press release announcing the
 - Bare paths (e.g. `references/press-release.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-prfaq.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-prfaq` 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-prfaq.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-prfaq.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/1-analysis/wizz-prfaq/references/verdict.md

@@ -78,6 +78,6 @@ purpose: "Token-efficient context for downstream PRD creation"
 
 This is the terminal stage. If the user wants to revise, loop back to the relevant stage. Otherwise, the workflow is done.
 
-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-prfaq.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/1-analysis/wizz-product-brief/SKILL.md

@@ -15,7 +15,7 @@ At the opening greeting, let the user know they can invoke `wizz-party-mode` for
 
 ## On Activation
 
-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 defaults.
+1. Resolve customization: Read `{project-root}/_wizz/_resolved/wizz-product-brief.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-product-brief` from the project root and read the snapshot again. On failure, read `{skill-root}/customize.toml` directly and use defaults.
 2. Execute each entry in `{workflow.activation_steps_prepend}` in order.
 3. Treat every entry in `{workflow.persistent_facts}` as foundational context for the rest of the run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
 4. `{workflow.external_sources}` is an org-configured registry of internal tools (knowledge bases, MCP tools); consult them alongside generic web research on the same triggers in `## Discovery`, org tools preferred when their directive matches. If a named tool is unavailable at runtime, fall back to standard behavior and note the gap when relevant.

package/src/bmm-skills/2-plan-workflows/wizz-agent-pm/SKILL.md

@@ -14,19 +14,18 @@ You are John, the Product Manager. You drive PRD creation through user interview
 - 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-pm.json` (subtree `agent`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-agent-pm` 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-pm.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-agent-pm.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/2-plan-workflows/wizz-agent-ux-designer/SKILL.md

@@ -14,19 +14,18 @@ You are Sally, the UX Designer. You translate user needs into interaction design
 - 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-ux-designer.json` (subtree `agent`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-agent-ux-designer` 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-ux-designer.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-agent-ux-designer.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/2-plan-workflows/wizz-create-prd/SKILL.md

@@ -9,7 +9,7 @@ This skill was consolidated into `wizz-prd`. It is retained as a thin compatibil
 
 ## 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-prd.toml` and `wizz-create-prd.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-prd.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-create-prd` 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/2-plan-workflows/wizz-edit-prd/SKILL.md

@@ -9,7 +9,7 @@ This skill was consolidated into `wizz-prd`. It is retained as a thin compatibil
 
 ## 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-edit-prd.toml` and `wizz-edit-prd.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-edit-prd.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-edit-prd` 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/2-plan-workflows/wizz-prd/SKILL.md

@@ -15,7 +15,7 @@ You are a master facilitator and coach helping the user create, edit, or validat
 
 ## On Activation
 
-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 defaults.
+1. Resolve customization: Read `{project-root}/_wizz/_resolved/wizz-prd.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-prd` from the project root and read the snapshot again. On failure, read `{skill-root}/customize.toml` directly and use defaults.
 2. Run `{workflow.activation_steps_prepend}`. Treat `{workflow.persistent_facts}` as foundational context (entries prefixed `file:` are loaded). `{workflow.external_sources}` is an org-configured registry of internal tools (knowledge bases, MCP tools); consult them alongside generic web research on the same triggers, org tools preferred when their directive matches. Research itself fires during Discovery — see **Research subagents**.
 3. Load `{project-root}/_wizz/bmm/config.yaml` (+ `config.user.yaml` if present). Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`. Missing keys → neutral defaults; never block.
 4. If headless, follow `references/headless.md` for the whole run. Otherwise greet the user **by name** using `{user_name}` and **in their language** using `{communication_language}` — and stay in `{communication_language}` for every turn for the entire run, not just the greeting. In the greeting, let the user know that at any point they can invoke `wizz-party-mode` for multi-agent perspectives or `wizz-advanced-elicitation` for deeper exploration on a specific section. Then scan for misroute on the first message: if the signal points elsewhere (game → Wizz GDS; express build → `wizz-quick-dev`; one-pager → `wizz-product-brief`; vet product idea → `wizz-prfaq`; agent skill or custom agent → `wizz-workflow-builder`), suggest they might want the other options before continuing.

package/src/bmm-skills/2-plan-workflows/wizz-ux/SKILL.md

@@ -30,7 +30,7 @@ UX may lead, follow, or stand alone. Inherit `sources:` by reference; the spines
 
 ## On Activation
 
-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 defaults.
+1. Resolve customization: Read `{project-root}/_wizz/_resolved/wizz-ux.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-ux` from the project root and read the snapshot again. On failure, read `{skill-root}/customize.toml` directly and use defaults.
 2. Run `{workflow.activation_steps_prepend}`. Treat `{workflow.persistent_facts}` as foundational context (entries prefixed `file:` are loaded). `{workflow.external_sources}` is an org-configured registry of internal tools; consult them alongside generic web research on the same triggers, org tools preferred when their directive matches.
 3. Load `{project-root}/_wizz/bmm/config.yaml` (+ `config.user.yaml` if present). Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`. Missing keys → neutral defaults; never block.
 4. If headless, follow `references/headless.md` for the whole run. Otherwise greet the user **by name** using `{user_name}` and **in their language** using `{communication_language}` — and stay in `{communication_language}` for every turn. In the greeting, let the user know `wizz-party-mode` and `wizz-advanced-elicitation` are always available. Then scan for misroute on the first message: PRD → `wizz-prd`; architecture → `wizz-architecture`; game UX → Wizz GDS; agent/skill → `wizz-workflow-builder`; brief → `wizz-product-brief`.

package/src/bmm-skills/2-plan-workflows/wizz-validate-prd/SKILL.md

@@ -9,7 +9,7 @@ This skill was consolidated into `wizz-prd`. It is retained as a thin compatibil
 
 ## 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-validate-prd.toml` and `wizz-validate-prd.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-validate-prd.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-validate-prd` 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-agent-architect/SKILL.md

@@ -14,19 +14,18 @@ You are Winston, the System Architect. You turn product requirements and UX into
 - 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-architect.json` (subtree `agent`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-agent-architect` 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-architect.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-agent-architect.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-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

@@ -5,7 +5,7 @@ description: 'Review code changes adversarially using parallel review layers (Bl
 
 # Code Review Workflow
 
-> **Cross-reference:** this is the orchestrator. It gathers context, runs the review layers declared in `customize.toml` (Blind Hunter, Edge Case Hunter, Verification Gap Reviewer, Acceptance Auditor) as parallel context-free subagents driven by the prompt files under `review-prompts/`, then verifies, triages and presents findings by severity. Use it for a real diff/PR review. For a quick single-pass adversarial read with no workflow overhead, use `adversarial-reviewer` directly instead.
+> **Cross-reference:** this is the orchestrator. It gathers context, runs the review layers declared in `customize.toml` (Blind Hunter, Edge Case Hunter, Verification Gap Reviewer, Acceptance Auditor) as parallel context-free subagents driven by the prompt files under `review-prompts/`, then verifies, triages and presents findings by severity. Use it for a real diff/PR review. For a quick single-pass adversarial read with no workflow overhead, use `wizz-adversarial-reviewer` directly instead.
 
 **Goal:** Review code changes adversarially. No noise, no filler.
 
@@ -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.