task-pipeline-skill 0.12.0 → 0.17.1

package/README.md

@@ -5,17 +5,17 @@
 [![license](https://img.shields.io/badge/license-MIT-blue)](LICENSE)
 
 Full-cycle task delivery pipeline orchestrator for **Claude Code**. One skill that
-runs any substantial task through an up-front **intake grill** + **9 gated stages** —
-built on the [superpowers](https://github.com/obra/superpowers) skills.
+runs any substantial task through an up-front **intake grill** + **10 gated stages** —
+with every stage's doctrine **built in**: no companion plugin required.
 
 ## What it does
 
-`intake grill → docs study → brainstorm → spec → plan → subagent build → tests →
-lint/deploy → post-deploy log check → docs/wiki sync`
+`intake grill → docs study → brainstorm + decompose → spec → plan → subagent build →
+tests → lint/deploy → post-deploy log check → docs/wiki sync → acceptance`
 
 It **grills you first, always**: stage 0 is mandatory — a one-line task ("make me
 feature X") is expanded, one question at a time, into a locked brief, and the grill
-also sweeps stages 1→9 for anything that would stop the run later. Each stage gates
+also sweeps stages 1→10 for anything that would stop the run later. Each stage gates
 the next. Every gate is typed — **auto** (the orchestrator verifies it, pass/fail)
 or **manual** (waits for your go). One model, confirmed before the run starts.
 
@@ -23,16 +23,17 @@ or **manual** (waits for your go). One model, confirmed before the run starts.
 |---|---|---|---|
 | 0 | Intake grill — **mandatory** | shared understanding + autonomy sweep; brief locked | manual |
 | 1 | Docs study | contracts grounded on current docs | auto |
-| 2 | Brainstorm | design approved; UI verdict recorded | manual |
+| 2 | Brainstorm + decompose | design approved; UI verdict recorded; every REQ answered; platform: module map approved | manual |
 | 3 | Spec | committed + reviewed; UI: super-ux chain validated, linter green | manual |
 | 4 | Plan | parallel-ready, DoD per task | auto |
-| 5 | Dev | tasks DONE, TDD green per task | auto |
+| 5 | Dev | tasks DONE (three review verdicts each), TDD green per task | auto |
 | 6 | Tests | full suite green, new code covered | auto |
 | 7 | Lint + deploy | lint clean + suite green before deploy | manual |
 | 8 | Post-deploy | clean boot / honest degradation | auto |
 | 9 | Docs + wiki | docs + wiki synced | auto |
+| 10 | **Acceptance** | every REQ accounted for with evidence; operator signs off | manual |
 
-These stages (0 intake + 1→9) are the plugin's **example** flow. It's a machine-readable config
+These stages (0 intake + 1→10) are the plugin's **example** flow. It's a machine-readable config
 ([`pipeline.example.json`](plugins/task-pipeline/skills/task-pipeline/pipeline.example.json))
 against a universal contract
 ([`pipeline.schema.json`](plugins/task-pipeline/skills/task-pipeline/pipeline.schema.json)):
@@ -40,6 +41,35 @@ a host project copies the example to `pipeline.json` and rewrites it with its ow
 stages (any count), its own `skills[]`, and its own `auto`/`manual` gate types —
 "bring your own skills". The framework bakes in no fixed stages.
 
+## Everything is built in — zero required dependencies
+
+The doctrine each stage runs on ships inside the skill. Nothing to install for it,
+nothing to resolve at preflight, no version skew with someone else's repo, and no
+stage that can fail because a plugin is missing:
+
+| Stage | Built-in doctrine |
+|---|---|
+| 0 Intake grill | [`references/grill.md`](plugins/task-pipeline/skills/task-pipeline/references/grill.md) — interview loop, domain awareness, autonomy sweep |
+| 2 Brainstorm | [`references/brainstorm.md`](plugins/task-pipeline/skills/task-pipeline/references/brainstorm.md) — approaches, YAGNI, the no-code-before-approval gate |
+| 2 Decompose | [`references/decomposition.md`](plugins/task-pipeline/skills/task-pipeline/references/decomposition.md) — platforms only: brick criteria, module map, build order |
+| 3 Spec | [`references/spec.md`](plugins/task-pipeline/skills/task-pipeline/references/spec.md) — UX-track order, locked contracts, global constraints, self-review |
+| 4 Plan | [`references/planning.md`](plugins/task-pipeline/skills/task-pipeline/references/planning.md) — zero-context tasks, parallel groups, no placeholders |
+| 5 Build | [`references/build.md`](plugins/task-pipeline/skills/task-pipeline/references/build.md) + [`review.md`](plugins/task-pipeline/skills/task-pipeline/references/review.md) — isolation, ledger, subagent loop, review rubric, fix loop |
+| 5–6 TDD | [`references/tdd.md`](plugins/task-pipeline/skills/task-pipeline/references/tdd.md) — the iron law, red/green/refactor, the suite gate |
+| 10 Acceptance | [`references/acceptance.md`](plugins/task-pipeline/skills/task-pipeline/references/acceptance.md) — REQ coverage table, evidence rules, the closing question |
+| any loop | [`references/loop-guard.md`](plugins/task-pipeline/skills/task-pipeline/references/loop-guard.md) — churn detection, caps, the break protocol |
+
+**Ported, not depended on.** Stage 0 is adapted from
+[Matt Pocock's `grilling` / `grill-with-docs`](https://github.com/mattpocock/skills)
+and stages 2–6 from the corresponding skills in
+[obra/superpowers](https://github.com/obra/superpowers) — both MIT, both credited in
+[LICENSE](LICENSE) → *Third-party*. Nothing at runtime reaches for either.
+
+**Optional bridge:** if you already run an equivalent skill set, map it onto stages
+2/4/5/6 in your `pipeline.json` → `skills[]`. That's a substitution, never a
+requirement — the gates still govern, and nothing detects, recommends or waits for
+an external provider.
+
 ## Intake grill (stage 0) — mandatory
 
 Inspired by [Matt Pocock's grill-me](https://github.com/mattpocock/skills). Before
@@ -64,7 +94,7 @@ decisions that are hard to reverse, surprising without context **and** the resul
 a real trade-off get an ADR. Both files are created lazily.
 
 **Autonomy comes from the sweep.** Beyond the task itself, the grill pre-resolves
-everything that would otherwise interrupt stages 1→9: which external libs need docs,
+everything that would otherwise interrupt stages 1→10: which external libs need docs,
 branch and task-tracker policy, the test command and what "green" means, the lint
 command, the deploy target and its **authorization**, where logs and health live,
 which docs and runbooks to update, and the model. Each gets an answer or an explicit
@@ -72,6 +102,80 @@ which docs and runbooks to update, and the model. Each gets an answer or an expl
 authorization has a hard floor: a standing go counts only if it names the target and
 the preconditions.
 
+## The REQ spine — why nothing falls out the back
+
+Every gate before the last one asks *"is this artifact good?"* — none asks *"does
+this still contain everything that was asked for?"* Scope doesn't leak inside a
+stage; it leaks on the **seams**, because brief → spec → plan → task briefs is four
+rewrites and nothing compares the lists.
+
+So the grill's second hard output is an addressable **requirement table**: one row
+per independently verifiable deliverable, each naming how it will be verified. A
+requirement you can't say how to verify is a badly-stated requirement — it gets
+split during the grill, not discovered at the end.
+
+From there the ids thread through everything:
+
+| Where | What it does |
+|---|---|
+| Spec | every section carries `covers: REQ-…` |
+| Plan | every task carries `Implements: REQ-…`; **the gate is set equality** against the brief — a difference is printed as the explicit list of dropped requirements |
+| Build | the implementer's brief quotes the REQ statement verbatim, so it optimises the requirement and not just the instruction |
+| Review | a third verdict beside spec-compliance and code-quality: **does this satisfy its REQ?** |
+| Deploy | no REQ may still be `open`; a `partial` ships only with explicit acceptance |
+| **Acceptance** | every REQ gets `verified` / `partial` / `deferred` / `dropped` — and `verified` requires **evidence**: a passing test name, a `file:line`, a command and its output |
+
+Two rules keep it honest. **The list is frozen** — adding mid-run is free, removing
+or narrowing needs your explicit agreement, because silently restating the task
+smaller makes every later gate pass honestly on a shrunken task. And **deferred out
+loud is forgotten** — anything postponed, dropped or half-done goes into an
+append-only carry-over ledger the moment it's said, including implementer concerns
+and non-blocking review findings.
+
+Stage 10 closes the circle with the question the pipeline exists to be able to
+answer from a list rather than from memory: *here's what you asked for, here's what
+shipped, here's what's deferred and where it lives — what's missing?*
+
+## Platforms — decomposed into bricks, built one at a time
+
+A one-feature task runs the pipeline once. A **platform** — several independent
+capabilities, several separately shippable surfaces, requirements no single
+deliverable satisfies — gets cut into modules at stage 2, before any spec is
+written ([`references/decomposition.md`](plugins/task-pipeline/skills/task-pipeline/references/decomposition.md)).
+
+Modules are cut **by capability, never by layer** ("Ordering", "Billing" — not
+"Controllers", "Services"), and a candidate is only a brick when it is
+independently specifiable, buildable and testable, owns its own entities, talks to
+its neighbours through declared contracts only, and can land while leaving the
+system working. The committed module map fixes the build order — **walking skeleton
+first**, then topological, no cycles — and every requirement maps to exactly one
+module.
+
+Then stages 3→10 run **per module**: dossier → plan → build → tests → deploy →
+post-deploy → docs → acceptance → next brick. Stages 0–2 run once for the platform,
+and the map's status column is what a resumed session reads to know where it
+stopped. Each module's spec is a full dossier: architecture, entities and
+ownership, contracts in and out with their failure behavior, business rules, edge
+and failure cases, UI/Figma chain, limits, open questions.
+
+## Loop guard — churn is detected, not endured
+
+Any repeating pass can start undoing the previous one: two shapes alternating, the
+same file rewritten round after round, a finding that was closed coming back. That
+looks like progress and consumes a run, so it is
+[detected mechanically](plugins/task-pipeline/skills/task-pipeline/references/loop-guard.md):
+every repeat pass logs one line per touched file with **the reason that forced it**
+— a finding id, a failed gate item. "Cleanup" is not a reason.
+
+It trips on revert-oscillation, a file edited twice for the same reason, a
+resurrected finding, a third entry into one stage, or two loops editing one file —
+plus hard caps (5 fix rounds per task, 2 re-entries per stage, 3 passes per module).
+On a trip the run **stops editing**, names shape A and shape B with their evidence,
+escalates to the layer that owns the conflict (rubric → operator → plan → spec →
+module map), re-plans the check as an ordered checklist with one verification
+command per item, and goes through it one at a time. A higher-layer conflict is
+never settled inside a lower loop.
+
 ## UX track (user-facing tasks) — super-ux recommended
 
 The moment a task touches any user-facing surface (web / mobile / CLI / TUI — a
@@ -88,12 +192,8 @@ before interface.
 
 ## Prerequisites
 
-**superpowers** — https://github.com/obra/superpowers
-
-```
-/plugin marketplace add obra/superpowers
-/plugin install superpowers@superpowers
-```
+**None for the pipeline itself** — the doctrine for every stage ships inside the
+skill (see *Everything is built in* above).
 
 **super-ux** (only for user-facing tasks) — https://github.com/ssheleg/super-ux
 
@@ -160,8 +260,9 @@ on the same Claude Code install yields a duplicate skill).
 
 ## Use
 
-Say *"run this through the pipeline"* / *"полный цикл"* / *"прогони по конвейеру"*,
-or `/task-pipeline`. The skill creates a per-stage TaskList and walks the gates.
+Say *"run this through the pipeline"* or *"the full cycle"*, or invoke
+`/task-pipeline`. The skill creates a per-stage TaskList and walks the gates.
+Russian phrasings (*"полный цикл"*, *"прогони по конвейеру"*) route the same way.
 
 ## Model policy
 
@@ -192,79 +293,50 @@ clean checkout. Copy and adapt it per project; nothing is hardcoded.
 
 ## Companion skills
 
-`references/companion-skills.md` lists what powers each stage and how to install
-it: **superpowers** (required), **super-ux** (required for user-facing tasks —
-install line surfaced on the spot), **context7** (docs stage), **wiki-update**
-(stage 9). The stage-0 grill is **not** on that list — it's built into the skill. A
-single preflight
-block prints which are ready, which to install, and the model recommendation, so you
-arm the whole run in one exchange.
+`references/companion-skills.md` separates what's built in (stages 0, 2, 3, 4, 5, 6
+and 10 — nothing to install) from the short optional list: **super-ux** (required only for
+user-facing tasks — install line surfaced on the spot), **context7** (docs stage),
+**wiki-update** (stage 9). A single preflight block prints which are ready, which to
+install, and the model recommendation, so you arm the whole run in one exchange.
 
 ## Portability
 
-Stages 6–9 read the host project's `CLAUDE.md` conventions (tests / lint / deploy /
+Stages 6–10 read the host project's `CLAUDE.md` conventions (tests / lint / deploy /
 docs / wiki) with detection fallbacks, so the skill works in any repo. The
 canonical artifact layout each stage writes to is fixed in
 [`references/artifacts.md`](plugins/task-pipeline/skills/task-pipeline/references/artifacts.md).
 
-## По-русски
-
-**task-pipeline** — оркестратор полного цикла доставки задачи для Claude Code:
-один скилл проводит любую существенную задачу через **интейк-грил + 9 гейтованных
-стадий** (изучение доков → брейншторм → спека → план → сборка сабагентами →
-тесты → линт/деплой → пост-деплой проверка логов → синк доков/вики), построенных
-на скиллах [superpowers](https://github.com/obra/superpowers).
-
-- **Грил на входе (стадия 0) — обязателен.** Одна строка задачи («сделай фичу X»)
-  недостаточна для автономной работы, поэтому стадию нельзя пропустить: пайплайн
-  «допрашивает» оператора — по одному вопросу за ход, с рекомендованным ответом,
-  изучив код до вопроса — пока все ветки решений не закрыты и не зафиксированы в
-  брифе. Ни одна стадия 1+ не стартует без закоммиченного подтверждённого брифа.
-  **Грил встроен в скилл** — ставить нечего: вся доктрина лежит в
-  `references/grill.md`, без компаньонов, резолва и фолбэков. Портировано из
-  [grill-with-docs Мэтта Покока](https://github.com/mattpocock/skills) (MIT, см.
-  `LICENSE` → *Third-party*).
-- **Доменная осознанность на гриле.** Пайплайн читает `CONTEXT.md` / `docs/adr/`
-  проекта и держит оператора в рамках его же языка: ловит термины, конфликтующие с
-  глоссарием, заменяет размытые слова каноничными, проверяет отношения конкретными
-  краевыми сценариями, вскрывает расхождения между кодом и только что сказанным.
-  Разрешённый термин сразу пишется в `CONTEXT.md`; решение, которое трудно
-  откатить, неочевидно без контекста и стало результатом реального компромисса,
-  получает ADR. Файлы создаются лениво.
-- **Автономию даёт свип по стадиям.** Помимо самой задачи грил заранее закрывает
-  всё, что иначе остановит стадии 1→9: внешние библиотеки и где их доки, политику
-  веток и трекер задач, команду тестов и что значит «зелено», команду линта, цель
-  деплоя и **авторизацию на него**, где живут логи/health, какие доки и раннбуки
-  обновлять, и модель. По каждому пункту — либо ответ, либо явное «здесь
-  остановись и спроси»; незаданный вопрос = запланированное прерывание. У
-  авторизации деплоя жёсткий пол: постоянное «go» засчитывается, только если
-  названы цель и предусловия.
-- Ни одна стадия не стартует, пока не пройден гейт предыдущей; деплой требует
-  зелёного полного прогона тестов и явного «go» оператора.
-- **UX-трек (super-ux рекомендуется):** как только задача трогает интерфейс
-  (web/mobile/CLI/TUI), [super-ux](https://github.com/ssheleg/super-ux) —
-  рекомендуемый воркфлоу, детектится ещё на гриле; если установлен — используется,
-  если нет — сразу даётся строка установки. Стадия спеки гоняет `/ux` →
-  `ux-foundation` (персоны, JTBD, CJM) → `ux-flows` (флоу + `screens.md` — карта
-  экранов) → `ux-scenarios` (сценарии, ux-contract v4) → `/ux-lint` (линтер должен
-  быть зелёным) до написания плана; спека включает ID сценариев, `SCR-` экраны,
-  стадии CJM и UX-паттерны.
-  Сценарии — до интерфейса.
-- **Модель — одна на прогон, подтверждается один раз до старта.** Рекомендация по
-  умолчанию — *самая мощная reasoning-модель, доступная в окружении* (сейчас это
-  последнее поколение Opus, но это **тир, а не строка**). Идентификаторы моделей
-  устаревают, и провайдер может быть другой, поэтому ничего не захардкожено:
-  актуальный топ-тир определяется в рантайме, а в конфиге стадий стоят
-  провайдер-агностичные токены (`default` / `inherit`). Оператор подтверждает или
-  переопределяет (можно по стадиям) — дальше пайплайн больше не переспрашивает.
-  Сабагенты стадии 5 пинятся на подтверждённую модель автоматически.
-- Стадии 6–9 читают конвенции хост-проекта из `CLAUDE.md` (тесты / линт /
-  деплой / доки / вики), поэтому скилл работает в любом репозитории.
-
-Запуск: скажите *«полный цикл»* / *«прогони по конвейеру»* или `/task-pipeline
-<задача>`. Установка — см. раздел Install выше (плагин, `npx skills add
-ssheleg/task-pipeline`, `npx task-pipeline-skill` / `npx
-github:ssheleg/task-pipeline` или `./install.sh`).
+## What this gives you
+
+Agents write code well and judge *when to stop asking you things* badly. A
+substantial task turns into twenty interruptions, or into a confident build that
+skipped the tests. `task-pipeline` front-loads every decision into one intake
+conversation, then runs ten gated stages without stopping to check in.
+
+- **The intake grill asks what a senior engineer would ask** before anything is
+  touched — scope, edge cases, failure modes, rollback, who the user is — so the
+  build does not stall halfway through.
+- **Every stage has a gate.** No code before a spec. No deploy before tests. No
+  "done" before the post-deploy logs have been read.
+- **Team discipline without a team.** ADRs, a written plan, a real test suite, a
+  wiki entry — produced as part of the work, not promised for later.
+- **It adapts to your repo, not the reverse.** Deploy, docs and wiki conventions
+  are read from the host project, so nothing is imposed.
+
+## Author
+
+Built by ssheleg — [sshlg.me](https://sshlg.me)
+
+- X / Twitter — [@fuck_this_year](https://x.com/fuck_this_year)
+- Telegram — [@sshlg](https://t.me/sshlg)
+
+Part of the [ssheleg skill family](https://github.com/ssheleg/sshlg-skills):
+`super-ux`, `task-pipeline`, `make-skill`, `sheleg-design`, `seo-aeo-audit`.
+One command installs all five for every agent you use:
+
+```bash
+npx sshlg-skills install
+```
 
 ## License
 

package/cursor/rules/task-pipeline.mdc

@@ -1,15 +1,19 @@
 ---
-description: "task-pipeline: run a substantial task through a disciplined, gated delivery cycle — an intake grill that expands the request, then docs→brainstorm→spec→plan→build→tests→lint/deploy→post-deploy→docs. Apply when the user asks to run a task through the pipeline, the full cycle / полный цикл / прогони по конвейеру, or starts any substantial feature/fix/build."
+description: "task-pipeline: run a substantial task through a disciplined, gated delivery cycle — an intake grill that expands the request into a checkable requirement list, then docs→brainstorm→spec→plan→build→tests→lint/deploy→post-deploy→docs/wiki→acceptance. Apply when the user asks to 'run this through the pipeline' / 'прогони по конвейеру', asks for 'the full cycle' / 'полный цикл', or starts any substantial feature/fix/build."
 alwaysApply: false
 ---
 
 # task-pipeline — gated delivery cycle (Cursor)
 
 Self-contained rule (Cursor copies this file into projects — no external links).
-Run a substantial task through an up-front **intake grill + 9 gated stages**. No
+Run a substantial task through an up-front **intake grill + 10 gated stages**. No
 stage advances until its **gate** passes. Each gate is `auto` (verify it yourself,
 pass/fail) or `manual` (wait for the user's explicit go).
 
+**No companion skill is required.** Every rule below is the doctrine itself — the
+grill, the design gate, the plan format, the build loop and TDD. Nothing to
+install, nothing to resolve, nothing that breaks when a plugin is missing.
+
 ## Model — decide once, before you start
 
 Recommended: **the most capable reasoning model the environment offers** (at time
@@ -32,7 +36,7 @@ user up front, then run the rest without mid-flight questions:
 4. Walk the decision tree depth-first; ask prerequisite decisions first.
 5. Reconcile contradictions; chase dodges ("decide later" → "latest you can decide
    and still ship?").
-6. Run the **autonomy sweep** — resolve now whatever would stop stages 1→9 later:
+6. Run the **autonomy sweep** — resolve now whatever would stop stages 1→10 later:
    external libs and where their docs live; UI verdict; base branch, branch policy,
    commit convention, task tracker; the test command and what "green" means; the
    lint command; the deploy target, release toggle and **deploy authorization**;
@@ -55,6 +59,19 @@ Offer an ADR (`docs/adr/NNNN-slug.md`, 1–3 sentences is a complete ADR) only w
 all three hold: hard to reverse, surprising without context, and the result of a
 real trade-off. Any one missing → skip it.
 
+**Write the REQ spine before the brief is confirmed.** Turn the request into an
+addressable list — one row per independently verifiable deliverable (not one per
+sentence), each naming **how it is verified**: a test name, a `file:line`, a command
+and its expected output, or a scenario id. *A requirement you can't say how to
+verify is a badly-stated requirement* — split it here. Then freeze the list:
+adding later is free, **removing or narrowing needs the user's explicit
+agreement**. Quietly restating the task in smaller terms is the subtlest way to
+lose it — every later gate then passes honestly on a task that shrank.
+
+Seed a **carry-over ledger** next to the brief, append-only. Anything deferred,
+dropped, or left half-done goes in the moment it's said — including implementer
+concerns and non-blocking review findings. **Deferred out loud is forgotten.**
+
 Stop when shared understanding is reached (every branch answered or explicitly
 deferred) and lock the answers into a short brief the user confirms. Only then
 start. Later stages read that brief instead of asking again.
@@ -63,31 +80,87 @@ start. Later stages read that brief instead of asking again.
 specific (named target + named preconditions). A vague "just do everything" does
 not authorize an outward, irreversible action — stage 7 stops and asks.
 
-## Stages 1→9
+## Stages 1→10
 
 1. **Docs study** (auto) — ground every external lib/API on current docs, not recall.
-2. **Brainstorm** (manual) — 2–3 approaches + a recommendation; design approved.
-   Record whether the task touches a user-facing surface (UI verdict).
-3. **Spec** (manual) — write and commit the design; lock shared contracts. For UI
-   tasks, run the UX chain FIRST (see super-ux below) and embed it.
-4. **Plan** (auto) — zero-context tasks, exact paths, TDD steps, DoD each,
-   dependency graph + parallel groups, non-overlapping file ownership.
-5. **Dev** (auto) — isolate (worktree), TDD per task (failing test → minimal impl →
-   green → commit); two-stage review (spec compliance, then code quality).
+2. **Brainstorm + decompose** (manual) — read the brief, explore the code, then 2–3
+   approaches with a recommendation, YAGNI applied, design presented in sections and
+   approved. **Hard gate: no code, no scaffolding before that approval** — including
+   on "obviously simple" tasks. Record whether the task touches a user-facing surface
+   (UI verdict). **If the brief is a platform, not a change** — several independent
+   capabilities or separately shippable surfaces — cut it into modules before any
+   spec: modules by capability, never by layer; a module qualifies as a brick only if
+   it is independently specifiable, buildable and testable, owns its own entities,
+   talks to others through declared contracts only, and can land while leaving the
+   system working. Commit a module map (module, delivers, entities owned, depends on,
+   contracts exposed, UI?, REQs, status) in build order — the **walking skeleton
+   first**, then topologically, no cycles (a cycle means the cut is wrong). Every REQ
+   maps to exactly one module. Then stages 3→10 run **per module**, one brick at a
+   time; stages 0–2 run once, and the map's status column is the resume point. Single
+   module → record "single module: <name>" and move on.
+3. **Spec** (manual) — write and commit the design; lock every shared contract
+   (types, schemas, signatures, file layout) plus a **Global Constraints** block of
+   exact values every later task inherits. Self-review it for placeholders,
+   contradictions, ambiguity and scope before showing it. For UI tasks, run the UX
+   chain FIRST (see super-ux below) and embed it.
+4. **Plan** (auto) — every task names the REQ ids it `Implements:`, and the set of those ids must **equal** the brief's REQ set — a difference is scope lost, print it and fix it. Zero-context tasks: exact paths, complete code in every step,
+   the exact command and its expected output, TDD steps, DoD each, dependency graph
+   + parallel groups, non-overlapping file ownership. **No placeholders** — no TBD,
+   no "add error handling", no "similar to Task N", no undefined types.
+5. **Dev** (auto) — isolate first (existing worktree? native worktree tool? else
+   `git worktree` into an ignored dir), baseline tests green, then one task at a
+   time: TDD (failing test → watch it fail → minimal impl → watch it pass →
+   commit), then a review with **all three** verdicts — spec compliance, **REQ
+   satisfied** (judged against the requirement's own statement, not the task's
+   instructions), and code quality. Findings loop back to the implementer (max 5
+   rounds, then adjudicate in writing); minor findings are recorded, never blocking. Keep a progress ledger in
+   a file so a lost context can resume instead of redoing finished work. Tasks in
+   the same parallel group run concurrently **only** if each worker has its own
+   worktree — otherwise sequential. Close the stage by integrating: sync with the
+   base branch, re-run the full suite on the result, merge (or open a PR — that's
+   outward, so ask first), remove the worktree.
 6. **Tests** (auto) — full suite green (not just new tests); new/changed code
-   covered; no skip/xfail hiding red.
+   covered including failure paths; no skip/xfail hiding red. Tests assert real
+   behavior, never mock behavior.
 7. **Lint + deploy** (manual) — lint clean AND suite green before deploy; deploy is
    outward → explicit user go, or the specific standing authorization recorded in
    the stage-0 brief.
 8. **Post-deploy** (auto) — tail logs / health-check; clean boot or an honest
    degradation report (never silent success).
-9. **Docs** (auto) — update module docs/runbooks in the SAME change.
+9. **Docs + wiki** (auto) — update module docs/runbooks in the SAME change, and
+    sync the project's knowledge base/wiki if it has one.
+10. **Acceptance** (manual) — the closing stage: go back to the brief and account
+    for **every** REQ. One row each, status `verified` / `partial` / `deferred` /
+    `dropped`, and every `verified` carries **evidence** — a passing test name, a
+    `file:line`, a command and its output. "Done" without evidence is downgraded to
+    `partial`, never upgraded. Then ask out loud, list in hand: *here's what you
+    asked for, here's what shipped, here's what's deferred and where it lives —
+    what's missing?* Ask it even when the table is green. Gate: no REQ `unknown`,
+    no ledger row without a home, user signs off.
 
-Cross-cutting: answer from the brief's autonomy section rather than re-asking, track
+Cross-cutting: answer from the brief's autonomy section rather than re-asking, log every deferral in the ledger, never narrow the task silently, track
 tasks, conventional commits, honest degradation (never claim a failed/skipped step
 succeeded), and get explicit go before any outward/irreversible action (deploy,
 publish, repo create).
 
+**Loop guard — break churn instead of iterating.** Every repeating pass (a fix
+round, a re-entered stage, the next module) logs one line per touched file: the
+file, the pass, and the reason that forced it — a finding id or a failed gate item.
+"Cleanup" is not a reason. **Stop immediately** when: an edit undoes what an earlier
+pass in this run deliberately did (A→B→A); the same file is edited twice for the
+same reason; a finding already fixed or parked comes back; a stage is entered a
+third time for one artifact; two loops edit one file. Hard caps: 5 fix rounds per
+task, 2 re-entries per stage, 3 passes per module. On a stop: name shape A and shape
+B with their evidence and who asks for each; escalate to the layer that owns the
+conflict (two findings → the review rubric; finding vs plan → the user; plan vs spec
+→ back to planning; ambiguous spec → back to spec; two modules claiming one file →
+back to the module map) — **never settle a higher-layer conflict inside a lower
+loop**; then re-plan the check as an ordered checklist, one owner and one
+verification command per item, and go through it one at a time, one commit per item,
+no opportunistic edits. Re-check the list once in the same order at the end. If it
+trips again after a re-planned pass, stop and hand back with both shapes, the
+evidence and your recommendation.
+
 ## super-ux for user-facing tasks (recommended)
 
 If the task touches any UI (web/mobile/CLI/TUI), the WHY→UI→scenario chain comes

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "task-pipeline-skill",
-  "version": "0.12.0",
-  "description": "Full-cycle task delivery pipeline orchestrator skill for Claude Code \u2014 a mandatory built-in intake grill + 9 gated stages (docs, brainstorm, spec, plan, build, tests, deploy, post-deploy, docs/wiki) built on the superpowers skills, with a super-ux UX track for user-facing tasks and toggleable release automation. This package is the installer CLI.",
+  "version": "0.17.1",
+  "description": "Full-cycle task delivery pipeline orchestrator skill for Claude Code — a mandatory built-in intake grill + 10 gated stages (docs, brainstorm+decompose, spec, plan, build, tests, lint/deploy, post-deploy, docs/wiki, acceptance) whose doctrine ships inside the skill with no required companion plugin, plus a super-ux UX track for user-facing tasks and toggleable release automation. This package is the installer CLI.",
   "bin": {
     "task-pipeline": "bin/task-pipeline.js"
   },
@@ -23,11 +23,11 @@
   "keywords": [
     "pipeline",
     "workflow",
-    "superpowers",
     "orchestrator",
     "tdd",
     "deploy",
     "spec-driven",
+    "self-contained",
     "claude-code",
     "skill"
   ]

package/plugins/task-pipeline/.claude-plugin/plugin.json

@@ -1,10 +1,21 @@
 {
   "name": "task-pipeline",
-  "description": "Thin orchestrator: a mandatory built-in intake grill expands the task, sharpens its domain language and pre-resolves what would stop later stages, then docs study, brainstorm, spec, plan, subagent build, tests, lint/deploy, post-deploy log check, docs/wiki sync — typed auto/manual gates, one provider-agnostic model confirmed up front, a super-ux UX track for user-facing tasks, and toggleable project-configurable release automation. Built on the superpowers skills; generic-portable.",
-  "version": "0.12.0",
-  "author": { "name": "ssheleg" },
+  "description": "Self-contained orchestrator that runs a task through a mandatory built-in intake grill + 10 gated stages (docs, brainstorm+decompose, spec, plan, subagent build, tests, lint/deploy, post-deploy, docs/wiki, acceptance). Every stage's doctrine is built into the skill — no companion plugin required — with typed auto/manual gates, a loop guard that breaks churn, one provider-agnostic model confirmed up front, a super-ux UX track for user-facing tasks, and toggleable project-configurable release automation.",
+  "version": "0.17.1",
+  "author": {
+    "name": "ssheleg"
+  },
   "homepage": "https://github.com/ssheleg/task-pipeline",
   "repository": "https://github.com/ssheleg/task-pipeline",
   "license": "MIT",
-  "keywords": ["pipeline", "workflow", "superpowers", "orchestrator", "tdd", "deploy", "spec-driven", "claude-code"]
+  "keywords": [
+    "pipeline",
+    "workflow",
+    "orchestrator",
+    "tdd",
+    "deploy",
+    "spec-driven",
+    "self-contained",
+    "claude-code"
+  ]
 }

package/plugins/task-pipeline/commands/task-pipeline.md

@@ -1,19 +1,21 @@
 ---
-description: Run a task through task-pipeline — an intake grill that expands the request, then docs → brainstorm → spec → plan → build → tests → deploy → post-deploy → docs/wiki.
+description: Run a task through task-pipeline — an intake grill that expands the request, then docs → brainstorm → spec → plan → build → tests → deploy → post-deploy → docs/wiki → acceptance.
 argument-hint: <one-line task description>
 ---
 Use the `task-pipeline` skill to run the task below through all gated stages —
 **stage 0 intake grill** → docs study → brainstorm → spec → plan → subagent
-build → tests → lint/deploy → post-deploy → docs/wiki. The **intake grill is
-mandatory and built in** (`references/grill.md` — nothing to install): interview the
+build → tests → lint/deploy → post-deploy → docs/wiki → **acceptance**. **Every stage's doctrine is
+built into the skill** (`references/{grill,brainstorm,decomposition,spec,planning,build,review,tdd,acceptance,loop-guard}.md`)
+— no companion plugin is required for any of them. The **intake grill is
+mandatory** (`references/grill.md`): interview the
 operator one question at a time (with a recommended answer each, exploring the
 codebase before asking) until every decision branch is resolved, applying the
 grill's **domain awareness** (challenge terms against `CONTEXT.md`, sharpen fuzzy
 language, ADRs for hard-to-reverse calls) and covering the **autonomy sweep** (what
-would otherwise stop stages 1→9: docs sources, branch/tracker policy, test and lint
+would otherwise stop stages 1→10: docs sources, branch/tracker policy, test and lint
 commands, deploy target and authorization, log locations, docs/wiki targets) —
-until the brief is locked, so the rest runs autonomously. For any user-facing task, recommend/use
-**super-ux**. Honor every stage gate by its type (`auto` = verify yourself;
+until the brief is locked — including the **REQ table**, the request as an addressable list where every row names how it is verified — so the rest runs autonomously and the final stage can account for all of it. The list is frozen: adding is free, removing needs the operator's agreement. Anything deferred goes into the carry-over ledger the moment it's said. For any user-facing task, recommend/use
+**super-ux**. **If the brief describes a platform rather than a change**, stage 2 also cuts it into modules (`references/decomposition.md`) — module map committed, walking skeleton first, every REQ in exactly one module — and stages 3→10 then run per module, one brick at a time. **If any loop starts undoing an earlier pass** (same file edited twice for the same reason, a closed finding returning, a third entry into one stage), stop and run the loop guard (`references/loop-guard.md`): name both shapes, escalate to the layer that owns the conflict, re-plan the check as an ordered list, then go item by item. Honor every stage gate by its type (`auto` = verify yourself;
 `manual` = wait for explicit go). Confirm the **model once at preflight** —
 recommend the most capable one the environment offers, never a hardcoded id — then
 run the whole pipeline on it without re-asking.