wdi-method 0.6.30 → 0.6.31

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

@@ -1,125 +1,127 @@
----
-name: wdi-help
-description: Check project delivery status, open or pending specs and tickets, current gate progress, and determine what to build or which skill to invoke next. Answers from this project's status registry and five gates.
----
-
-# 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.yaml` | Primary machine-readable status: which spec is open, tickets progress, red validators (or `status.md`) |
-| `.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` | Fallback only when status is absent/stale: spec → release, size, and ticket index (MUST query selectively) |
-| `.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.yaml` (or `status.md`) rather than counting files yourself. You
-MUST NOT open or inspect `.control/registry/specs.yaml` if the status file is present and answers which
-spec is open.
-
-## 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` |
-| Closed specs remain in `.scratch/`, or need archival/pruning | `wdi-prune-or-archive` — archives closed spec to `.archive/specs/` or prunes from disk |
-| Raw manual-test notes needing triage, review, and spec drafting | `wdi-daily-what-to-build` — classifies notes, drafts spec/tickets via `wdi-build`, gets second opinion |
-| Autonomous delivery loop with local runner and peer review | `wdi-daily-autopilot` — composes routine, resolves local runners, launches `/loop` unattended |
-| Merged autopilot run needing branch cleanup and physical test checklist | `wdi-daily-what-to-test` — syncs branch, prunes merged worktrees/branches, configures smoke target, provides delta-scoped checklist |
-| Cleaning up generated rendered duplicate files from git | Untrack via `git rm -r --cached .what-rendered/ .how-rendered/`, add to `.gitignore`, regenerate via `validate.py --generate` |
-
-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.yaml` (or `status.md`) is missing or stale,
-  say so, query `specs.yaml` selectively, and name `validate.py --generate`.
-- You MUST NOT call Read on the entire 1000+ line `.control/registry/specs.yaml` file into context. When
-  discovering active or open work as a fallback, query `specs.yaml` selectively (e.g. `Grep` for `status:\s*(open|ready-for-dev)`).
-- You MUST NOT run broad or recursive searches across `.scratch/` (e.g. searching `*` or `**/*`). When
-  inspecting candidate open specs or tickets, inspect only the candidate spec's folder using the `spec_folder:`
-  path resolved from `specs.yaml`.
-- You MUST treat `wdi-help` as a fast status and routing skill: if filesystem drift, orphaned folders, or
-  discrepancies between registry and disk are suspected, route to `wdi-reconcile` rather than conducting
-  a filesystem audit in this skill.
-- 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: Check project delivery status, open or pending specs and tickets, current gate progress, and determine what to build or which skill to invoke next. Answers from this project's status registry and five gates.
+---
+
+# 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.yaml` | Primary machine-readable status: which spec is open, tickets progress, red validators (or `status.md`) |
+| `.control/wdi-method.yaml` | The installed version, and `upgrade_pending` — what `wdi-upgrade` still owes. Absent means nothing |
+| `.control/registry/index.yaml` | The global `mode`, the gate map, and `gates_passed` |
+| `.control/registry/components.yaml` | Per-component `mode`, `risk_accepted`, and `g4_passed` |
+| `.control/registry/specs.yaml` | Fallback only when status is absent/stale: spec → release, size, and ticket index (MUST query selectively) |
+| `.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.yaml` (or `status.md`) rather than counting files yourself. You
+MUST NOT open or inspect `.control/registry/specs.yaml` if the status file is present and answers which
+spec is open.
+
+## 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 |
+|---|---|
+| `upgrade_pending` is present in `.control/wdi-method.yaml` | `wdi-upgrade` — **before anything else**, however long ago `update` ran. Content is still in the old shape, and every skill below reads the new one. Name the pending items in the answer |
+| `upgrade_pending` is absent | No content is waiting to move. Do NOT guess from the version number: whether an upgrade is owed is a fact about the content, and `update` probed it. It does NOT mean the validators are green — a few `wdi-upgrade` items are found only by the validator, so a red validator is still routed by its own row. A repo updated before this field existed has no record — `npx wdi-method upgrade-check` writes one |
+| `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` and `.what/experience.md` land 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 |
+| A gate's work is visibly done but `gates_passed` does not list it — components exist without `G2`, a spine without `G3` | Ask the owner whether that gate passed, and record it only on their answer. The skill that follows reads `gates_passed`, and a gate nobody recorded is a precondition nobody can check |
+| 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` |
+| Closed specs remain in `.scratch/`, or need archival/pruning | `wdi-prune-or-archive` — archives closed spec to `.archive/specs/` or prunes from disk |
+| Raw manual-test notes needing triage, review, and spec drafting | `wdi-daily-what-to-build` — classifies notes, drafts spec/tickets via `wdi-build`, gets second opinion |
+| Autonomous delivery loop with local runner and peer review | `wdi-daily-autopilot` — composes routine, resolves local runners, launches `/loop` unattended |
+| Merged autopilot run needing branch cleanup and physical test checklist | `wdi-daily-what-to-test` — syncs branch, prunes merged worktrees/branches, configures smoke target, provides delta-scoped checklist |
+| Cleaning up generated rendered duplicate files from git | Untrack via `git rm -r --cached .what-rendered/ .how-rendered/`, add to `.gitignore`, regenerate via `validate.py --generate` |
+
+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.yaml` (or `status.md`) is missing or stale,
+  say so, query `specs.yaml` selectively, and name `validate.py --generate`.
+- You MUST NOT call Read on the entire 1000+ line `.control/registry/specs.yaml` file into context. When
+  discovering active or open work as a fallback, query `specs.yaml` selectively (e.g. `Grep` for `status:\s*(open|ready-for-dev)`).
+- You MUST NOT run broad or recursive searches across `.scratch/` (e.g. searching `*` or `**/*`). When
+  inspecting candidate open specs or tickets, inspect only the candidate spec's folder using the `spec_folder:`
+  path resolved from `specs.yaml`.
+- You MUST treat `wdi-help` as a fast status and routing skill: if filesystem drift, orphaned folders, or
+  discrepancies between registry and disk are suspected, route to `wdi-reconcile` rather than conducting
+  a filesystem audit in this skill.
+- 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

@@ -13,7 +13,7 @@ of where things are, a reader that can see this product's code.
 |---|---|---|---|
 | `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 |
+| `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** — read from `gates_passed`; missing, ask the owner | 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 |
 | `structure` | Re-derive `.control/structure-codebase.md` and `structure-document.md` from the tree on disk | — | when folders change, and at spec close |
@@ -106,6 +106,10 @@ components is the moment that ends. Landing goes through `wdi-ux` — it owns th
 skill MAY write them — but it is dispatched from here rather than left for the owner to remember. It is
 the only deferral left in the flow, and this is where it closes.
 
+The act is not done until it is verified: `validate.py` MUST show `ux-landed` green before this intent
+reports. Red means a UX run still waits while components exist, or the corpus still cites the run —
+landing that stopped halfway, found now rather than at G3.
+
 **Containers MAY be registered here when they are genuinely already known** — an app, an API, a database
 the product plainly has. Then a screen `LC` gets its container the moment it is born and there is no debt
 at all. They MUST NOT be guessed to achieve that: `wdi-blueprint` intent `platform` owns the real answer
@@ -147,9 +151,10 @@ them; it MUST NOT restate them.
 2. Classify each base folder. For the codebase map the only test is deployability — a **container** runs
    its own code or stores its own data, a **library** is imported by something else, anything else stays
    a line in the top-level tree or in a non-unit section. Size and importance MUST NOT decide it.
-   Container headings MUST be **exactly the `built: true` containers** in `components.yaml`: every
-   heading is a registered container, and a `built: false` one MUST NOT get a heading because no code of
-   ours lives in it. The match is one-directional, and reading it both ways makes it unsatisfiable.
+   Container headings MUST be **exactly the `built: true` containers without `repo:`** in
+   `components.yaml`: every heading is a registered container, a `built: false` one MUST NOT get a
+   heading because no code of ours lives in it, and one whose `repo:` names another repository MUST NOT
+   get one here because its code map is there. The match is one-directional, and reading it both ways makes it unsatisfiable.
 3. Draw the convention, not the contents. A shape that repeats MUST be written once with a placeholder.
 4. Mark key files `★` by the four tests in the guide. Borderline files are left out.
 5. Write from `templates/structure-codebase.md` and `templates/structure-document.md`. Template comments

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

@@ -1,108 +1,114 @@
----
-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 spec 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 — Land the Goals
-
-The template's `Goals` section is a pointer: `Goals — see goals.yaml → goals:`. The engine drafts
-`BG-N` statements in conversation, but nothing in `bmad-product-brief` writes them anywhere durable —
-the returned `brief.md` has no place left to hold them.
-
-Write each goal discussed as a row in `.control/registry/goals.yaml` → `goals:`, with the next
-`id` in sequence and its `statement`. Add a `why:` field only when the goal's justification is not
-already carried by `The Problem` or `Why` — most goals need no `why:` at all. This step is what
-finishes the brief; a pointer to an empty list is not a finished G1 artifact, and you MUST NOT report
-it as one.
-
-This is landing, not editing `brief.md` — the rule in the header is about the prose document, not the
-registry. Registry conversion is part of producing the artifact, the same way it is for a screen
-becoming an `LC` row.
-
-## Step 5 — 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`, landed in the registry, and the brief's own section stays a pointer | A goal's statement was written into the brief instead of, or as well as, the registry row from Step 4 |
-| 5 | Success Criteria names exactly one measurable figure, with a timeframe | A mission statement, a mix of signals, or a claim nobody could check without opening the code |
-| 6 | Scope Out written as items | Left implicit |
-| 7 | No Assumptions or Prerequisites section | Either appeared in the brief instead of being routed through `wdi-question` |
-| 8 | Memlog at `.control/memlog/brief.md` | A `.memlog.md` appeared inside `.what/` — `--workspace` was used |
-| 9 | No raw material folded in | Research or brainstorming prose copied into the brief instead of cited |
-| 10 | No Product Component list | A slicing was written at G1; it belongs to `wdi-init` intent `component`, after G2 |
-| 11 | `bmad-review` structure + prose ran | `doc_standards` did not fire |
-
-Check 8 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 11. 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, the goal rows landed in Step 4,
-and the result of all eleven 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 spec 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 — Land the Goals
+
+The template's `Goals` section is a pointer: `Goals — see goals.yaml → goals:`. The engine drafts
+`BG-N` statements in conversation, but nothing in `bmad-product-brief` writes them anywhere durable —
+the returned `brief.md` has no place left to hold them.
+
+Write each goal discussed as a row in `.control/registry/goals.yaml` → `goals:`, with the next
+`id` in sequence and its `statement`. Add a `why:` field only when the goal's justification is not
+already carried by `The Problem` or `Why` — most goals need no `why:` at all. This step is what
+finishes the brief; a pointer to an empty list is not a finished G1 artifact, and you MUST NOT report
+it as one.
+
+This is landing, not editing `brief.md` — the rule in the header is about the prose document, not the
+registry. Registry conversion is part of producing the artifact, the same way it is for a screen
+becoming an `LC` row.
+
+## Step 5 — 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`, landed in the registry, and the brief's own section stays a pointer | A goal's statement was written into the brief instead of, or as well as, the registry row from Step 4 |
+| 5 | Success Criteria names exactly one measurable figure, with a timeframe | A mission statement, a mix of signals, or a claim nobody could check without opening the code |
+| 6 | Scope Out written as items | Left implicit |
+| 7 | No Assumptions or Prerequisites section | Either appeared in the brief instead of being routed through `wdi-question` |
+| 8 | Memlog at `.control/memlog/brief.md` | A `.memlog.md` appeared inside `.what/` — `--workspace` was used |
+| 9 | No raw material folded in | Research or brainstorming prose copied into the brief instead of cited |
+| 10 | No Product Component list | A slicing was written at G1; it belongs to `wdi-init` intent `component`, after G2 |
+| 11 | `bmad-review` structure + prose ran | `doc_standards` did not fire |
+
+Check 8 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 11. 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`.
+
+## Step 6 — Record the gate
+
+Ask the owner whether G1 passed. Write `G1` into `gates_passed` only on their explicit *yes* —
+`delivery-flow-guide.md` § *Recording a gate that passed*.
+
+## Output
+
+A short report: intent dispatched, what the brief now claims in one line, the goal rows landed in Step 4,
+and the result of all eleven checks — naming the failures, not summarising them away — and whether G1
+was recorded.