For Spec Kit and OpenSpec projects

Spec-driven coding,
decided by evidence.

speccoder implements your feature task by task. Before each attempt it turns the spec's acceptance examples into tests that must fail; after it, it runs your checks and audits the diff. A task is ticked only when the evidence holds — never on the model's word.

brew install hupe1980/tap/speccoder

speccoder run

▶ T002 Collapse every run of other characters into one -
  ✓ baseline
  ✓ red assertion
  · attempt 1/2
    ∴ One pass that remembers the last dash collapses every run.
    “I'll track the last character pushed.”
    turn 1  read_file    src/lib.rs   allow
    turn 2  write_file   src/lib.rs   allow
    turn 3  run_command  cargo test   allow
  ✓ attempt 1/2
  ✓ verify
  ✓ audit
  ✓ commit 4be81c2
✓ T002 verified · 42.5k in / 2170 out · 3s — verdict: verified

A coding agent that cannot mark its own homework

Agents are good at writing code and too good at declaring victory. speccoder separates the two: a model proposes, and code decides.

  1. 1

    Ready

    The next task whose dependencies in tasks.md are met.

  2. 2

    Red

    Tests derived from the spec's acceptance examples, which must fail now. The implementer cannot change them.

  3. 3

    Attempt

    The model works in an isolated worktree. Every tool call is allowed, sent to you, or denied — before it runs.

  4. 4

    Judge

    Your checks again, the acceptance tests green, and an audit that catches deleted or weakened tests.

  5. 5

    Record

    A passing task is ticked and committed. Everything else is saved in git and undone, and you decide.

Your decisions, not the agent's chores

The agents do the coding; you decide what only a person can. speccoder ui opens the project as an app on your machine: what blocks you first, the riskiest work to review next, each task's evidence, the spec to sign off requirement by requirement, the code and the report.

Needs You: a call waiting for approval, an open question in the spec and requirements to review, across two featuresNeeds You: a call waiting for approval, an open question in the spec and requirements to review, across two features

Everything around the model, done properly

Evidence decides

verified means spec-derived tests went red → green and nothing regressed. Held-out tests the model never sees and wrong variants of the change test the tests themselves.

Review the tests first

Approve each requirement together with the tests derived from it — red before any code exists. Unsure how to put it? Shape turns rough words into a testable requirement and marks every word it added.

Bugs, reproduced first

speccoder bug writes a test that fails the way you describe, asks you once, and accepts a fix only if undoing it makes that test fail again.

Spec Kit and OpenSpec

Reads your specs as Spec Kit 0.13–1.2 and OpenSpec 1.0+ write them, and runs their own planning skills, hooks and workflows.

Isolated and sandboxed

Work happens on speccoder/<feature> in its own worktree. Commands run in an OS sandbox: no writes outside, no credentials, no daemon sockets, no network unless you allow it.

Every call governed

Each call is classified before it runs. An approval covers exactly what you saw and ends with the run; every decision records who made it.

Durable and replayable

Every model and tool call is journaled. A killed run resumes without repeating finished calls; any recorded run replays offline, without a model.

Your model, or your agent

Anthropic, OpenAI, Amazon Bedrock or a local OpenAI-compatible server — or let GitHub Copilot, OpenCode, Claude Code, Codex or Gemini CLI make the attempts, every call they make decided by speccoder.

Proof in the pull request

Every tick is signed. speccoder attest verify --branch checks them on any pull request — no model, no network — and posts the speccoder / evidence check with a tour of each task.

From spec to verified branch in minutes

You need git, a Spec Kit or OpenSpec project and a model. No project yet? speccoder new makes one with the tools' own commands, and speccoder sample replays a recorded run without a key.

Read the quickstart
# detects your checks, runs them, offers to commit the config
speccoder init

# the key from the environment only
export ANTHROPIC_API_KEY=…

speccoder run      # task by task, with evidence
speccoder inbox    # what waits for you
speccoder ui       # the same, as an app
git merge speccoder/001-my-feature

What verified does not mean

It means the acceptance tests derived from your spec went from red to green and no check regressed. It does not mean the change is correct, complete or safe. speccoder makes review cheaper and better informed; it does not replace it. When it cannot demonstrate something — a gap no failing test shows, a task that contradicts its spec — it stops and says so instead of guessing.

Questions

What is speccoder?

A coding agent for spec-driven projects (GitHub Spec Kit and OpenSpec), with a terminal dashboard and an app. It works through a feature's tasks one at a time and ticks a task only when evidence shows it is done: tests derived from your spec that fail before the change and pass after it, your own checks, and an audit of the diff.

How is it different from a coding agent in my editor?

An editor agent decides when it is done. speccoder never takes the model's word: a task is decided by tests, checks and a diff audit, every attempt is recorded in git, and a person decides whatever is uncertain. You can even let GitHub Copilot, OpenCode, Claude Code, Codex or Gemini CLI make the attempts: speccoder decides every call they make and keeps the judgement.

Which models does it support?

Anthropic and OpenAI models, Amazon Bedrock (a Bedrock API key or an aws login session), any OpenAI-compatible server (Ollama, vLLM, llama.cpp, LM Studio), and GitHub Copilot, OpenCode, Claude Code, Codex or Gemini CLI as executors over ACP (or any command). API keys are read from the environment only.

Is it safe to run on my code?

speccoder works in its own git worktree and never touches your checkout. Every command it starts runs in an OS sandbox (Seatbelt on macOS, Landlock and seccomp on Linux) that writes only to the worktree, cannot read credentials, has no network beyond loopback and cannot reach daemon sockets such as Docker's. Every tool call is classified before it runs: allowed, needing your approval, or denied.

Which spec formats does it support?

GitHub Spec Kit (projects created by 0.13 to 1.2) and OpenSpec (1.0 and newer). speccoder reads their files as they write them and runs their planning skills (Spec Kit: specify, clarify, plan, tasks, analyze; OpenSpec: propose, explore, archive) with its own model. Kiro specs are recognised and refused.

Can a reviewer check the evidence without trusting the author?

Yes. speccoder attest verify --branch checks every ticked task of a branch against its signed evidence using the reviewer's own trust, with no model key and no network. Its GitHub Action posts the result on each pull request as the speccoder / evidence check.

What does verified mean?

The spec-derived acceptance tests went from red to green and none of your checks regressed. It does not mean the change is correct, complete or safe. Review the speccoder branch like any contribution before you merge it.

Let evidence decide.