task-pipeline-skill 0.9.0 → 0.12.0

package/plugins/task-pipeline/skills/task-pipeline/SKILL.md

@@ -1,20 +1,20 @@
 ---
 name: task-pipeline
-description: "Orchestrates a task through the full end-to-end delivery pipeline — an up-front intake grill that expands the request into a complete brief, then docs study, brainstorm, spec, plan, subagent-driven build, test suite, lint/deploy, post-deploy log check, and docs/wiki sync — as gated stages built on the superpowers skills. Use when the user wants to run a task through the pipeline, asks for the full cycle / полный цикл / прогони по конвейеру, invokes /task-pipeline, or starts any substantial feature, fix, or build that should follow the disciplined cycle rather than ad-hoc coding. Grills the operator first so the rest runs autonomously; recommends super-ux for any user-facing task; reminds which model to switch to per stage; reads host-project conventions for deploy/docs/wiki so it stays project-agnostic."
+description: "Use when running a substantial task through the full end-to-end delivery pipeline — an up-front intake grill that expands the request into a complete brief, then docs study, brainstorm, spec, plan, subagent-driven build, test suite, lint/deploy, post-deploy log check, and docs/wiki sync — as gated stages built on the superpowers skills. Use when the user wants to run a task through the pipeline, asks for the full cycle / полный цикл / прогони по конвейеру, invokes /task-pipeline, or starts any substantial feature, fix, or build that should follow the disciplined cycle rather than ad-hoc coding. The intake grill is mandatory — it front-loads every decision, including the per-stage autonomy sweep, so stages 1→9 run without mid-flight questions; recommends super-ux for any user-facing task; confirms one model up front (most capable available, never a hardcoded id); reads host-project conventions for deploy/docs/wiki so it stays project-agnostic."
 ---
 
 # task-pipeline
 
 Thin orchestrator. Runs a task through **gated stages**, each built on an
 existing skill. Keeps the main thread disciplined: no stage advances until its
-gate passes; each stage names the model to use.
+gate passes; the whole run uses one model, confirmed before it starts.
 
 **Grill first, then run autonomously.** A one-line task ("make me feature X") is
-never enough to finish without a human in the loop. Stage 0 **grills the operator
-up front** — a relentless, one-question-at-a-time interview that resolves every
-decision branch — and locks the answers into a brief. That front-loads all the
-human input so stages 1→9 can run to the end with only the built-in gate
-approvals, not mid-flight discovery.
+never enough to finish without a human in the loop. Stage 0 is **mandatory**: a
+relentless, one-question-at-a-time interview that resolves every decision branch
+*and* sweeps stages 1→9 for anything that would stop the run later — then locks
+the answers into a brief. Autonomy is bought there or not at all; every question
+skipped at stage 0 comes back as an interruption at stage 6.
 
 **Config contract: [`pipeline.schema.json`](pipeline.schema.json).** A pipeline is
 a machine-readable config — an ordered list of stages, each with `skills[]` (the
@@ -56,58 +56,92 @@ workflow for the WHY→UI→scenario chain (`/ux`, `ux-foundation`, `ux-flows`,
   (or `npx skills add ssheleg/super-ux`). For UI tasks the spec gate **requires**
   it — install before stage 3, otherwise stop and ask the operator to install.
 
-**grill-me (optional, enhances stage 0).** If the `grill-me` / `grilling` skill
-resolves, stage 0 uses it; otherwise stage 0 runs its own built-in grill loop —
-no hard dependency. Install (optional): `npx skills add mattpocock/skills` or the
-engineering-advanced-skills marketplace.
+**The grill is built in — no companion skill, nothing to install.** Stage 0 ships
+with this skill: the full doctrine lives in [`references/grill.md`](references/grill.md)
+(interview loop, domain awareness, autonomy sweep, output). It is **mandatory** —
+no "clear enough task" exemption, no starting stage 1 without a committed,
+operator-confirmed brief. The one sanctioned bypass is the entry-from-super-ux
+short-circuit, and even that demands a scope confirmation.
+
+Two things the grill does beyond clarifying the request:
+- **Domain awareness.** It reads the project's own `CONTEXT.md` / `docs/adr/` and
+  holds the operator to them — challenging terms that conflict with the glossary,
+  sharpening overloaded words, stress-testing with concrete scenarios, and
+  flagging where the code contradicts what was just said. Resolved terms are
+  written to `CONTEXT.md` as they land; genuinely hard-to-reverse decisions get an
+  ADR.
+- **The autonomy sweep.** It pre-resolves what would otherwise stop stages 1→9
+  mid-flight (test/lint/deploy commands, branch policy, log locations, docs
+  targets, the model decision, deploy authorization). Autonomy is bought here or
+  not at all — an unasked question is a scheduled interruption.
 
 ## How to run
 
 1. Restate the task in one line. Create a **TaskList: one task per stage, starting
    with stage 0** (survives context loss; lets you resume). Then run the
    **companion preflight** (`references/companion-skills.md`): detect which
-   companion skills resolve and emit the recommendation block — install the
-   required/recommended ones (superpowers always; super-ux for UI tasks) before
-   proceeding.
-2. **Run stage 0 (Intake grill) first** — grill the operator until shared
-   understanding is reached and the brief is locked (`references/stages.md` → 0).
-   Do not touch stage 1 before the brief is confirmed. **Entered from super-ux?**
+   companion skills resolve and emit ONE block covering both the companions —
+   install the required/recommended ones (superpowers always; super-ux for UI
+   tasks) — **and the model decision** (`references/model-tiering.md`): recommend
+   the most capable model available, let the operator confirm or override, record
+   it. Ask once, here.
+2. **Run stage 0 (Intake grill) — always, no exceptions.** Grill until shared
+   understanding is reached, the autonomy sweep is covered and the brief is locked
+   (`references/stages.md` → 0). Do not touch stage 1 before the brief is
+   committed and confirmed. **Entered from super-ux?**
    (a validated `docs/ux/` chain and/or a `docs/ux/plans/…` fix plan already
    exists — super-ux's `/ux` hands off here) → don't re-grill or rebuild the UX
    chain: just check it's OK (`/ux-lint` green), confirm scope in one line, and
    skip ahead to the first stage with real work (see `references/stages.md` → 0).
-3. Walk stages 1→9. Before each: **model check** (see `references/model-tiering.md`) —
-   if recommended ≠ current, emit the reminder block and wait for the operator to `/model`.
+3. Walk stages 1→9 on the model confirmed at preflight. **Don't re-ask about the
+   model at every boundary** — only when the operator recorded a per-stage override
+   map and the next stage's entry differs (`references/model-tiering.md`).
 4. Do **not** advance until the stage **gate** passes (`references/stages.md`).
    Honor the gate **type**: for `auto`, verify the gate's `check` yourself and
    stop/return on fail; for `manual`, present the result and **wait for the
    operator's explicit "continue"/go** — an auto gate never substitutes for a
    required manual approval.
-5. Cross-cutting, every stage: task tracker + conventional commits per host
-   conventions; worktree isolation for the build; honest degradation (never claim a
-   failed/skipped step succeeded); outward/irreversible actions (deploy, publish,
-   repo create) need explicit operator go.
+5. Cross-cutting, every stage: **answer from the brief's autonomy section rather
+   than asking again** — it was grilled precisely so you wouldn't have to; task
+   tracker + conventional commits per host conventions; worktree isolation for the
+   build; honest degradation (never claim a failed/skipped step succeeded);
+   outward/irreversible actions (deploy, publish, repo create) need explicit
+   operator go — or a **specific** standing authorization recorded in the brief
+   (named target + preconditions; a vague "do everything" is not one).
 
 ## Stages (detail in `references/stages.md`)
 
-| # | Stage | Model | Invoke | Gate | Type |
-|---|---|---|---|---|---|
-| 0 | Intake grill | Fable | `grill-me` / `grilling` if present, else built-in grill loop | shared understanding reached; brief locked + confirmed | manual |
-| 1 | Docs study | Fable | `context7` (resolve-library-id → get-library-docs) / `context7-docs` | contracts grounded on fetched docs | auto |
-| 2 | Brainstorm | Fable | `superpowers:brainstorming` + **UI detection** | design approved; UI verdict recorded | manual |
-| 3 | Spec | Fable | **UI → super-ux chain first** (`/ux` → `ux-foundation` CJM → `ux-flows` screens → `ux-scenarios` → `/ux-lint`), then spec `docs/superpowers/specs/…-design.md` | committed + reviewed; UI: chain validated, linter green, scenarios/`SCR-` traced | manual |
-| 4 | Plan | Fable | `superpowers:writing-plans` → `docs/superpowers/plans/…md` | parallel-ready, DoD per task | auto |
-| 5 | Dev | **Opus** | `superpowers:using-git-worktrees` + `superpowers:subagent-driven-development` (TDD) | tasks DONE, TDD green per task | auto |
-| 6 | Tests | **Opus** | host test runner + `superpowers:test-driven-development` | full suite green; new/changed code covered | auto |
-| 7 | Lint + deploy | host | host lint → deploy per host convention | lint clean + suite green before deploy; deploy needs go | manual |
-| 8 | Post-deploy | host | tail deploy logs / health-check | clean boot or honest degradation report | auto |
-| 9 | Docs + wiki | host | host module docs/runbook rules → `wiki-update` | docs synced, wiki synced | auto |
-
-## Model reminder (emit at a boundary when recommended ≠ current)
-
-> ⏸ **Stage N (`<stage>`) recommends `<model>` (`<id>`).** You're on `<current>`.
-> Switch: `/model <id>` — then say "continue". *(Reminder only — override if you
-> don't have that model.)*
+All stages run on the **one model confirmed at preflight** (default: the most
+capable available — see `references/model-tiering.md`).
+
+| # | Stage | Invoke | Gate | Type |
+|---|---|---|---|---|
+| 0 | Intake grill — **mandatory** | built in: [`references/grill.md`](references/grill.md) | shared understanding reached; autonomy sweep covered; brief locked + confirmed | manual |
+| 1 | Docs study | `context7` (resolve-library-id → get-library-docs) / `context7-docs` | contracts grounded on fetched docs | auto |
+| 2 | Brainstorm | `superpowers:brainstorming` + **UI detection** | design approved; UI verdict recorded | manual |
+| 3 | Spec | **UI → super-ux chain first** (`/ux` → `ux-foundation` CJM → `ux-flows` screens → `ux-scenarios` → `/ux-lint`), then spec `docs/superpowers/specs/…-design.md` | committed + reviewed; UI: chain validated, linter green, scenarios/`SCR-` traced | manual |
+| 4 | Plan | `superpowers:writing-plans` → `docs/superpowers/plans/…md` | parallel-ready, DoD per task | auto |
+| 5 | Dev | `superpowers:using-git-worktrees` + `superpowers:subagent-driven-development` (TDD) | tasks DONE, TDD green per task | auto |
+| 6 | Tests | host test runner + `superpowers:test-driven-development` | full suite green; new/changed code covered | auto |
+| 7 | Lint + deploy | host lint → deploy per host convention | lint clean + suite green before deploy; deploy needs a go (or the brief's specific standing authorization) | manual |
+| 8 | Post-deploy | tail deploy logs / health-check | clean boot or honest degradation report | auto |
+| 9 | Docs + wiki | host module docs/runbook rules → `wiki-update` | docs synced, wiki synced | auto |
+
+## Model — ask once, at preflight
+
+Default recommendation: **the most capable reasoning model the environment
+offers** (currently the latest Opus generation — read that as a tier, not a
+string). **Never hardcode a model id**: generations ship, tiers get renamed, and
+the operator may be on another provider entirely — resolve the top tier available
+at runtime. Stage configs use provider-agnostic tokens (`default` / `inherit`).
+
+> 🧠 **Model for this run:** recommended **`<top tier available>`**. You're on
+> `<current>`. `/model <id>` to switch, or "keep current", or name per-stage
+> overrides. *(Reminder only — if that tier isn't available, say which one you're
+> using and continue.)*
+
+Record the answer in the brief; don't re-ask per stage. Stage-5 subagents are
+pinned to the confirmed model automatically. Detail: `references/model-tiering.md`.
 
 ## Bring your own skills
 
@@ -124,6 +158,7 @@ automation is on — `pipeline.schema.json` is the only contract.
 
 - `pipeline.schema.json` — the universal pipeline config contract (stages + release)
 - `pipeline.example.json` — this plugin's default flow (stage 0 + 1→9) + release, as config
+- `references/grill.md` — the built-in stage-0 grill: loop, domain awareness, autonomy sweep
 - `references/stages.md` — per-stage detail + exact gate criteria + gate types
 - `references/model-tiering.md` — model map, ids, the `/model` reminder mechanic, override
 - `references/conventions.md` — how stages 6–9 read the host project's CLAUDE.md

package/plugins/task-pipeline/skills/task-pipeline/pipeline.example.json

@@ -1,25 +1,30 @@
 {
   "$schema": "./pipeline.schema.json",
   "version": 1,
-  "_note": "EXAMPLE ONLY — copy this file, rename to pipeline.json in your project, and rewrite it. This particular example encodes the plugin's own default flow (an up-front intake grill + superpowers + a super-ux UX track for user-facing tasks); it is NOT a fixed contract. Your project defines its own stages (any count), each executed by your own skills/agents, with your own gate types. The universal contract is pipeline.schema.json; test/validate.py checks this example against it. gate.type: auto = orchestrator verifies the check itself (pass/fail); manual = wait for an explicit operator go. Which stages are manual vs auto is the operator's decision, not the plugin's.",
+  "_note": "EXAMPLE ONLY — copy this file, rename to pipeline.json in your project, and rewrite it. This particular example encodes the plugin's own default flow (an up-front intake grill + superpowers + a super-ux UX track for user-facing tasks); it is NOT a fixed contract. Your project defines its own stages (any count), each executed by your own skills/agents, with your own gate types. Stage models use provider-agnostic tokens ('default' = the model confirmed for the run, 'inherit' = whatever the operator is on) — never hardcode a vendor model id, it goes stale. The universal contract is pipeline.schema.json; test/validate.py checks this example against it. gate.type: auto = orchestrator verifies the check itself (pass/fail); manual = wait for an explicit operator go. Which stages are manual vs auto is the operator's decision, not the plugin's.",
   "stages": [
     {
       "id": 0,
       "state": "intake",
       "name": "Intake grill",
-      "model": "claude-fable-5",
-      "skills": ["grill-me", "grilling"],
+      "model": "default",
+      "skills": [
+        "task-pipeline:grill"
+      ],
       "gate": {
         "type": "manual",
-        "check": "grill the operator one question at a time (recommended answer per question; explore codebase/docs before asking) until shared understanding is reached — every decision branch has a recorded answer or explicit deferral, no open contradictions; UI verdict recorded (arms super-ux); decisions locked into a committed task brief the operator confirms before stage 1"
+        "check": "MANDATORY stage — never skipped (only sanctioned bypass: the entry-from-super-ux short-circuit). The grill is built into the skill (references/grill.md) — no companion to install. Per its contract: one question at a time, a recommended answer with each, explore the codebase/docs before asking, depth-first, contradictions reconciled; domain awareness applied (terms challenged against CONTEXT.md, ADRs recorded for hard-to-reverse calls). The autonomy sweep is covered — every stage 1-9 has its blockers pre-resolved (docs sources, branch/tracker policy, test + lint commands, deploy target and authorization, log/health locations, docs+wiki targets) or is explicitly marked 'stop and ask here'. UI verdict recorded (arms super-ux); model decision recorded. All of it locked into a committed task brief the operator confirms before stage 1."
       }
     },
     {
       "id": 1,
       "state": "docs-study",
       "name": "Docs study",
-      "model": "claude-fable-5",
-      "skills": ["context7", "context7-docs"],
+      "model": "default",
+      "skills": [
+        "context7",
+        "context7-docs"
+      ],
       "gate": {
         "type": "auto",
         "check": "every contract the design will lock is grounded in fetched docs, not recall; unresolvable libraries are flagged in the spec"
@@ -29,8 +34,10 @@
       "id": 2,
       "state": "brainstorm",
       "name": "Brainstorm",
-      "model": "claude-fable-5",
-      "skills": ["superpowers:brainstorming"],
+      "model": "default",
+      "skills": [
+        "superpowers:brainstorming"
+      ],
       "gate": {
         "type": "manual",
         "check": "the user approves the design AND the UI verdict is recorded (does the task touch a user-facing surface — web/mobile/CLI/TUI? this arms the stage-3 UX track)"
@@ -40,30 +47,40 @@
       "id": 3,
       "state": "spec",
       "name": "Spec",
-      "model": "claude-fable-5",
-      "skills": ["super-ux:ux-foundation", "super-ux:ux-scenarios", "superpowers:brainstorming"],
+      "model": "default",
+      "skills": [
+        "super-ux:ux-foundation",
+        "super-ux:ux-flows",
+        "super-ux:ux-scenarios",
+        "superpowers:brainstorming"
+      ],
       "gate": {
         "type": "manual",
-        "check": "spec committed and user-reviewed with all shared contracts locked; for UI tasks additionally: UX track ran FIRST (/ux -> ux-foundation CJM -> ux-scenarios), scenarios validated in docs/ux/scenarios.md, CJM/foundation coverage present, and every user-facing spec requirement traces to a scenario ID — scenarios come BEFORE interface"
+        "check": "UX track ran FIRST for user-facing tasks (/ux -> ux-foundation CJM -> ux-flows screens -> ux-scenarios -> /ux-lint green); spec committed and user-reviewed; every user-facing requirement traces to a scenario ID"
       }
     },
     {
       "id": 4,
       "state": "plan",
       "name": "Plan",
-      "model": "claude-fable-5",
-      "skills": ["superpowers:writing-plans"],
+      "model": "default",
+      "skills": [
+        "superpowers:writing-plans"
+      ],
       "gate": {
         "type": "auto",
-        "check": "every spec requirement maps to a task; no placeholders; parallel-group tasks share no files; for UI tasks each user-facing task names the scenario ID(s) it implements and its DoD includes satisfying them"
+        "check": "every spec requirement maps to a task; no placeholders; parallel-group tasks share no files; UI tasks name the scenario ID(s) and SCR- screen(s) they implement in their DoD"
       }
     },
     {
       "id": 5,
       "state": "dev",
       "name": "Dev",
-      "model": "claude-opus-4-8",
-      "skills": ["superpowers:using-git-worktrees", "superpowers:subagent-driven-development"],
+      "model": "default",
+      "skills": [
+        "superpowers:using-git-worktrees",
+        "superpowers:subagent-driven-development"
+      ],
       "gate": {
         "type": "auto",
         "check": "all plan tasks DONE (two-stage review: spec compliance, then code quality); full test suite green"
@@ -73,8 +90,10 @@
       "id": 6,
       "state": "tests",
       "name": "Tests",
-      "model": "claude-opus-4-8",
-      "skills": ["superpowers:test-driven-development"],
+      "model": "default",
+      "skills": [
+        "superpowers:test-driven-development"
+      ],
       "gate": {
         "type": "auto",
         "check": "full suite green (not just new tests); new/changed code covered; no skip/xfail smuggling a red suite past the gate"
@@ -84,19 +103,24 @@
       "id": 7,
       "state": "lint-deploy",
       "name": "Lint + deploy",
-      "model": "inherit",
-      "skills": ["host:lint", "host:deploy"],
+      "model": "default",
+      "skills": [
+        "host:lint",
+        "host:deploy"
+      ],
       "gate": {
         "type": "manual",
-        "check": "lint clean and full suite green before deploy; deploy is outward and needs explicit operator go"
+        "check": "lint clean and full suite green before deploy; deploy is outward and needs explicit operator go — or the specific standing authorization recorded in the stage-0 brief (named target + named preconditions; a vague 'do everything' is not one)"
       }
     },
     {
       "id": 8,
       "state": "post-deploy",
       "name": "Post-deploy",
-      "model": "inherit",
-      "skills": ["host:health-check"],
+      "model": "default",
+      "skills": [
+        "host:health-check"
+      ],
       "gate": {
         "type": "auto",
         "check": "clean boot confirmed (no error spike, live subsystems healthy), or an honest degradation report with next steps"
@@ -106,8 +130,11 @@
       "id": 9,
       "state": "docs-wiki",
       "name": "Docs + wiki",
-      "model": "inherit",
-      "skills": ["host:module-docs", "wiki-update"],
+      "model": "default",
+      "skills": [
+        "host:module-docs",
+        "wiki-update"
+      ],
       "gate": {
         "type": "auto",
         "check": "docs in sync with code in the same change; wiki synced; dangling links fixed"

package/plugins/task-pipeline/skills/task-pipeline/pipeline.schema.json

@@ -45,7 +45,7 @@
         "id": { "type": "integer", "description": "Optional ordinal." },
         "state": { "type": "string", "minLength": 1, "description": "Unique stable key for the stage." },
         "name": { "type": "string", "description": "Optional human label." },
-        "model": { "type": "string", "description": "Optional recommended model id for the stage." },
+        "model": { "type": "string", "description": "Optional model for the stage. Prefer a provider-agnostic token over a vendor id, which goes stale as generations ship and may not exist on the operator's provider at all: 'default' = the model confirmed for this run (recommended: the most capable reasoning model the environment offers), 'inherit' = whatever the operator is currently on. A literal id is allowed but treated as an example, not a contract." },
         "skills": {
           "type": "array",
           "minItems": 1,

package/plugins/task-pipeline/skills/task-pipeline/references/artifacts.md

@@ -8,7 +8,10 @@ shape.
 ## In the host project
 
 ```
+CONTEXT.md                            # stage 0 — domain glossary, written inline as terms resolve
 docs/
+  adr/
+    NNNN-<slug>.md                    # stage 0 — ADRs for hard-to-reverse decisions
   superpowers/
     specs/
       YYYY-MM-DD-<topic>-brief.md     # stage 0 — locked intake brief (grill output)
@@ -33,7 +36,8 @@ design → plan is traceable at a glance.
 
 | Stage | Writes | Consumed by |
 |---|---|---|
-| 0 Intake | `specs/<topic>-brief.md` (seed from `templates/brief.md`) | stages 2–4 |
+| 0 Intake | `specs/<topic>-brief.md` (seed from the skill's `templates/brief.md`) | stages 2–4 |
+| 0 Grill (domain) | `CONTEXT.md`, `docs/adr/NNNN-<slug>.md` — created **lazily**, only when a term resolves or a decision qualifies | stages 2–4 + the repo |
 | 3 Spec | `specs/<topic>-design.md` (+ links `docs/ux/*` for UI) | stage 4 |
 | 4 Plan | `plans/<topic>.md` | stage 5 |
 | 3 UX track | `docs/ux/{foundation,flows,screens,scenarios}.md` | stages 4–9 + `/ux-lint` |
@@ -51,9 +55,9 @@ plugins/task-pipeline/
     SKILL.md
     pipeline.schema.json                      # generic pipeline contract
     pipeline.example.json                     # this plugin's own flow, as config
-    references/{stages,model-tiering,conventions,artifacts,companion-skills}.md
+    references/{grill,stages,model-tiering,conventions,artifacts,companion-skills}.md
 cursor/rules/task-pipeline.mdc                # Cursor channel (self-contained rule)
-templates/brief.md                            # skeleton seeded at stage 0
+plugins/task-pipeline/skills/task-pipeline/templates/{brief,context,adr}.md      # stage-0 skeletons (ship on every channel)
 bin/task-pipeline.js                          # npx installer (package task-pipeline-skill)
 package.json
 install.sh                                    # POSIX installer

package/plugins/task-pipeline/skills/task-pipeline/references/companion-skills.md

@@ -5,20 +5,25 @@ skills. Preflight-detect each one; if a needed skill doesn't resolve, **give the
 operator the install line immediately** and (for required ones) stop until it's
 installed. Never silently degrade a required capability.
 
+**Stage 0 is the exception: the grill is part of this skill**
+(`references/grill.md`), so it has no companion, no install line and no failure
+mode where it can't run.
+
 ## The matrix
 
 | Skill / tool | Needed for | Required? | Install |
 |---|---|---|---|
 | **superpowers** (`brainstorming`, `writing-plans`, `subagent-driven-development`, `using-git-worktrees`, `test-driven-development`) | stages 2, 4, 5, 6 | **Required** (always) | `/plugin marketplace add obra/superpowers` → `/plugin install superpowers@superpowers` |
 | **super-ux** (`ux-foundation`, `ux-flows`, `ux-scenarios`, `ux-audit`, `/ux`, `/ux-lint`) | stage 3 UX track | **Required for any user-facing task** | `/plugin marketplace add ssheleg/super-ux` → `/plugin install super-ux@super-ux` (or `npx skills add ssheleg/super-ux`) |
-| **grill-me** / **grilling** | stage 0 intake grill | Optional (built-in grill loop is the fallback) | `npx skills add mattpocock/skills`, or the engineering-advanced-skills marketplace |
+| ~~grill-me / grilling~~ | — | **Not a dependency.** The stage-0 grill is **built into this skill** (`references/grill.md`) — nothing to install, nothing to resolve, no fallback path | — |
 | **context7** (MCP) | stage 1 docs study | Recommended (web-search fallback) | connect the context7 MCP server |
 | **wiki-update** | stage 9 wiki sync | Optional (skip wiki if absent) | user's wiki skill set |
 
-## Preflight recommendation (emit before stage 0)
+## Preflight (emit before stage 0)
 
-At the very start, detect which of the above resolve and print ONE recommendation
-block so the operator can arm the full flow before work begins. Example:
+At the very start, detect which of the above resolve and print ONE block —
+companions **plus the model decision** (`model-tiering.md`), so the operator arms
+the whole run in a single exchange. Example:
 
 ```
 Pipeline companions:
@@ -27,17 +32,32 @@ Pipeline companions:
                            /plugin marketplace add ssheleg/super-ux
                            /plugin install super-ux@super-ux
   ✓ context7           — ready
-  ✗ grill-me           — optional; falling back to the built-in grill loop
   ✓ wiki-update        — ready
-Recommend installing the ✗ items marked recommended, then say "continue".
+  • intake grill       — built in, no install needed
+
+🧠 Model for this run: recommended <top tier available>. You're on <current>.
+   /model <id> to switch, or "keep current", or name per-stage overrides.
+
+Install the ✗ items you want, answer the model line, then say "continue".
 ```
 
 Rules:
 - Only flag **super-ux** as recommended when the task implies a UI (the stage-0
   grill decides this; when unsure, flag it — a false positive costs one install).
 - **superpowers** missing → stop; it's required for the core stages.
+- **Never gate stage 0 on an install.** The grill ships with this skill; there is
+  no external grill dependency to detect, recommend, or fall back from.
 - Optional tools missing → state the fallback, don't block.
 - Re-detect after the operator installs; don't assume.
+- The model answer goes into the brief. Don't ask again per stage
+  (`model-tiering.md` → *Mechanic*).
+
+## Credit
+
+The built-in grill is adapted from Matt Pocock's `grilling` / `grill-with-docs`
+skills (MIT, https://github.com/mattpocock/skills) — see the repo `LICENSE` →
+*Third-party*. It is **ported, not depended on**: no install, no resolution, no
+version skew.
 
 ## Hand-off the other direction
 

package/plugins/task-pipeline/skills/task-pipeline/references/grill.md

@@ -0,0 +1,131 @@
+# The grill — stage 0, built in
+
+The intake grill is **part of this skill**. No companion skill to install, no
+provider to resolve, nothing to fall back to: this file *is* the implementation.
+
+Its job is not to design. It is to take a one-line request ("make me feature X")
+and interview it into a brief complete enough that stages 1→9 finish without
+coming back to the operator.
+
+> Adapted, with thanks, from Matt Pocock's `grilling` / `grill-with-docs` skills
+> (MIT — see this repo's `LICENSE` → *Third-party*). The domain-awareness
+> half — glossary challenges, `CONTEXT.md`, ADR discipline — comes from there; the
+> autonomy sweep and the brief are this pipeline's.
+
+## The loop
+
+Interview the operator relentlessly about every aspect of the task until you reach
+a **shared understanding**. Walk down each branch of the decision tree, resolving
+dependencies between decisions one by one.
+
+1. **One question per turn.** Never bundle. Wait for the answer before the next.
+2. **Recommend an answer with every question** (+ a one-line rationale). "What do
+   you think?" is lazy — you have the codebase in front of you, they don't.
+3. **If the codebase can answer it, go read the codebase.** Spending the
+   operator's turn on something `grep`/`Read`/context7 would have told you is the
+   most common way to waste a grill.
+4. **Depth-first.** Finish a branch before opening another; ask prerequisite
+   decisions first, so later answers don't invalidate earlier ones.
+5. **Reconcile contradictions immediately**, and chase dodges: "we'll decide
+   later" → "what's the latest you can decide and still ship?"
+6. **Cover the autonomy sweep** (below). An unasked question is not neutral — it
+   is a scheduled interruption at stage 6.
+
+**Stop** when a re-scan surfaces no new branches. Don't grill past diminishing
+returns: genuinely reversible calls can be deferred with a note.
+
+## Domain awareness
+
+While exploring the codebase, also look for what the project already says about
+itself — and hold the operator to it.
+
+### Find the existing docs
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── docs/adr/
+│   ├── 0001-event-sourced-orders.md
+│   └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+A `CONTEXT-MAP.md` at the root means multiple contexts, and points at where each
+one lives (`src/ordering/CONTEXT.md`, `src/billing/CONTEXT.md`, …), each with its
+own `docs/adr/` alongside the system-wide one. Infer which context the task
+belongs to; if it's genuinely unclear, ask.
+
+Create these files **lazily** — only when you have something real to write.
+
+### Techniques during the session
+
+- **Challenge against the glossary.** When a term conflicts with `CONTEXT.md`, say
+  so on the spot: *"Your glossary defines 'cancellation' as X, but you seem to mean
+  Y — which is it?"*
+- **Sharpen fuzzy language.** Vague or overloaded terms get a proposed canonical
+  one: *"You're saying 'account' — do you mean the Customer or the User? Those are
+  different things."*
+- **Stress-test with concrete scenarios.** Invent specific cases that probe edge
+  conditions and force precision about the boundaries between concepts.
+- **Cross-reference with the code.** When the operator states how something works,
+  check whether the code agrees, and surface contradictions: *"Your code cancels
+  entire Orders, but you just said partial cancellation is possible — which is
+  right?"*
+- **Update `CONTEXT.md` inline.** Resolve a term → write it down right then, not in
+  a batch at the end. Format: [`templates/context.md`](../templates/context.md).
+  Keep it free of implementation detail — only terms a domain expert would
+  recognize.
+
+### Offer an ADR sparingly
+
+Only when **all three** are true:
+
+1. **Hard to reverse** — changing your mind later carries real cost.
+2. **Surprising without context** — a future reader will ask "why on earth this
+   way?"
+3. **A real trade-off** — genuine alternatives existed and one was chosen for
+   specific reasons.
+
+Any one missing → skip it. Format and what qualifies:
+[`templates/adr.md`](../templates/adr.md). ADRs land in `docs/adr/` with sequential
+numbering (scan for the highest number, increment).
+
+## The autonomy sweep
+
+Resolving the *task* is not enough. The grill must also pre-resolve everything that
+would otherwise stop stages 1→9 mid-flight. Every row gets an answer **or** an
+explicit "stop and ask me here":
+
+| Stage | What to settle up front |
+|---|---|
+| run-wide | the model decision ([`model-tiering.md`](model-tiering.md)); what to decide autonomously vs escalate |
+| 1 Docs | external libs/APIs/SDKs in play; any private ones context7 can't resolve → where their docs live |
+| 2–3 Spec | UI verdict (arms super-ux); any scenario-tracing waiver |
+| 4–5 Dev | base branch; worktree/branch policy; is `main` off-limits; commit convention; task tracker |
+| 6 Tests | the test command; what "green" means here; known-red baseline; coverage expectation |
+| 7 Lint+deploy | lint command; deploy target and path; release automation on/off; deploy-from-main rule; **deploy authorization** |
+| 8 Post-deploy | where logs / health live (app name, endpoint, workflow) |
+| 9 Docs+wiki | which module docs / runbooks this change updates; wiki sync yes/no |
+
+**Deploy authorization has a hard floor.** Deploy and publish are outward and
+irreversible, so a vague "just do everything" authorizes nothing. A standing
+authorization counts only when it is **specific** — named target, named
+preconditions ("staging once lint and the full suite are green; production always
+asks"). Specific and recorded → it satisfies the stage-7 manual gate. Broader,
+absent or ambiguous → stage 7 stops and asks.
+
+## Output
+
+Everything resolved goes into the **task brief**, seeded from
+[`templates/brief.md`](../templates/brief.md) and committed to
+`docs/superpowers/specs/YYYY-MM-DD-<topic>-brief.md` — scope, users, UI verdict,
+constraints, locked decisions, the autonomy table, done-criteria, open
+assumptions. Seed the template only when the file is absent; never overwrite an
+existing brief.
+
+Plus, where the session produced them: an updated `CONTEXT.md` and any ADRs, each
+written as the decision landed.
+
+The operator confirms the brief. Only then does stage 1 begin.