task-pipeline-skill 1.94.1 → 1.96.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.
Files changed (58) hide show
  1. package/CHANGELOG.md +73 -0
  2. package/CONTRIBUTING.md +32 -0
  3. package/HOW-IT-WORKS.md +4 -3
  4. package/README.md +19 -7
  5. package/SKILL-CARD.md +2 -2
  6. package/evals/RESULTS.md +55 -8
  7. package/evals/cases/task-pipeline.json +139 -0
  8. package/evals/fixtures/lessons/expect-match.sh +30 -0
  9. package/evals/fixtures/lessons/index.jsonl +2 -0
  10. package/evals/fixtures/waves-unclaimed/expect-refusal.sh +26 -0
  11. package/evals/fixtures/waves-unclaimed/inventory.json +33 -0
  12. package/evals/fixtures/waves-unclaimed/modules.json +4 -0
  13. package/evals/fixtures/waves-unclaimed/plan.json +5 -0
  14. package/evals/task-pipeline.evals.json +104 -0
  15. package/package.json +1 -1
  16. package/plugins/task-pipeline/.claude-plugin/plugin.json +1 -1
  17. package/plugins/task-pipeline/agents/verifier.md +1 -1
  18. package/plugins/task-pipeline/commands/task-pipeline.md +3 -2
  19. package/plugins/task-pipeline/hooks/release-gate.sh +1 -1
  20. package/plugins/task-pipeline/skills/task-pipeline/SKILL.md +16 -11
  21. package/plugins/task-pipeline/skills/task-pipeline/pipeline.example.json +4 -0
  22. package/plugins/task-pipeline/skills/task-pipeline/pipeline.schema.json +19 -0
  23. package/plugins/task-pipeline/skills/task-pipeline/references/artifacts.md +1 -1
  24. package/plugins/task-pipeline/skills/task-pipeline/references/audit.md +5 -2
  25. package/plugins/task-pipeline/skills/task-pipeline/references/brainstorm.md +1 -1
  26. package/plugins/task-pipeline/skills/task-pipeline/references/browser.md +1 -1
  27. package/plugins/task-pipeline/skills/task-pipeline/references/certification.md +1 -1
  28. package/plugins/task-pipeline/skills/task-pipeline/references/companion-skills.md +3 -2
  29. package/plugins/task-pipeline/skills/task-pipeline/references/continuity.md +10 -2
  30. package/plugins/task-pipeline/skills/task-pipeline/references/doctrine-map.md +20 -2
  31. package/plugins/task-pipeline/skills/task-pipeline/references/finish-line.md +145 -0
  32. package/plugins/task-pipeline/skills/task-pipeline/references/grill.md +1 -1
  33. package/plugins/task-pipeline/skills/task-pipeline/references/iteration.md +9 -5
  34. package/plugins/task-pipeline/skills/task-pipeline/references/loop-guard.md +5 -0
  35. package/plugins/task-pipeline/skills/task-pipeline/references/portability.md +13 -1
  36. package/plugins/task-pipeline/skills/task-pipeline/references/progress.md +8 -0
  37. package/plugins/task-pipeline/skills/task-pipeline/references/review.md +7 -2
  38. package/plugins/task-pipeline/skills/task-pipeline/references/spec.md +7 -5
  39. package/plugins/task-pipeline/skills/task-pipeline/references/stage-00-intake.md +158 -0
  40. package/plugins/task-pipeline/skills/task-pipeline/references/stage-01-docs-study.md +10 -0
  41. package/plugins/task-pipeline/skills/task-pipeline/references/stage-02-brainstorm.md +52 -0
  42. package/plugins/task-pipeline/skills/task-pipeline/references/stage-03-spec.md +66 -0
  43. package/plugins/task-pipeline/skills/task-pipeline/references/stage-04-plan.md +11 -0
  44. package/plugins/task-pipeline/skills/task-pipeline/references/stage-05-dev.md +55 -0
  45. package/plugins/task-pipeline/skills/task-pipeline/references/stage-06-tests.md +11 -0
  46. package/plugins/task-pipeline/skills/task-pipeline/references/stage-07-lint-deploy.md +15 -0
  47. package/plugins/task-pipeline/skills/task-pipeline/references/stage-08-post-deploy.md +29 -0
  48. package/plugins/task-pipeline/skills/task-pipeline/references/stage-09-docs-wiki.md +45 -0
  49. package/plugins/task-pipeline/skills/task-pipeline/references/stage-10-acceptance.md +91 -0
  50. package/plugins/task-pipeline/skills/task-pipeline/references/stages.md +49 -484
  51. package/plugins/task-pipeline/skills/task-pipeline/references/verification.md +1 -1
  52. package/plugins/task-pipeline/skills/task-pipeline/references/waves.md +9 -6
  53. package/plugins/task-pipeline/skills/task-pipeline/scripts/graph.py +1 -1
  54. package/plugins/task-pipeline/skills/task-pipeline/scripts/stage_checkpoint.py +156 -33
  55. package/plugins/task-pipeline/skills/task-pipeline/scripts/waves.py +219 -3
  56. package/plugins/task-pipeline/skills/task-pipeline/templates/brief.md +14 -0
  57. package/plugins/task-pipeline/skills/task-pipeline/templates/inventory.schema.json +15 -1
  58. package/plugins/task-pipeline/skills/task-pipeline/templates/run.md +26 -2
@@ -36,7 +36,8 @@ A fix designed against today's state is the intermediate state that
36
36
  seam, and the fix is then paid for twice. The finding gets an id in its owning register
37
37
  and lands on a canvas node. Its wave decides when it is built.
38
38
 
39
- **The hotfix lane is the only exception, and it is closed.** It has five entries:
39
+ **The hotfix lane is the only exception, and it is closed.** This list is its single home;
40
+ [`finish-line.md`](finish-line.md)'s blocking test B2 cites it. It has five entries:
40
41
  - production is down;
41
42
  - data is being lost or corrupted;
42
43
  - a credential has leaked;
@@ -57,12 +58,12 @@ reason. "It is quick" is not one of the five entries.
57
58
  | 4 | Question round | answers from the sources, then one batch to the operator | every question is answered, assumed, or blocks a named node |
58
59
  | 5 | Plan | the work graph with waves and risk classes — `scripts/waves.py sync-graph` writes each node's `wave` and `risk` from the plan, so `graph.py close` enforces the rounds it owes — and one packet per node | every REQ lands on a node; [`planning.md`](planning.md)'s set comparison holds |
59
60
  | 6 | Build | parallel agents, each owning disjoint files | each node is committed on its branch, with its own checks green |
60
- | 7 | Verify | rounds per node, starting as each node lands | each node passes its risk class's rounds |
61
+ | 7 | Verify | rounds per node, starting as each node lands; each finding triaged at discovery ([`finish-line.md`](finish-line.md)) | each node passes its risk class's rounds |
61
62
  | 8 | Seam check | cross-module checks per seam group | every seam the canvas names is exercised end to end |
62
63
  | 9 | Docs | stage 9 over everything the release iteration shipped | the doc gate passes and the docs match the code |
63
64
  | 10 | Release | versions, tags, pins, changelogs, in dependency order | the published artefacts resolve |
64
- | 11 | Post-release check | the stage-8 trio on what was released | every item the release claims closed is checked on the released artefact |
65
- | 12 | Next pool | the re-measured inventory and the proposal | the hand-back is sent |
65
+ | 11 | Post-release check | the stage-8 trio on what was released, read as a finish-line round | every item the release claims closed is checked on the released artefact, and `finish:` is computed |
66
+ | 12 | Next pool | the re-measured inventory and the proposal | the hand-back, with its `finish:` line, is sent |
66
67
  | 13 | Retrospective | the project retro, plus the shared lesson store where one exists | written last ([`retrospective.md`](retrospective.md)) |
67
68
 
68
69
  Steps 1–4 are stages 0–4 run once. Steps 6–8 are stages 5–8 per wave, and a wave's
@@ -218,7 +219,10 @@ actually published, installed or deployed — never on the branch. Each item the
218
219
  claims closed is re-checked against the released artefact. For installed packages and
219
220
  skills, follow [`deploy-targets.md`](deploy-targets.md) → *The verification trio*: update
220
221
  within the authorized rollout and read back each claimed installed channel. A failure goes to the hotfix
221
- lane if it is one of its five entries. Otherwise it goes to the next pool, with an id.
222
+ lane if it is one of its five entries. Every post-release failure is triaged at the finish
223
+ line ([`finish-line.md`](finish-line.md) → *Triage at discovery*): a blocking one is fixed in
224
+ this release iteration, and the corrective release counts against `run.finish.maxReleases`; a
225
+ deferred one goes to the next pool, with an id.
222
226
 
223
227
  ## The next pool
224
228
 
@@ -101,6 +101,11 @@ review cap reached — 3 rounds — artifact: test/validate.py
101
101
  - **New > self-inflicted** — the reader is still paying. Continuing is then the
102
102
  operator's call, made with the numbers in hand rather than out of fatigue.
103
103
 
104
+ At the level of a whole iteration only new **blocking** findings argue for continuing; a
105
+ deferred or noise finding is paid for on the board, not with another round
106
+ ([`finish-line.md`](finish-line.md) → *Rounds and the stop*). The class is read from the
107
+ run ledger's `finding:` lines and the rounds from its `round:` lines, never from memory.
108
+
104
109
  **The pair is the whole point.** A round count alone says how tired everyone is; the
105
110
  pair says whether the loop still produces anything. Measured on one file once, the
106
111
  guard's shapes and the run's own prose disagreed — one still paying, one exhausted —
@@ -39,8 +39,19 @@ a row pointing outside the bundle is the defect this file exists to catch.
39
39
 
40
40
  | Workflow decision | Home |
41
41
  |---|---|
42
+ | 0 · Stage procedure | `references/stage-00-intake.md` |
43
+ | 1 · Stage procedure | `references/stage-01-docs-study.md` |
44
+ | 2 · Stage procedure | `references/stage-02-brainstorm.md` |
45
+ | 3 · Stage procedure | `references/stage-03-spec.md` |
46
+ | 4 · Stage procedure | `references/stage-04-plan.md` |
47
+ | 5 · Stage procedure | `references/stage-05-dev.md` |
48
+ | 6 · Stage procedure | `references/stage-06-tests.md` |
49
+ | 7 · Stage procedure | `references/stage-07-lint-deploy.md` |
50
+ | 8 · Stage procedure | `references/stage-08-post-deploy.md` |
51
+ | 9 · Stage procedure | `references/stage-09-docs-wiki.md` |
52
+ | 10 · Stage procedure | `references/stage-10-acceptance.md` |
42
53
  | The stage list, ids, names, gate types | `pipeline.example.json` |
43
- | Per-stage criteria, freedom levels, the run checklist | `references/stages.md` |
54
+ | Full gates, freedom levels, the run checklist and exact stage-detail routes | `references/stages.md` |
44
55
  | Which reference owns which stage (the doctrine map) | `references/doctrine-map.md` |
45
56
  | What the intake grill asks, and the autonomy sweep | `references/grill.md` |
46
57
  | **The escalation boundary** — what an agent may settle alone | `references/grill.md` |
@@ -53,6 +64,7 @@ a row pointing outside the bundle is the defect this file exists to catch.
53
64
  | The entry audit and what it inspects | `references/setup.md` |
54
65
  | The ladder, seams, axis rotation, ratchets | `references/audit.md` |
55
66
  | Loop detection and its caps | `references/loop-guard.md` |
67
+ | **The finish line** — when an iteration stops: the contract, triage at discovery, the round budget | `references/finish-line.md` |
56
68
  | **What the run prints about itself** — the header block, the rail, the iteration line | `references/progress.md` |
57
69
  | **What the run leaves running and leaves behind** — the eight classes, the `holds:` field, the teardown | `references/residue.md` |
58
70
  | **The run mode** — item-by-item pacing, default off, what it never collapses | `references/continuity.md` |
@@ -169,6 +169,9 @@ SCOPE what this claim covers: the commit, the environment, the REQ
169
169
  NOT VERIFIED what was built and NOT checked, or could not be. The literal
170
170
  `none within the stated scope` is a valid answer; an empty
171
171
  field is not
172
+ FINISH finish: done | budget | blocked — the finish block, as
173
+ finish-line.md prints it; mid-iteration, the round and
174
+ the open blocking count
172
175
 
173
176
  DECISIONS WAITING <n> each as a question with options, asked HERE
174
177
  AMBIGUITIES <n> computed, below
@@ -189,6 +192,11 @@ And `none within the stated scope` is a claim with a subject — it says *nothin
189
192
  what SCOPE names is unverified*. Leaving the field empty says nothing at all, which reads
190
193
  as the same thing and is not: canon 9a, one artifact over.
191
194
 
195
+ **`FINISH` says why the iteration stopped** ([`finish-line.md`](finish-line.md) → *The
196
+ finish block*): `done` with its exit checks green on the artefact, `budget` with each open
197
+ blocker a `needs-operator` board row, or `blocked`. A hand-back that cannot fill it has not
198
+ reached a finish line, and says which round it is in.
199
+
192
200
  **Where there is no brief** — `checkup`, `setup`, a short path — TASK quotes the
193
201
  operator's own sentence instead, marked as such. An unquotable TASK is a run that cannot
194
202
  say what it was asked, which is worth its own line.
@@ -108,14 +108,19 @@ Review in this order; stop reading the diff only when you've covered all of it.
108
108
  **Severities:**
109
109
 
110
110
  - **Critical** — wrong behavior, data loss, security hole, a red or dishonest test
111
- suite. Blocks.
111
+ suite. Blocks the node when the defect is in its diff or caused by it.
112
112
  - **Important** — a real defect or spec gap that will bite: missing requirement,
113
- unhandled failure path, a magic value the constraints named. Blocks.
113
+ unhandled failure path, a magic value the constraints named. Blocks the node when the
114
+ defect is in its diff or caused by it.
114
115
  - **Minor** — style, naming, a nit with no behavioral consequence. Never blocks;
115
116
  goes to the ledger.
116
117
  - **⚠️ Cannot verify from diff** — the requirement lives in unchanged code or spans
117
118
  tasks. Not a blocker for the reviewer; the controller resolves it.
118
119
 
120
+ **A pre-existing defect the reviewer notices** — one the diff neither contains nor
121
+ causes — does not block the node, whatever its severity. It goes to finish-line triage
122
+ ([`finish-line.md`](finish-line.md) → *Triage at discovery*).
123
+
119
124
  Formatting nits that don't change meaning are not findings. Praise is not a
120
125
  finding either.
121
126
 
@@ -28,9 +28,12 @@ spec*.
28
28
 
29
29
  ## UX track (user-facing tasks only)
30
30
 
31
- Runs on **super-ux** — the one companion this pipeline recommends by name
32
- ([`companion-skills.md`](companion-skills.md)). If it isn't installed on a UI task,
33
- give the install line and stop; don't improvise a half-chain.
31
+ Apply [the artifact-provider contract](companion-skills.md): super-ux is the
32
+ preferred provider; equivalent artifacts or the inline fallback remain valid.
33
+ Missing or invalid scenario artifacts stop the gate, regardless of provider.
34
+ Record each unavailable check by name as NOT_RUN; do not claim a linter ran.
35
+ The following chain describes the super-ux provider when available. Other
36
+ providers owe the same scenario quality and traces, not these package commands.
34
37
 
35
38
  0. **The design destination is already decided — read it, don't re-open it.** When
36
39
  Figma is on, the stage-0 brief names the team/org and the files — one per surface
@@ -94,8 +97,7 @@ green over both.
94
97
  not checkable; a record is. The track writes a **director record** in the product's
95
98
  repository, beside `docs/ux/`: `docs/design/<surface>/director-record.md`, a header
96
99
  line `surface_class: <class>` and one `## <Field>` heading per field. Which fields are
97
- owed is the brief's `surface_class` ([`stages.md`](stages.md) → stage 0, *The surface
98
- class*):
100
+ owed is the brief's `surface_class` ([`stage-00-intake.md`](stage-00-intake.md) → *0 — Intake grill — MANDATORY*, the surface-class bullet):
99
101
 
100
102
  | Class | Fields the record owes |
101
103
  |---|---|
@@ -0,0 +1,158 @@
1
+ # Stage 0 detail
2
+
3
+ The full gate and freedom level remain in [stages.md](stages.md).
4
+
5
+ ## Contents
6
+
7
+ - 0 — Intake grill — MANDATORY
8
+
9
+ ## 0 — Intake grill — MANDATORY
10
+ - **Stage 0 is not optional and not skippable.** There is no "small enough task"
11
+ exemption, no "the request was already clear" exemption, no starting stage 1
12
+ "while the operator thinks". The only sanctioned bypass is the
13
+ entry-from-super-ux short-circuit below, and even that still requires a scope
14
+ confirmation and a record of what was adopted vs skipped. A run that reaches
15
+ stage 1 without a committed, operator-confirmed brief is a **failed run** —
16
+ stop and go back.
17
+ - **Entry-from-super-ux short-circuit (check FIRST).** task-pipeline is often
18
+ launched *from* super-ux — its `/ux` action menu offers "execute autonomously
19
+ via the task-pipeline plugin" once the UX chain (and often a
20
+ `docs/ux/plans/…` fix plan) is already built. Before grilling, detect that:
21
+ if `docs/ux/` already holds a validated chain (foundation → flows → screens →
22
+ scenarios) and/or a fresh fix plan, **do not re-run the grill or the stage-3
23
+ UX track from scratch.** Instead: (1) run a quick check — `/ux-lint`
24
+ (`docs/ux/lint.py`) green, chain present, plan (if any) readable; (2) confirm
25
+ the scope with the operator in ONE line; (3) skip to the first stage that
26
+ still has real work (usually stage 4 Plan if a UX fix plan already exists, or
27
+ stage 3 Spec to formalize it). Record what was adopted vs skipped. If the
28
+ check finds drift/gaps, fall back to the normal flow for the missing parts
29
+ only.
30
+ - **What (normal entry):** the operator's one-line task is almost never enough to
31
+ run autonomously. Before anything else, **grill the operator** to expand that
32
+ one line into a complete, unambiguous brief — resolve every decision branch
33
+ up front so stages 1→10 need no further human input beyond the manual gates.
34
+ This is input expansion, not design: turn "make me feature X" into locked
35
+ answers for scope, users, constraints, data, edge cases, done-criteria.
36
+ - **Phase 1 — harvest the knowledge sources FIRST**
37
+ ([`knowledge-sources.md`](knowledge-sources.md)). Before the first question:
38
+ query what the project already knows about this task — code, **the code graph**
39
+ when one is built ([`knowledge-graph.md`](knowledge-graph.md): `graphify query` /
40
+ `affected` / `god-nodes` answer *reach*, which is what grep cannot), `CLAUDE.md`,
41
+ `CONTEXT.md`/ADRs, `docs/` + `docs/ux/`, past pipeline briefs and carry-over
42
+ ledgers, **the retro's standing instructions and run stamps** (`<artifacts>/retro.md`,
43
+ read **in full** — ten standing rows and ten stamps, both bounded **by a cap**, and they bind this
44
+ run; stamp each instruction as it fires. Its *Recent log* is **queried** by the
45
+ task's nouns, not read: uncapped narrative inside a binding source is what makes the
46
+ capped part get skimmed, [`retrospective.md`](retrospective.md)), **lessons from other
47
+ projects** (source 7b, [`knowledge-sources.md`](knowledge-sources.md): `scripts/lessons.py
48
+ query` over the local index, then a shared store where the session lists one — each
49
+ layer's state printed in the source ledger), the **knowledge wiki** if one is
50
+ installed
51
+ ([obsidian-wiki](https://github.com/ar9av/obsidian-wiki) — recommended,
52
+ never required), and any **other repo or hosted doc system the project names as
53
+ its docs**. Write the **source ledger** into the brief (a row per source, or an
54
+ explicit "none found"; **the graph's row carries its measured lag — commits and
55
+ days behind `HEAD`, the signal that measured it, and `⚠ not trusted for reach
56
+ until refreshed` on anything but `current`**
57
+ ([`knowledge-graph.md`](knowledge-graph.md) → *Measure the lag*; a build date is
58
+ the graph's own reply about itself, not a measurement of it). It is retrieval
59
+ scoped by the task's own nouns, not a read of everything — and it is what makes
60
+ phase 2's answers checkable instead of merely confident.
61
+ - **Phase 1b — the documentation inventory**
62
+ ([`documentation.md`](documentation.md)). Four questions, answered before the
63
+ interview and written to `docs/DOCMAP.md` (seeded from
64
+ [`../templates/docmap.md`](../templates/docmap.md), **only when absent**): where
65
+ do settled things live, what is each fact's single home, what does a change of
66
+ type X oblige, and what proves it. A project with no answers gets them seeded —
67
+ registers, the matrix and `scripts/check-docs.sh` — and the seeding is itself
68
+ recorded as the register's first entry. **One decision home per project:** an
69
+ existing `docs/adr/` *is* the register and is recorded as such, never duplicated.
70
+ The gate is seeded so that it exits `0` on its own seeds; a project that starts
71
+ red learns on day one that the gate is noise.
72
+ - **Phase 1b+ — offer the entry audit, once** ([`setup.md`](setup.md)). When
73
+ `docs/DOCMAP.md` is absent or its regime line predates the project's last release,
74
+ ask whether to audit the documentation that already exists **before** building on
75
+ it. Record the answer — including a refusal — in the brief's autonomy sweep and
76
+ never ask again. `audit.md`'s ladder runs at the *end* over the change; this runs
77
+ at the *start* over what is already there.
78
+ - **Phase 1c — reconcile intent against as-built.** Git says how it *should* be;
79
+ the run record says how it *turned out*. Read both for the area you are about to
80
+ touch and resolve every divergence — the document is stale, the record is wrong,
81
+ or they genuinely disagree and that is a decision. There is no fourth option, and
82
+ starting on an unresolved divergence means building against a system that does
83
+ not exist.
84
+ - **Phase 1d — the short-path triage: printed, proposed, never taken silently.** This
85
+ pipeline's own boundary exempts a typo, a one-line fix and a mechanical rename — and
86
+ nothing measured that until 2026-08-10, so the exemption depended on an agent
87
+ remembering it while eleven stages and four manual gates stood in front of a
88
+ one-paragraph edit. Three questions, each with something behind it:
89
+
90
+ ```
91
+ 1. files the request names, resolved git ls-files -- <paths> -> N
92
+ 2. any of them a public contract the surfaces the host's release
93
+ syncs, its schema or config
94
+ contracts, a shipped command,
95
+ its README -> yes/no
96
+ 3. behaviour a user or a caller observes changes -> yes/no
97
+ ```
98
+
99
+ Few files, no contract, no observable change ⇒ **propose** the short path: stages 1,
100
+ 2, 3 and 4 marked `⊘` with the triage answer as the reason, and 5→10 running
101
+ unchanged. **Propose, never take.** The answer goes in the brief's autonomy sweep and
102
+ silence takes the full flow — the same floor deploy authorization uses. The glyph is
103
+ what makes it safe: a skipped stage is printed on the rail **with its reason**
104
+ ([`progress.md`](progress.md)), and a skip nobody can see is indistinguishable from a
105
+ stage that was never entered.
106
+ - **How it runs: [`grill.md`](grill.md)** — the full doctrine, built into this
107
+ skill (nothing to install). In short: close what the sources can, then ONE batch
108
+ of the material unknowns, ordered by dependency, a recommended answer with each —
109
+ one at a time only where answers depend on each other or the operator asks;
110
+ contradictions reconciled on the spot; **every answer that touches
111
+ a harvested source is checked against it** — the operator outranks any document,
112
+ but only out loud, and the losing side is logged for the stage-9 doc update; plus
113
+ **domain awareness**
114
+ (challenge terms against `CONTEXT.md`, sharpen fuzzy language, stress-test with
115
+ concrete scenarios, cross-reference the code, record ADRs for hard-to-reverse
116
+ calls) and the **autonomy sweep** that pre-resolves every stage-1→10 blocker.
117
+ Deploy authorization has a hard floor there: a standing go counts only when it
118
+ names the target and the preconditions.
119
+ - **The run mode is settled here too** ([`continuity.md`](continuity.md)): does
120
+ the run advance item-by-item with no check-in between items, and on what
121
+ interval? Exactly three sources arm it: `pipeline.json` → `run.loop` (read
122
+ first — a recorded mode is the answer and is not re-asked), the operator's answer
123
+ here, or a standing instruction the host already carries. The ledger names which, once:
124
+ `loop: armed by <source:line>`. **Absent all three, it is off.** It buys pacing, never
125
+ authorization: no loop mode collapses a `manual` gate or an outward act. The
126
+ same file carries the other half of pacing — the context budget, which fires
127
+ only on a harness signal or the operator's word, never on an estimate.
128
+ - **UI early-detect:** one branch of the grill is always "does this touch a
129
+ user-facing surface (web/mobile/CLI/TUI)?". If yes → surface **super-ux**
130
+ now (use it if installed; otherwise give the install line — see SKILL.md
131
+ *Prerequisites*); this arms the stage-3 UX track. **And the same branch records
132
+ the surface's class** — the next bullet.
133
+ - **The surface class.** Every user-facing task's brief carries
134
+ `surface_class: flagship | product | internal | ad`, and the class selects the gate
135
+ profile the visual layer is held to for the rest of the run:
136
+
137
+ | Class | What it is | Director record (stage 3) | Visual half (stages 5–6) | Stage 10 |
138
+ |---|---|---|---|---|
139
+ | `flagship` | the surface a product is judged by — landing, onboarding, paywall, a hero screen | the full record | **gate**: full matrix, pairwise across every axis, the full rubric | approved contact sheet |
140
+ | `product` | an ordinary screen of the product | the short record — Brief, Mode, References, Markers, Open | **gate**: every state and the mandatory pairs; the gate items of the rubric | approved contact sheet |
141
+ | `internal` | an admin panel, an internal tool, a CLI | none owed | recommended; the project linter is the floor | the functional look |
142
+ | `ad` | a creative that runs as an advertisement or a store asset | Brief, Mode, References, Markers, ADA (its rubric profile and safe zones), Open | **gate**: the ad profile and the safe zones | approved contact sheet |
143
+
144
+ Ask it as one question with a recommended answer read off the request — a landing or a
145
+ paywall is `flagship` unless the operator says otherwise — and never leave it to stage
146
+ 5: a class decided at build time is decided by whoever wants the build to pass. A
147
+ work-graph node that builds the surface copies the class as `surface_class`, and
148
+ `graph.py certify` then owes the fourth, `visual` reading on `flagship` and `product`
149
+ ([`certification.md`](certification.md) → *The fourth reading*).
150
+ - **Artifact:** lock the resolved decisions into a **task brief** committed at
151
+ `<artifacts>/specs/YYYY-MM-DD-<topic>-brief.md` (scope, users/UI verdict and,
152
+ for a user-facing task, `surface_class`, constraints, assumptions, explicitly-deferred items, done-criteria) **plus the
153
+ autonomy sweep's per-stage answers and the model decision**. Seed it from
154
+ the skill's `templates/brief.md` skeleton — but only when absent, never
155
+ overwrite an existing brief. Stages 2–4 build on this brief; stages 5–10 read
156
+ its autonomy section instead of asking. Where the session produced them, also:
157
+ an updated `CONTEXT.md` (terms written as they resolved) and any ADRs under
158
+ `docs/adr/` — see `grill.md` → *Domain awareness*.
@@ -0,0 +1,10 @@
1
+ # Stage 1 detail
2
+
3
+ The full gate and freedom level remain in [stages.md](stages.md).
4
+
5
+ ## 1 — Docs study
6
+ - **What:** ground every external library / API / SDK the task touches on the
7
+ *current* docs, before locking any contract.
8
+ - **Invoke:** the `context7` MCP — `context7:resolve-library-id` → `context7:query-docs`,
9
+ scoped by topic or the `context7-docs` skill. Web-search fallback for libs context7
10
+ can't resolve.
@@ -0,0 +1,52 @@
1
+ # Stage 2 detail
2
+
3
+ The full gate and freedom level remain in [stages.md](stages.md).
4
+
5
+ ## 2 — Brainstorm + decompose
6
+ - **How it runs: [`brainstorm.md`](brainstorm.md)** — built into this skill. Read
7
+ the brief first (stage 0 already answered scope/constraints/done-criteria), then
8
+ explore the codebase, scope-check for decomposition, the open questions in one
9
+ batch, 2–3 approaches with a recommendation, design presented in sections and
10
+ approved section by section. **Hard gate:** no code, no scaffolding, no implementation
11
+ skill before the operator approves the design — including on "obviously simple"
12
+ tasks.
13
+ - **UI detection (mandatory check):** decide whether the task touches any
14
+ user-facing surface (web, mobile, CLI, TUI — new feature, new screen/command,
15
+ or a change to user-visible behavior). Record the verdict; it arms the UX
16
+ track in stage 3.
17
+ - **Decomposition (platforms only): [`decomposition.md`](decomposition.md).** If
18
+ the brief describes a platform rather than a change — several independent
19
+ capabilities, several surfaces that could ship separately, REQs no single
20
+ deliverable satisfies — cut it into **modules** before any spec is written, and
21
+ commit the module map (`specs/<topic>-modules.md`): what each module delivers,
22
+ the entities it owns, what it depends on, the contracts it exposes, its REQs and
23
+ its status, in build order with the walking skeleton first. Single-module work
24
+ records `single module: <name>` in the design and moves on — a skipped
25
+ decomposition is a decision, never an omission.
26
+ - **Where the queue is a work graph, it is WRITTEN here**
27
+ ([`work-graph.md`](work-graph.md)): `.task-pipeline/graph.json`, carrying the frozen REQ
28
+ ids so `serves` resolves, one node per unit of work with its owner, what it touches and
29
+ **the check that will close it**, and an edge per dependency **naming what it hands
30
+ over**. The check is the planner's job and not the verifier's: a node whose completion
31
+ test is decided by whoever happens to close it is a node two closes will disagree about,
32
+ and `validate` refuses one that names none. Then
33
+ `python3 scripts/graph.py validate` — a graph that does not validate is not a queue, and
34
+ `next` refuses to walk one. The reason to prefer it over a prose plan is measured, not
35
+ aesthetic: a 400-node graph and a 4-node graph produce the same 27-byte frontier, so the
36
+ cost of knowing what is next does not grow with the programme.
37
+ - **And the check is what THREE readings will run, not one**
38
+ ([`certification.md`](certification.md)). A node is closed by `unit`, `seam` and `product`
39
+ reports, dispatched blind and in parallel, and `certify` refuses the close until all three
40
+ pass. That is a planning fact, not only a verification one: a node whose blast radius nobody
41
+ can name is a node the seam and product tiers cannot scope, so `touches` and `serves` are
42
+ what make the two outer readings possible at all.
43
+ - **The queue exists here, so the loop arms here** ([`continuity.md`](continuity.md) →
44
+ *Part 1a*). Where the loop is armed — `run.loop` with `arm: after-decomposition`, the
45
+ operator's preflight answer, or a standing instruction the host carries (which arms here
46
+ unless it says otherwise) — and the map holds more than one module, arm the mode at the
47
+ close of this stage, cite the source as `loop: armed by <source:line>`, and print one
48
+ line: the mode, and
49
+ either the job id and its cancel command (`interval`) or the delay chosen and why
50
+ (`dynamic`). Arming collapses no gate and authorizes no outward act; it decides only
51
+ that the run does not stop to ask *"shall I take the next one?"*. Single-module work
52
+ arms nothing and says so — a loop with one item is a timer.
@@ -0,0 +1,66 @@
1
+ # Stage 3 detail
2
+
3
+ The full gate and freedom level remain in [stages.md](stages.md).
4
+
5
+ ## 3 — Spec — with UX track for user-facing tasks
6
+ - **How it runs: [`spec.md`](spec.md)** — built into this skill: the UX-track order,
7
+ what the spec must lock (types, schemas, signatures, file layout, the **Global
8
+ Constraints** block stages 4–5 depend on), the self-review pass and the operator
9
+ review gate.
10
+ - **UX track (runs FIRST when stage 2 flagged UI; skip entirely otherwise).**
11
+ Apply [the artifact-provider contract](companion-skills.md): super-ux is the
12
+ preferred provider; equivalent artifacts or the inline fallback remain valid.
13
+ Missing or invalid scenario artifacts stop the gate, regardless of provider.
14
+ Record each unavailable check by name as NOT_RUN; do not claim a linter ran.
15
+ The following chain describes the super-ux provider when available. Other
16
+ providers owe the same scenario quality and traces, not these package commands.
17
+ When using super-ux, walk its chain top-down (see its `system-map.md`):
18
+ 0. **Destination first, when Figma is on.** The brief already names the team/org
19
+ and the files — **one per surface** (App, Web, ASO: store screenshots, icon and
20
+ logo), never one file for every frame; `docs/ux/foundation.md` → *Design tooling*
21
+ is the canonical record. Confirm each **resolves** before drawing. **Never create a file while a
22
+ recorded one resolves; if it doesn't resolve, stop and ask — never create a
23
+ replacement** (that is the duplicate, and it hides a permissions problem).
24
+ A creation happens at most once, in the named team, and its URL is written to
25
+ the canonical record before the first frame.
26
+ 1. `/ux` (the only super-ux entry) — reports which `docs/ux/` layers exist,
27
+ repairs the skeleton, records the Figma on/off choice, recommends the next
28
+ action. Never make the operator pick skills.
29
+ 2. `ux-foundation` → `docs/ux/foundation.md` — the **WHY**: personas, Jobs to
30
+ Be Done, **customer journey maps (CJM)**, user stories (Given/When/Then).
31
+ 3. `ux-flows` → `docs/ux/flows.md` + `docs/ux/screens.md` — the **HOW + UI
32
+ map**: task analysis, user-flow diagrams (branches, error paths), every
33
+ screen + state with wireframe and (Figma on) a Figma frame link.
34
+ 4. `ux-scenarios` → `docs/ux/scenarios.md` — the **WHAT** (source of truth for
35
+ behavior): scenarios validated against the scenario-format contract super-ux
36
+ itself ships (`scenario-format.md` — read its current version there, never
37
+ pin one here) — IDs, statuses, `Traces:` to stories/journey stages/flows,
38
+ edge/error states enumerated.
39
+ 5. **Run the super-ux linter** (`/ux-lint` or `python3 docs/ux/lint.py`) — it
40
+ must pass: no drift, no orphans, no broken traces or stale Figma links.
41
+ These skills are **idempotent** — reuse and extend existing `docs/ux/` layers,
42
+ never rebuild from scratch. If the chain already exists and is validated (e.g.
43
+ the task entered from super-ux), just verify (linter green) and embed it into
44
+ the spec; only build the parts that are missing.
45
+ - **COPY track and VISUAL track — a parallel layer after UX, and their
46
+ convergence.** Three tracks, three questions, none substituting for another:
47
+ super-ux decides what the interface must **do**, `copywriting` how it
48
+ **sounds** (every string a product's user will read, against the brand pack),
49
+ `sheleg-design` how it **looks** (tokens, themes, typography, motion). COPY and
50
+ VISUAL are **parallel** — both consume the UX track's scenarios, neither
51
+ consumes the other — and where both ran, **their convergence check is run and
52
+ recorded before the spec is committed**: each can be right alone and the two
53
+ disagree together on one screen. The full doctrine — each track's scope and
54
+ out-of-scope, the refusal sentences, the four contradictions the check
55
+ catches — is [`spec.md`](spec.md) → *The COPY and VISUAL tracks, and their
56
+ convergence*, its one home. **The VISUAL track leaves a trace, not a fact**: a
57
+ director record at `docs/design/<surface>/director-record.md`, whose fields the gate
58
+ reads by the brief's `surface_class` (`python3 scripts/visual_gate.py record <file>
59
+ --class <c>`), and a refusal is that same file saying `Mode: declined` and why.
60
+ - **Spec:** write the approved design to
61
+ `<artifacts>/specs/YYYY-MM-DD-<topic>-design.md` and commit it. Lock all
62
+ shared contracts (types, schemas, signatures, file layout). For UI tasks the
63
+ spec **embeds the UX layer**: links the validated scenario IDs, the flows and
64
+ `SCR-` screens, the CJM stages the feature serves, and the UX
65
+ patterns/principles from super-ux that apply (`best-practices.md`,
66
+ `ux-design-principles.md`, `component-guidelines.md`).
@@ -0,0 +1,11 @@
1
+ # Stage 4 detail
2
+
3
+ The full gate and freedom level remain in [stages.md](stages.md).
4
+
5
+ ## 4 — Plan
6
+ - **How it runs: [`planning.md`](planning.md)** — built into this skill →
7
+ `<artifacts>/plans/YYYY-MM-DD-<topic>.md` (same slug as the brief and the
8
+ spec). Zero-context tasks, exact
9
+ paths, complete code in every step, TDD steps with expected output, DoD each,
10
+ dependency graph + parallel groups, non-overlapping file ownership, and the
11
+ Global Constraints block copied verbatim from the spec.
@@ -0,0 +1,55 @@
1
+ # Stage 5 detail
2
+
3
+ The full gate and freedom level remain in [stages.md](stages.md).
4
+
5
+ ## 5 — Dev
6
+ - **How it runs: [`build.md`](build.md)** — built into this skill: isolate the
7
+ workspace (native worktree tool first, git fallback, baseline tests), keep a
8
+ ledger under `.task-pipeline/build/<plan>/` so a compacted context can resume,
9
+ then one fresh implementer subagent per task with a file-based brief and report,
10
+ a review after every task ([`review.md`](review.md)), and a five-round fix loop
11
+ with an explicit breaker. TDD per task ([`tdd.md`](tdd.md)): failing test →
12
+ watch it fail → minimal impl → watch it pass → commit. Pin subagents to the
13
+ run's confirmed model (`model-tiering.md`). The plan's parallel groups fan out
14
+ **only when all three hold** — the tasks share no `depends:`, their file ownership
15
+ is exclusive per the plan, and each implementer gets its own worktree; otherwise
16
+ sequential. A group that did fan out gets **one convergence check over all its
17
+ reports and diffs together, before the first worktree is integrated**
18
+ ([`build.md`](build.md) §4.2a) — a per-task review reads one diff and cannot see a
19
+ contradiction that exists only between two of them.
20
+ - **Web front end? The task's own surface is checked in a browser, not in the diff.**
21
+ Where a browser channel is connected — `playwright` **or** `chrome-devtools`, either
22
+ one, whichever answers first (**how**: [`browser.md`](browser.md); which:
23
+ [`companion-skills.md`](companion-skills.md)): after a
24
+ task that changes a rendered surface, load it, take a snapshot and read the
25
+ console and the network log **before the task is marked DONE** — a component can be
26
+ correct and land under a fixed header, and a review of the diff cannot see that.
27
+ **What the look finds is fixed in this task, or parked with the ruling the GATE below
28
+ requires — never parked silently** — a browser finding filed without a ruling is the
29
+ diff-review verdict wearing a screenshot; the look was worth taking only if it can
30
+ still change the code or is on record as deliberately not doing so. Absent, say the surface was verified by reading
31
+ the diff and treat it as the weaker claim it is. **On a surface whose brief names a
32
+ `surface_class`, the project linter runs here too**, after each task that changes a
33
+ rendered surface — `python3 scripts/visual_gate.py lint <dir>`; an S1 finding is
34
+ fixed in the task, and NOT_RUN (exit 3) is recorded as such
35
+ ([`browser.md`](browser.md) → *The visual half*). **With Figma on, the token drift
36
+ probe runs beside it** after a task that touches the token file or a tokenised
37
+ component: `python3 scripts/visual_gate.py tokens --figma <variables.json> --css
38
+ <tokens.css>`. A FAIL is fixed in the task, renaming one side to match the other.
39
+ No export is NOT_RUN, recorded as such. A component whose API the task changed
40
+ updates its Code Connect mapping in the same change
41
+ ([`build.md`](build.md) → *Code Connect, kept*). A slop marker caught while the
42
+ implementer is dispatched costs a line; caught on the contact sheet it costs a round. Stage 6 repeats this over the whole tree; this one catches it while the
43
+ implementer that wrote it is still dispatched. The matrix pointed this companion at
44
+ stages 5–6 from the day it was added and **this stage had never named it** — found by
45
+ the guard comparing the two, not by a reader.
46
+ - **Domain companions, where the task is on their ground** — recommended, never a
47
+ gate ([`companion-skills.md`](companion-skills.md)): `sheleg-dev` when the build
48
+ wires money, tracking, sign-in or page speed; `agent-stack` when the thing being
49
+ built is an agent system; `telegram-dev` when Telegram is the platform rather
50
+ than the transport. Absent, the build ships on the host's own doctrine and the
51
+ close-out names the seam nobody checked.
52
+ - **Integration closes the stage:** sync with the base branch, re-run the full suite
53
+ on the result, land it the project's way (merge, or a PR — outward, so it needs a
54
+ go), remove the worktree. Stages 7–9 act on the integrated result, so a branch the
55
+ operator chose to leave unmerged is recorded as such.
@@ -0,0 +1,11 @@
1
+ # Stage 6 detail
2
+
3
+ The full gate and freedom level remain in [stages.md](stages.md).
4
+
5
+ ## 6 — Tests
6
+ - **What:** consolidate test coverage for the change: confirm new functionality
7
+ has tests (written test-first in stage 5), update/repair existing tests the
8
+ change touched, and add edge-case + failure-path tests per DoD.
9
+ - **Invoke:** the host test runner (see `conventions.md` → *Lint + test*); the
10
+ built-in [`tdd.md`](tdd.md) cycle for any uncovered gap — failing test first,
11
+ same as stage 5.
@@ -0,0 +1,15 @@
1
+ # Stage 7 detail
2
+
3
+ The full gate and freedom level remain in [stages.md](stages.md).
4
+
5
+ ## 7 — Lint + deploy
6
+ - Read host conventions (`conventions.md`): run the linter; fix failures. The suite
7
+ is already green from stage 6 — re-run it if code changed since. For UI projects,
8
+ the **super-ux linter** (`python3 docs/ux/lint.py` / `/ux-lint`) is part of lint —
9
+ it must pass too (no UX drift merges). Then deploy per the project's convention;
10
+ if the project defines release automation (`pipeline.json` → `release`, toggle
11
+ on), that is what "deploy" runs here. **No runbook, or one too thin to act on?
12
+ Write it first** ([`deploy-targets.md`](deploy-targets.md)) — a deploy performed
13
+ from inference about the project is one nobody can repeat or roll back, and the
14
+ operator is standing at this gate anyway. That reference also carries the CLI
15
+ verbs per target for when the runbook names a platform you have to recall.
@@ -0,0 +1,29 @@
1
+ # Stage 8 detail
2
+
3
+ The full gate and freedom level remain in [stages.md](stages.md).
4
+
5
+ ## 8 — Post-deploy
6
+ - Tail deploy logs / health-check per conventions. Confirm clean boot, no error
7
+ spike, live subsystems healthy. **All three of the verification trio, not one of
8
+ them** ([`deploy-targets.md`](deploy-targets.md) → *The verification trio*):
9
+ deployment/process state, runtime logs, and a health-check request from outside.
10
+ Where deploy happens in CI, verify the **deploy** job and not only the build —
11
+ a green build beside a skipped deploy is the commonest way a run reports success
12
+ while nothing shipped.
13
+ - **A deployed web target is opened, not curled.** A `200` proves the server
14
+ answered; it says nothing about whether the page rendered, whether a bundle 404'd,
15
+ or whether the console filled with errors on load — all three ship green past a
16
+ health check. Where a browser channel is connected — `playwright` **or**
17
+ `chrome-devtools`, either one ([`browser.md`](browser.md)) — load the deployed URL and read
18
+ the console and the network log; quote what you read, not that you looked
19
+ ([`companion-skills.md`](companion-skills.md)). Absent → say the check was an HTTP
20
+ response only, which is the honest name for it.
21
+ - **Read the CI verdict for the deploy's own commit** ([`conventions.md`](conventions.md)
22
+ → *The CI verdict*): the run's conclusion quoted, the **failing step's log quoted**
23
+ on anything but `success`, and one of the three states stated — including **`no run
24
+ found`**, out loud, because a project without CI is a legitimate state and not a
25
+ green one.
26
+ - **A public surface a logged-out reader will see** can additionally be audited for
27
+ search and answer-engine visibility with `seo-aeo-audit`
28
+ ([`companion-skills.md`](companion-skills.md)) — recommended, never a gate;
29
+ absent, visibility ships unaudited and the close-out says so.
@@ -0,0 +1,45 @@
1
+ # Stage 9 detail
2
+
3
+ The full gate and freedom level remain in [stages.md](stages.md).
4
+
5
+ ## 9 — Docs + wiki
6
+ - **The propagation sweep runs first** ([`documentation.md`](documentation.md)).
7
+ The ledger below names the documents you **read**; the matrix in `docs/DOCMAP.md`
8
+ names the documents you **owe**. They are not the same list, and the gap between
9
+ them is where documentation rots — the document nobody read is exactly the
10
+ document nobody updated. Walk the matrix row for **every** change type this run
11
+ produced. Every settled thing gets an id in the register, every answered question
12
+ is flipped to `Resolved→<id>`, and every document named in a
13
+ `Consequences / affects:` line cites its decision.
14
+ - **Then run the documentation gate** (`bash scripts/check-docs.sh`, or whatever
15
+ `docs/DOCMAP.md` → *Gates* names) and print its **ratchet counts** beside the
16
+ verdict, so "green" reads as *"green, and here is exactly what was not looked
17
+ at"* ([`gates.md`](gates.md)). A check that skipped says so.
18
+ - **The stage-0 source ledger is the work list** ([`knowledge-sources.md`](knowledge-sources.md)
19
+ → *Close the loop*): every source the harvest read gets updated if this run
20
+ changed or disproved it. What was worth reading at stage 0 and is wrong now is
21
+ the next run's false premise.
22
+ - Update host module docs / runbooks per the project's self-update rules, in the
23
+ **same change**. For UI tasks, confirm the super-ux layers were updated in this
24
+ change and the linter is green (super-ux *same-change* + *no-drift* rules).
25
+ - **Sync the knowledge wiki** — `wiki-update` when
26
+ [obsidian-wiki](https://github.com/ar9av/obsidian-wiki) is installed (detect:
27
+ `~/.obsidian-wiki/config`, or the skill resolves). Not installed → recommend it
28
+ once with its install line and continue; a missing wiki never blocks the gate.
29
+ Distil the knowledge (decisions, seams, why), not a diff summary.
30
+ - **Refresh the code graph** — `/graphify . --update` when one exists
31
+ ([`knowledge-graph.md`](knowledge-graph.md)). The close-out has **three**
32
+ artifacts, not two: docs, wiki, graph. The graph is the source the *next* run's
33
+ harvest queries first, so a stale one is a false premise carrying the authority of
34
+ a machine — a wrong doc gets argued with, a wrong graph gets believed. Incremental
35
+ and model-free for code; a run that deleted code legitimately rebuilds smaller
36
+ (`--force`).
37
+ - **Then check the graph against the docs** — the cheap half of the divergence sweep
38
+ (`graphify god-nodes`; any doc naming a module the graph no longer has). A hub no
39
+ doc names, or an edge the docs deny, is either a leak in the code or a lie in the
40
+ docs; a doc naming a node that no longer exists is a stale ledger row found
41
+ mechanically. Doc-side findings are fixed here; **absences go to stage 10's ladder
42
+ walk as REQ rows** ([`audit.md`](audit.md)).
43
+ - **Docs living in another repository** are outward: propose the edit, get an
44
+ explicit go, then open a PR there. No go → the exact edit goes in the carry-over
45
+ ledger.