task-pipeline-skill 0.12.0 → 1.0.0
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 +477 -0
- package/LICENSE +47 -0
- package/README.md +369 -171
- package/cursor/rules/task-pipeline.mdc +125 -20
- package/package.json +8 -4
- package/plugins/task-pipeline/.claude-plugin/plugin.json +15 -4
- package/plugins/task-pipeline/commands/task-pipeline.md +20 -8
- package/plugins/task-pipeline/skills/task-pipeline/SKILL.md +112 -39
- package/plugins/task-pipeline/skills/task-pipeline/pipeline.example.json +35 -16
- package/plugins/task-pipeline/skills/task-pipeline/references/acceptance.md +119 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/artifacts.md +47 -14
- package/plugins/task-pipeline/skills/task-pipeline/references/brainstorm.md +108 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/build.md +365 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/companion-skills.md +72 -31
- package/plugins/task-pipeline/skills/task-pipeline/references/conventions.md +27 -3
- package/plugins/task-pipeline/skills/task-pipeline/references/decomposition.md +139 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/grill.md +78 -7
- package/plugins/task-pipeline/skills/task-pipeline/references/knowledge-sources.md +159 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/loop-guard.md +100 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/planning.md +195 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/review.md +174 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/spec.md +144 -0
- package/plugins/task-pipeline/skills/task-pipeline/references/stages.md +190 -35
- package/plugins/task-pipeline/skills/task-pipeline/references/tdd.md +110 -0
- package/plugins/task-pipeline/skills/task-pipeline/templates/README.md +5 -3
- package/plugins/task-pipeline/skills/task-pipeline/templates/brief.md +50 -2
- package/plugins/task-pipeline/skills/task-pipeline/templates/carryover.md +36 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,482 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## v1.0.0 — 2026-07-28
|
|
4
|
+
|
|
5
|
+
**1.0.** Eighteen releases in ten days added a stage, a requirement spine, a
|
|
6
|
+
decomposition pass and a loop guard; this one adds nothing and instead makes the
|
|
7
|
+
whole thing coherent enough to depend on. Every file was read against every other
|
|
8
|
+
file, the contradictions between them are fixed, and the repo now carries the
|
|
9
|
+
surface a stranger needs before they trust it.
|
|
10
|
+
|
|
11
|
+
What 1.0 promises: the stage flow (0 intake + 1→10), `pipeline.schema.json`, the
|
|
12
|
+
artifact layout in `references/artifacts.md`, and the two install paths are stable.
|
|
13
|
+
Breaking any of them means a 2.0.
|
|
14
|
+
|
|
15
|
+
### Fixed — contradictions between doctrine files
|
|
16
|
+
- **Two names for one idea.** `brainstorm.md` told the agent to split an oversized
|
|
17
|
+
task into "sub-projects", each with its own spec→plan→build cycle;
|
|
18
|
+
`decomposition.md` — the file that actually owns the procedure — calls them
|
|
19
|
+
**modules**, cuts them at the end of stage 2, and runs stages 3→10 per module
|
|
20
|
+
against a committed module map. An agent that read the first file ran a
|
|
21
|
+
decomposition the second file's gate could not check. Brainstorm now hands off to
|
|
22
|
+
`decomposition.md` by name.
|
|
23
|
+
- **The same split, invented twice.** `planning.md` independently told stage 4 to
|
|
24
|
+
"split the spec into one plan per subsystem" — a second, unrecorded decomposition
|
|
25
|
+
two stages after the one with the gate and the map. A plan now covers exactly one
|
|
26
|
+
spec; a multi-subsystem spec arriving at stage 4 is a missed stage-2
|
|
27
|
+
decomposition and goes back there.
|
|
28
|
+
- **A hardcoded `main`.** `build.md` and `review.md` both built the final
|
|
29
|
+
whole-branch review package with `git merge-base main HEAD`, in a pipeline whose
|
|
30
|
+
stage-0 brief records the base branch precisely because it is not always `main`.
|
|
31
|
+
On any repo with a `master`, a `develop` or a stacked base, the final review saw
|
|
32
|
+
the wrong diff. Both now read the brief's base.
|
|
33
|
+
- **A five-status set that claimed to have four.** `acceptance.md` listed four
|
|
34
|
+
statuses, declared "there is no fifth status", then named `unknown` in the next
|
|
35
|
+
clause. Reworded so the mechanism is legible: four ways to close, and anything
|
|
36
|
+
that fits none of them is `unknown`, which fails the gate.
|
|
37
|
+
- **A version pin on someone else's contract.** The README and `stages.md` both
|
|
38
|
+
pinned super-ux's scenario format at "ux-contract v4" — the exact cross-repo
|
|
39
|
+
version skew this project ported its own doctrine in-house to avoid. Both now
|
|
40
|
+
point at the contract super-ux itself ships, with no version named here.
|
|
41
|
+
- **A blockquote where a sentence should be.** In `knowledge-sources.md` the
|
|
42
|
+
precedence chain `code > host docs and ADRs > the wiki > memory` wrapped so the
|
|
43
|
+
second line *began* with `>`, which Markdown renders as a block quote —
|
|
44
|
+
the rule about which source wins was visually broken in the file that defines it.
|
|
45
|
+
- **`skills[]` entries that resolve to nothing.** `pipeline.example.json` names
|
|
46
|
+
`task-pipeline:grill` and `host:lint` beside real skills, with no key anywhere for
|
|
47
|
+
the two prefixes. A host copying the example had no way to tell a notional label
|
|
48
|
+
from an installable skill. The convention is now stated in the config and in
|
|
49
|
+
`SKILL.md`: `task-pipeline:<name>` is this skill's own `references/<name>.md`,
|
|
50
|
+
`host:<name>` is the host project's command per `conventions.md`, everything else
|
|
51
|
+
is a real skill. Stage 3 also gained the `/ux` entry point and `/ux-lint`, which
|
|
52
|
+
the doctrine mandates and the config had omitted.
|
|
53
|
+
- **A repo tree that had drifted.** `references/artifacts.md`'s map of this
|
|
54
|
+
repository listed `templates/` outside the tree and missed several files.
|
|
55
|
+
- A broken ordered list in the Cursor rule (`3a.` is not a list marker) and a
|
|
56
|
+
`references/` index in `SKILL.md` that never mentioned `templates/`.
|
|
57
|
+
|
|
58
|
+
### Added — the open-source surface
|
|
59
|
+
- `CONTRIBUTING.md` — dev setup, the repository layout, and **the nine invariants**
|
|
60
|
+
written out with the failure each one prevents: four-way version sync, the stage
|
|
61
|
+
list living on three machine-checked surfaces, every human-facing description
|
|
62
|
+
having to name the flow's final stage last, no hardcoded vendor model ids, no
|
|
63
|
+
unreachable reference file, no external provider in the default flow, stage 0 and
|
|
64
|
+
stage 10 staying manual, the frontmatter budget, and resolving links.
|
|
65
|
+
- `SECURITY.md` — what the executable surface actually is (two installers, a
|
|
66
|
+
validator, two workflows), private reporting with a 72-hour acknowledgement, and
|
|
67
|
+
an explicit scope: doctrine that would lead an agent to exfiltrate secrets, push
|
|
68
|
+
to an unnamed repo or deploy without a go **is** a security bug here.
|
|
69
|
+
- `CODE_OF_CONDUCT.md`, GitHub issue forms (bug / doctrine change, with routing to
|
|
70
|
+
super-ux and obsidian-wiki), and a pull-request template whose checklist is the
|
|
71
|
+
list of surfaces that drift.
|
|
72
|
+
- `CLAUDE.md` — house rules for any agent working in this repo, which is also what
|
|
73
|
+
this pipeline's own stage-0 harvest reads first: the commands, the branch and
|
|
74
|
+
commit policy, the invariants, and the docs that must be updated in the same
|
|
75
|
+
change. The project now dogfoods the convention it asks of every host.
|
|
76
|
+
- **Two validator guards, each with a CI negative self-test:** the open-source root
|
|
77
|
+
files must exist, and `npm test` must actually run the validator. A documented
|
|
78
|
+
check nobody can run is a check nobody runs.
|
|
79
|
+
|
|
80
|
+
### Changed
|
|
81
|
+
- **README rewritten.** Same substance, ordered so it can be read: a one-paragraph
|
|
82
|
+
statement of the problem, a Mermaid diagram of the flow with gate types coloured,
|
|
83
|
+
the gate table, *what you get*, then a quickstart — before the deep sections.
|
|
84
|
+
Configuration, install/update and a documentation map now live in their own
|
|
85
|
+
places instead of interleaved with doctrine.
|
|
86
|
+
- Package, marketplace and plugin descriptions rewritten — shorter, and all three
|
|
87
|
+
now say the same thing about the same ten stages.
|
|
88
|
+
- npm metadata: a `test` script (`npm test`), a `bugs` URL, `homepage` at the README.
|
|
89
|
+
- `.worktrees/` is git-ignored — stage 5 creates them.
|
|
90
|
+
|
|
91
|
+
> The open-source surface above shipped in v0.18.1, hours earlier the same day;
|
|
92
|
+
> it is restated here because it is part of what 1.0 means.
|
|
93
|
+
|
|
94
|
+
## v0.18.1 — 2026-07-28
|
|
95
|
+
|
|
96
|
+
Open-source hygiene pass — the repo is public, so the files a first-time
|
|
97
|
+
contributor looks for now exist, and the validator keeps them there.
|
|
98
|
+
|
|
99
|
+
### Added
|
|
100
|
+
- `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, issue forms and a
|
|
101
|
+
pull-request template.
|
|
102
|
+
- `CLAUDE.md` — house rules for any agent working in this repo: the commands, the
|
|
103
|
+
branch and commit policy, and the invariants that drift most often.
|
|
104
|
+
- The validator now requires the open-source root files, with a CI negative
|
|
105
|
+
self-test that deletes `CONTRIBUTING.md` and proves the check fails.
|
|
106
|
+
|
|
107
|
+
### Changed
|
|
108
|
+
- npm metadata: a `test` script, a `bugs` URL, and `homepage` pointing at the
|
|
109
|
+
README. Package, marketplace and plugin descriptions rewritten so all three say
|
|
110
|
+
the same thing about the ten stages.
|
|
111
|
+
- `.worktrees/` is ignored — the pipeline creates them during stage 5.
|
|
112
|
+
|
|
113
|
+
## v0.18.0 — 2026-07-28
|
|
114
|
+
|
|
115
|
+
The grill stops opening cold. Stage 0 now reads what the project already knows
|
|
116
|
+
about the task **before** the first question, checks every answer against it, and
|
|
117
|
+
stage 9 updates the same list at the end — the loop the pipeline was missing.
|
|
118
|
+
|
|
119
|
+
### Added
|
|
120
|
+
- **Stage 0 phase 1: the knowledge harvest** (`references/knowledge-sources.md`).
|
|
121
|
+
Before question one, query what the project already knows about *this* task —
|
|
122
|
+
the code, `CLAUDE.md`/`AGENTS.md`, `CONTEXT.md` + `docs/adr/`, `docs/` and
|
|
123
|
+
`docs/ux/`, previous pipeline briefs and their carry-over ledgers, **the
|
|
124
|
+
knowledge wiki when one is installed**, and **any other repository or hosted doc
|
|
125
|
+
system the project names as its docs**. It is retrieval scoped by the task's own
|
|
126
|
+
nouns, not a read of everything: query, follow one hop, stop when the terms
|
|
127
|
+
return nothing new. Nothing is ever fetched on a guess — a doc repo is in scope
|
|
128
|
+
because the project names it.
|
|
129
|
+
- **The source ledger** — a required `## Knowledge sources` section in the brief
|
|
130
|
+
(source, what it says about this task, freshness, authority, "stale after this
|
|
131
|
+
run?"). `none found` is a valid, useful row: it tells the next run the search
|
|
132
|
+
happened and came back empty. Silence doesn't.
|
|
133
|
+
- **Answers are validated against the harvest** (`grill.md` → *Domain awareness*).
|
|
134
|
+
The cheap win is not re-asking what an ADR already answers. The one that matters:
|
|
135
|
+
**an answer nobody can check is a recollection** — people answer from memory
|
|
136
|
+
about systems they wrote a year ago, and a false premise adopted at stage 0 makes
|
|
137
|
+
every later gate pass honestly on it. So the grill quotes the source instead:
|
|
138
|
+
*"the March ADR says X, you just described Y — has it changed?"* The operator
|
|
139
|
+
**outranks every document, but only out loud** — an override quoted against its
|
|
140
|
+
source is a recorded decision, an unquoted one is an undetected divergence.
|
|
141
|
+
Precedence when sources disagree: **code > host docs/ADRs > wiki > memory.**
|
|
142
|
+
- **obsidian-wiki is the recommended knowledge base**
|
|
143
|
+
(https://github.com/ar9av/obsidian-wiki — Karpathy's LLM-wiki pattern), detected
|
|
144
|
+
via `~/.obsidian-wiki/config` or a resolving `wiki-query`/`wiki-update`.
|
|
145
|
+
Installed → queried in the harvest, synced with `wiki-update` at stage 9. Absent
|
|
146
|
+
→ the preflight prints `pip install obsidian-wiki` / `obsidian-wiki setup --vault
|
|
147
|
+
<path>` **once** and the run continues. A recommendation, never a gate; a project
|
|
148
|
+
whose `CLAUDE.md` names a different knowledge base wins.
|
|
149
|
+
- **Stage 9 closes the loop:** the stage-0 ledger *is* its work list. Every source
|
|
150
|
+
the harvest read gets updated if this run changed or disproved it — including the
|
|
151
|
+
docs the grill already proved stale, which is why those conflicts are logged in
|
|
152
|
+
phase 2 instead of only being settled out loud. Docs living in **another
|
|
153
|
+
repository** are outward: propose the edit and get an explicit go, or carry it
|
|
154
|
+
over with the exact change written down. Never a direct push to a repo the task
|
|
155
|
+
didn't name.
|
|
156
|
+
- **Autonomy-sweep row** for doc sources beyond this repo, and whether stage 9 may
|
|
157
|
+
write to them — decided at intake, like every other outward action.
|
|
158
|
+
- **Three validator guards, each with a CI negative self-test:** the brief template
|
|
159
|
+
must keep its `## Knowledge sources` section; the stage-0 gate must require the
|
|
160
|
+
harvest *and* its ledger before the interview; the stage-9 gate must name that
|
|
161
|
+
ledger as its work list. A harvest with nowhere to land degrades silently back
|
|
162
|
+
into asking from memory, which is precisely the failure it exists to stop.
|
|
163
|
+
|
|
164
|
+
## v0.17.1 — 2026-07-28
|
|
165
|
+
|
|
166
|
+
A full-repo consistency audit. v0.16.0 added a third review verdict and a tenth
|
|
167
|
+
stage; several surfaces never heard about either. An agent reads one surface, not
|
|
168
|
+
all of them, so a stage that is `three verdicts` in the config and `both verdicts`
|
|
169
|
+
in the prompt that actually runs simply produces two.
|
|
170
|
+
|
|
171
|
+
### Fixed
|
|
172
|
+
- **The third review verdict now exists where reviews are actually dispatched.**
|
|
173
|
+
`references/review.md`'s task-review prompt asked for *"two verdicts"* — so the
|
|
174
|
+
REQ-satisfaction verdict the stage-5 gate requires was never returned. It now asks
|
|
175
|
+
for three (spec compliance → **REQ satisfied** → code quality), with the REQ one
|
|
176
|
+
judged against the requirement's quoted statement rather than the task's
|
|
177
|
+
instructions. Same correction in `build.md` (§4.4 and its gate), `planning.md`'s
|
|
178
|
+
plan header, `stages.md` and the Cursor rule.
|
|
179
|
+
- **Stage-5's gate now names the ledger harvest.** `build.md`'s gate omitted
|
|
180
|
+
"every parked finding and implementer concern harvested into the carry-over
|
|
181
|
+
ledger" — the one thing that must happen before the scratch workspace is deleted.
|
|
182
|
+
- **Three gates in the doctrine files were weaker than the same gates in
|
|
183
|
+
`stages.md`:** `planning.md` didn't state the REQ **set-equality** check (the
|
|
184
|
+
brief→plan seam), `spec.md` didn't require `covers: REQ-…` per section, and
|
|
185
|
+
`brainstorm.md` didn't require every REQ answered by the design or the module map
|
|
186
|
+
approved for a platform. All three now match.
|
|
187
|
+
- **Descriptions listed the flow wrong.** npm, the marketplace entry, the plugin
|
|
188
|
+
manifest: `…post-deploy, acceptance, docs/wiki` — eleven items for ten stages,
|
|
189
|
+
with the final stage listed second-to-last. The `/task-pipeline` command's
|
|
190
|
+
description and `SKILL.md`'s frontmatter stopped at docs/wiki and never named
|
|
191
|
+
acceptance at all.
|
|
192
|
+
- **Built-in doctrine tables were missing rows** for stage 10 acceptance
|
|
193
|
+
(`SKILL.md`, `README.md`, `companion-skills.md`), stage-2 decomposition and the
|
|
194
|
+
loop guard (`README.md`, `companion-skills.md`) — files that ship, are reachable,
|
|
195
|
+
and were absent from the very tables that say what ships.
|
|
196
|
+
- Smaller drift: the Cursor rule's stage 9 dropped the wiki sync; four gate checks
|
|
197
|
+
in `pipeline.example.json` had v0.16.0 sentences concatenated without punctuation;
|
|
198
|
+
`stages.md` wrote `implements:` where the plan format writes `Implements:`;
|
|
199
|
+
`artifacts.md` had the acceptance artifact listed before the spec and the ledger
|
|
200
|
+
attributed to stages `0→9`; the v0.1.0 design snapshot's disclaimer still
|
|
201
|
+
described the live shape as nine stages.
|
|
202
|
+
|
|
203
|
+
### Added
|
|
204
|
+
- **Three validator guards, each with a CI negative self-test**, so this class of
|
|
205
|
+
drift fails instead of shipping:
|
|
206
|
+
1. every human-facing description (npm, marketplace, plugin, `SKILL.md`, the
|
|
207
|
+
command, the Cursor rule, `README.md`) must name the flow's **final stage**,
|
|
208
|
+
and must not list it before the stage it runs after — derived from
|
|
209
|
+
`pipeline.example.json`, not hardcoded;
|
|
210
|
+
2. no shipped surface may say *two/both verdicts* while the dev gate declares
|
|
211
|
+
three;
|
|
212
|
+
3. each stage doctrine file's own `GATE (auto|manual)` must match that stage's
|
|
213
|
+
gate type in the config.
|
|
214
|
+
|
|
215
|
+
## v0.17.0 — 2026-07-28
|
|
216
|
+
|
|
217
|
+
Two mechanisms stop being files nobody walks and become operational doctrine: a
|
|
218
|
+
platform is cut into bricks before it is specced, and a loop that starts undoing
|
|
219
|
+
itself is broken instead of endured.
|
|
220
|
+
|
|
221
|
+
### Added
|
|
222
|
+
- **Decomposition is stage 2's second half**, wired end to end —
|
|
223
|
+
`references/decomposition.md` now reached from `SKILL.md`'s doctrine table, the
|
|
224
|
+
stage-2 gate in `stages.md`, the example config, the Cursor rule, the command and
|
|
225
|
+
the README. A brief that describes a *platform* — several independent
|
|
226
|
+
capabilities, several separately shippable surfaces, REQs no single deliverable
|
|
227
|
+
satisfies — is cut into **modules** before any spec exists: by capability, never
|
|
228
|
+
by layer, and a candidate is a brick only when it is independently specifiable,
|
|
229
|
+
buildable and testable, owns its entities, talks through declared contracts only,
|
|
230
|
+
and can land while leaving the system working. The module map carries build order
|
|
231
|
+
— **walking skeleton first**, then topological, no cycles — with every REQ mapped
|
|
232
|
+
to exactly one module. Single-module work records `single module: <name>`: a
|
|
233
|
+
skipped decomposition is a decision, never an omission.
|
|
234
|
+
- **The module dossier** (`spec.md`): for a decomposed platform the spec has nine
|
|
235
|
+
required sections — purpose and boundary, architecture, entities and ownership,
|
|
236
|
+
contracts in and out **with their behavior when the other side is down**,
|
|
237
|
+
business rules in the domain's language, edge and failure cases, UI/Figma chain,
|
|
238
|
+
non-functional limits, and open questions with a decide-by moment. A skipped
|
|
239
|
+
section says why in one line; silence is not a skip.
|
|
240
|
+
- **The loop guard binds every repeating loop** — `references/loop-guard.md` is now
|
|
241
|
+
referenced from `SKILL.md`'s cross-cutting rules, a `stages.md` section, the
|
|
242
|
+
stage-5 fix loop, the Cursor rule and the command. Every repeating pass logs one
|
|
243
|
+
line per touched file with the reason that forced it ("cleanup" is not a reason).
|
|
244
|
+
It trips on revert-oscillation, a file edited twice for the same reason, a
|
|
245
|
+
resurrected finding, a third entry into one stage, or two loops editing one file,
|
|
246
|
+
plus hard caps (5 fix rounds per task, 2 re-entries per stage, 3 passes per
|
|
247
|
+
module). On a trip: stop editing, name shape A and shape B with their evidence,
|
|
248
|
+
escalate to the layer that owns the conflict, re-plan the check as an ordered
|
|
249
|
+
checklist with one verification command per item, then go through it one at a
|
|
250
|
+
time. **A higher-layer conflict is never settled inside a lower loop.**
|
|
251
|
+
- **Two autonomy-sweep rows** (grill + brief template): platform-or-single-module
|
|
252
|
+
with the deploy cadence it implies, and who signs off acceptance plus where
|
|
253
|
+
deferred REQs are tracked.
|
|
254
|
+
- **`conventions.md` gains the issue tracker** stage 10 needs — read the host's
|
|
255
|
+
convention, never invent a tracker, never close a run on "we'll remember it".
|
|
256
|
+
- `artifacts.md` gains the module map and the run-level ledger
|
|
257
|
+
(`.task-pipeline/run.md`) the loop guard writes to.
|
|
258
|
+
|
|
259
|
+
### Tests
|
|
260
|
+
- **The stage list is cross-checked across all three surfaces it is published on** —
|
|
261
|
+
`SKILL.md`'s table, `references/stages.md` and `pipeline.example.json`: identical
|
|
262
|
+
ids in identical order, matching names, matching gate types, and every stage in
|
|
263
|
+
`stages.md` carrying a `**GATE (auto|manual)**` line. Drift between surfaces is
|
|
264
|
+
invisible in review and lethal at runtime — a stage manual on one surface and auto
|
|
265
|
+
on another.
|
|
266
|
+
- `decomposition.md` and `loop-guard.md` join the stub-rejected doctrine set.
|
|
267
|
+
- Three negative self-tests against a mutated copy: a flipped gate type, a removed
|
|
268
|
+
GATE line and a deleted doctrine file each fail the validator.
|
|
269
|
+
|
|
270
|
+
## v0.16.1 — 2026-07-28
|
|
271
|
+
|
|
272
|
+
### Fixed
|
|
273
|
+
- **v0.16.0 added a tenth stage and left "1→9" in fifteen places** — the skill
|
|
274
|
+
description, the command, the Cursor rule, `stages.md`, `grill.md`, the brief
|
|
275
|
+
template, the example config and the README all still promised nine. The
|
|
276
|
+
package, marketplace and plugin descriptions said "9 gated stages" too, which
|
|
277
|
+
is what npm and the marketplace show. All re-synced to ten, and the plan
|
|
278
|
+
filename now uses the same slug as the brief and the spec.
|
|
279
|
+
|
|
280
|
+
## v0.16.0 — 2026-07-28
|
|
281
|
+
|
|
282
|
+
Scope stops leaking. The request becomes an addressable list of requirements, the
|
|
283
|
+
ids are traced through every stage, and a new final stage accounts for all of them.
|
|
284
|
+
|
|
285
|
+
The failure this fixes: every gate up to now asked *"is this artifact good?"* and
|
|
286
|
+
none asked *"does this still contain everything that was asked for?"* Scope doesn't
|
|
287
|
+
leak inside a stage — it leaks on the **seams**, because brief → spec → plan → task
|
|
288
|
+
briefs is four rewrites by a model and nothing compared the lists.
|
|
289
|
+
|
|
290
|
+
### Added
|
|
291
|
+
- **The REQ spine.** The grill's second hard output is a requirement table in the
|
|
292
|
+
brief — one row per *independently verifiable* deliverable, each naming **how it
|
|
293
|
+
is verified** (test name, `file:line`, command + expected output, scenario id). A
|
|
294
|
+
requirement you can't say how to verify is a badly-stated requirement, and gets
|
|
295
|
+
split during the grill rather than discovered at the end. One REQ = one
|
|
296
|
+
deliverable, not one per sentence: an inflated table is ignored, and an ignored
|
|
297
|
+
table protects nothing.
|
|
298
|
+
- **Traceability through the run.** Spec sections carry `covers: REQ-…`; plan tasks
|
|
299
|
+
carry `Implements: REQ-…`; the implementer's task brief quotes the requirement
|
|
300
|
+
statement **verbatim**, so it optimises the requirement and not just the
|
|
301
|
+
instruction; the review rubric gains a verdict beside spec-compliance and
|
|
302
|
+
code-quality — **does this satisfy its REQ?**
|
|
303
|
+
- **Stage 10 — Acceptance** (`references/acceptance.md`, manual gate). Closes the
|
|
304
|
+
circle: every REQ gets `verified` / `partial` / `deferred` / `dropped`, written to
|
|
305
|
+
`specs/<topic>-acceptance.md`. `verified` **requires evidence** — a passing test
|
|
306
|
+
name, a `file:line`, a command and its output. "Done" without evidence is
|
|
307
|
+
downgraded to `partial`, never upgraded. Then the operator is asked the closing
|
|
308
|
+
question out loud, list in hand: *here's what you asked for, here's what shipped,
|
|
309
|
+
here's what's deferred and where it lives — what's missing?* Asked even when the
|
|
310
|
+
table is green. Manual by design: an automated check can prove the table is
|
|
311
|
+
well-formed; only the person who asked can confirm it is what they asked for.
|
|
312
|
+
- **The carry-over ledger** (`templates/carryover.md`) — append-only, seeded at
|
|
313
|
+
stage 0, written by every stage, read in full at stage 10. Implementer concerns
|
|
314
|
+
and parked review findings are harvested into it before the scratch workspace is
|
|
315
|
+
deleted. The rule: **deferred out loud is forgotten** — a row with no home
|
|
316
|
+
(issue, backlog, or an agreed `dropped`) blocks the acceptance gate.
|
|
317
|
+
|
|
318
|
+
### Changed
|
|
319
|
+
- **The brief→plan seam is now mechanical.** Stage 4's gate is **set equality**
|
|
320
|
+
between the brief's REQ ids and the union of `Implements:` across plan tasks. A
|
|
321
|
+
non-empty difference fails the gate and is reported as the explicit list of
|
|
322
|
+
dropped requirements — a comparison, not a judgement call.
|
|
323
|
+
- **No silent narrowing.** The REQ list is frozen once confirmed: adding mid-run is
|
|
324
|
+
free, **removing or narrowing needs the operator's explicit agreement**, recorded
|
|
325
|
+
in the ledger. Quietly restating the task smaller is the subtlest loss, because
|
|
326
|
+
every later gate then passes honestly on a task that shrank without anyone
|
|
327
|
+
deciding it should.
|
|
328
|
+
- **Gates tightened** — stage 0 requires the REQ table and a seeded ledger; stage 2
|
|
329
|
+
requires the design to answer every REQ (or an operator-agreed drop); stage 3
|
|
330
|
+
requires `covers:` on every section; stage 5 harvests concerns into the ledger;
|
|
331
|
+
**stage 7 refuses to deploy while any REQ is still `open`** (a `partial` ships only
|
|
332
|
+
with explicit acceptance — a gap is cheapest to close before it ships).
|
|
333
|
+
|
|
334
|
+
### Fixed
|
|
335
|
+
- **`decomposition.md` and `loop-guard.md` shipped unreachable.** Both linked only
|
|
336
|
+
to each other; nothing in `SKILL.md` pointed at either, so under progressive
|
|
337
|
+
disclosure an agent would never load them — two contracts that existed, passed
|
|
338
|
+
every check, and were dead context. Wired into the doctrine table (stage 2 for
|
|
339
|
+
decomposition, cross-cutting for the loop guard), and the validator now walks the
|
|
340
|
+
link graph from `SKILL.md` and fails on any reference nothing reaches.
|
|
341
|
+
|
|
342
|
+
### Tests
|
|
343
|
+
- `references/acceptance.md` joins the built-in doctrine set (stub-rejected);
|
|
344
|
+
`templates/carryover.md` required; the brief template must carry
|
|
345
|
+
`## Requirements`, a `REQ-NNN` row and the verification column; the shipped flow's
|
|
346
|
+
last stage must be `acceptance` with a **manual** gate whose check demands
|
|
347
|
+
evidence; the plan gate must state the set comparison.
|
|
348
|
+
- Nine new invariants, each verified to fail on a broken copy; four added to CI as
|
|
349
|
+
negative self-tests.
|
|
350
|
+
|
|
351
|
+
## v0.15.0 — 2026-07-28
|
|
352
|
+
|
|
353
|
+
Coherence pass over the v0.13.0 port: three contradictions resolved, three gaps
|
|
354
|
+
closed, and the config's gate text re-synced with the doctrine.
|
|
355
|
+
|
|
356
|
+
### Fixed
|
|
357
|
+
- **Model policy contradicted itself.** `build.md` and `review.md` told the final
|
|
358
|
+
whole-branch review to run "on the most capable model available" while
|
|
359
|
+
`model-tiering.md` promises **one** model per run. Both now default to the run's
|
|
360
|
+
confirmed model; when the run sits below the top tier, escalation for that single
|
|
361
|
+
review (and for fix-loop rounds 4–5) is **offered out loud**, never switched
|
|
362
|
+
silently, and only the operator's recorded override map authorizes a cheaper tier.
|
|
363
|
+
- **Parallel groups were planned and then forbidden.** `planning.md` mandates
|
|
364
|
+
dependency-ordered parallel groups with exclusive file ownership; `build.md` said
|
|
365
|
+
"never dispatch implementers in parallel". New §4.2 states the real rule: default
|
|
366
|
+
sequential, fan out only when the tasks share a group, own disjoint files **and**
|
|
367
|
+
each implementer gets its own worktree; integrate the worktrees one at a time; any
|
|
368
|
+
merge conflict means the plan's ownership was wrong — fall back to sequential and
|
|
369
|
+
record it. The fix loop never fans out.
|
|
370
|
+
- **Scratch dirs could land in a task's diff.** The isolation snippet now ignores
|
|
371
|
+
**and commits** both `.worktrees/` and `.task-pipeline/` before anything is
|
|
372
|
+
created.
|
|
373
|
+
|
|
374
|
+
### Added
|
|
375
|
+
- **Stage 5 now ends with integration.** Sync with the base branch, re-run the full
|
|
376
|
+
suite on the merged result (green-in-isolation is not green), land it the
|
|
377
|
+
project's way — merge, or a PR, which is outward and needs a go — never
|
|
378
|
+
force-push a shared branch, never land on `main` when the brief forbids it, then
|
|
379
|
+
remove the worktree. Stages 7–9 lint, deploy and document the integrated result,
|
|
380
|
+
so "leave it unmerged" is allowed but must be recorded. The stage-5 gate, the
|
|
381
|
+
stage table, the Cursor rule and the example config carry the new condition.
|
|
382
|
+
- **Inline execution mode.** A harness without subagents (or a plan too small to be
|
|
383
|
+
worth dispatching) runs the same loop inline: same isolation, ledger, TDD and
|
|
384
|
+
review rubric applied to your own diff — declared out loud, since a self-review is
|
|
385
|
+
weaker evidence than a fresh reviewer's. Replaces the capability that
|
|
386
|
+
`superpowers:executing-plans` used to cover.
|
|
387
|
+
- **Grill + brief sweep row for integration** — how the branch lands (merge / PR +
|
|
388
|
+
approver / "leave it") and whether parallel fan-out is wanted, so stage 5 never
|
|
389
|
+
stops to ask.
|
|
390
|
+
|
|
391
|
+
### Changed
|
|
392
|
+
- The implementer contract spells the TDD loop out inline instead of pointing a
|
|
393
|
+
zero-context subagent at a file it can't resolve, and the plan header no longer
|
|
394
|
+
cites a skill-internal path.
|
|
395
|
+
- `pipeline.example.json` gate text for stages 4, 5 and 6 re-synced with
|
|
396
|
+
`references/stages.md`; stage 4's gate now also names type/name consistency and
|
|
397
|
+
the per-task DoD.
|
|
398
|
+
- `review.md` defines `$WORKSPACE` where it first uses it; `build.md` §4 subsections
|
|
399
|
+
renumbered after the insert.
|
|
400
|
+
|
|
401
|
+
## v0.14.0 — 2026-07-28
|
|
402
|
+
|
|
403
|
+
### Fixed
|
|
404
|
+
- Skill front-matter was **1039 characters**, over the 1024 canon limit, and the
|
|
405
|
+
validator did not check it. Description tightened to 996 and the limit is now
|
|
406
|
+
enforced.
|
|
407
|
+
|
|
408
|
+
### Changed
|
|
409
|
+
- Triggers restructured English-first — `'run this through the pipeline' /
|
|
410
|
+
'прогони по конвейеру'` — in both the skill and the Cursor rule.
|
|
411
|
+
- README is English-only, with a plain statement of what the pipeline gives you
|
|
412
|
+
and an author/links block.
|
|
413
|
+
|
|
414
|
+
### Added
|
|
415
|
+
- Validator enforces the description canon: `Use when` opening, Russian trigger
|
|
416
|
+
aliases present, front-matter under 1024 characters.
|
|
417
|
+
|
|
418
|
+
## v0.13.0 — 2026-07-28
|
|
419
|
+
|
|
420
|
+
The last external dependency is gone. Every stage now runs on doctrine that ships
|
|
421
|
+
inside the skill — the pipeline installs and runs with nothing else present.
|
|
422
|
+
|
|
423
|
+
- **superpowers is no longer a prerequisite.** The preflight no longer resolves
|
|
424
|
+
`superpowers:*`, the "install this or stop" branch is deleted, and no stage can
|
|
425
|
+
fail because a companion plugin is missing. `Prerequisites` in SKILL.md and the
|
|
426
|
+
README now read "none required".
|
|
427
|
+
- **Six new built-in references carry stages 2→6:**
|
|
428
|
+
- `references/brainstorm.md` — stage 2: read the brief first, explore, scope-check
|
|
429
|
+
for decomposition, one question at a time, 2–3 approaches with a recommendation,
|
|
430
|
+
YAGNI, design approved section by section. The **hard gate** (no code, no
|
|
431
|
+
scaffolding before approval, including on "obviously simple" tasks) is explicit.
|
|
432
|
+
- `references/spec.md` — stage 3: UX-track order, what the spec must lock (types,
|
|
433
|
+
schemas, signatures, file layout) plus the **Global Constraints** block stages
|
|
434
|
+
4–5 consume verbatim, the self-review pass, the operator-review gate.
|
|
435
|
+
- `references/planning.md` — stage 4: zero-context task format, dependency graph,
|
|
436
|
+
parallel groups with exclusive file ownership, required plan header and task
|
|
437
|
+
structure, the no-placeholders list, the self-review checklist.
|
|
438
|
+
- `references/build.md` — stage 5: worktree detection (submodule guard, native
|
|
439
|
+
tool first, ignored-directory check, baseline tests), a git-ignored ledger at
|
|
440
|
+
`.task-pipeline/build/<plan>/progress.md` that survives compaction, the
|
|
441
|
+
file-based dispatch contract, the four implementer statuses, the five-round fix
|
|
442
|
+
loop with its breaker and adjudication rules, and the single final fix wave.
|
|
443
|
+
- `references/review.md` — the review rubric (spec compliance, correctness,
|
|
444
|
+
constraints, test honesty, degradation, boundaries, security, docs-same-change),
|
|
445
|
+
severity ladder, controller rules ("never pre-judge a reviewer"), and the three
|
|
446
|
+
reviewer prompts. External helper scripts are replaced by plain git commands, so
|
|
447
|
+
the doctrine works on any agent.
|
|
448
|
+
- `references/tdd.md` — stages 5–6: the iron law, red/green/refactor with both
|
|
449
|
+
mandatory verifications, honest-test rules, the stage-6 full-suite gate, and the
|
|
450
|
+
rationalization table.
|
|
451
|
+
- **Ported, not depended on.** Stages 2–6 are adapted from `brainstorming`,
|
|
452
|
+
`writing-plans`, `using-git-worktrees`, `subagent-driven-development`,
|
|
453
|
+
`test-driven-development` and `requesting-code-review` in
|
|
454
|
+
[obra/superpowers](https://github.com/obra/superpowers) (MIT) and rewritten for
|
|
455
|
+
this pipeline's stages, gates, artifacts and single-model policy. `LICENSE` gains
|
|
456
|
+
a second *Third-party* section with Jesse Vincent's copyright notice covering the
|
|
457
|
+
six files.
|
|
458
|
+
- **Optional bridge, not a dependency.** An operator who already runs an equivalent
|
|
459
|
+
skill set can substitute it on stages 2/4/5/6 via `pipeline.json` → `skills[]`.
|
|
460
|
+
Nothing detects, recommends or waits for it; the gates still govern; providers are
|
|
461
|
+
never mixed inside one stage.
|
|
462
|
+
- **Config:** `pipeline.example.json` stages now name `task-pipeline:brainstorm`,
|
|
463
|
+
`task-pipeline:spec`, `task-pipeline:plan`, `task-pipeline:build` +
|
|
464
|
+
`task-pipeline:review`, and `host:test-runner` + `task-pipeline:tdd`.
|
|
465
|
+
- **Every channel updated** — SKILL.md (built-in doctrine table, stage table,
|
|
466
|
+
references list), `references/stages.md`, `references/companion-skills.md` (matrix
|
|
467
|
+
split into built-in vs optional, superpowers moved to a struck-through
|
|
468
|
+
"not a dependency" row), `references/artifacts.md` (new files in the repo map, the
|
|
469
|
+
`.task-pipeline/` scratch workspace, and a note that `docs/superpowers/` is a
|
|
470
|
+
retained directory *name*, not a dependency), the `/task-pipeline` command, the
|
|
471
|
+
Cursor rule (now carrying the design gate, plan format, build loop and TDD rules
|
|
472
|
+
inline) and the README in both languages.
|
|
473
|
+
- **Validator:** requires all six doctrine files and rejects stubs (<1.5 KB), and
|
|
474
|
+
fails the build if the shipped default flow names an external provider
|
|
475
|
+
(`superpowers:*`, `grill-me`, `grilling`) in any stage's `skills[]`.
|
|
476
|
+
- **Artifact paths unchanged** — briefs, specs and plans still live under
|
|
477
|
+
`docs/superpowers/{specs,plans}` so existing projects need no migration; the name
|
|
478
|
+
is now documented as historical convention only.
|
|
479
|
+
|
|
3
480
|
## v0.12.0 — 2026-07-27
|
|
4
481
|
|
|
5
482
|
The grill stops being someone else's skill. It is ported in, in full, and gains
|
package/LICENSE
CHANGED
|
@@ -25,6 +25,9 @@ SOFTWARE.
|
|
|
25
25
|
Third-party
|
|
26
26
|
================================================================================
|
|
27
27
|
|
|
28
|
+
1) Intake grill (stage 0)
|
|
29
|
+
-------------------------
|
|
30
|
+
|
|
28
31
|
The built-in intake grill (stage 0) is adapted from the `grilling` /
|
|
29
32
|
`grill-with-docs` skills in https://github.com/mattpocock/skills — specifically
|
|
30
33
|
its interview loop and its domain-awareness discipline (glossary challenges,
|
|
@@ -57,3 +60,47 @@ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
57
60
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
58
61
|
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
59
62
|
SOFTWARE.
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
2) Stage doctrine (stages 2-6)
|
|
66
|
+
------------------------------
|
|
67
|
+
|
|
68
|
+
The built-in doctrine for stages 2-6 is adapted from the `brainstorming`,
|
|
69
|
+
`writing-plans`, `using-git-worktrees`, `subagent-driven-development`,
|
|
70
|
+
`test-driven-development` and `requesting-code-review` skills in
|
|
71
|
+
https://github.com/obra/superpowers — specifically the design-dialogue and
|
|
72
|
+
design-approval discipline, the zero-context plan format, the worktree isolation
|
|
73
|
+
procedure, the subagent task/review/fix loop with its ledger and breaker, the
|
|
74
|
+
reviewer contracts, and the red-green-refactor rules. Rewritten for this
|
|
75
|
+
pipeline's stages, gates, artifacts and single-model policy. Affected files:
|
|
76
|
+
|
|
77
|
+
plugins/task-pipeline/skills/task-pipeline/references/brainstorm.md
|
|
78
|
+
plugins/task-pipeline/skills/task-pipeline/references/spec.md
|
|
79
|
+
plugins/task-pipeline/skills/task-pipeline/references/planning.md
|
|
80
|
+
plugins/task-pipeline/skills/task-pipeline/references/build.md
|
|
81
|
+
plugins/task-pipeline/skills/task-pipeline/references/review.md
|
|
82
|
+
plugins/task-pipeline/skills/task-pipeline/references/tdd.md
|
|
83
|
+
|
|
84
|
+
Those portions are used under the following license:
|
|
85
|
+
|
|
86
|
+
MIT License
|
|
87
|
+
|
|
88
|
+
Copyright (c) 2025 Jesse Vincent
|
|
89
|
+
|
|
90
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
91
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
92
|
+
in the Software without restriction, including without limitation the rights
|
|
93
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
94
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
95
|
+
furnished to do so, subject to the following conditions:
|
|
96
|
+
|
|
97
|
+
The above copyright notice and this permission notice shall be included in all
|
|
98
|
+
copies or substantial portions of the Software.
|
|
99
|
+
|
|
100
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
101
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
102
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
103
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
104
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
105
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
106
|
+
SOFTWARE.
|