wdi-method 0.6.6 → 0.6.8

package/kit/skills/wdi-help/SKILL.md

@@ -1,110 +1,111 @@
----
-name: wdi-help
-description: Use when you need to know where the project stands in the delivery flow and which skill comes next. Answers from this project's five gates, not from BMad's phase column.
----
-
-# WDI Help
-
-`bmad-help` cannot answer "where am I" in this project. Its progress detection globs `output-location`
-paths resolved from `resolve_config.py`, so it is blind to every class-A artifact this project redirects
-into `.what/` and `.how/`. It also lists two required gates — `epics.md` and `sprint-status.yaml` — that
-this project's route never produces, and it is the only BMad skill with no `customize.toml`, so none of
-that can be corrected.
-
-This skill replaces it for position and routing. `bmad-help` remains useful for one thing only: questions
-about BMad itself.
-
-## Inputs
-
-| Source | What it answers |
-|---|---|
-| `.control/generated/status` | Which spec is open, how many of its tickets are done, which validators are red |
-| `.control/registry/index.yaml` | The global `mode`, and the gate map |
-| `.control/registry/components.yaml` | Per-component `mode`, `risk_accepted`, and `g4_passed` |
-| `.control/registry/specs.yaml` | Spec → release, size, `depends_on`, and its ticket index |
-| `.constitution/method/document/delivery-flow-guide.md` | The five gates and their checklists |
-| `.constitution/method/why/README.md` | The whole shape, when the caller has never seen the method |
-
-You MUST read `.control/generated/status` rather than counting files yourself. It is generated from the
-registry; hand-counting produces a second answer that will disagree.
-
-## What to answer
-
-Three things, in this order, and nothing else unless asked:
-
-1. **Where the project stands** — the last gate passed, and which gate is next.
-2. **What blocks that gate** — the specific artifact, validator, or blocking question that is not ready.
-3. **Which skill to invoke next** — one skill, named, with its intent, and the reason in a clause.
-
-Keep it under fifteen lines. A routing answer that needs scrolling has failed at its job.
-
-## The one thing that changes the answer
-
-**Read the component's `mode` before routing to G4.** A component at `mode: catalog` skips G4 entirely —
-routing it to `wdi-component` is wrong, and the next step is `wdi-build`. That is the single most common
-mis-route in this flow, because every other gate is the same for every component.
-
-## Routing by what exists
-
-| State | Next |
-|---|---|
-| `wdi-method update` just ran and its summary printed an `upgrade` line | `wdi-upgrade` — **before anything else**. Content is still in the old shape, and every skill below reads the new one |
-| `wdi-method update` just ran and printed **no** `upgrade` line | Nothing. The update was mechanical and complete; carry on from wherever the gates say you are |
-| `wdi-method install` just ran, first time in this repo | `wdi-init` intent `setup` — the global `mode`, and nothing has started until it is set |
-| Someone asks whether to run `/setup-matt-pocock-skills` | **No**, unless they are changing tracker. `install` and `update` seed `docs/agents/` already answered for this method; re-running the interview restores defaults that contradict Article 3 |
-| The installer refused, naming the ticket engines | Not a skill. Install them — `/plugin install mattpocock-skills`, or `npx skills@latest add mattpocock/skills` — then run the installer again |
-| No registry, or no global `mode` set | `wdi-init` intent `setup` — nothing has started |
-| No `.what/_product-brief/brief.md` | `wdi-problem` — G1 has not started |
-| A brief exists, and no PRD covers the area in play | `wdi-product` intent `prd` |
-| A PRD covers it but the promise has moved | `wdi-product` intent `update` — never a second PRD for the same area |
-| Only the **wording** of an `FR` is wrong | Nobody. Whichever skill is at work fixes it directly; putting it behind a gate is how three earlier corrections were dropped |
-| A PRD exists and the interface is a large part of what it promises | `wdi-ux` — optional, and it runs **before G2**, which reads its `EXPERIENCE.md`. It needs no Product Component: `design-system.md` lands at once, and the two `<pc>`-scoped halves land when `wdi-init` intent `component` runs |
-| A PRD exists, no `product_components` yet | `wdi-init` intent `component` — the slicing is born here, at the tail of G2 |
-| Components exist, `mode` or `risk_accepted` unset | `wdi-init` intents `mode` and `risk` — both are the owner's, and G4 cannot be read without them |
-| Components exist, no UC catalogue or no spine | `wdi-blueprint` — intent `catalog` first, then `platform` |
-| The blueprint is complete and G3 has not been held | The gate. Read `.how-rendered/blueprint.md`, not seven files |
-| G3 passed, a component at `outline`/`guarded`/`deep` has no depth | `wdi-component` |
-| G3 passed, the component is at `mode: catalog` | `wdi-build` — G4 is skipped by design |
-| Depth done and G4 passed for every component the work touches | `wdi-build` — it opens the spec, has the owner run `to-spec` and `to-tickets`, ships each ticket, closes the spec |
-| A small fix touching no `FR`, `UC`, `AD-N`, or domain model | Fast Path: the owner runs `/implement` directly. It stops and becomes a spec `S` the moment an `FR` is touched |
-| The owner wants every `FR` delivered without being asked in between | `wdi-autopilot` — a preflight first, then one mandate the owner accepts, then a loop that fires it. Route here only when the owner asks for it; it is never the default next step |
-| A planning assumption turned out void | `wdi-decision` intent `open` — it proposes, and changes nothing |
-| The owner has to decide something and wants the reading done first | `wdi-explain-to-me` — it briefs, and changes nothing; the decision then goes to `wdi-decision` or `wdi-question` |
-| An accepted `DEC-` has not reached its documents | `wdi-decision` intent `apply` |
-| A bug, a failing test, unexpected behaviour | `wdi-systematic-debugging`, before any fix is proposed |
-| Numbers are wanted before the work is committed | `wdi-report` intent `estimate` |
-
-A brief that exists but is thin is still a brief. You MUST NOT route back to `wdi-problem` because a
-section reads weakly — route there only when the brief is absent, when a change signal invalidates what
-it claims, or when one of its eight required sections is missing outright.
-
-## Rules
-
-- You MUST answer from this project's five gates — G1 Problem · G2 Product · G3 Blueprint · G4 Component ·
-  G5 Release. BMad's `phase` column MUST NOT be used; it mixes two conventions and names gates this
-  project does not run.
-- When a `wdi-*` wrapper exists for a BMad skill, you MUST name the wrapper, never the skill it wraps. The
-  wrapper carries the position check and the content checks; routing past it produces an artifact nothing
-  verifies. Today every BMad skill this method uses has one: `wdi-problem`, `wdi-product`,
-  `wdi-blueprint`, `wdi-build`, `wdi-decision`, `wdi-review`, `wdi-ux`.
-- Only `.control/questions/blocking.md` holds a gate. `external.md` holds go-live and MUST NOT be reported
-  as blocking a design gate; `assumptions.md` holds nothing.
-- You MUST NOT invent progress. If `.control/generated/status` is missing or stale, say so and name
-  `validate.py --generate`.
-- You MUST NOT route anyone to `/setup-matt-pocock-skills` to *finish an install*. The installer seeds
-  `docs/agents/` pre-answered, and that interview's own defaults send every engineering skill looking for a
-  root `CONTEXT.md` and `docs/adr/` — which Article 3 forbids and `wdi-reconcile` reports. It is for
-  changing tracker, and nothing else.
-- You MUST NOT run other skills on the user's behalf. Name the skill; let them invoke it. The one skill that
-  runs others is `wdi-autopilot`, and only under a mandate the owner accepted — that is what the mandate is.
-- When the next step is blocked by a decision rather than by work, route to `wdi-question` or
-  `wdi-decision`, not to a producing skill.
-- When asked about BMad itself — what a BMad skill does, what it writes, which are deprecated — answer
-  from `bmad-skill-register.md`, and only fall back to `bmad-help` for module documentation.
-- When the caller has never seen this method, point at `.constitution/method/why/README.md` rather than
-  paraphrasing it here.
-
-## When there is no spec open
-
-Say so plainly, then route by the table above. An artifact a later gate produces MUST NOT be reported as
-missing — that is not a gap, it is the plan.
+---
+name: wdi-help
+description: Use when you need to know where the project stands in the delivery flow and which skill comes next. Answers from this project's five gates, not from BMad's phase column.
+---
+
+# WDI Help
+
+`bmad-help` cannot answer "where am I" in this project. Its progress detection globs `output-location`
+paths resolved from `resolve_config.py`, so it is blind to every class-A artifact this project redirects
+into `.what/` and `.how/`. It also lists two required gates — `epics.md` and `sprint-status.yaml` — that
+this project's route never produces, and it is the only BMad skill with no `customize.toml`, so none of
+that can be corrected.
+
+This skill replaces it for position and routing. `bmad-help` remains useful for one thing only: questions
+about BMad itself.
+
+## Inputs
+
+| Source | What it answers |
+|---|---|
+| `.control/generated/status` | Which spec is open, how many of its tickets are done, which validators are red |
+| `.control/registry/index.yaml` | The global `mode`, and the gate map |
+| `.control/registry/components.yaml` | Per-component `mode`, `risk_accepted`, and `g4_passed` |
+| `.control/registry/specs.yaml` | Spec → release, size, `depends_on`, and its ticket index |
+| `.constitution/method/document/delivery-flow-guide.md` | The five gates and their checklists |
+| `.constitution/method/why/README.md` | The whole shape, when the caller has never seen the method |
+
+You MUST read `.control/generated/status` rather than counting files yourself. It is generated from the
+registry; hand-counting produces a second answer that will disagree.
+
+## What to answer
+
+Three things, in this order, and nothing else unless asked:
+
+1. **Where the project stands** — the last gate passed, and which gate is next.
+2. **What blocks that gate** — the specific artifact, validator, or blocking question that is not ready.
+3. **Which skill to invoke next** — one skill, named, with its intent, and the reason in a clause.
+
+Keep it under fifteen lines. A routing answer that needs scrolling has failed at its job.
+
+## The one thing that changes the answer
+
+**Read the component's `mode` before routing to G4.** A component at `mode: catalog` skips G4 entirely —
+routing it to `wdi-component` is wrong, and the next step is `wdi-build`. That is the single most common
+mis-route in this flow, because every other gate is the same for every component.
+
+## Routing by what exists
+
+| State | Next |
+|---|---|
+| `wdi-method update` just ran and its summary printed an `upgrade` line | `wdi-upgrade` — **before anything else**. Content is still in the old shape, and every skill below reads the new one |
+| `wdi-method update` just ran and printed **no** `upgrade` line | Nothing. The update was mechanical and complete; carry on from wherever the gates say you are |
+| `wdi-method install` just ran, first time in this repo | `wdi-init` intent `setup` — the global `mode`, and nothing has started until it is set |
+| Someone asks whether to run `/setup-matt-pocock-skills` | **No**, unless they are changing tracker. `install` and `update` seed `docs/agents/` already answered for this method; re-running the interview restores defaults that contradict Article 3 |
+| The installer refused, naming engines | Not a skill. `npx skills@latest add mattpocock/skills` — **into this repo**, all six it names; a user-level plugin does not count. Then run the installer again |
+| An engine will not invoke, or `engines-invocable` is red | `wdi-init` intent `engines` — `npx skills update` puts the author's `disable-model-invocation` back, and one command strips it out again |
+| No registry, or no global `mode` set | `wdi-init` intent `setup` — nothing has started |
+| No `.what/_product-brief/brief.md` | `wdi-problem` — G1 has not started |
+| A brief exists, and no PRD covers the area in play | `wdi-product` intent `prd` |
+| A PRD covers it but the promise has moved | `wdi-product` intent `update` — never a second PRD for the same area |
+| Only the **wording** of an `FR` is wrong | Nobody. Whichever skill is at work fixes it directly; putting it behind a gate is how three earlier corrections were dropped |
+| A PRD exists and the interface is a large part of what it promises | `wdi-ux` — optional, and it runs **before G2**, which reads its `EXPERIENCE.md`. It needs no Product Component: `design-system.md` lands at once, and the two `<pc>`-scoped halves land when `wdi-init` intent `component` runs |
+| A PRD exists, no `product_components` yet | `wdi-init` intent `component` — the slicing is born here, at the tail of G2 |
+| Components exist, `mode` or `risk_accepted` unset | `wdi-init` intents `mode` and `risk` — both are the owner's, and G4 cannot be read without them |
+| Components exist, no UC catalogue or no spine | `wdi-blueprint` — intent `catalog` first, then `platform` |
+| The blueprint is complete and G3 has not been held | The gate. Read `.how-rendered/blueprint.md`, not seven files |
+| G3 passed, a component at `outline`/`guarded`/`deep` has no depth | `wdi-component` |
+| G3 passed, the component is at `mode: catalog` | `wdi-build` — G4 is skipped by design |
+| Depth done and G4 passed for every component the work touches | `wdi-build` — it opens the spec, has the owner run `to-spec` and `to-tickets`, ships each ticket, closes the spec |
+| A small fix touching no `FR`, `UC`, `AD-N`, or domain model | Fast Path: the owner runs `/implement` directly. It stops and becomes a spec `S` the moment an `FR` is touched |
+| The owner wants every `FR` delivered without being asked in between | `wdi-autopilot` — a preflight first, then one mandate the owner accepts, then a loop that fires it. Route here only when the owner asks for it; it is never the default next step |
+| A planning assumption turned out void | `wdi-decision` intent `open` — it proposes, and changes nothing |
+| The owner has to decide something and wants the reading done first | `wdi-explain-to-me` — it briefs, and changes nothing; the decision then goes to `wdi-decision` or `wdi-question` |
+| An accepted `DEC-` has not reached its documents | `wdi-decision` intent `apply` |
+| A bug, a failing test, unexpected behaviour | `wdi-systematic-debugging`, before any fix is proposed |
+| Numbers are wanted before the work is committed | `wdi-report` intent `estimate` |
+
+A brief that exists but is thin is still a brief. You MUST NOT route back to `wdi-problem` because a
+section reads weakly — route there only when the brief is absent, when a change signal invalidates what
+it claims, or when one of its eight required sections is missing outright.
+
+## Rules
+
+- You MUST answer from this project's five gates — G1 Problem · G2 Product · G3 Blueprint · G4 Component ·
+  G5 Release. BMad's `phase` column MUST NOT be used; it mixes two conventions and names gates this
+  project does not run.
+- When a `wdi-*` wrapper exists for a BMad skill, you MUST name the wrapper, never the skill it wraps. The
+  wrapper carries the position check and the content checks; routing past it produces an artifact nothing
+  verifies. Today every BMad skill this method uses has one: `wdi-problem`, `wdi-product`,
+  `wdi-blueprint`, `wdi-build`, `wdi-decision`, `wdi-review`, `wdi-ux`.
+- Only `.control/questions/blocking.md` holds a gate. `external.md` holds go-live and MUST NOT be reported
+  as blocking a design gate; `assumptions.md` holds nothing.
+- You MUST NOT invent progress. If `.control/generated/status` is missing or stale, say so and name
+  `validate.py --generate`.
+- You MUST NOT route anyone to `/setup-matt-pocock-skills` to *finish an install*. The installer seeds
+  `docs/agents/` pre-answered, and that interview's own defaults send every engineering skill looking for a
+  root `CONTEXT.md` and `docs/adr/` — which Article 3 forbids and `wdi-reconcile` reports. It is for
+  changing tracker, and nothing else.
+- You MUST NOT run other skills on the user's behalf. Name the skill; let them invoke it. The one skill that
+  runs others is `wdi-autopilot`, and only under a mandate the owner accepted — that is what the mandate is.
+- When the next step is blocked by a decision rather than by work, route to `wdi-question` or
+  `wdi-decision`, not to a producing skill.
+- When asked about BMad itself — what a BMad skill does, what it writes, which are deprecated — answer
+  from `bmad-skill-register.md`, and only fall back to `bmad-help` for module documentation.
+- When the caller has never seen this method, point at `.constitution/method/why/README.md` rather than
+  paraphrasing it here.
+
+## When there is no spec open
+
+Say so plainly, then route by the table above. An artifact a later gate produces MUST NOT be reported as
+missing — that is not a gap, it is the plan.

package/kit/skills/wdi-init/SKILL.md

@@ -11,7 +11,8 @@ of where things are, a reader that can see this product's code.
 
 | Intent | Does | Precondition | How often |
 |---|---|---|---|
-| `setup` | Guide the global `mode` setting · scaffold the registries that are still empty · **report** the documents already present, read-only · derive the two structure maps | before G1 | once per project |
+| `setup` | Guide the global `mode` setting · scaffold the registries that are still empty · **report** the documents already present, read-only · derive the two structure maps · align the engines | before G1 | once per project |
+| `engines` | Run `npx wdi-method engines --fix`, then report what it changed: the flag stripped from `to-spec` · `to-tickets` · `implement` so `wdi-build` can invoke them, the retired BMad G5 wrappers locked out of model invocation and denied in `.claude/settings.json`, and `docs/agents/` repaired where it still carried upstream's answer | after every `wdi-method install` or `update` | each version jump, and any time `engines-invocable` is red |
 | `component` | Propose the slicing from the brief plus every PRD · birth what is accepted: registry row plus `SRS`/`SDD` skeletons · propose `mode`, `risk_accepted`, `risk_note`, `owns` | **G2 passed** | each time a component is born |
 | `mode` | Change `mode` — global in `index.yaml`, or one component in `components.yaml`. Guided | — | any time |
 | `risk` | Set or review one component's `risk_accepted`, with disclosure of what it touches | the component exists | any time, usually before G4 |
@@ -26,6 +27,23 @@ of where things are, a reader that can see this product's code.
 - Retiring or renaming a Product Component that already carries an SRS **is not its authority**. That
   goes through `wdi-decision`. Birthing is cheap; retiring is not.
 
+## Intent `engines`
+
+One command does the work — `npx wdi-method engines --fix` — and this intent exists because the work is
+not the installer's to do unasked. Two of the three things it touches are files somebody else owns:
+`docs/agents/*.md` is the product's, and the engines' `SKILL.md` files are the author's. `install` and
+`update` do the two mechanical halves (the flag, the BMad lock) on every run; the config repair happens
+only here, knowingly, and the previous text is kept as `.bak`.
+
+Report, always, in this order: which engines are present and which are missing (all six are required —
+`to-spec` · `to-tickets` · `implement` · `tdd` · `code-review` · `domain-modeling`), which had the flag
+stripped, how many BMad wrappers were locked, and whether `docs/agents/issue-tracker.md` was upstream's
+or already the method's. If any engine is missing, say so and stop: `npx skills@latest add
+mattpocock/skills` is the owner's to run, and a user-level plugin does not count — its files cannot be
+unlocked.
+
+Then run `validate.py`. `engines-invocable` green is the proof, not the report.
+
 ## Intent `setup`
 
 1. Read the tree. Report every document already present, by path, with one line on what it looks like.