wizz-method 2.19.1 → 2.19.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -107,7 +107,7 @@ In short: **the menu chooses the agent, the registry chooses the skill(s) and th
|
|
|
107
107
|
|
|
108
108
|
Inside the 1-area branch, three shortcuts **demote on their own**, before counting any factor: a **question with a single definable answer**, a **single delivery**, and the **diagnosis of one specific mechanism** all go to the area agent. "How do I improve / reduce X" is not that question — it has no single answer. What stays with you is the request of **open scope that the request itself does not delimit** ("how do I improve the signup conversion rate", "the page gets visits and nobody buys"): there the scope has to be discovered first, and that is your work. What decides is not the size of the request, it is whether the request already states what the delivery is. **Two clauses cut across all of this** (canonical source: `_shared/complexity-signal.md`): a **sensitive subsystem** — changing auth/sessions, payments/billing, permissions, or migrating production data — is yours even as a single delivery of one area, because the blast radius of a mistake lands outside the delivery itself; and, the other way round, open scope stops being open when **one catalogue entry covers the whole outcome** and what leaves at the end is that entry's own deliverable ("a plan to reduce churn" is `wizz-churn-prevention`, "what to check before going live" is `wizz-site-launch-kit`) — that one goes to the area, not to you.
|
|
109
109
|
|
|
110
|
-
**Changing the product's code is `dev`, even when the subject is visual** — the delivery is a commit. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it. **Exception: new or rebuilt screens.** When the request asks to BUILD screens in code (a new app, page, dashboard or panel, or a whole screen rebuilt in the product), the visual decision has not been made yet, so `designer` comes first and the sequence is design → dev: the designer runs its research gate (`wizz-design-needs` → `wizz-ui-component-curator` / `wizz-premium-landing-ui-researcher`) before any screen is coded. A generic design skill from outside the registry (e.g. the frontend-design plugin) never stands in for that gate. A tweak to an existing screen (a price, a label, a spacing) stays dev, and
|
|
110
|
+
**Changing the product's code is `dev`, even when the subject is visual** — the delivery is a commit. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it. **Exception: new or rebuilt screens.** When the request asks to BUILD screens in code (a new app, page, dashboard or panel, or a whole screen rebuilt in the product), the visual decision has not been made yet, so `designer` comes first and the sequence is design → dev: the designer runs its research gate (`wizz-design-needs` → `wizz-ui-component-curator` / `wizz-premium-landing-ui-researcher`) before any screen is coded. A generic design skill from outside the registry (e.g. the frontend-design plugin) never stands in for that gate. A tweak to an existing screen (a price, a label, a spacing) stays dev, and so does building one component in code ("create a card component", a button, a modal): the delivery is a file in the repo. Redesigning a section with no build asked for ("redesign the hero") or choosing which component fits ("find a card that matches our style") stays designer.
|
|
111
111
|
|
|
112
112
|
**What `rel` drags counts as an extra area when the related capability shapes the SAME deliverable.** Ask of each edge: would the thing being handed over be incomplete without this? A sales page without the offer and the conversion structure is half a page (same artifact → escalates); a text post does not become a video job because of a `before: [get-brolls]` edge (different artifact → does not). `pairs_with` alone never escalates.
|
|
113
113
|
|
|
@@ -35,7 +35,7 @@ Written as bare labels, the 3 factors above were true of almost any request, and
|
|
|
35
35
|
|
|
36
36
|
**And the counterpart has one exception: a single entry already delimits the scope.** If the whole outcome being asked for fits the `when:` of ONE catalogue entry, and what leaves at the end is that entry's own deliverable — a plan, a recommendation, an audit — then the scope is not open, the catalogue delimited it, and the request goes to that entry's area. "A plan to reduce churn" is `wizz-churn-prevention`; "I want ChatGPT and Perplexity to cite us" is `wizz-ai-seo`; "what to check before going live" is `wizz-site-launch-kit`. It stops being the exception the moment delivering the outcome means changing what other areas own: "improve the signup conversion rate" ends up in copy, UI and code, so it comes back to the maestro through the area clause. Ask which single entry would deliver it whole — if it takes two, the scope really is open. (Owner's decision, 2026-09-18.)
|
|
37
37
|
|
|
38
|
-
**Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it. **Exception: new or rebuilt screens.** When the request asks to BUILD screens in code (a new app, page, dashboard or panel, or a whole screen rebuilt in the product), the visual decision has not been made yet, so `designer` comes first and the sequence is design → dev (2 areas → maestro): the designer runs its research gate before any screen is coded. A tweak to an existing screen (a price, a label, a spacing) stays dev, and
|
|
38
|
+
**Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it. **Exception: new or rebuilt screens.** When the request asks to BUILD screens in code (a new app, page, dashboard or panel, or a whole screen rebuilt in the product), the visual decision has not been made yet, so `designer` comes first and the sequence is design → dev (2 areas → maestro): the designer runs its research gate before any screen is coded. A tweak to an existing screen (a price, a label, a spacing) stays dev, and so does building one component in code ("create a card component", a button, a modal): the delivery is a file in the repo. Redesigning a section with no build asked for ("redesign the hero") or choosing which component fits ("find a card that matches our style") stays designer.
|
|
39
39
|
|
|
40
40
|
**What `rel` drags counts as an extra area when the related capability shapes the SAME deliverable.** Writing the copy of a sales page without the offer and without the conversion structure delivers half a page: offer, copy and conversion are the same artifact, so that is 2 areas → maestro. What does NOT count is an adjacent capability that would produce a **different** artifact: a plain text post for LinkedIn does not need video capture just because the social content skill declares `before: [get-brolls]` — the b-roll would be another deliverable, not part of this one. `pairs_with` alone never escalates: it is neighbourhood, not dependency. The question to ask about each edge is "would the thing I am about to hand over be incomplete without this?", not "is this related?".
|
|
41
41
|
|
|
@@ -74,7 +74,7 @@ This gate does NOT fire for an open-scope request. "My site is bad, sort it out"
|
|
|
74
74
|
|
|
75
75
|
**And the counterpart has one exception: a single entry already delimits the scope.** If the whole outcome being asked for fits the `when:` of ONE catalogue entry, and what leaves at the end is that entry's own deliverable — a plan, a recommendation, an audit — then the scope is not open, the catalogue delimited it, and the request goes to that entry's area. "A plan to reduce churn" is `wizz-churn-prevention`; "I want ChatGPT and Perplexity to cite us" is `wizz-ai-seo`; "what to check before going live" is `wizz-site-launch-kit`. It stops being the exception the moment delivering the outcome means changing what other areas own: "improve the signup conversion rate" ends up in copy, UI and code, so it comes back to the maestro through the area clause. Ask which single entry would deliver it whole — if it takes two, the scope really is open. (Owner's decision, 2026-09-18.)
|
|
76
76
|
|
|
77
|
-
**Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it. **Exception: new or rebuilt screens.** When the request asks to BUILD screens in code (a new app, page, dashboard or panel, or a whole screen rebuilt in the product), the visual decision has not been made yet, so `designer` comes first and the sequence is design → dev (2 areas → maestro): the designer runs its research gate before any screen is coded. A tweak to an existing screen (a price, a label, a spacing) stays dev, and
|
|
77
|
+
**Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it. **Exception: new or rebuilt screens.** When the request asks to BUILD screens in code (a new app, page, dashboard or panel, or a whole screen rebuilt in the product), the visual decision has not been made yet, so `designer` comes first and the sequence is design → dev (2 areas → maestro): the designer runs its research gate before any screen is coded. A tweak to an existing screen (a price, a label, a spacing) stays dev, and so does building one component in code ("create a card component", a button, a modal): the delivery is a file in the repo. Redesigning a section with no build asked for ("redesign the hero") or choosing which component fits ("find a card that matches our style") stays designer.
|
|
78
78
|
|
|
79
79
|
**The area count includes what `rel` drags, when the related capability shapes the SAME deliverable.** Before deciding "1 area", look at the `rel` of the entry that matched, and ask of each edge: **would the thing I am about to hand over be incomplete without this?** — not "is this related?". Writing the copy of a sales page without the offer and without the conversion structure delivers half a page: offer, copy and conversion are the same artifact, so that is 2 areas, hence maestro. What does NOT count is an adjacent capability that would produce a **different** artifact: a plain text post for LinkedIn does not need video capture just because `wizz-social-content` declares `before: [get-brolls]` — the b-roll would be another deliverable, not part of this one. `pairs_with` alone never escalates: it is neighbourhood, not dependency. Every edge is reciprocal by construction (the schema validator rejects one-way edges), so the relation shows up whichever side the user enters from. Resolve id → area via the `ids:` map in `{project-root}/_wizz/_config/registry/index.yaml`; outside a Wizz project, via `skills-registry.yaml` itself.
|
|
80
80
|
|