Wdi Help

---
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.