examples / the board runner

The autonomous board runner

Instead of driving each stage by hand, file one-line tickets and let a runner on your laptop drain them — drafting, asking its questions on the ticket, building, and opening PRs — with you gating the decisions. Gate state lives as labels on GitHub issues.

1 Provision the board

sdd board --project

Creates the gate labels on the repo — sdd:spec, sdd:spec-review, sdd:plan, … sdd:done, plus sdd:awaiting-you — and, with --project, an aggregating GitHub Project. The labels are the source of truth; the Project is just a view.

2 Enable the runner

The runner is inert until you flip it on in .sdd/config.json:

{ "runnerActive": true,
  "board": { "provider": "github", "repo": "you/notes-api" }, … }

Auth: an unattended runner should authenticate with an API key (ANTHROPIC_API_KEY) — a Max subscription is for interactive use, per Anthropic's terms. --allow-subscription overrides for personal, hands-on runs. And run it as a distinct GitHub identity from yourself, so it can tell your reply comments from its own.

3 File a ticket

sdd new "let users tag notes and filter by tag"

Opens an issue labelled sdd:spec — the first actionable gate. (Creating the issue in the GitHub UI and adding the label yourself works identically.)

4 Run it

sdd run          # poll continuously; --once for a single cycle

The runner picks up the ticket, drafts a spec as a comment, then posts its — and the expert panel's — open questions, and parks, labelling the ticket sdd:awaiting-you:

## sdd questions — spec

1. [security] Can a user tag another user's note, or only their own?
2. [product] What's the success criterion — filter latency, adoption?

Reply in a comment to answer (free-form is fine); I'll refine on the next pass.

You reply in a comment whenever you get to it. On its next poll the runner reads your answer, refines the spec, and advances the ticket to sdd:spec-review. The comment thread is the conversation — and the polling is idempotent, so it never re-drafts or re-asks.

Prefer hands-on? sdd draft <ticket#> pulls the ticket into the interactive TUI (draft → interrogate → refine) and pushes the result back — same ticket, same gate, synchronous.

5 Approve through the gates

sdd approve 12        # spec-review → plan

Approving relabels the ticket to the next stage. The runner plans (another Q&A round if it has questions), you approve again (→ build), and the build stage:

  • creates an isolated git worktree + sdd/<slug> branch,
  • implements the plan and runs your tests (bounded fix loop),
  • pushes and opens a PR, recording it back on the ticket,
  • advances to sdd:build-review. A red or empty build stays put instead — it never opens a junk PR.

Approve once more (→ review) and the review stage runs the panel over the PR diff and posts its verified findings on the PR. Not happy at any gate?

sdd bounce 12 --note "tighten the acceptance criteria"

…sends it back a stage, with your note as feedback the next pass reads.

The flow at a glance

sdd new ─▶ [sdd:spec] ─runner▶ draft + ask ─▶ [awaiting you] ─you▶ reply
   ─runner▶ refine ─▶ [sdd:spec-review] ─you: approve▶ [sdd:plan] ─runner▶ …
   ─▶ [sdd:build] ─runner▶ branch + build + PR ─▶ [sdd:build-review] ─you: approve▶
   ─▶ [sdd:review] ─runner▶ review the PR ─▶ [sdd:done] ─you▶ merge

You touch it only at the gates — reply, approve/bounce, merge. Everything is a label change, so sdd status and the board always show exactly where each feature stands, and sdd:awaiting-you is your at-a-glance queue.

← Single-repo feature Next: a multi-repo product →