Finish Line

Coding agents start products well and stall in the last 20%: closed issues stand in for working features, the agent that wrote the code also grades it, long sessions drift, and "done" means the agent said so. This skill makes completion a property of the running software, not the transcript. It first writes down what the product is — only from its docs and what the running app does, every claim quoting its source, unknowns listed instead of guessed — and has an independent verifier check that against the docs. Then it freezes a definition of done built on that brief, works it one item at a time, and lets an item pass only with screenshots, a passing test, a verdict from a separate verifier, and a clean tamper check.

Fully autonomous. No step waits for a person. The agent decides with a fixed procedure and logs every decision in DECISIONS.md; the independent verifier approves or rejects changes to the definition of done; the runner reverts sessions that game the gate, pauses items that stall and brings them back as research rounds, retries a failing CLI, re-checks owner actions, and accepts a finished state only when the ledger proves it. Every issue found is resolved: defects found anywhere become ledger items, and an item that resists is never abandoned — it returns in research rounds that go deeper each time (docs, library source, issue trackers, the web) until it passes. The only things left to the owner — keys, accounts, production, DNS, store listings, merging — are collected in OWNER_ACTIONS.md, each with a check that reopens the work by itself once it's done.

State lives in .finish/ inside the product repo, so every session resumes where the last one stopped.

When to use

• A product has docs (PRD, specs, implementation plan, issues) and code, but isn't launched
• An agent keeps claiming completion that the app doesn't back up
• The user wants it finished without being asked questions every iteration
• The user wants every feature tested visually, end to end, against the docs
• Several half-built products exist and one has to be picked and shipped

When NOT to use

• No docs or spec at all: write the PRD first, then come back
• A single bug fix or one feature: just do it
• Pure libraries or CLIs: still usable with api / command verify methods, but skip the visual parts

Setup

Tools: git, jq, a headless agent CLI. Web: npm i -g @playwright/cli (repo-level Playwright installs happen in Phase 0). Mobile: Maestro (curl -Ls "https://get.maestro.mobile.dev" | bash) and an emulator/simulator. Recommended: Docker (real local Postgres/Redis/Mailpit/MinIO), gh, gitleaks.

Optional env, passed through to every session: FINISH_GIT_NAME, FINISH_GIT_EMAIL (commit identity), FINISH_NO_AI_TRAILERS=1 (no AI attribution in commits/PRs), FINISH_UNTIL=P1|P2 (keep going past P0), FINISH_MAX_AMENDMENTS (5), FINISH_COMPANIONS=auto|off|install, FINISH_KEEP_HOOKS=1.

Optional companions: scripts/companions.sh install adds community skill packs pinned to reviewed commits — superpowers and Addy Osmani's agent-skills by default; Matt Pocock's skills and gstack on request. See Companion skills below.

How to run it

Never run the build loop without the protocol: the laws in its §0 are what keep the result honest.

The workflow

What replaces asking the owner

Companion skills

Installed community skills help at named protocol steps — superpowers' TDD, debugging and verification-before-completion; Addy Osmani's review, security, performance and launch checklists; gstack's browser and read-only QA, security and benchmark skills; Matt Pocock's tdd, diagnosing-bugs and code-review as fallbacks. companions.sh detect writes .finish/companions.json (slot → exact skill name) and the session invokes each only at its step (protocol §2.2, Law 9). They never decide anything: the ledger, the gate, tamper and the verifier do. Every runner session runs under a policy that denies each pack's asking, planning, publishing and merging skills, turns hooks off, and puts gstack in its no-human mode; the verifier has no Skill tool and skips CLAUDE.md. Details, pins and licenses: references/companions.md.

Scripts

Common gotchas

References

• references/protocol.md — the per-session protocol (laws, phases, decision procedure, owner actions). The runner sends it as the prompt.
• references/upgrades.md — checked legacy gate repair, custom-gate refusal and frozen upgrade boundaries.
• references/ledger.md — precedence, P0/P1/P2 cut, launch gates, schema, freeze, amendments.
• references/verification.md — init.sh, local infra, verify.sh commands per stack, spec rules, playwright-cli, tamper rules.
• references/portfolio-triage.md — choosing the one product to finish.
• references/companions.md — which community skills are used at which step, which are denied and why, the session policy, pins, licenses, limits.
• companions/ — catalog.json (packs, slots, deny lists) and .claude-plugin/marketplace.json (finish-line's marketplace, every plugin pinned to a commit).
• templates/ — verify.sh, finish-verifier.md (+ finish-verifier.history: hashes of shipped versions, so the runner only refreshes unmodified copies), claude-settings.local.json (+ .history, so only finish-line's own copy is ever merged into), e2e/ (config, fixture, example spec), maestro/ example flow, ledger.example.json, product.example.json (the brief it is built on).