Talk it through, grill the plan, capture it as a task, a roadmap or a spec. 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-task 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
> Read [.task/CLAUDE.md](../CLAUDE.md) and follow its `## Executing a task` section./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/CLAUDE.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 pointer) 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.