gh-repo-mission

gh-repo-mission

Generate a starter command + a /goal mission prompt that drives Claude Code to build a repo end-to-end, unattended, against criteria it cannot fake its way past.

When to use

The user is about to build something and wants the agent to run autonomously to a verifiable finish line — not "help me code" but "don't stop until this is provably done."

Hard constraints (learned the hard way)

• The /goal condition is capped at 4000 characters. Write the condition to fit. If it runs long, cut prose, not criteria. (Anything over 4000 is rejected outright.)
• Numeric, non-gameable criteria only. "Works well" is gameable; "≥90% line coverage AND the CLI exits 0 on the 3 fixtures in examples/" is not.
• Leave credentialed steps to the human. Never instruct the agent to npm publish, deploy, run vercel --prod, or touch real tokens/keys. The mission documents those as the human's job.

What to gather first (ask only if unknown; infer from the repo otherwise)

1. What is being built + the target version (usually v1.0.0).
2. The runtime/stack and how tests run (npm test, pytest, etc.).
3. What "done" means as observable outputs: files that must exist, commands that must exit 0, fixtures that must run, perf numbers that must hold.

Structure of the output

Produce two blocks.

Block A — starter command (one line)

A single shell line that scaffolds or opens the work, e.g. gh repo create <owner>/<repo> --public --source=. --remote=origin or a mkdir && cd && git init.

Block B — the /goal condition (<4000 chars)

Open with DO NOT STOP until <repo> reaches v<X>, meeting ALL of: then a numbered list drawn from this non-gameable criteria catalog (pick the ones that fit; keep each measurable):

1. Features → tests. Every feature has a test that fails without it and passes with it. State a coverage floor and the exact command that proves it.
2. Two-directional CI. CI must prove the happy path passes and that a known-bad input fails (a guard test), so green can't be faked by deleting assertions.
3. Runnable fixtures. Concrete example inputs in examples/ that the built tool processes end-to-end with exit 0 — name them.
4. Benchmark / perf gate. A measurable threshold (e.g. "processes the 1k-row fixture in <2s on CI") that fails the build if regressed.
5. Release tags. Conventional commits; a tag v<X>; a final self-check command that prints the delivered artifact list.
6. No-padding clause. "No stub files, no TODO bodies, no commented-out code to hit a count; every file must do real work." This blocks gaming length/file-count targets.
7. Adversarial review. "Before tagging, run a multi-agent adversarial review; fix every real finding; record declines with reasons."
8. Spec-first. "First commit = PRD/spec. Encode every decision there and in STATUS.md."

Close with the boundary line: "Leave all publish/deploy/credential steps to me — document the commands, never run them."

Template

DO NOT STOP until <repo> reaches v<X>, meeting ALL of:
1. <feature set> each covered by a test that fails without it; `<test cmd>` green at ≥<N>% lines.
2. CI proves happy path passes AND a known-bad input is rejected (guard test).
3. examples/<f1>, examples/<f2> run end-to-end with exit 0 via `<run cmd>`.
4. Perf gate: `<bench cmd>` stays under <threshold> or the build fails.
5. Conventional commits; tag v<X>; `<self-check cmd>` prints the delivered artifacts.
6. No stubs, no TODO bodies, no padding — every file does real work.
7. Before tagging: multi-agent adversarial review; fix real findings; record declines.
8. First commit = PRD.md; decisions encoded in PRD.md + STATUS.md.
Leave npm publish / deploy / credentialed steps to me — document, never run.

Guardrails

• Keep the condition under 4000 chars — count before handing it over.
• Prefer commands the agent can actually run in this environment; don't invent tooling.
• If the human's stack is unknown, make the criteria stack-agnostic ("the test command", "the build command") rather than guessing a framework.
• Pair the mission with gh-adversarial-review for the pre-tag gate and gh-publish for the human-run release steps.