agentleFS
Sign inStart free
leighstillardleighstillard/coach-ship-skills/skills/ship/SKILL.md

ship

Skill2 starsChanged 5 months agoMITView on GitHub

Take a finished local change to a merged PR through non-negotiable release gates. Use when the user says ship it, /ship, get this merged, release this, or when /coach has a READY local diff. Enforces simplify, verify, design applicability, PR evidence, independent review, CI, and merge babysitting while preserving Anthropic budget where safe.

194 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ios-sync, open-gstack-browser and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Saqlain-811Skill

    ios-sync

    Regenerate the iOS debug bridge against the latest upstream gstack templates. (gstack)

    Also in 6 projects that use this

  • seek888Skill

    open-gstack-browser

    Launch GStack Browser — AI-controlled Chromium with the sidebar extension baked in. Opens a visible browser window where you can watch every action in real time. The sidebar shows a live activity feed and chat. Anti-bot stealth built in. Use when asked to "open gstack browser", "launch browser", "connect chrome", "open chrome", "real browser", "launch chrome", "side panel", or "control my browser". Voice triggers (speech-to-text aliases): "show me the browser".

    Also in 10 projects that use this

  • ayudaySkill

    setup-deploy

    Configure deployment settings for /land-and-deploy. Detects your deploy platform (Fly.io, Render, Vercel, Netlify, Heroku, GitHub Actions, custom), production URL, health check endpoints, and deploy status commands. Writes the configuration to CLAUDE.md so all future deploys are automatic. Use when: "setup deploy", "configure deployment", "set up land-and-deploy", "how do I deploy with gstack", "add deploy config".

    Also in 19 projects that use this

  • ShreyRaviSkill

    landing-report

    Read-only queue dashboard for workspace-aware ship. Shows which VERSION slots are currently claimed by open PRs, which sibling Conductor workspaces have WIP work likely to ship soon, and what slot /ship would pick next. No mutations — just a snapshot. Use when asked to "landing report", "what's in the queue", "show me open PRs", or "which version do I claim next". (gstack)

    Also in 9 projects that use this

  • zebbernSkill

    debug-fix

    Find and fix a bug or issue — from any source (GitHub issue, error message, user report, or observed behavior)

    Also in 4 projects that use this

  • ramybarsoumSkill

    document-release

    Post-ship documentation update. Reads all project docs, cross-references the diff, updates README/ARCHITECTURE/CONTRIBUTING/CLAUDE.md to match what shipped, polishes CHANGELOG voice, cleans up TODOS, and optionally bumps VERSION. Use when asked to "update the docs", "sync documentation", or "post-ship docs". Proactively suggest after a PR is merged or code is shipped.

    Also in 23 projects that use this

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 6 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 181 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Independent review addressed: Prefer /codex:review --wait for normal diffs and /codex:adversarial-review --wait for high-risk/design-heavy …

    line 19
  2. Distinctive:

    Use deterministic tools and shell commands before model review where possible.

    line 24
  3. Distinctive:

    Prefer Codex for independent review to preserve Anthropic budget, but do not skip review if Codex is unavailable.

    line 25
  4. Distinctive:

    Do not launch redundant Claude subagents during ship.

    line 26
  5. Very specific:

    If a gate fails because credentials or budgets are exhausted, stop with BLOCKED and the exact missing requirement.

    line 27
  6. Distinctive:

    Never open a PR before verification unless the user explicitly asks for a draft/WIP PR.

    line 62
  7. Distinctive:

    Never merge with unresolved critical review findings.

    line 63
  8. Distinctive:

    Do not count a reviewer's prose summary as evidence that CI or verification passed.

    line 64

“Common” is measured: kept by at least 6 in 10 of the 181 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Ship

Goal

The change is merged to the default branch, or you stop with the exact unmet invariant and evidence. You may choose the order, but you may not waive invariants.

Invariants

These are preconditions, not a checklist. If any is unmet, achieving it becomes the next action.

  1. Diff understood. git status and git diff have been inspected; every changed/untracked file is intentional.
  2. Simplified. /simplify has run on the final shape, or explicitly returned UNCHANGED. Substantial code changes after simplify reopen this invariant.
  3. Verified. /verify ended in VERIFIED with real entry-point evidence. Tests/builds alone do not satisfy this. Any code change after VERIFIED reopens this invariant.
  4. Design checked when user-visible. /design-check passed, passed with notes, or returned DESIGN N/A.
  5. PR carries evidence. /pr opened a PR whose body includes verification evidence, review/design notes, and risk/rollback.
  6. Independent review addressed. Prefer /codex:review --wait for normal diffs and /codex:adversarial-review --wait for high-risk/design-heavy diffs when Codex is available. Otherwise use an independent Claude reviewer. Critical findings are fixed; important findings are fixed or explicitly accepted/rebutted. Non-trivial fixes reopen invariants 2-4.
  7. Green and uncontested. CI is green, required approvals/review comments are addressed, conflicts are resolved, and merge method matches repo convention.
  8. Merged or blocked honestly. /babysit owns the final loop until merged or a real blocker is reported.

Budget policy

  • Use deterministic tools and shell commands before model review where possible.
  • Prefer Codex for independent review to preserve Anthropic budget, but do not skip review if Codex is unavailable.
  • Do not launch redundant Claude subagents during ship; ship is a gate loop, not an implementation swarm.
  • If a gate fails because credentials or budgets are exhausted, stop with BLOCKED and the exact missing requirement.

State tracking

Maintain a visible invariant checklist. Report transitions tersely:

  • [ship] simplify: SIMPLIFIED → verify
  • [ship] verify: NOT VERIFIED → fixing blocker
  • [ship] review: critical fixed → re-verify
  • [ship] ci: green + approved → merge

PR evidence minimum

The PR body must contain:

  • changed behaviour (What)
  • reason/context (Why)
  • verification commands and representative output (How verified)
  • design screenshots/output or DESIGN N/A
  • independent review status and unresolved accepted risks
  • rollback notes

Exit report

End with:

[ship] <MERGED | BLOCKED | NOT SHIPPED>
PR: <url if opened>
Merged: <yes/no + merge commit if available>
Invariant status:
- Diff understood: <evidence>
- Simplified: <SIMPLIFIED/UNCHANGED/BLOCKED>
- Verified: <VERIFIED/NOT VERIFIED>
- Design: <PASS/PASS WITH NOTES/DESIGN N/A/FAIL>
- Review: <tool used + unresolved findings>
- CI/merge: <status>
Next: <only if not merged>

Gotchas

  • Never open a PR before verification unless the user explicitly asks for a draft/WIP PR; label it as not verified in the body.
  • Never merge with unresolved critical review findings.
  • Do not count a reviewer's prose summary as evidence that CI or verification passed.
  • A late CI/review fix invalidates prior verification if it changes behaviour.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free