wdi-method 0.6.30 → 0.6.32
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +129 -0
- package/NOTICE +7 -2
- package/README.md +16 -11
- package/bin/wdi-method.js +396 -87
- package/kit/.constitution/method/document/architecture-guide.md +217 -209
- package/kit/.constitution/method/document/bmad-skill-register.md +107 -104
- package/kit/.constitution/method/document/corpus-guide.md +522 -517
- package/kit/.constitution/method/document/decision-guide.md +236 -216
- package/kit/.constitution/method/document/delivery-flow-guide.md +20 -0
- package/kit/.constitution/method/document/prd-guide.md +245 -245
- package/kit/.constitution/method/document/templates/design-system.md +96 -66
- package/kit/.constitution/method/document/templates/experience.md +62 -0
- package/kit/.constitution/method/document/templates/structure-codebase.md +131 -129
- package/kit/.constitution/method/document/templates/ux.md +78 -76
- package/kit/.constitution/method/document/ux-guide.md +161 -115
- package/kit/.constitution/method/method-glossary.md +3 -0
- package/kit/.constitution/method/scripts/validate.py +3375 -3200
- package/kit/.constitution/method/structure-guide.md +204 -202
- package/kit/.constitution/method/why/README.md +1 -1
- package/kit/.constitution/method/why/artifact-map.md +158 -157
- package/kit/.constitution/method/why/portability.md +19 -2
- package/kit/skills/wdi-autopilot/SKILL.md +32 -19
- package/kit/skills/wdi-blueprint/SKILL.md +271 -264
- package/kit/skills/wdi-build/SKILL.md +28 -19
- package/kit/skills/wdi-component/SKILL.md +179 -174
- package/kit/skills/wdi-daily-autopilot/SKILL.md +24 -13
- package/kit/skills/wdi-daily-what-to-build/SKILL.md +9 -6
- package/kit/skills/wdi-daily-what-to-test/SKILL.md +2 -0
- package/kit/skills/wdi-decision/SKILL.md +206 -203
- package/kit/skills/wdi-explain-to-me/SKILL.md +2 -0
- package/kit/skills/wdi-help/SKILL.md +130 -125
- package/kit/skills/wdi-init/SKILL.md +10 -5
- package/kit/skills/wdi-problem/SKILL.md +114 -108
- package/kit/skills/wdi-product/SKILL.md +167 -162
- package/kit/skills/wdi-prune-or-archive/SKILL.md +2 -0
- package/kit/skills/wdi-reconcile/SKILL.md +170 -169
- package/kit/skills/wdi-upgrade/SKILL.md +234 -215
- package/kit/skills/wdi-ux/SKILL.md +187 -169
- package/kit-overlay/AGENTS.md +15 -2
- package/kit-overlay/portability.md +19 -2
- package/lib/platforms.mjs +420 -248
- package/package.json +1 -1
- package/scaffold/.control/registry/index.yaml +2 -1
package/CHANGELOG.md
CHANGED
|
@@ -10,6 +10,135 @@ version contains every fix below it.
|
|
|
10
10
|
|
|
11
11
|
---
|
|
12
12
|
|
|
13
|
+
## [0.6.32] - 2026-10-04
|
|
14
|
+
|
|
15
|
+
A patch by the owner's choice, though it carries behaviour changes: until now the method only worked
|
|
16
|
+
properly on Claude Code. Read the whole entry if the repo uses any other host.
|
|
17
|
+
|
|
18
|
+
**Read this before you update.** `update` can now refuse where it went through before: the engines
|
|
19
|
+
have to be in a folder **every selected host reads**, not just somewhere in the repo. The refusal names
|
|
20
|
+
each host and the `npx skills add … --agent <id>` that fixes it. `validate.py` `engines-invocable` goes
|
|
21
|
+
red for the same reason, and for engines it could not see before (flagged engines under `.kiro/skills`
|
|
22
|
+
used to read as "no engines in this repo").
|
|
23
|
+
|
|
24
|
+
### Changed: behaviour
|
|
25
|
+
|
|
26
|
+
- **One record per host.** `lib/platforms.mjs` now records, for each host, where it reads skills, the
|
|
27
|
+
`npx skills` agent id, its project rule files, how a person types a skill, whether it can hold a skill to
|
|
28
|
+
manual-only, and whether it has a scheduler of its own. `install` / `update` write the selected hosts
|
|
29
|
+
into `.control/wdi-method.yaml` as `platforms:` and `hosts:`; `update` reuses that list, and the skills
|
|
30
|
+
and `validate.py` read it. The five-folder lists in the installer and the validator are gone.
|
|
31
|
+
- **Engines are checked per host, and unlocked and locked everywhere.** Engine detection, the
|
|
32
|
+
`disable-model-invocation` strip, and the BMad G5 lock cover every `.<host>/skills` folder in the repo,
|
|
33
|
+
plus every folder a supported host reads. Kiro, Cline, Trae, Junie, Qwen, CodeBuddy and the rest were
|
|
34
|
+
missed before.
|
|
35
|
+
- **Manual-only on every host, in three layers.** The host's own lock where it has one —
|
|
36
|
+
`disable-model-invocation: true` (honoured by Claude Code, CodeBuddy, Factory Droid, Qwen, Kimi Code,
|
|
37
|
+
Pi, Pochi, OpenClaw, CodeWhale, Zencoder), `.claude/settings.json` deny rules (Claude Code only now; a repo
|
|
38
|
+
without Claude Code no longer gets a `.claude/` folder), and `"ask"` under `permission.skill` in
|
|
39
|
+
`opencode.json` for OpenCode (merged; a value the product set is kept). A guard line at the top of
|
|
40
|
+
the five manual-only skills. A rule in the `AGENTS.md` block. On a host with no lock, the last two are
|
|
41
|
+
the lock.
|
|
42
|
+
- **The method block reaches every host's rule file.** Besides `AGENTS.md`: `CLAUDE.md`, `GEMINI.md`,
|
|
43
|
+
`QWEN.md`, `CODEBUDDY.md`, `CRUSH.md`, `.goosehints`, `replit.md`, `.junie/guidelines.md`,
|
|
44
|
+
`.cursorrules`, `.agents/AGENTS.md`, `.trae/rules/wdi-method.md`, `.zencoder/rules/wdi-method.md` —
|
|
45
|
+
each only for the host that reads it. An existing file keeps everything outside the block.
|
|
46
|
+
- **`wdi-build` invokes the engines through the host's own skill mechanism.** A skill tool where the host
|
|
47
|
+
has one; elsewhere, reading the engine's whole `SKILL.md` from the repo — which is how those hosts load
|
|
48
|
+
any skill. Three contradictory statements (Skill tool only / "the owner runs them" / read-and-follow
|
|
49
|
+
under a mandate only) are replaced by that one rule. Paraphrasing an engine is still forbidden.
|
|
50
|
+
- **`wdi-daily-autopilot` and `wdi-autopilot` use the host's own scheduler, or run once.** `/loop` on
|
|
51
|
+
Claude Code, Command Code, and Qoder; the host's scheduler on CodeBuddy, Cline, Goose, GitHub Copilot,
|
|
52
|
+
Warp, and AdaL. On every other host the skill runs one iteration per invocation under the same mandate,
|
|
53
|
+
ledger, and branch — never a shell loop or an OS scheduler.
|
|
54
|
+
- **Engines in the repo but not where a host reads can be copied in place.** The TUI offers it (copy,
|
|
55
|
+
leave the host out, or stop); non-interactively it is `--copy-engines` on `install` / `update`, or
|
|
56
|
+
`npx wdi-method engines --copy` later. The source is the repo's own copy — no network, nothing
|
|
57
|
+
overwritten. The refusal message now names all three fixes and the Windows symlink fallback.
|
|
58
|
+
- **`wdi-help` names the next skill in this host's syntax** — `/name`, `$name` (Codex, Cortex),
|
|
59
|
+
`/skill:name` (Kimi Code, Pi), `@name` (Windsurf).
|
|
60
|
+
- **Hosts removed:** iFlow (shut down), Firebender (service ends 2026-10-31), Roo Code (archived), Hermes
|
|
61
|
+
Agent (reads `~/.hermes/skills` only), Neovate (no documented project skill folder), Mux (runs other
|
|
62
|
+
agents, reads no skills itself). `--agents` with one of them is refused with the reason; `update` on a
|
|
63
|
+
repo that names one says so and leaves its folders alone.
|
|
64
|
+
- **`--agents antigravity` now means the Antigravity IDE** (`.agent/skills`), as BMad's id does. It was
|
|
65
|
+
silently aliased to the CLI.
|
|
66
|
+
- The installer's last Indonesian strings are English; the host picker says how many hosts it searches.
|
|
67
|
+
|
|
68
|
+
**`wdi-upgrade`:** not needed. Nothing in the repo's content changes shape; `update` itself writes the new
|
|
69
|
+
stamp fields. If `update` refuses, it prints three fixes: `--copy-engines` (offline, from the repo's own
|
|
70
|
+
copy), `npx skills add … --agent <id>`, or leaving an unused host out with `--agents`.
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
## [0.6.31] - 2026-09-28
|
|
75
|
+
|
|
76
|
+
A patch by the owner's choice, though it carries behaviour changes — read the whole entry.
|
|
77
|
+
|
|
78
|
+
**Read this before you update.** Two validator rules are new or stricter, so a repo that is green today
|
|
79
|
+
can come back red. Most of it is something that was already wrong and went unchecked; two parts are new
|
|
80
|
+
obligations — the ban on citing a UX run from the corpus, and `landed_from` on every landed UX document.
|
|
81
|
+
|
|
82
|
+
### Changed: behaviour
|
|
83
|
+
|
|
84
|
+
- **New validator `ux-landed`, checked per run.** Every landed UX document names the run file(s) it came
|
|
85
|
+
from in a new frontmatter field, `landed_from`. Once Product Components exist, every active run
|
|
86
|
+
`DESIGN.md` / `EXPERIENCE.md` in `_bmad-output/ux/` MUST be named by some landed document — a
|
|
87
|
+
component's, or `.what/experience.md` — and `.what/` and `.how/` MUST NOT cite the run anywhere else.
|
|
88
|
+
`landed_from` is provenance: the run may be deleted later and it stays valid. `.control/decisions/` may
|
|
89
|
+
still cite the run. A run file without frontmatter is recognised by its filename. UX stays optional: the rule
|
|
90
|
+
is silent with no run, silent before any component exists, silent on a run marked `superseded` or
|
|
91
|
+
`withdrawn`, and no `mode` or `risk_accepted` value changes it.
|
|
92
|
+
- **`container-built` understands a product split across repositories.** A new optional field `repo:` on
|
|
93
|
+
a container names the repository its code lives in when that is NOT this one. Such a container keeps
|
|
94
|
+
`built: true` and its C4 place, but gets no heading in this repo's code map — the template, the
|
|
95
|
+
structure guide, and the validator now say the same thing. Absent `repo:` means this repository, so a
|
|
96
|
+
single-repo product sees no change. `repo:` naming this repository — compared with the `origin`
|
|
97
|
+
remote; without one the comparison is reported as skipped — or `repo:` on a `built: false` container,
|
|
98
|
+
is red.
|
|
99
|
+
- **`cites-resolve` recognises installed skill copies under every host.** `.<host>/skills/bmad-*` and
|
|
100
|
+
`.<host>/skills/wdi-*` are skipped by pattern instead of a three-host list, so a repo installed for
|
|
101
|
+
Kiro, Cline, Trae, or any other supported host no longer carries permanent findings on files it may not
|
|
102
|
+
edit. `.work/` is skipped too — scratch is not authority, so a pasted validator line is not a claim.
|
|
103
|
+
- **`update` records what `wdi-upgrade` still owes.** The probes now write `upgrade_pending` into
|
|
104
|
+
`.control/wdi-method.yaml`, numbered by the rows of `wdi-upgrade`'s checklist, and the field is absent
|
|
105
|
+
when nothing is owed. `npx wdi-method upgrade-check` re-probes at any time and rewrites it (exit 1 while
|
|
106
|
+
anything is pending); `wdi-upgrade` ends by running it, and `wdi-help` routes on the field instead of on
|
|
107
|
+
whether `update` "just ran". The probes no longer report the method's own skill text under a non-Claude
|
|
108
|
+
host, or a scratch paper, as stale product content.
|
|
109
|
+
|
|
110
|
+
### Changed: method
|
|
111
|
+
|
|
112
|
+
- **UX has a product level.** New `.what/experience.md` (template `templates/experience.md`) holds the
|
|
113
|
+
experience every component keeps — foundation, information architecture, voice and tone, the flow map,
|
|
114
|
+
journeys that cross components, shared edge cases. `design-system.md` grows the build side: state
|
|
115
|
+
patterns, interaction primitives, how accessibility is met, surfaces that are not screens.
|
|
116
|
+
`ux-guide.md` § *Product level* maps each `bmad-ux` section to one of the two, and both land at G2
|
|
117
|
+
because neither path contains a `<pc>`. A flow zoom-in lands with the component owning its screens,
|
|
118
|
+
never with the owner of a shared composite drawn inside it.
|
|
119
|
+
- **Completing `touches` on an applied decision is allowed**, append-only, for a file the applying commit
|
|
120
|
+
really changed within what the Decision says. A change outside it is a finding, not a trace.
|
|
121
|
+
- **Gates get recorded.** `wdi-problem`, `wdi-product`, `wdi-blueprint`, and `wdi-component` end by asking
|
|
122
|
+
the owner whether their gate passed and write `gates_passed` / `g4_passed` only on an explicit yes.
|
|
123
|
+
Skills that need a passed gate read the record and ask when it is missing; `wdi-reconcile` reports
|
|
124
|
+
downstream work whose gate was never recorded. `delivery-flow-guide.md` § *Recording a gate that passed*.
|
|
125
|
+
- **Session papers from outside tools live in `.work/<tool>/<slug>/`**, distilled into `DEC-` / memlog /
|
|
126
|
+
`.control/reports/` and deleted when the session closes. `corpus-guide.md` no longer asks for a `DEC-`
|
|
127
|
+
before scratch is deleted — the two guides disagreed.
|
|
128
|
+
|
|
129
|
+
**What a repo that already has the method installed does about it.** Run
|
|
130
|
+
`npx wdi-method@latest update --yes`, then read the `upgrade` line or `upgrade_pending`. Expect, where
|
|
131
|
+
they apply: cross-component UX sections parked in `design-system.md` (item 15), SRS or landed UX
|
|
132
|
+
documents citing the UX run (item 16), containers whose code lives in another repository (item 17 —
|
|
133
|
+
fill `repo:` there, drop it where it names this repo, and re-run `wdi-init` intent `structure`), and
|
|
134
|
+
landed UX documents with no `landed_from` (item 18). Gate skills now record `gates_passed`; a repo whose
|
|
135
|
+
gates passed before that is asked once per gate by `wdi-upgrade`, and nothing is written without a yes.
|
|
136
|
+
|
|
137
|
+
**`wdi-upgrade`:** needed when `upgrade_pending` lists anything — items 15–18 are new in this version —
|
|
138
|
+
or when `wdi-help` shows a passed gate that was never recorded. Not needed otherwise.
|
|
139
|
+
|
|
140
|
+
---
|
|
141
|
+
|
|
13
142
|
## [0.6.30] - 2026-09-27
|
|
14
143
|
|
|
15
144
|
A patch. No behaviour changes.
|
package/NOTICE
CHANGED
|
@@ -23,6 +23,11 @@ License: MIT (https://github.com/kevva)
|
|
|
23
23
|
|
|
24
24
|
========================================================================
|
|
25
25
|
Upstream Methodology & Skills Architecture
|
|
26
|
-
- BMad Method: Copyright (c) BMad Code
|
|
27
|
-
|
|
26
|
+
- BMad Method: Copyright (c) 2025 BMad Code, LLC, MIT License (https://github.com/bmad-code-org/BMAD-METHOD).
|
|
27
|
+
BMad, BMad Method and BMad Core are trademarks of BMad Code, LLC; WDI Method is not affiliated with
|
|
28
|
+
or endorsed by BMad Code, LLC.
|
|
29
|
+
- mattpocock/skills: Copyright (c) 2026 Matt Pocock, MIT License (https://github.com/mattpocock/skills)
|
|
30
|
+
|
|
31
|
+
WDI Method installs alongside both today. From 0.7.0 (mattpocock/skills) and 0.8.0 (BMad Method) parts of
|
|
32
|
+
the kit are adapted from them; every adapted file names its source and version. See UPSTREAM.md.
|
|
28
33
|
========================================================================
|
package/README.md
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
> A review layer on top of BMad: documents a human reads to check technical decisions before code is written, sized to what the change actually deserves.
|
|
4
4
|
|
|
5
5
|
[English](README.md) | [Bahasa Indonesia](translations/README.id.md) | [简体中文](translations/README.zh-CN.md) | [日本語](translations/README.ja.md) | [한국어](translations/README.ko.md) | [Español](translations/README.es.md) | [Deutsch](translations/README.de.md) | [Français](translations/README.fr.md) | [Português (Brasil)](translations/README.pt-BR.md) | [Русский](translations/README.ru.md)
|
|
6
|
-
[Website](https://wiradelta.com/wdi-method/docs/) | [Changelog](CHANGELOG.md) | [Contributing](CONTRIBUTING.md) | [License](LICENSE) | [Security](SECURITY.md) | [Privacy](PRIVACY.md)
|
|
6
|
+
[Website](https://wiradelta.com/wdi-method/docs/) | [Changelog](CHANGELOG.md) | [Roadmap](ROADMAP.md) | [Contributing](CONTRIBUTING.md) | [License](LICENSE) | [Security](SECURITY.md) | [Privacy](PRIVACY.md)
|
|
7
7
|
|
|
8
8
|
---
|
|
9
9
|
|
|
@@ -38,7 +38,7 @@ A document behind the code is in its expected state, not a defect. Where the own
|
|
|
38
38
|
- Node.js 20 or later.
|
|
39
39
|
- Git.
|
|
40
40
|
- [uv](https://docs.astral.sh/uv/), which runs the method's Python 3.11+ validators.
|
|
41
|
-
- An agent
|
|
41
|
+
- An agent host: any of the hosts `npx wdi-method --list-agents` prints — Claude Code, Kiro, Cursor, Codex, OpenCode, Gemini CLI, GitHub Copilot, and more.
|
|
42
42
|
|
|
43
43
|
Run the three steps in order. The installer stops if step 1 or step 2 has not been done. All prompts offer defaults; pressing <kbd>Enter</kbd> accepts them.
|
|
44
44
|
|
|
@@ -53,7 +53,7 @@ Install the engines into your repository (choose either "copy" or "symlink"):
|
|
|
53
53
|
```bash
|
|
54
54
|
npx skills@latest add mattpocock/skills
|
|
55
55
|
```
|
|
56
|
-
*Select all six engines the method drives:* `to-spec`, `to-tickets`, `implement`, `tdd`, `code-review`, and `domain-modeling`.
|
|
56
|
+
*Select all six engines the method drives:* `to-spec`, `to-tickets`, `implement`, `tdd`, `code-review`, and `domain-modeling`, and every agent host you will use. Each host must be able to read them — Kiro, for one, reads only `.kiro/skills` — and when one cannot, the installer stops and prints the `npx skills add … --agent <id>` for that host.
|
|
57
57
|
|
|
58
58
|
> **Why the Claude Code Plugin Is Not Enough:** Three of the six engines (`to-spec`, `to-tickets`, `implement`) ship with `disable-model-invocation: true`. On every install and update, WDI Method removes that line from the copies in your repo, so `wdi-build` and `wdi-autopilot` can run them. It cannot edit a user-level plugin, so the installer stops until the engines are in the repo. `--skip-engines-check` skips this check.
|
|
59
59
|
|
|
@@ -64,14 +64,19 @@ npx wdi-method
|
|
|
64
64
|
```
|
|
65
65
|
*(Non-interactive: `npx wdi-method install --yes --agents claude-code --product "Your Product"`)*
|
|
66
66
|
|
|
67
|
-
> **What the installer changes in BMad:** The installer also turns off model invocation for 13 BMad build and sprint skills that the engines replace, and
|
|
67
|
+
> **What the installer changes in BMad:** The installer also turns off model invocation for 13 BMad build and sprint skills that the engines replace, and, on hosts that have a lock, adds one (`.claude/settings.json` deny rules for Claude Code, `"ask"` in `opencode.json` for OpenCode). On every host, the method block it writes into `AGENTS.md` and each host's own rule file forbids them. You can still run them by typing the command.
|
|
68
|
+
|
|
69
|
+
> **Every host works the same way:** the method records what each selected host can do in `.control/wdi-method.yaml` (`hosts:`) — where it reads skills, how you type one, whether it can hold a skill to manual-only, and whether it has a scheduler of its own. Skills read that record instead of assuming Claude Code.
|
|
68
70
|
|
|
69
71
|
### Your First Command: `/wdi-help`
|
|
70
72
|
Inside your coding agent, run:
|
|
71
73
|
```text
|
|
72
74
|
/wdi-help
|
|
73
75
|
```
|
|
74
|
-
`wdi-help` reads `.control/registry/` and tells you the gate your project is at, the open specs, and the next skill, without guessing from the conversation.
|
|
76
|
+
`wdi-help` reads `.control/registry/` and tells you the gate your project is at, the open specs, and the next skill, without guessing from the conversation. Most hosts take `/wdi-help`; Codex takes `$wdi-help`, Kimi Code and Pi take `/skill:wdi-help`, and Windsurf takes `@wdi-help`. `wdi-help` names the next skill in your host's form.
|
|
77
|
+
|
|
78
|
+
### Updating Later: Do I Need `/wdi-upgrade`?
|
|
79
|
+
You never have to work it out from the version number. `npx wdi-method@latest update` checks your repo's content for anything still in an older shape and writes what it found into `upgrade_pending` in `.control/wdi-method.yaml` — absent means nothing is owed. `/wdi-help` reads that field and tells you to run `/wdi-upgrade` first when it is there. `npx wdi-method upgrade-check` re-checks at any time. Every [`CHANGELOG.md`](CHANGELOG.md) entry also ends with a `wdi-upgrade: needed / not needed` line.
|
|
75
80
|
|
|
76
81
|
---
|
|
77
82
|
|
|
@@ -108,7 +113,7 @@ Once the architecture is in place, everyday work runs as a daily rhythm through
|
|
|
108
113
|
1. **`/wdi-daily-what-to-build [reviewer] <notes>`**
|
|
109
114
|
Turns hand-testing notes, QA observations, or bug reports into a reviewed spec or ticket on the development branch, for a later autopilot run. It stops there: it never commits, pushes, or starts the autopilot.
|
|
110
115
|
2. **`/wdi-daily-autopilot [self-review] [peer] [interval] [--skip-peer-review]`**
|
|
111
|
-
Checks for an accepted mandate and runs the preflight if there is none, resolves reviewers from local config, and starts the loop (default `/loop 10m /wdi-autopilot`). The loop works on branch `autopilot/<mandate-id>`, writes the code test-first, records every decision in its ledger, and ends with one PR ready for review. The owner merges.
|
|
116
|
+
Checks for an accepted mandate and runs the preflight if there is none, resolves reviewers from local config, and starts the loop on the host's own scheduler (every 10 minutes by default — `/loop 10m /wdi-autopilot` on Claude Code). On a host without a scheduler it runs one iteration each time you type it. The loop works on branch `autopilot/<mandate-id>`, writes the code test-first, records every decision in its ledger, and ends with one PR ready for review. The owner merges.
|
|
112
117
|
3. **`/wdi-daily-what-to-test [web <target> | mobile <target> | desktop]`**
|
|
113
118
|
After a merge: syncs the development branch, prunes merged branches and worktrees, prepares the app for hand-testing, and builds a checklist from the tickets closed since the last sync (`before_sync..HEAD`). With no argument it only syncs, prunes, and builds the checklist.
|
|
114
119
|
4. **`/wdi-prune-or-archive [--spec <id> | --all-closed] [--archive | --prune] [--dry-run]`**
|
|
@@ -158,11 +163,11 @@ A runner named as a reviewer MUST be read-only. The read-only flag per CLI: `cla
|
|
|
158
163
|
WDI Method installs 22 skills: 7 gate skills, 5 for the daily tier (including `wdi-autopilot`), and 10 you run any time.
|
|
159
164
|
|
|
160
165
|
How a skill starts:
|
|
161
|
-
- **You type it**: the four daily tier skills and `wdi-explain-to-me` (they carry `disable-model-invocation: true`).
|
|
162
|
-
- **You type it, or `wdi-autopilot` runs it under an accepted mandate**: `wdi-build`. It carries no `disable-model-invocation` flag, because `wdi-autopilot` has to invoke it; the rule that agents do not start it on their own is in the Method policy the installer writes into `
|
|
166
|
+
- **You type it**: the four daily tier skills and `wdi-explain-to-me` (they carry `disable-model-invocation: true` for the hosts that honour it, and a guard line plus an `AGENTS.md` rule for the hosts that do not).
|
|
167
|
+
- **You type it, or `wdi-autopilot` runs it under an accepted mandate**: `wdi-build`. It carries no `disable-model-invocation` flag, because `wdi-autopilot` has to invoke it; the rule that agents do not start it on their own is in the Method policy the installer writes into `AGENTS.md` and every rule file a selected host reads.
|
|
163
168
|
- **You type it, or the agent names it and waits for your go-ahead**: the other skills.
|
|
164
169
|
- **The agent may run it on its own (read-only)**: `wdi-help`.
|
|
165
|
-
- **Fired by
|
|
170
|
+
- **Fired by the host's scheduler under an accepted mandate, or once per invocation where the host has none**: `wdi-autopilot`. Under a mandate, `wdi-autopilot` also runs the other skills.
|
|
166
171
|
|
|
167
172
|
| Skill | What It Does | How It Starts |
|
|
168
173
|
|---|---|---|
|
|
@@ -176,8 +181,8 @@ How a skill starts:
|
|
|
176
181
|
| `/wdi-build` | G5. One spec from open to closed: you run `to-spec` and `to-tickets`, each ticket goes to a green PR, then the spec closes. It never merges. | You type it, or `wdi-autopilot` runs it |
|
|
177
182
|
| **Daily tier** | | |
|
|
178
183
|
| `/wdi-daily-what-to-build` | Turns hand-testing notes into a reviewed spec or ticket for a later autopilot run. Stops before code, commit, or push. | You type it |
|
|
179
|
-
| `/wdi-daily-autopilot` | Checks for an accepted mandate (runs the preflight if there is none), resolves reviewers from local config, and starts the loop, every 10 minutes by default. | You type it |
|
|
180
|
-
| `/wdi-autopilot` | The loop itself: works through every FR under one accepted mandate, on one branch with one PR, and writes every decision to one ledger. | Fired by
|
|
184
|
+
| `/wdi-daily-autopilot` | Checks for an accepted mandate (runs the preflight if there is none), resolves reviewers from local config, and starts the loop on the host's own scheduler, every 10 minutes by default — or runs one iteration where the host has none. | You type it |
|
|
185
|
+
| `/wdi-autopilot` | The loop itself: works through every FR under one accepted mandate, on one branch with one PR, and writes every decision to one ledger. | Fired by the host's scheduler (or once per invocation) under an accepted mandate |
|
|
181
186
|
| `/wdi-daily-what-to-test` | After a merge: syncs the development branch, prunes merged branches and worktrees, prepares the app for hand-testing, and builds a checklist from the closed tickets. | You type it |
|
|
182
187
|
| `/wdi-prune-or-archive` | Moves closed specs to `.archive/specs/` or removes them with `git rm`, through `lifecycle.py`, which checks first and rolls back on failure. The spec row stays in `specs.yaml`. | You type it |
|
|
183
188
|
| **Any time** | | |
|