Comparison with alternatives

What task-pipeline optimizes for

• An argued plan. The model tends to agree and start coding before the plan is examined; grill interrogates the decision first — one question at a time, recommendations allowed to disagree with you, closing on a pre-mortem — so what gets frozen is what survived the questioning, not the first idea that sounded good.
• Proportional depth. The pattern elsewhere is to fix shaky understanding with volume — more templates, more artifacts, the same ceremony for a rename and a rewrite. Here depth is the skill you pick (to-task / to-plan / to-roadmap / to-spec), never a template you're made to fill: a two-file fix and a month-long migration don't carry the same paperwork.
• A fixed, checkable plan contract. Steps are ### Step N with Goal / Touches / optional Logic — a format a validator (validate.sh) checks and reports on every write, not free text. The check is informational; it gates nothing.
• Rails, not a generator. You work out the plan in chat and stay its author; the capture skill serializes that decision to disk and keeps the implementing session on it. It does not invent a plan from a one-line prompt. Autopilot exists (roadmap-to-workflow fans a roadmap out to sessions) but it is an explicit opt-in over a roadmap you already approved.
• Attachable per-decision specs. After a chat discussion you can pin one or several load-bearing decisions into .task/spec/<slug>.md and cite them from any task, plan, or roadmap via a Spec: header; the implementing session reads them as fixed anchors.
• Roadmap traceability. A roadmap fans out into a generated plan per item, the driver ticks each item's checkbox as it lands, and the git history of the artifacts shows what was done.
• A small surface. No orchestration engine, no hooks, no MCP server, no API keys, no task database, and exactly one subagent — the review pass, task:code-reviewer, whose whole prompt is a readable Markdown file. All state is flat Markdown under .task/; orchestration is delegated to Claude Code's own Workflows and verification to whatever build/test command your project already declares. The consequences: everything is auditable as plain text, there is nothing extra to maintain, and there is zero lock-in.

Two honest limits frame all of it. It runs on Claude Code only — leave Claude Code and the artifacts are just Markdown you'd read by hand. And nothing is enforced: validate.sh only reports, and implement <path> is a plain instruction a session can deviate from — you stay in the loop by design, not by a gate. (A two-file, twenty-minute fix also doesn't need any of this.)

The sections below compare against six references — default Claude Code (plan mode + TodoWrite), obra/superpowers, Matt Pocock's skills, Fission-AI/OpenSpec, github/spec-kit, and claude-task-master — on one shared axis set: where the plan lives, who authors the plan, plan format, result review, moving parts & infrastructure, trace in the repo, and multi-task initiatives. Each ends with an honest "Use X if". The other tools' details are as of July 2026 and from their own docs — check them if a difference is load-bearing for you. (task-pipeline's own multilingual claim has one caveat: only your artifact prose is translated; the format's fixed strings — section headers, commit trailers, the Execution block — stay English.)

vs default Claude Code

	Default Claude Code	task-pipeline
Where the plan lives	Text in chat; lost on /clear	## Plan inside .task/task/<slug>.md; hand-editable, /clear-durable
Who authors the plan	You draft it in plan mode, but it evaporates with the context	You author it in chat; the skill only serializes what you decided
Plan format	Arbitrary text / TodoWrite items	### Step N with Goal / Touches / optional Logic, checked by validate.sh on write
Result review	Whatever the model decides to do	The ## Execution block hands the commit to task:code-reviewer: prove each finding → fix the confirmed ones inside Touches → run the project's build and tests → amend
Moving parts	None beyond the chat	Flat Markdown under .task/; nothing else added
Trace in the repo	None	Normal code commits; the plan artifacts stay local and git-excluded
Multi-task initiatives	None	to-roadmap → a plan per item, or opt-in autopilot roadmap-to-workflow

Use default Claude Code if the task is one or two files and twenty minutes. Use task-pipeline if the task is longer than one session, needs a plan you can hand-edit and resume, or should leave a record.

vs superpowers

	task-pipeline	superpowers
Who authors the plan	You, by hand; a /task:… skill serializes it	Auto-triggered by context; a skills library steers the agent
Form	Linear capture → any session implements	A library of situational skills
Project config	config.md (stack, commits, language)	Minimal
Result review	One task:code-reviewer agent: prove-before-fix, fixes scoped to Touches, your build and tests, then amend	Test-first TDD (red/green/refactor) plus a between-task code-review skill
Moving parts	Flat Markdown under .task/; Claude Code only	Skills library installed across many agents
Platforms	Claude Code only	Claude Code, Antigravity, Codex App, Codex CLI, Cursor, Factory Droid, GitHub Copilot CLI, Kimi Code, OpenCode, Pi
Artifact languages	Any, via config.md	English by default

Use task-pipeline if you want a controlled capture-then-implement process, non-English artifacts, and a review pass that has to prove a defect before it edits anything. Use superpowers if you want skills that fire automatically, a strict test-first workflow, and one library that follows you across many coding agents.

vs Matt Pocock's skills

task-pipeline's grill is openly inspired by Matt Pocock's grilling skill, and his set — grill → to-spec → to-tickets → implement → code-review — is the closest workflow-shape neighbor here, so it sits next to superpowers. Where the two diverge is scope and platform, not the "argue the plan, then capture it" instinct they share.

	task-pipeline	Matt Pocock's skills
Who authors the plan	You in chat; the capture skill serializes what you decided	You in chat via the grill loop; to-spec synthesizes the discussion (task-pipeline's grill is credited to this skill)
Plan format	Templated ### Step N with Goal / Touches / optional Logic, checked by validate.sh on write	A prose spec plus "tracer-bullet" tickets that declare their blocking edges
Result review	## Execution block hands the commit to the plugin's own task:code-reviewer; no execute skill — any plain session implements the artifact	implement builds with TDD at agreed seams, then a two-axis code-review (coding standards + spec compliance)
Scope	Capture only; the routine around a task (filing tickets, pulling work from a tracker) is left to project-level skills	Covers that routine too — to-tickets files the work and the chain reads from your tracker
Moving parts	Flat Markdown under .task/, git-excluded	Specs and tickets go to GitHub, Linear, or local files, chosen at setup
Platforms	Claude Code only	Cross-agent — "work with any model"; installs into Codex and other Agent-Skills harnesses, plus a Claude Code plugin
Multi-task initiatives	to-roadmap → a plan per item, or opt-in unattended autopilot (roadmap-to-workflow fans a roadmap out to dynamic workflows)	An interactive chain; wayfinder plans a big chunk of work resolved one ticket at a time — no unattended runner

Use task-pipeline if you want capture-only, templated-and-validated artifacts that any plain Claude Code session can implement, with tracker routine left to your own project skills. Use Matt's skills if you want one composable set that spans the whole loop — grill through tickets to review — travels across many coding agents, and files its output straight into GitHub or Linear.

vs OpenSpec

	task-pipeline	OpenSpec
Paradigm	Per-task capture, chat-first	Spec-driven (a living spec set + deltas)
Who authors the plan	You in chat; captured after the discussion	You and the agent author specs up front as the source of truth
Spec granularity	Pinned per-decision .task/spec/<slug>.md files, cited via Spec:	A living whole-system spec
Moving parts	Flat Markdown under .task/, git-excluded	An openspec/ directory committed to the repo
Trace in the repo	Invisible — a personal tool, no repo trace	Part of the repository, visible to the team
Language	Multilingual via config.md	English by default

Use task-pipeline if you want a personal tool with no trace in the repo and specs pinned per decision. Use OpenSpec if you work in a team where a whole-system spec committed to the repo is the source of truth.

vs GitHub spec-kit

	task-pipeline	GitHub spec-kit
Paradigm	Chat-first capture; no forms, no fixed phase sequence	Form-first, spec-driven ceremony
Who authors the plan	You in chat; the skill serializes it	Driven through a command sequence you fill in and refine
Workflow	One short capture skill (to-task / to-plan / to-roadmap / to-spec)	/speckit.constitution → /speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement
Moving parts	Flat Markdown under .task/; nothing to install	A specify CLI (installed via uv) plus per-agent integrations
Trace in the repo	Invisible — git-excluded	A .specify/ artifact tree committed to the repo
Platforms	Claude Code only	30+ AI coding agents, cross-agent

Use task-pipeline if you want chat-first capture with no ceremony and no repo trace. Use spec-kit if you want an explicit, phased spec workflow whose artifacts live in the repo and travel across many coding agents.

vs claude-task-master

	task-pipeline	claude-task-master
Who authors the plan	You author it in chat; the skill serializes your decisions	Generated: task-master parse-prd turns a PRD into tasks
Where tasks live	## Plan in flat Markdown under .task/	Its own .taskmaster/ task store
Moving parts & infrastructure	No MCP server, no API keys, no task database	Runs as an MCP server (npx task-master-ai); needs a provider API key (Anthropic / OpenAI / Gemini / others), or the Claude Code CLI without keys
Result review	task:code-reviewer on the commit: prove, fix inside Touches, run the build and tests, amend	Tracks task status; review is not its job
Editors	Claude Code	Cursor, Windsurf, VS Code, Q Developer CLI and others, via MCP

Use task-pipeline if you want to serialize your own decisions into flat Markdown with no extra infrastructure. Use Task Master if you want tasks generated from a PRD into a managed store and an MCP-native tracker shared across several editors.

→ Next: Troubleshooting.