wdi-method 0.4.6 → 0.5.2

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

@@ -1,98 +1,98 @@
----
-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 wave is open, which stories sit at which status, 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/waves.yaml` | Wave → release, size, `depends_on` |
-| `.constitution/document/delivery-flow-guide.md` | The five gates and their checklists |
-| `.constitution/method/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 |
-|---|---|
-| 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 lands nothing until a `<pc>` exists |
-| 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 `.control/generated/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 wave, runs `bmad-spec`, ships each story, closes the wave |
-| A small fix touching no `FR`, `UC`, `AD-N`, or domain model | Fast Path: `bmad-build` directly. It stops and becomes a wave `S` the moment an `FR` is touched |
-| A planning assumption turned out void | `wdi-decision` intent `open` — it proposes, and changes nothing |
-| 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 run other skills on the user's behalf. Name the skill; let them invoke it.
-- 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/README.md` rather than
-  paraphrasing it here.
-
-## When there is no wave 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 wave is open, which stories sit at which status, 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/waves.yaml` | Wave → release, size, `depends_on` |
+| `.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 |
+|---|---|
+| 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 lands nothing until a `<pc>` exists |
+| 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 `.control/generated/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 wave, runs `bmad-spec`, ships each story, closes the wave |
+| A small fix touching no `FR`, `UC`, `AD-N`, or domain model | Fast Path: `bmad-build` directly. It stops and becomes a wave `S` the moment an `FR` is touched |
+| A planning assumption turned out void | `wdi-decision` intent `open` — it proposes, and changes nothing |
+| 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 run other skills on the user's behalf. Name the skill; let them invoke it.
+- 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 wave 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

@@ -106,7 +106,7 @@ statement that the content was wrong.
 
 ## Intent `structure`
 
-The rules for what belongs in a map live in `.constitution/structure-guide.md`. This intent applies
+The rules for what belongs in a map live in `.constitution/method/structure-guide.md`. This intent applies
 them; it MUST NOT restate them.
 
 1. **Derive from the tree on disk**, honouring `.gitignore`. A map assembled from what the caller says

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

@@ -1,90 +1,90 @@
----
-name: wdi-problem
-description: Use at G1 Problem — when the product brief is created, updated, or validated. Checks position and preconditions, dispatches bmad-product-brief, then verifies the result against brief-guide.md and the template. Never writes the brief itself.
----
-
-# WDI Problem
-
-G1 decides **what the problem is, whose it is, and why it earns work.** `bmad-product-brief` writes the
-brief; this skill decides whether it should run at all, hands it the right intent, and checks what came
-back. Both halves matter: the override TOML controls **where** the artifact lands, and nothing in BMad
-checks **what is in it**.
-
-You MUST NOT write or edit `brief.md` yourself. If a check fails, name what is missing and re-dispatch — a
-hand-patched brief makes the memlog lie about how it got that way.
-
-## Inputs
-
-| Source | What it answers |
-|---|---|
-| `.what/_product-brief/brief.md` | Whether a brief already exists, and what intent applies |
-| `.constitution/document/brief-guide.md` | The rules the result is checked against |
-| `.constitution/document/templates/brief.md` | The required shape |
-| `_bmad-output/brainstorming/` · `forge/` · `planning-artifacts/` | Raw material available to feed in |
-| `.control/product-glossary.md` | Terms already fixed, so the brief does not invent competing ones |
-
-## Step 1 — Position
-
-- If `brief.md` exists, the intent is **update** or **validate**, never **create**. A second create would
-  overwrite the singleton.
-- If a wave is open and the ask is a scope change rather than a problem change, this is the wrong skill.
-  Route to `wdi-decision`, which wraps `bmad-correct-course`.
-- If the ask is about one initiative rather than the product, route to `wdi-product`.
-
-## Step 2 — Preconditions
-
-None of these block. Each is a question you MUST put to the owner before dispatching, once.
-
-| Check | Why it matters |
-|---|---|
-| Is there raw material worth feeding in? | Exploration output in `_bmad-output/` is invisible to the skill unless it is named |
-| Does the claim rest on outside data? | Market size, competitor, stack choice — those want `bmad-deep-recon` first |
-| Is the primary user already obvious? | If not, discovery is not finished and the brief will stall at the gate |
-
-## Step 3 — Dispatch
-
-Invoke `bmad-product-brief` with the detected intent. Do not restate the rules to it — they arrive through
-`persistent_facts` and `doc_standards` in `_bmad/custom/bmad-product-brief.toml`. Repeating them here would
-create a second copy that drifts.
-
-Name the raw-material files explicitly in the handoff. The skill globs its own output locations, and this
-project redirects them.
-
-## Step 4 — Verify
-
-Check the returned brief against the guide. Report every failure; fix none of them by hand.
-
-| # | Check | Fails when |
-|---|---|---|
-| 1 | Home | Anything landed outside `.what/_product-brief/` |
-| 2 | Eight required sections present | The template's "drop what does not earn its place" was applied to one of them |
-| 3 | Exactly one `primary` in Who This Serves | Zero, or more than one |
-| 4 | Goals numbered `BG-N` | Numbered `G1`–`G4`, which collides with the gates |
-| 5 | Scope Out written as items | Left implicit |
-| 6 | Memlog at `.control/memlog/brief.md` | A `.memlog.md` appeared inside `.what/` — `--workspace` was used |
-| 7 | No raw material folded in | Research or brainstorming prose copied into the brief instead of cited |
-| 8 | No Product Component list | A slicing was written at G1; it belongs to `wdi-init` intent `component`, after G2 |
-| 9 | `bmad-review` structure + prose ran | `doc_standards` did not fire |
-
-Check 6 MUST be fixed immediately rather than reported. A `.memlog.md` inside `.what/` is corpus pollution,
-and every later run compounds it.
-
-## Rules
-
-- You MUST NOT land anything from `_bmad-output/` into the corpus beyond the brief itself. Every other
-  output has its owner in the table in `corpus-guide.md`, and for exploration output the answer is that it
-  stays put.
-- You MUST NOT delete an exploration run folder after feeding it in. The `update` intents re-read the
-  original inputs.
-- You MUST NOT open G1 on a brief that has not been through check 9. Gate time is for deciding.
-- A brief concluding the idea is not worth building is a **pass**. You MUST report it as one rather than
-  offering to rework it.
-- Every unresolved `[ASSUMPTION]` MUST be filed through `wdi-question` before the gate opens — into
-  `assumptions.md` by default, `blocking.md` only through the three tests that file states.
-- When the ask is about the Product Component slicing, this is the wrong skill at any point. Before the list
-  exists it belongs to `wdi-init` intent `component`; after G3 a correction goes through `wdi-decision`.
-
-## Output
-
-A short report: intent dispatched, what the brief now claims in one line, and the result of all nine checks
-— naming the failures, not summarising them away.
+---
+name: wdi-problem
+description: Use at G1 Problem — when the product brief is created, updated, or validated. Checks position and preconditions, dispatches bmad-product-brief, then verifies the result against brief-guide.md and the template. Never writes the brief itself.
+---
+
+# WDI Problem
+
+G1 decides **what the problem is, whose it is, and why it earns work.** `bmad-product-brief` writes the
+brief; this skill decides whether it should run at all, hands it the right intent, and checks what came
+back. Both halves matter: the override TOML controls **where** the artifact lands, and nothing in BMad
+checks **what is in it**.
+
+You MUST NOT write or edit `brief.md` yourself. If a check fails, name what is missing and re-dispatch — a
+hand-patched brief makes the memlog lie about how it got that way.
+
+## Inputs
+
+| Source | What it answers |
+|---|---|
+| `.what/_product-brief/brief.md` | Whether a brief already exists, and what intent applies |
+| `.constitution/method/document/brief-guide.md` | The rules the result is checked against |
+| `.constitution/method/document/templates/brief.md` | The required shape |
+| `_bmad-output/brainstorming/` · `forge/` · `planning-artifacts/` | Raw material available to feed in |
+| `.control/product-glossary.md` | Terms already fixed, so the brief does not invent competing ones |
+
+## Step 1 — Position
+
+- If `brief.md` exists, the intent is **update** or **validate**, never **create**. A second create would
+  overwrite the singleton.
+- If a wave is open and the ask is a scope change rather than a problem change, this is the wrong skill.
+  Route to `wdi-decision`, which wraps `bmad-correct-course`.
+- If the ask is about one initiative rather than the product, route to `wdi-product`.
+
+## Step 2 — Preconditions
+
+None of these block. Each is a question you MUST put to the owner before dispatching, once.
+
+| Check | Why it matters |
+|---|---|
+| Is there raw material worth feeding in? | Exploration output in `_bmad-output/` is invisible to the skill unless it is named |
+| Does the claim rest on outside data? | Market size, competitor, stack choice — those want `bmad-deep-recon` first |
+| Is the primary user already obvious? | If not, discovery is not finished and the brief will stall at the gate |
+
+## Step 3 — Dispatch
+
+Invoke `bmad-product-brief` with the detected intent. Do not restate the rules to it — they arrive through
+`persistent_facts` and `doc_standards` in `_bmad/custom/bmad-product-brief.toml`. Repeating them here would
+create a second copy that drifts.
+
+Name the raw-material files explicitly in the handoff. The skill globs its own output locations, and this
+project redirects them.
+
+## Step 4 — Verify
+
+Check the returned brief against the guide. Report every failure; fix none of them by hand.
+
+| # | Check | Fails when |
+|---|---|---|
+| 1 | Home | Anything landed outside `.what/_product-brief/` |
+| 2 | Eight required sections present | The template's "drop what does not earn its place" was applied to one of them |
+| 3 | Exactly one `primary` in Who This Serves | Zero, or more than one |
+| 4 | Goals numbered `BG-N` | Numbered `G1`–`G4`, which collides with the gates |
+| 5 | Scope Out written as items | Left implicit |
+| 6 | Memlog at `.control/memlog/brief.md` | A `.memlog.md` appeared inside `.what/` — `--workspace` was used |
+| 7 | No raw material folded in | Research or brainstorming prose copied into the brief instead of cited |
+| 8 | No Product Component list | A slicing was written at G1; it belongs to `wdi-init` intent `component`, after G2 |
+| 9 | `bmad-review` structure + prose ran | `doc_standards` did not fire |
+
+Check 6 MUST be fixed immediately rather than reported. A `.memlog.md` inside `.what/` is corpus pollution,
+and every later run compounds it.
+
+## Rules
+
+- You MUST NOT land anything from `_bmad-output/` into the corpus beyond the brief itself. Every other
+  output has its owner in the table in `corpus-guide.md`, and for exploration output the answer is that it
+  stays put.
+- You MUST NOT delete an exploration run folder after feeding it in. The `update` intents re-read the
+  original inputs.
+- You MUST NOT open G1 on a brief that has not been through check 9. Gate time is for deciding.
+- A brief concluding the idea is not worth building is a **pass**. You MUST report it as one rather than
+  offering to rework it.
+- Every unresolved `[ASSUMPTION]` MUST be filed through `wdi-question` before the gate opens — into
+  `assumptions.md` by default, `blocking.md` only through the three tests that file states.
+- When the ask is about the Product Component slicing, this is the wrong skill at any point. Before the list
+  exists it belongs to `wdi-init` intent `component`; after G3 a correction goes through `wdi-decision`.
+
+## Output
+
+A short report: intent dispatched, what the brief now claims in one line, and the result of all nine checks
+— naming the failures, not summarising them away.