Talk it through, grill the plan, capture it at the depth you pick. Any later session reads the file and runs it. A free plugin — no server, no hooks, no MCP.
This is an example of what /task:to-plan produces for the run above — a plain Markdown file under .task/, not a screenshot. Header, ---, ## Description, a step-by-step ## Plan, and the stamped ## Execution block that tells any session what to do next.
# HTTP retry with backoff
---
## Description
### Problem
Outbound calls to the payments API fail intermittently under load, and a single
timeout currently drops the whole request.
### Outcome
Transient failures (timeouts, 5xx, 429) retry with exponential backoff and
jitter, capped at 5 attempts. A request that exhausts every attempt lands in a
dead-letter queue for later inspection instead of being silently lost.
## Plan
### Step 1: Wrap the payments client in a retry policy
**Goal:** Every outbound payments call retries transient failures with
exponential backoff plus jitter, giving up after 5 attempts.
**Touches:** `src/payments/client.ts` `src/payments/retry.ts`
**Logic:** Classify the error — timeout / 5xx / 429 are retryable, other 4xx
fail fast. Sleep `base * 2 ** attempt` plus random jitter between tries; surface
the last error once the cap is hit.
### Step 2: Route exhausted retries to a dead-letter queue
**Goal:** A call that fails all 5 attempts is written to the DLQ with its payload
and last error, instead of surfacing as an unhandled failure.
**Touches:** `src/payments/client.ts` `src/payments/dead-letter.ts`
**Logic:** After the retry cap, enqueue `{ request, lastError, attempts }` and
return a typed `RetriesExhausted` result the caller can branch on.
## Execution
> If `Spec:` headers are present, read each `.task/spec/<slug>.md` first and honor its
> decisions as fixed. `.task/` is pipeline-internal and invisible to the repo: never name
> `.task/` paths, spec/roadmap/task slugs, or `§` numbers in code, comments, commits, or PR
> text. Implement the Plan above (or the Description if none) with the tools in
> `.task/config/config.md` → Code Navigation / Code Editing, then commit per
> `.task/config/config.md` → Commit Format. Then spawn the `task:code-reviewer` agent on this
> file: it proves each finding, fixes confirmed defects within **Touches** plus regressions
> this diff introduced outside them, runs Build and Tests, and amends the commit; with no
> `## Plan`, scope fixes to what you changed. If `Roadmap:` + `Source item:` are present,
> tick item #N's checkbox in `.task/roadmap/<slug>.md` once the review returns OK./plugin marketplace add https://github.com/SpaiR/task-pipeline.git
/plugin install task@task-pipelineThat's the whole setup. The first capture in a new project writes .task/config/config.md for you — there's no separate setup step. See Getting started for the first run end to end.
task-pipeline is not an orchestration engine. No hooks, no execution loop of its own, and exactly one subagent — the review pass, whose entire prompt is a Markdown file you can read — plus one file per task and your project's own checks running against the diff. The neighbors sell breadth — dozens of skills, a full SDLC in a box. This one sells the opposite: the least structure that still makes a plan outlive its session.
task-pipeline is for tasks longer than one session — work that needs a plan you can hand-edit, or that should leave a record. A two-file, twenty-minute fix doesn't need this; default Claude Code (plan mode + TodoWrite) is the better tool there.
Reach for it when the plan deserves an argument and a record: real forks to interrogate, decisions a colleague — or tomorrow-you — will reread, work that spans several tasks. And when it should outlast a /clear. Descriptions are written in your language; only the format's fixed strings (section headers, commit trailers, the Execution block) stay English. The comparison page lays out where it fits against six references — default Claude Code, superpowers, Matt Pocock's skills, OpenSpec, spec-kit, and claude-task-master.
If this is the shape of tool you've wanted, star it on GitHub — it's how you'll find it again.