Gh repo mission
Use when the user wants to kick off a new repo or feature build with Claude Code and asks for a mission prompt, a /goal, a "DO NOT STOP until" directive, an autonomous build brief, a starter command, or a non-gameable spec to drive an unattended agent. Triggers on "write me a /goal", "mission prompt for this repo", "goal prompt", "build brief", "autonomous build", "don't stop until vX", "acceptance criteria for the agent", "spec-first build", "make a Claude Code goal", "set up an agent to build X end to end". Produces a <4000-char /goal condition plus a starter command, with numeric criteria the agent cannot game, while leaving npm publish, deploys, and credentialed steps to the human.From its SKILL.md
npx -y skills add aymandakirgh/ghclaudetoolkit --skill gh-repo-missionAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.9 KB, as published. Nobody here has run it
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
/goalcondition 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, runvercel --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)
- What is being built + the target version (usually
v1.0.0). - The runtime/stack and how tests run (
npm test,pytest, etc.). - 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):
- 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.
- 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.
- Runnable fixtures. Concrete example inputs in
examples/that the built tool processes end-to-end with exit 0 — name them. - Benchmark / perf gate. A measurable threshold (e.g. "processes the 1k-row fixture in <2s on CI") that fails the build if regressed.
- Release tags. Conventional commits; a tag
v<X>; a final self-check command that prints the delivered artifact list. - 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.
- Adversarial review. "Before tagging, run a multi-agent adversarial review; fix every real finding; record declines with reasons."
- 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-reviewfor the pre-tag gate andgh-publishfor the human-run release steps.