Why Strikethroo?
Most spec-driven tools optimize the input: better spec in, better code out, human catches the rest at the end. Strikethroo assumes the agent is an unreliable narrator of its own work -- including a second agent asked to review the first -- and that the scarce resource is your attention, not tokens.
You review the plan, not the diff
Correcting a plan costs a sentence. Correcting the same misunderstanding in a diff costs a review cycle, a rework cycle, and a re-review. An explicit approval gate puts your careful read where it is worth the most, and one question is asked at a time so it never gets skim-answered.
Guarantees are compiled, not requested
A rule in Markdown is a request; a rule in TypeScript is a guarantee. Hooks and templates are yours to edit. The certification rule -- an uncertified review is never reported as a clean one -- is compiled and cannot be loosened by editing a hook.
Nobody marks their own homework
The optional review gate runs on a different harness than the one that wrote the code -- the current harness is structurally excluded from the candidate set, not merely deprioritized. The reviewer detects and never fixes; findings are reported for you to act on.
Bends to your conventions
Plain-Markdown hooks fire at eleven points across the workflow; inject your test commands, standards, and domain rules so every plan, task, and run inherits them. No plugins, no code.
Speed, measured honestly. The industry clock starts at the prompt and stops when code appears. The clock that pays your salary stops when the code is merged -- and on that clock, generation is a rounding error next to the review rounds a fast-but-wrong draft costs you. Strikethroo is built against the second clock. That is not quality traded for speed; on that clock they are the same number.
Read the full thesis, with the file-by-file claims to verify it yourself: Why Strikethroo.
Also true, and less interesting: no API keys (runs on the subscription you already pay for), harness-agnostic Agent Skills (one SKILL.md on any harness supporting the format), and clean per-agent context at every step.
Adapts to every codebase
Every codebase has its own conventions, and Strikethroo bends to them instead of imposing its own. Three plain-Markdown surfaces -- no plugins, no code:
Hooks
Fire at eleven points across the workflow (before planning, after each phase, on errors, and more). Drop in your test commands, coding standards, and domain rules; every plan, task, and execution run inherits them.
Templates
Define the shape of plans and tasks -- add your own sections and checklists.
Project context
One file of domain knowledge every step reads.
Hooks, templates, and a project-context file are all plain Markdown -- nothing to compile, no plugin API to learn. See the Customization Guide for examples.
Quick Start
# 1. Bootstrap the shared workspace
npx strikethroo init --harnesses claude
# 2. Install the workflow skills
npx skills add e0ipso/strikethroo
On re-init, --harnesses is optional — Strikethroo reuses the saved selection in .ai/strikethroo/.init-metadata.json. Workspaces initialized before that field existed must pass --harnesses once.
Already set up? Refresh the workspace and update installed workflow skills in one step:
npx strikethroo@latest update
Exit 0 requires both the workspace refresh and the skills installer to succeed. If the installer fails after a successful refresh, the refreshed workspace is kept; re-run update or the installer command it reports. Start a fresh agent session after updating — a running session may still follow previous skill instructions. Old skill copies cannot show update notices until you run update once.
Requires Node.js 22+ and an assistant that supports the Agent Skills format.
Profiles: a tailored setup in one step
A strikethroo profile packages a complete workspace configuration -- hooks, templates, project context -- so init --profile <folder | user/repo | git URL> starts from a setup tuned for your stack instead of the shipped defaults, and export profile packages yours to share. See Strikethroo profiles in the Customization Guide.
In your coding assistant
flowchart LR
A[Work Order] --> B[Plan]
B --> C{Review}
C -->|Edit| B
C -->|Approve| G["Execute<br/>(generates tasks)"]
G --> H["Code Review<br/>(optional)"]
H -->|Fix| G
H -->|Pass| J[Done]
Two commands. Read the plan, approve it, run it:
| Step | Command | Output |
|---|
| Plan | /st-create-plan <your prompt> | .ai/strikethroo/plans/64--auth/plan-64--auth.md |
| Execute | /st-execute-blueprint 64 | Task blueprint, then working code, one commit per phase |
| Review | Automatic (optional) | Findings validated against schema; report-only |
st-execute-blueprint decomposes the plan into atomic tasks and builds the dependency-mapped blueprint itself when one does not exist yet. Run /st-generate-tasks 64 on its own only when you want to inspect or hand-tune the blueprint before execution starts.
Your review lands on the plan, before any code exists -- that is where a correction costs a sentence. Each step runs with clean context: the planning agent sees only the work order, and each execution sub-agent receives only its specific task. After execution, an optional automated review gate runs once on a discovered second harness, critiques the cumulative diff, and reports schema-validated findings for you to act on.
See the Workflow Guide for the full step-by-step with advanced patterns. Once a plan exists, visualize its plans, tasks, and dependency graph in Visualizations.
Visualize the data
Strikethroo comes with an optional web application to help you visualize your plans, tasks, and progress. No installation necessary, just execute the following command in a project using Strikethroo:
npx strikethroo serve
This will open a web page that will help you navigate your plans and their tasks, present or archived.
By default the viewer listens only on 127.0.0.1:4317, so it is reachable from the same machine and nowhere else. Two flags change where it listens:
| Flag | Default | Purpose |
|---|
--host <ip> | 127.0.0.1 | IP address to bind. Use 0.0.0.0 (or :: for IPv6 too) to reach the viewer from another machine, for example from your workstation when Strikethroo runs in a headless VM. Only IP addresses are accepted. |
--port <n> | 4317 | Port to bind. |
# Inside the VM: listen on every interface and skip opening a browser
npx strikethroo serve --host 0.0.0.0 --no-open
Then browse to the VM's IP address, for example http://192.168.122.10:4317; serve prints every address it answers on. Hostnames such as myvm.local are refused, so use the IP address. Binding a network address gives anyone who can reach that port full access to the workspace, including editing the hooks and configuration your agents run with, and serve prints a warning when you do it. Use it only on a network you trust, such as a VM's host-only or NAT network. Add --read-only to turn off archiving, config edits, and self-review launch. If you can SSH into the machine, a tunnel (ssh -L 4317:127.0.0.1:4317 <vm>) keeps the default loopback bind. Behind a TLS-terminating reverse proxy, pass its public address with --public-url https://viewer.example.com so that hostname and origin are accepted; it adds no authentication. See the CLI reference for details.
Check the workspace
npx strikethroo validate
Reads your workspace and reports internal inconsistencies -- missing or malformed plan and task frontmatter, dependencies pointing at tasks that do not exist, dependency cycles, blueprint phases and task files that disagree, duplicate ids. It only reads: nothing is written or fixed for you. Every finding is an error, so the command exits non-zero as soon as it reports one, which makes it usable as a CI step. Add --json for a machine-readable report on stdout, or --workspace <path> to point it at a workspace other than the one discovered from the current directory. A workspace without CODE_REVIEW.md, schemas/self-review-v2.xsd, or templates/UPDATE_NOTICE_TEMPLATE.md is valid and produces no finding for them, while a missing required file is reported. init and update restore any shipped file you deleted.
| Plans board | Plan detail page | Archive |
|---|
| | |
Optional Code Review Gate
After blueprint execution, an optional automated code review gate runs once when a second harness is discovered. The reviewer critiques the cumulative diff against the plan's requirements and emits findings validated against a schema. The gate reports; it does not decide -- there are no severity or confidence floors, and nothing is applied automatically. You read the findings and choose what to act on.
To disable: Empty .ai/strikethroo/config/hooks/CODE_REVIEW.md. The gate skips cleanly with a note in the execution summary. A deleted file is restored by the next init or update.
Important: A green review gate is not a correctness guarantee. The gate reduces exposure to the same class of error a human PR approval reduces, and leaves the same class of error behind. See Customization for limitations and configuration.
Documentation
