wizz-method 2.0.0 → 2.1.1

package/src/bmm-skills/4-implementation/wizz-quick-dev/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-quick-dev/step-05-present.md

@@ -73,6 +73,6 @@ Workflow complete.
 
 ## 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-quick-dev.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-quick-dev/step-oneshot.md

@@ -77,6 +77,6 @@ Workflow complete.
 
 ## 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-quick-dev.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-retrospective/SKILL.md

@@ -13,7 +13,6 @@ Every finding you report carries a source reference (file, line, commit, or log)
 
 - Bare paths and `{skill-root}` (e.g. `references/aggregate-views.md`, `scripts/sprint_status.py`) resolve from this skill's installed directory.
 - `{project-root}` → the project working directory.
-- `{skill-name}` → the skill directory's basename.
 - **Scripts:** `git_evidence.py` is stdlib-only and runs under `python3`, the Wizz default. `sprint_status.py` needs `ruamel.yaml` to round-trip the YAML without destroying its comments, so it runs under `uv run --no-cache`, which provisions the dependency from the script's own header. Do not rewrite it to `python3`: without `ruamel.yaml` installed globally it fails with `ModuleNotFoundError`.
 
 ## Modes
@@ -26,7 +25,7 @@ For automation, `-H <epic>` — an explicit epic in headless mode — is the sta
 
 Run these in order before the retrospective begins:
 
-1. **Resolve the workflow block.** Run `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`. If it fails, resolve `{workflow.*}` yourself by reading `{skill-root}/customize.toml`, then `{project-root}/_wizz/custom/{skill-name}.toml`, then `.user.toml` in that order, merging base → team → user (scalars override, keyed arrays-of-tables merge by `code`/`id`, other arrays append).
+1. **Resolve the workflow block.** Read `{project-root}/_wizz/_resolved/wizz-retrospective.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-retrospective` from the project root and read the snapshot again. If it fails, resolve `{workflow.*}` yourself by reading `{skill-root}/customize.toml`, then `{project-root}/_wizz/custom/wizz-retrospective.toml`, then `.user.toml` in that order, merging base → team → user (scalars override, keyed arrays-of-tables merge by `code`/`id`, other arrays append).
 2. **Run prepend steps** — execute each entry in `{workflow.activation_steps_prepend}` in order.
 3. **Load persistent facts** — treat every `{workflow.persistent_facts}` entry as standing context. `file:` entries are paths/globs under `{project-root}` whose contents load as facts; all others are literal facts.
 4. **Load config** from `{project-root}/_wizz/bmm/config.yaml`: `project_name`, `user_name`, `communication_language`, `document_output_language`, `user_skill_level`, `planning_artifacts`, `implementation_artifacts`, and `date` (system datetime), plus `output_folder` from `{project-root}/_wizz/core/config.yaml`. Speak all output in `{communication_language}`; write all documents in `{document_output_language}`. Never state time estimates — AI has changed development speed, so hour/day/week predictions are noise.

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

@@ -9,7 +9,7 @@ You are a senior developer about to commit to this plan. Two moves, in order: fi
 
 ## 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-sprint-planning.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-sprint-planning` 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. Load `{project-root}/_wizz/bmm/config.yaml` (and `config.user.yaml` if present). Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{project_name}`, `{planning_artifacts}`, `{implementation_artifacts}`, `{project_knowledge}` (skip gracefully if unset), `{date}`. Stay in `{communication_language}` for every turn, not just the greeting.

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

@@ -14,19 +14,18 @@ description: 'Summarize sprint status and surface risks. Use when the user says
 - 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-sprint-status.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-sprint-status` 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-sprint-status.toml` — team overrides
+3. `{project-root}/_wizz/custom/wizz-sprint-status.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.
 
@@ -232,7 +231,7 @@ If the command targets a story, set `story_key={{next_story_id}}` when prompted.
   </check>
 
   <check if="choice == 4">
-    <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-sprint-status.json` (subtree `workflow.on_complete`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-sprint-status` 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>
     <action>Exit workflow</action>
   </check>
 </step>
@@ -305,7 +304,7 @@ If the command targets a story, set `story_key={{next_story_id}}` when prompted.
 
 <template-output>is_valid = true</template-output>
 <template-output>message = "sprint-status.yaml valid: metadata complete, all statuses recognized"</template-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-sprint-status.json` (subtree `workflow.on_complete`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-sprint-status` 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/core-skills/_shared/handoff-protocol.md

@@ -30,6 +30,14 @@ o entrypoint da skill e apenas as referências necessárias (progressive disclos
   acima de Opus (Fable); em sessão Opus quem recebe pula para `review`
   (detalhe completo em `_shared/model-ladder.md`, no módulo wizz).
   Campo opcional: sem ele o handoff funciona normal.
+- max_calls (opcional): teto de chamadas de ferramenta (tool calls) que o
+  executor pode gastar neste brief, como inteiro. Quem recebe despacha o
+  `wizz-exec-<hint>` com esse teto declarado no brief. Ao atingir o teto,
+  o executor PARA, entrega o parcial com pendências explícitas e não
+  escala sozinho: quem delega decide o próximo passo (reemitir com teto
+  maior, escalar 1 degrau, ou absorver o resto). Regra instrucional, igual
+  à anti-loop: nada programático conta as chamadas. Sem `max_calls` o
+  handoff funciona normal.
 - precisa planejar (opcional): veredito sim/não do fator de planejamento
   do sinal de complexidade, avaliado por quem delega. Evita que quem
   recebe re-derive o sinal para aplicar o Gate de Planejamento
@@ -47,6 +55,7 @@ o entrypoint da skill e apenas as referências necessárias (progressive disclos
     decisões já tomadas na cadeia: escopo é só mobile-first.
     seção relevante da skill: page-cro/references/checkout-flow.md
     model_hint: sonnet
+    max_calls: 40
 
 ## Regra anti-loop
 

package/src/core-skills/wizz-advanced-elicitation/SKILL.md

@@ -14,7 +14,7 @@ You are Wizz's shared refinement checkpoint: other skills invoke you at natural
 
 ## 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-advanced-elicitation.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-advanced-elicitation` from the project root and read the snapshot again. On failure, read `{skill-root}/customize.toml` directly and use defaults.
 2. Hold every `{workflow.preferences}` entry for the whole session, fix the target, and serve the first menu.
 
 ## Serving the Catalog
@@ -61,4 +61,4 @@ Use the method's description as its intent and its output_pattern as a flexible
 
 Never change the work unless the user accepts the proposal. If they reject it, drop the proposal entirely. Any other reply is instruction to follow.
 
-When a method casts personas (round tables, panels, debates), reuse party members already in the session if party mode is active; otherwise resolve installed agents on demand via `python3 {project-root}/_wizz/scripts/resolve_config.py --project-root {project-root} --key agents` (a four-layer merge of `_wizz/config.toml`, `config.user.toml`, and the two `_wizz/custom/` overrides; each entry keyed by agent code carries name, title, icon, description). If neither yields a fit, invent named viewpoints suited to the content.
+When a method casts personas (round tables, panels, debates), reuse party members already in the session if party mode is active; otherwise resolve installed agents on demand by reading the `agents` key of `{project-root}/_wizz/_resolved/_config.json` (the same four-layer merge, resolved at install time, of `_wizz/config.toml`, `config.user.toml`, and the two `_wizz/custom/` overrides; each entry keyed by agent code carries name, title, icon, description). If neither yields a fit, invent named viewpoints suited to the content.

package/src/core-skills/wizz-brainstorming/SKILL.md

@@ -18,7 +18,7 @@ The session runs in one of three stances, chosen by the user — set explicitly
 
 ## On Activation
 
-1. Resolve customization: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, use a subagent to read `{skill-root}/customize.toml` directly with defaults.
+1. Resolve customization: Read `{project-root}/_wizz/_resolved/wizz-brainstorming.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-brainstorming` from the project root and read the snapshot again. On failure, use a subagent to read `{skill-root}/customize.toml` directly with defaults.
 2. Run each `{workflow.activation_steps_prepend}` entry. Treat each `{workflow.persistent_facts}` entry as foundational context (`file:`-prefixed entries are paths/globs under `{project-root}` — load their contents; others are facts verbatim).
 3. Load `{project-root}/_wizz/core/config.yaml` (and `config.user.yaml` if present); resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{output_folder}`, `{project_name}`, `{date}`. Missing → neutral defaults; never block.
 4. **If launched headless** (a machine signal, not a human asking for output — `references/headless.md` lists them): load `references/headless.md` and follow it for the whole run. It is the *only* context where you generate ideas yourself; never load it otherwise.
@@ -34,13 +34,13 @@ These fight your defaults, in every mode; hold them deliberately. The stance you
 - **Keep shifting the creative domain** — every 5–10 turns (or ~10 ideas when you're generating), usually by moving to the next technique.
 - **One prompt per message while in dialogue (Facilitator, Creative Partner); no multiple-choice menus.** Don't stack questions into a wall or hand a menu that invites lazy picking — both pull the user out of generating. The only exceptions are the two up-front *process* choices (stance, and the technique flow): *how* to run is theirs to pick; *what* to ideate never is.
 
-**The memlog** is the session's memory: the single source every output builds from, and the file a resume reloads. Whatever isn't in it is gone. Log every idea, decision, question, and bit of user direction — anything you'd regret losing if the window closed — one line each, the gist in the user's meaning, in time order; never edit or reorder. Skip your prompts and small talk. All writes go through the shared `{project-root}/_wizz/scripts/memlog.py` (atomic; don't read it back mid-session — resume is the one exception):
+**The memlog** is the session's memory: the single source every output builds from, and the file a resume reloads. Whatever isn't in it is gone. Log every idea, decision, question, and bit of user direction — anything you'd regret losing if the window closed — one line each, the gist in the user's meaning, in time order; never edit or reorder. Skip your prompts and small talk. All writes go through the shared `{project-root}/_wizz/scripts/memlog.js` (atomic; don't read it back mid-session — resume is the one exception):
 
-- `memlog.py init --workspace {doc_workspace} --field topic="<topic>" --field goal="<goal>" --field mode="<facilitator|partner|autonomous>"` — create it once topic, goal, and stance are known.
-- `memlog.py append --workspace {doc_workspace} --type <kind> --text "<one-line gist>"` — log one entry. `--type` ∈ `idea`/`insight`/`question`/`decision`/`direction`/`technique` (a switch: `--text "started <name>"`); omit for a plain note. Add `--by user`/`--by coach` to mark authorship — **required in Creative Partner mode** (renders `(idea by user)`); skip it otherwise.
-- `memlog.py set --workspace {doc_workspace} --key status --value complete` — flip status at wrap-up.
+- `memlog.js init --workspace {doc_workspace} --field topic="<topic>" --field goal="<goal>" --field mode="<facilitator|partner|autonomous>"` — create it once topic, goal, and stance are known.
+- `memlog.js append --workspace {doc_workspace} --type <kind> --text "<one-line gist>"` — log one entry. `--type` ∈ `idea`/`insight`/`question`/`decision`/`direction`/`technique` (a switch: `--text "started <name>"`); omit for a plain note. Add `--by user`/`--by coach` to mark authorship — **required in Creative Partner mode** (renders `(idea by user)`); skip it otherwise.
+- `memlog.js set --workspace {doc_workspace} --key status --value complete` — flip status at wrap-up.
 
-(Each is `python3 {project-root}/_wizz/scripts/memlog.py …`.)
+(Each is `node {project-root}/_wizz/scripts/memlog.js …`.)
 
 ## Run a Session
 

package/src/core-skills/wizz-brainstorming/references/converge.md

@@ -17,7 +17,7 @@ Pick by what the decision needs:
 - **PMI (Plus / Minus / Interesting)** — when one strong candidate needs pressure-testing before commitment: list its pluses, minuses, and the merely-interesting, then judge.
 - **MoSCoW** — when scoping a build: sort into Must / Should / Could / Won't-this-time.
 
-Log the surviving directions and the reasoning with `python3 {project-root}/_wizz/scripts/memlog.py append --type decision --text "<one-line gist>"` (use `--by` in Creative Partner mode). Two or three convergence moves chained is fine (e.g. cluster → score the clusters); more than that is usually over-processing.
+Log the surviving directions and the reasoning with `node {project-root}/_wizz/scripts/memlog.js append --type decision --text "<one-line gist>"` (use `--by` in Creative Partner mode). Two or three convergence moves chained is fine (e.g. cluster → score the clusters); more than that is usually over-processing.
 
 ## Then finalize
 

package/src/core-skills/wizz-brainstorming/references/finalize.md

@@ -9,7 +9,7 @@ In Facilitator mode this is the one place your own creative contribution is welc
 1. **Hand them the mirror first.** Reflect a vivid sampling of *their* ideas back — deliberately include the odd, random, or buried ones from earlier, not just the recent obvious ones (in Creative Partner mode the `(... by user)` tags tell you which were theirs). Ask what they see now: conclusions, synergies, themes, the few that actually matter. Let them connect first; their own pattern-recognition is the point.
 2. **Then add the connections they would miss.** Lean in creatively — not new raw ideas, but the non-obvious links: this idea from technique one quietly solves that tension from technique four; these three are one idea wearing three hats; this wildcard is the real breakthrough.
 
-Record the insights and chosen directions with `memlog.py append --type insight`. **Then run `python3 {project-root}/_wizz/scripts/memlog.py set --workspace {doc_workspace} --key status --value complete`** — the session is done and must stop being offered for resume. Do this even if the user declines every artifact below.
+Record the insights and chosen directions with `memlog.js append --type insight`. **Then run `node {project-root}/_wizz/scripts/memlog.js set --workspace {doc_workspace} --key status --value complete`** — the session is done and must stop being offered for resume. Do this even if the user declines every artifact below.
 
 ## Artifacts
 

package/src/core-skills/wizz-brainstorming/references/headless.md

@@ -29,9 +29,9 @@ Free-form structured payload in the first message; provide what applies:
 
 ## Run
 
-1. Bind `{doc_workspace}` and create the memlog with `python3 {project-root}/_wizz/scripts/memlog.py init --workspace {doc_workspace} --field topic="<topic>" [--field goal="<goal>"]`. It remains the canonical source every artifact derives from.
-2. Run the divergent session per **The inversion**, capturing each idea with `memlog.py append --workspace {doc_workspace} --type idea --text "<idea>"` as it lands, and marking each technique switch with `memlog.py append --type technique --text "started <name>"`.
-3. Synthesize: surface the conclusions, connections, and the few directions that matter; record them with `memlog.py append --type insight`, then run `memlog.py set --workspace {doc_workspace} --key status --value complete`.
+1. Bind `{doc_workspace}` and create the memlog with `node {project-root}/_wizz/scripts/memlog.js init --workspace {doc_workspace} --field topic="<topic>" [--field goal="<goal>"]`. It remains the canonical source every artifact derives from.
+2. Run the divergent session per **The inversion**, capturing each idea with `memlog.js append --workspace {doc_workspace} --type idea --text "<idea>"` as it lands, and marking each technique switch with `memlog.js append --type technique --text "started <name>"`.
+3. Synthesize: surface the conclusions, connections, and the few directions that matter; record them with `memlog.js append --type insight`, then run `memlog.js set --workspace {doc_workspace} --key status --value complete`.
 4. Produce the requested artifacts from the log — `brainstorm.html` (the imaginative, self-contained, no-template report) and/or the succinct `brainstorm-intent.md` — the same artifacts `references/finalize.md` describes, delegating each to a subagent that reads the log as its sole source. (Headless produces the `artifacts` payload directly; it does not ask, unlike the interactive opt-in.)
 5. Execute each entry in `{workflow.external_handoffs}` (capture returned URLs/IDs into the JSON `external_handoffs` array; skip and flag unavailable tools — local files always exist). Then run `{workflow.on_complete}` if non-empty.
 

package/src/core-skills/wizz-brainstorming/references/mode-autonomous.md

@@ -5,6 +5,6 @@ The user handed you the topic and wants to see what you come up with on your own
 - **Run a real divergent session yourself.** Pick and run techniques on your own (use `brain.py` as in `## Choosing Techniques`, but *you* choose — no menu for the user), capturing each idea to the memlog with `--type idea --by coach`, marking each technique switch with a `technique` entry, shifting the creative domain every ~10 ideas, aiming past 100. Push past the obvious.
 - **Don't pepper the user with questions** — this is your run. One quick confirm of topic and goal up front is plenty.
 - **When it's mined out, synthesize and produce the keepsake.** Go to `## Wrap-Up` (`references/finalize.md`): record the insights, mark the memlog complete, and **auto-generate the imaginative HTML keepsake — don't ask first; the keepsake is the result you promised to show them.** Offer the other artifacts (intent doc, etc.) after.
-- **Then, because a human is here, offer to keep going together.** They may want to push an idea further or react to what you found — if so, switch into **Facilitator** or **Creative Partner** (load that frame), **record the switch in the memlog** so a resume restores the new stance — `python3 {project-root}/_wizz/scripts/memlog.py set --workspace {doc_workspace} --key mode --value <facilitator|partner>` — and continue from the same memlog.
+- **Then, because a human is here, offer to keep going together.** They may want to push an idea further or react to what you found — if so, switch into **Facilitator** or **Creative Partner** (load that frame), **record the switch in the memlog** so a resume restores the new stance — `node {project-root}/_wizz/scripts/memlog.js set --workspace {doc_workspace} --key mode --value <facilitator|partner>` — and continue from the same memlog.
 
 This is the interactive sibling of headless mode (`references/headless.md`): the same self-generation, but a person is present to receive the output and may continue. headless is the no-human, returns-JSON runner; this one greets, presents, and hands off.

package/src/core-skills/wizz-customize/SKILL.md

@@ -14,7 +14,7 @@ When the target's `customize.toml` doesn't expose what the user wants, say so pl
 ## Preflight
 
 - No `{project-root}/_wizz/` → Wizz isn't installed. Say so, stop.
-- `{project-root}/_wizz/scripts/resolve_customization.py` missing → continue, but Step 6 verify falls back to manual merge.
+- `npx wizz-method resolve` unavailable → continue, but Step 6 verify falls back to manual merge.
 - Both present → proceed.
 
 ## Activation
@@ -70,13 +70,13 @@ Merge semantics:
 
 Overrides are sparse: only the fields being changed. Never copy the whole `customize.toml`.
 
-**Template swap** (`*_template` scalar): offer to copy the default template to `{project-root}/_wizz/custom/{skill-name}-{purpose}-template.md`, point the override at the new path, offer to help edit it.
+**Template swap** (`*_template` scalar): offer to copy the default template to `{project-root}/_wizz/custom/<skill-name>-{purpose}-template.md`, point the override at the new path, offer to help edit it.
 
 ## Step 5: Team or user placement
 
 Under `{project-root}/_wizz/custom/`:
-- `{skill-name}.toml` — team, committed. Policies, org conventions, compliance.
-- `{skill-name}.user.toml` — user, gitignored. Personal tone, private facts, shortcuts.
+- `<skill-name>.toml` — team, committed. Policies, org conventions, compliance.
+- `<skill-name>.user.toml` — user, gitignored. Personal tone, private facts, shortcuts.
 
 Default by character (policy → team, personal → user), confirm before writing.
 
@@ -85,16 +85,19 @@ Default by character (policy → team, personal → user), confirm before writin
 1. Show the full TOML. If the file exists, show a diff. Never silently overwrite.
 2. Wait for explicit yes.
 3. Write. Create `{project-root}/_wizz/custom/` if needed.
-4. Verify:
+4. **Regenerate the resolved snapshot** — mandatory after every write: run `npx wizz-method resolve --skill <skill-name>` from `{project-root}` (Node, no Python; it rewrites the snapshot atomically and refreshes `_resolved/.index.json`, so `wizz doctor` never reports it as stale). This is what keeps `_resolved/<skill-name>.json` in sync with the file you just wrote.
+5. Verify — read the snapshot regenerated in the step above:
    ```
-   python3 {project-root}/_wizz/scripts/resolve_customization.py --skill <install-path> --key <agent-or-workflow>
+   {project-root}/_wizz/_resolved/<skill-name>.json
    ```
-   Show the merged output, point out the changed fields.
+   (subtree `<agent-or-workflow>`). Show the merged output, point out the changed fields.
 
-   **Resolver missing or fails:** read whichever layers exist — `<install-path>/customize.toml` (base), `{project-root}/_wizz/custom/{skill-name}.toml` (team), `{project-root}/_wizz/custom/{skill-name}.user.toml` (user) — apply base → team → user with the same merge rules (scalars override, tables deep-merge, `code`/`id`-keyed arrays merge by key, all other arrays append), describe how the changed fields resolve.
+   **Snapshot staleness:** snapshots are regenerated at `wizz update`, `wizz resolve`, and by the regenerate-snapshot step above; `wizz doctor` reports any snapshot that has gone stale. Editing a custom TOML by hand outside this skill, without running `wizz resolve` afterward, leaves the old `_resolved/<skill-name>.json` in force until the next regeneration.
 
-   **Verify shows override didn't land** (field unchanged, merge conflict, file not picked up): re-enter Step 4 with the verify output as context. Usually wrong field name, wrong merge mode (scalar vs array), or wrong scope.
-5. Summarize what changed, where the file lives, how to iterate. Remind the user to commit team overrides.
+   **Resolver missing or fails:** read whichever layers exist — `<install-path>/customize.toml` (base), `{project-root}/_wizz/custom/<skill-name>.toml` (team), `{project-root}/_wizz/custom/<skill-name>.user.toml` (user) — apply base → team → user with the same merge rules (scalars override, tables deep-merge, `code`/`id`-keyed arrays merge by key, all other arrays append), describe how the changed fields resolve.
+
+   **Verify shows override didn't land** (field unchanged, merge conflict, file not picked up): re-enter **Step 4: Compose the override** with the verify output as context. Usually wrong field name, wrong merge mode (scalar vs array), or wrong scope.
+6. Summarize what changed, where the file lives, how to iterate. Remind the user to commit team overrides.
 
 ## Complete when
 

package/src/core-skills/wizz-forge-idea/SKILL.md

@@ -17,14 +17,14 @@ Lead by questioning, not lecturing. Ask one question at a time, press on weak po
 
 ## Conventions
 
-- Scripts live in two places — run each from the exact path written, never assume co-location: the shared core scripts (`memlog.py`, `resolve_customization.py`, `resolve_config.py`) are installed by Wizz core at `{project-root}/_wizz/scripts/` and are never bundled here; this skill's own `resolve_personas.py` is at `{skill-root}/scripts/`.
+- Scripts live in two places — run each from the exact path written, never assume co-location: the shared core scripts (`memlog.js`, `resolve_customization.py`, `resolve_config.py`) are installed by Wizz core at `{project-root}/_wizz/scripts/` and are never bundled here; this skill's own `resolve_personas.py` is at `{skill-root}/scripts/`.
 - `{workflow.<name>}` resolves to fields in the merged `customize.toml` `[workflow]` table.
 
 ## 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 with defaults. Apply the resolved `{workflow.*}` values throughout.
+1. Resolve customization: Read `{project-root}/_wizz/_resolved/wizz-forge-idea.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-forge-idea` from the project root and read the snapshot again. On failure, read `{skill-root}/customize.toml` directly with defaults. Apply the resolved `{workflow.*}` values throughout.
 2. Run each `{workflow.activation_steps_prepend}` entry; treat each `{workflow.persistent_facts}` entry as foundational context (`file:` entries load their contents, `skill:` names a skill to consult, others are facts verbatim).
-3. Resolve central config: `python3 {project-root}/_wizz/scripts/resolve_config.py --project-root {project-root} --key core`; from the merged JSON read `{user_name}`, `{communication_language}`, `{output_folder}`. On failure use neutral defaults; never block. Greet `{user_name}` in `{communication_language}` and stay in it.
+3. Resolve central config: read `{project-root}/_wizz/_resolved/_config.json` (subtree `core`) for `{user_name}`, `{communication_language}`, `{output_folder}`. If the file is missing, run `npx wizz-method resolve` and read it again. On failure use neutral defaults; never block. Greet `{user_name}` in `{communication_language}` and stay in it.
 4. Note whether a Wizz persona is already active in this conversation — the user loaded one (e.g. the analyst, the storyteller) and invoked the forge from within it. If so, that persona leads the session, in voice, throughout.
 5. Resume: glob `{workflow.forge_output_path}/**/.memlog.md` (recursive, so it still finds sessions when `run_folder_pattern` is overridden to nest paths) and read only each match's frontmatter to find any whose `status` is not `complete`. Offer to resume one — then read its full memlog once to rebuild state and continue append-only — or to start fresh.
 6. Run each `{workflow.activation_steps_append}` entry.
@@ -53,7 +53,7 @@ Tell the user they can say **"attack this"**, **"defend this"**, or **"switch ro
 ### Set up the session
 
 Derive a kebab-case `{slug}` for the idea and bind the session workspace `{workspace} = {workflow.forge_output_path}/{workflow.run_folder_pattern}` (the pattern fills with `{slug}`). Create the memlog once the goal is known:
-`python3 {project-root}/_wizz/scripts/memlog.py init --workspace {workspace} --field idea="<idea>" --field goal="<goal>"`
+`node {project-root}/_wizz/scripts/memlog.js init --workspace {workspace} --field idea="<idea>" --field goal="<goal>"`
 
 Tell the user the path; state is on disk now, so the session survives interruption. If init fails, don't abort — run the forge in-conversation and tell the user state won't persist this session.
 
@@ -74,7 +74,7 @@ When a branch resolves, pause before moving on. Give the user a chance to raise
 Do not use agreement or praise to make the interaction smoother; they lower pressure and lead to shallower thinking. Agreement is allowed only when it helps the user think better. Praise is noise. Continued engagement and ego-stroking are not objectives. In attack mode, never agree with the idea until the user ends the mode. For each answer, either challenge the weak point or build on the strong point, whichever helps the user think better.
 
 Capture as you go — each decision, assumption, crack, kill, and locked idea, one bullet in the user's meaning:
-`python3 {project-root}/_wizz/scripts/memlog.py append --workspace {workspace} --type <decision|assumption|crack|kill|direction|lock|note> --text "<gist>"`
+`node {project-root}/_wizz/scripts/memlog.js append --workspace {workspace} --type <decision|assumption|crack|kill|direction|lock|note> --text "<gist>"`
 A `lock` is an idea the user hardens — settled, not to be reopened; locks are what `forged-idea.md` is distilled from. Don't read the memlog back except on resume. If the user raises a different branch, capture it and stay put — the loop and the stray insight both survive.
 
 ## The personas
@@ -103,5 +103,5 @@ The session can end in three valid states:
 
 Always render `{workspace}/forge-report.html` as a self-contained HTML file the user can open, with inline CSS and an inline-SVG seal or stamp. Summarize the outcome, the locked decisions, what was rejected and why, and the weak points that survived scrutiny, in the user's meaning. Credit the personas and parties that pressure-tested the idea by name, icon, and voice. Render a prominent wax-seal-style or stamped outcome mark, matched to the result: `HARDENED`, an `Idea Death Certificate` stamped `KILLED` with the cause of death, or `CLARIFIED`. Tell the user the path.
 
-Flip the status at the end: `python3 {project-root}/_wizz/scripts/memlog.py set --workspace {workspace} --key status --value complete`.
+Flip the status at the end: `node {project-root}/_wizz/scripts/memlog.js set --workspace {workspace} --key status --value complete`.
 If `{workflow.on_complete}` is non-empty, run all instructions in order.

package/src/core-skills/wizz-forge-idea/scripts/resolve_personas.py

@@ -108,7 +108,23 @@ def find_party_skill(project_root: Path, skill_root: Path):
 
 
 def load_party_workflow(project_root: Path, party_skill: Path):
-    """Merged [workflow] table for wizz-party-mode (base + user overrides)."""
+    """Merged [workflow] table for wizz-party-mode (base + user overrides).
+
+    Prefers the pre-resolved snapshot at `_wizz/_resolved/<skill-name>.json`
+    (written by `wizz update` / `wizz resolve` / wizz-customize) — one Read,
+    no spawn. Falls back to shelling out to resolve_customization.py, and
+    from there to the skill's base customize.toml, when the snapshot is
+    missing.
+    """
+    resolved_path = project_root / "_wizz" / "_resolved" / f"{party_skill.name}.json"
+    if resolved_path.exists():
+        try:
+            with resolved_path.open("r", encoding="utf-8") as f:
+                snapshot = json.load(f)
+            if isinstance(snapshot, dict) and isinstance(snapshot.get("workflow"), dict):
+                return snapshot["workflow"]
+        except (OSError, json.JSONDecodeError):
+            pass
     resolver = project_root / "_wizz" / "scripts" / "resolve_customization.py"
     data = _run_json([sys.executable, str(resolver), "--skill", str(party_skill), "--key", "workflow"])
     if data is not None and isinstance(data.get("workflow"), dict):

package/src/core-skills/wizz-party-mode/SKILL.md

@@ -10,14 +10,14 @@ Run a round-table where these agents talk to each other and to the user like rea
 ## Conventions
 
 - **Paths:** bare paths (e.g. `references/create-party.md`) resolve from `{skill-root}` (where `customize.toml` lives); `{project-root}`-prefixed paths from the project working dir. `{workflow.<name>}` resolves to `customize.toml`'s `[workflow]` table (overrides win).
-- **Scripts** (run via `python3`): `{project-root}/_wizz/scripts/resolve_config.py` resolves central config (four-layer TOML merge); `{project-root}/_wizz/scripts/resolve_customization.py` resolves `{workflow.*}`; `{skill-root}/scripts/resolve_party.py` resolves the roster, `party_mode`, `memory_enabled`, and scene/`open_cast`; `{project-root}/_wizz/scripts/memlog.py` reads/writes per-party memory.
+- **Scripts and snapshots**: `{project-root}/_wizz/_resolved/_config.json` carries the central config already merged across its four layers (no script); `{project-root}/_wizz/_resolved/wizz-party-mode.json` carries `{workflow.*}`; `{skill-root}/scripts/resolve_party.py` (run via `python3`) resolves the roster, `party_mode`, `memory_enabled`, and scene/`open_cast`; `node {project-root}/_wizz/scripts/memlog.js` reads/writes per-party memory.
 - **File roles:** a party's memory is the per-party memlog at `{workflow.memory_dir}/<party>/.memlog.md`; custom members and groups live in the user's `customize.toml` overrides. Mechanics in `references/party-memory.md` (memory) and `references/create-party.md` (authoring).
 - **Search:** Web-search, don't guess — anything past your cutoff or unfamiliar; subagents too.
 
 ## 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. Then run each `{workflow.activation_steps_prepend}` entry, and hold each `{workflow.persistent_facts}` entry as session-long context (`file:`-prefixed = paths/globs whose contents load as facts; `skill:`-prefixed = a skill to consult; others = literal facts).
-2. **Resolve core config:** `python3 {project-root}/_wizz/scripts/resolve_config.py --project-root {project-root}`. From the merged JSON's `core` table: greet with `{user_name}`, speak in `{communication_language}`, and resolve `{output_folder}`; `{date}` is today's date.
+1. **Resolve customization:** Read `{project-root}/_wizz/_resolved/wizz-party-mode.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-party-mode` from the project root and read the snapshot again. On failure, read `{skill-root}/customize.toml` directly and use defaults. Then run each `{workflow.activation_steps_prepend}` entry, and hold each `{workflow.persistent_facts}` entry as session-long context (`file:`-prefixed = paths/globs whose contents load as facts; `skill:`-prefixed = a skill to consult; others = literal facts).
+2. **Resolve core config:** read `{project-root}/_wizz/_resolved/_config.json` (if it is missing, run `npx wizz-method resolve` from the project root and read it again; if that also fails, use neutral defaults and never block). From its `core` table: greet with `{user_name}`, speak in `{communication_language}`, and resolve `{output_folder}`; `{date}` is today's date.
 3. **Detect intent and route.** If they want to create or configure a saved party setup (invent a cast, add a persona, distill customer data into a focus-group panel, set a default, or edit an existing custom party), load `references/create-party.md` and follow it. Otherwise run a party — continue below.
 4. **Resolve the roster:** `python3 {skill-root}/scripts/resolve_party.py --project-root {project-root} --skill {skill-root}`. It returns the active roster (`{workflow.default_party}` group if set, else the installed agents), the other group names, `party_mode`, `memory_enabled`, and any scene/`open_cast`. Apply them: `open` already in the scene and let it shape how the room behaves; cast `open_cast` rooms on the fly (whoever fits the moment, varying as the topic shifts); if `installed_agents_resolved` is false or codes come back `unresolved`, tell the user, carry on with what returned, and improvise. Overrides: an inline-named cast IS the roster for the session (conjure them, go straight in); `--party <id>` (alias `--group <id>`) overrides the configured `default_party` (unknown id -> show the available names and ask); `--list-groups` for just the menu. Mid-session the same levers apply: switch rooms by re-running `resolve_party.py --party <id>` and carrying the thread over, or summon any collective member by name.
 5. **Memory.** If `memory_enabled` (from `resolve_party.py`), follow `references/party-memory.md` for the whole run.

package/src/core-skills/wizz-party-mode/references/create-party.md

@@ -30,7 +30,7 @@ Ask which they're after if it isn't obvious, then proceed.
 
 ## Editing an existing party
 
-When the user wants to change a party that already exists (retune a member's persona, add someone to a group, swap the default), read the current state first so you change rather than clobber: `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key workflow` returns the merged `party_members`, `party_groups`, and `default_party`. Show the member or group being touched, capture only the delta with the user, and hand that sparse change to `wizz-customize` — it replaces a `party_members`/`party_groups` entry whose `code`/`id` matches and appends the rest, so an edit is just the changed entry, never a full rewrite.
+When the user wants to change a party that already exists (retune a member's persona, add someone to a group, swap the default), read the current state first so you change rather than clobber: `{project-root}/_wizz/_resolved/wizz-party-mode.json` (subtree `workflow`) holds the merged `party_members`, `party_groups`, and `default_party`; if the file is missing, run `npx wizz-method resolve --skill wizz-party-mode` from the project root and read it again. Show the member or group being touched, capture only the delta with the user, and hand that sparse change to `wizz-customize` — it replaces a `party_members`/`party_groups` entry whose `code`/`id` matches and appends the rest, so an edit is just the changed entry, never a full rewrite.
 
 ## Keeping new faces from a session
 

package/src/core-skills/wizz-party-mode/references/party-memory.md

@@ -34,7 +34,7 @@ When a character shows up who isn't in the party's roster — cast from an open-
 ## Write it
 
 ```
-python3 {project-root}/_wizz/scripts/memlog.py append \
+node {project-root}/_wizz/scripts/memlog.js append \
   --workspace {workflow.memory_dir}/{active} \
   --type <dynamic|moment|callback|outcome> \
   --text "<one succinct line, in the room's own read of it>"
@@ -42,7 +42,7 @@ python3 {project-root}/_wizz/scripts/memlog.py append \
 
 Add `--by <persona-code>` when a memory belongs to one character. Choose `init` vs `append` from the existence fact you already hold: the entry-read (and, on a mid-session room switch, that room's read) told you whether the memlog exists — `init --workspace {workflow.memory_dir}/{active}` once before the first append when it doesn't, plain `append` when it does. (`init` errors if the file already exists, so don't call it blind.)
 
-If `memlog.py` is unavailable or a write errors, skip it silently and never stall the party on a failed write.
+If `memlog.js` is unavailable or a write errors, skip it silently and never stall the party on a failed write.
 
 ## Forget
 

package/src/core-skills/wizz-party-mode/scripts/resolve_party.py

@@ -69,7 +69,23 @@ def load_agents(project_root: Path):
 
 
 def load_workflow(project_root: Path, skill_root: Path):
-    """Merged [workflow] table. Falls back to the skill's base customize.toml."""
+    """Merged [workflow] table.
+
+    Prefers the pre-resolved snapshot at `_wizz/_resolved/<skill-name>.json`
+    (written by `wizz update` / `wizz resolve` / wizz-customize) — one Read,
+    no spawn. Falls back to shelling out to resolve_customization.py, and
+    from there to the skill's base customize.toml, when the snapshot is
+    missing.
+    """
+    resolved_path = project_root / "_wizz" / "_resolved" / f"{skill_root.name}.json"
+    if resolved_path.exists():
+        try:
+            with resolved_path.open("r", encoding="utf-8") as f:
+                snapshot = json.load(f)
+            if isinstance(snapshot, dict) and "workflow" in snapshot:
+                return snapshot["workflow"]
+        except (OSError, json.JSONDecodeError):
+            pass
     script = project_root / "_wizz" / "scripts" / "resolve_customization.py"
     data = _run_json([sys.executable, str(script), "--skill", str(skill_root), "--key", "workflow"])
     if data is not None and "workflow" in data:

package/src/core-skills/wizz-review-adversarial-general/SKILL.md

@@ -7,7 +7,7 @@ description: 'Perform a Cynical Review and produce a findings report. Use when t
 
 > **Cross-reference:** this is the "Blind Hunter" review lens (diff only, no project context, no triage). It is not meant to be invoked standalone by a user. For an ad hoc adversarial pass outside a bmm workflow, use the `wizz-adversarial-reviewer` skill directly; for the full triaged multi-layer review of a real diff, run `wizz-code-review`.
 >
-> **No workflow currently invokes this skill.** `wizz-code-review` and `wizz-quick-dev` both carry the Blind Hunter prompt inline in their `customize.toml` review layers, so this file is a third copy of the same lens rather than its single source. Reconnecting the layers to it, or retiring it, is an open decision — see the note in `wizz-quick-dev/customize.toml`.
+> **Fonte única do prompt (2026-09-11, item 22 da auditoria):** o texto operacional do Blind Hunter mora em `src/bmm-skills/4-implementation/wizz-code-review/review-prompts/blind-hunter.md` (cópia idêntica em `wizz-quick-dev/review-prompts/`, paridade travada por `test/test-blind-hunter-parity.js`). Este SKILL.md guarda a persona e o mindset cínico que o revisor assume; os workflows não invocam esta skill — leem o review-prompts direto.
 
 **Goal:** Cynically review content and produce findings.
 

package/src/core-skills/wizz-spec/SKILL.md

@@ -18,7 +18,7 @@ Multiple skills may call to update the same spec over time.
 
 ## 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.
+1. Resolve customization: Read `{project-root}/_wizz/_resolved/wizz-spec.json` (subtree `workflow`). If the file is missing, empty or not valid JSON, run `npx wizz-method resolve --skill wizz-spec` from the project root and read the snapshot again. On failure, read `{skill-root}/customize.toml` directly.
 2. Run `{workflow.activation_steps_prepend}`. Treat `{workflow.persistent_facts}` as foundational context (`file:` entries are loaded).
 3. Load `{project-root}/_wizz/core/config.yaml` (and `config.user.yaml` if present), root level and `bmm` section. Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`.
 4. Detect mode. **Headless** when any of: no TTY, programmatic caller (another skill or non-interactive runner), or the first message pre-supplies all inputs and asks for an artifact path back. **Interactive** otherwise. In interactive mode, greet by `{user_name}` in `{communication_language}`, stay in that language, and mention that `wizz-party-mode` and `wizz-advanced-elicitation` are available for deeper exploration on any field.
@@ -55,15 +55,15 @@ Inside the spec folder:
 
 Deriving the contract from a living log instead of editing the contract in place is what lets the steps around the spec (PRD, UX, architecture, epics) run in any order and feed the same spec without merge drift: the log only accumulates, the artifact is re-rendered. So the spec is updated *only* by re-deriving it here — wizz-spec is its single writer; a hand-edit to `SPEC.md` from outside is unsupported and is overwritten on the next derive.
 
-Writes go through the shared script — `{project-root}/_wizz/scripts/memlog.py`, the same location as `resolve_customization.py` (atomic; never read it back except to resume):
+Writes go through the shared script — `{project-root}/_wizz/scripts/memlog.js` (atomic; never read it back except to resume):
 
-- `python3 {project-root}/_wizz/scripts/memlog.py init --workspace {spec-folder} --field topic="<what is being specced>"` — once, at create.
-- `python3 {project-root}/_wizz/scripts/memlog.py append --workspace {spec-folder} --type <decision|constraint|capability|assumption|question|direction|note|event> --text "<one-line gist, reason included>"` — as each lands.
+- `node {project-root}/_wizz/scripts/memlog.js init --workspace {spec-folder} --field topic="<what is being specced>"` — once, at create.
+- `node {project-root}/_wizz/scripts/memlog.js append --workspace {spec-folder} --type <decision|constraint|capability|assumption|question|direction|note|event> --text "<one-line gist, reason included>"` — as each lands.
 - Terminal moments (a validation verdict, "spec finalized") are `--type event` entries; the memlog carries no status field.
 
 ## The Operation
 
-Read the input and its ancillary linked materials. If there is no input, follow the no-input branch in **Workspace** (ask or block). If a prior `.memlog.md` exists at the target folder, read it — the operation becomes an update, and the memlog (not the rendered `SPEC.md`) is the authority on what was decided and on capability IDs. Preserve those IDs; new capabilities get the next unused `CAP-N`; never reuse retired IDs. Otherwise this is a create, and the first move is `memlog.py init`.
+Read the input and its ancillary linked materials. If there is no input, follow the no-input branch in **Workspace** (ask or block). If a prior `.memlog.md` exists at the target folder, read it — the operation becomes an update, and the memlog (not the rendered `SPEC.md`) is the authority on what was decided and on capability IDs. Preserve those IDs; new capabilities get the next unused `CAP-N`; never reuse retired IDs. Otherwise this is a create, and the first move is `memlog.js init`.
 
 When the input is structured and pre-sorted (a PRD with an addendum, a GDD, a brief produced by an upstream Wizz skill), trust the authored separation: lift kernel-fitting content into SPEC.md, lift overflow into appropriately-named companions. When the input is mixed (a brain dump, a transcript, an RFC, a customer email), do the sorting yourself: walk each claim, apply the three-lens load-bearing test (Spec Law rule 7), and route to the kernel field or a companion.
 

package/src/modules/lowticket/README.md

@@ -8,11 +8,11 @@ Install it and a fresh machine has the methodology and the four agents working,
 
 | Skill | Does | Use when | Do not use when |
 |---|---|---|---|
-| `lowticket-metodologia` | routes a request to the one knowledge shard that answers it, loads the guardrails alongside | any low ticket work: offer, creative, page, campaign, funnel | SaaS, B2B, client site, high ticket |
-| `lowticket-trafego` | campaign diagnosis and ruler: structure, bid cap, when to cut, how to scale | reading, cutting or scaling a Meta campaign | Google Ads, brand campaigns, writing ads |
-| `lowticket-funil` | the post-checkout ladder: upsell, downsell, final offer, price rules | after the front-end converts, to raise average order value | before a front-end that converts exists |
-| `lowticket-minerador` | mining and judging a competitor offer, with a cut-off rubric | hunting a new offer to model | the offer is already defined (use `wizz-offer-forge`) |
-| `lowticket-pagina` | page performance: connect rate, LCP, pixel order, acceptance targets | optimizing or building a low ticket sales page | institutional sites or apps |
+| `wizz-lowticket-metodologia` | routes a request to the one knowledge shard that answers it, loads the guardrails alongside | any low ticket work: offer, creative, page, campaign, funnel | SaaS, B2B, client site, high ticket |
+| `wizz-lowticket-trafego` | campaign diagnosis and ruler: structure, bid cap, when to cut, how to scale | reading, cutting or scaling a Meta campaign | Google Ads, brand campaigns, writing ads |
+| `wizz-lowticket-funil` | the post-checkout ladder: upsell, downsell, final offer, price rules | after the front-end converts, to raise average order value | before a front-end that converts exists |
+| `wizz-lowticket-minerador` | mining and judging a competitor offer, with a cut-off rubric | hunting a new offer to model | the offer is already defined (use `wizz-offer-forge`) |
+| `wizz-lowticket-pagina` | page performance: connect rate, LCP, pixel order, acceptance targets | optimizing or building a low ticket sales page | institutional sites or apps |
 
 All five read the Cérebro on activation and **none of them keeps its own memory**, the same contract as `wizz-offer-forge`. What is decided lives in the Cérebro; what is known lives in the shards.
 
@@ -52,4 +52,4 @@ To let the agent open a specific piece, point at the folder during install, or p
 swipe_file_path = "/absolute/path/to/the/swipe/file"
 ```
 
-Resolution order and the exact wording to use when the folder is absent: `skills/lowticket-metodologia/references/swipe-file.md`.
+Resolution order and the exact wording to use when the folder is absent: `skills/wizz-lowticket-metodologia/references/swipe-file.md`.

package/src/modules/lowticket/module.yaml

@@ -2,10 +2,13 @@ code: lowticket
 name: "Wizz Low Ticket"
 description: "Low ticket direct-response playbook for Meta Ads (BR/PT): funnel diagnosis, bid-cap campaigns, creatives, offers, sales pages, VSL players, upsell ladders, copy diagnosis, tracking setup and offer mining. Knowledge base in Portuguese, loaded one shard at a time."
 default_selected: false
+# Versão do contrato module.yaml <-> installer (auditoria 2026-09-11, item 25).
+# Ver tools/installer/modules/module-interface.js. Ausente = 1.
+interface_version: 1
 
 # --- Origin note (read this before editing the knowledge base) ---
 #
-# The knowledge under skills/lowticket-metodologia/knowledge/ is a distillation
+# The knowledge under skills/wizz-lowticket-metodologia/knowledge/ is a distillation
 # written from scratch: facts, benchmarks, checklists and critical analysis.
 # No third-party lesson text, transcript, PDF or prompt ships in this package.
 # The raw sources stay on the author's machine, outside npm and outside git.

package/src/modules/lowticket/skills/{lowticket-funil → wizz-lowticket-funil}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: lowticket-funil
+name: wizz-lowticket-funil
 description: Designs the post-checkout ladder for a low ticket offer - upsell 1, upsell 2, downsell and a final offer - deciding what each step sells, which pain it answers, what it costs and why it sits in that position, then writes the pages. Use when a front-end offer already converts and the goal is to raise average order value, or when an existing upsell sequence is not converting. Do NOT use before a front-end that converts exists, and do NOT use for traffic, campaigns or the front-end offer itself.
 ---
 
@@ -13,11 +13,11 @@ Every offer in the ladder exists because it answers that question for the step b
 
 ## Prerequisite
 
-**There has to be a front-end that converts.** Extending a funnel above a front that does not sell multiplies zero. If the front is not validated, say so and point to `wizz-offer-forge` (build the offer) or `lowticket-trafego` (find out why it is not selling).
+**There has to be a front-end that converts.** Extending a funnel above a front that does not sell multiplies zero. If the front is not validated, say so and point to `wizz-offer-forge` (build the offer) or `wizz-lowticket-trafego` (find out why it is not selling).
 
 ## Source of truth
 
-Read the Cérebro state first (via the `cerebro` skill). Then, if `lowticket-metodologia` is installed, read `knowledge/INDEX.md` + `knowledge/guardrails.md` and the shard `07-funil-upsell.md`, especially §7.4 (the conversion and ticket cascade) and §7.5-7.9 (pain per step, tone per page, copy rules, the technical block for post-checkout pages and the pre-build checklist). Its sibling shard `07a-copy-humanizacao.md` carries the humanization checklist used before delivering any page. Where a generic skill contradicts that shard, the shard wins and you say so.
+Read the Cérebro state first (via the `cerebro` skill). Then, if `wizz-lowticket-metodologia` is installed, read `knowledge/INDEX.md` + `knowledge/guardrails.md` and the shard `07-funil-upsell.md`, especially §7.4 (the conversion and ticket cascade) and §7.5-7.9 (pain per step, tone per page, copy rules, the technical block for post-checkout pages and the pre-build checklist). Its sibling shard `07a-copy-humanizacao.md` carries the humanization checklist used before delivering any page. Where a generic skill contradicts that shard, the shard wins and you say so.
 
 This skill has **no memory of its own**. What gets decided goes to the Cérebro; the artifact goes to a file.
 
@@ -109,4 +109,4 @@ The full anti-AI word list and the rhythm rules are in `references/copy-das-pagi
 
 ## Out of scope
 
-Traffic, campaigns, hiring, accounting, general operations. Bring it back to product, offer, price, pain, post-checkout sequence and copy, or route: `lowticket-trafego` for campaigns, `wizz-offer-forge` for the front-end offer, `lowticket-pagina` for the sales page itself.
+Traffic, campaigns, hiring, accounting, general operations. Bring it back to product, offer, price, pain, post-checkout sequence and copy, or route: `wizz-lowticket-trafego` for campaigns, `wizz-offer-forge` for the front-end offer, `wizz-lowticket-pagina` for the sales page itself.