agentleFS
mazze93mazze93/claude-code-skills/skills/ship/SKILL.md

ship

Skill1 starsChanged 11 days agoMITView on GitHub

Ship work end-to-end — validate, prove the change behaves, commit in milestones, push, and handle protected-main/PR-only repos. Use when asked to "ship", "ship it", "release", "commit and push", "open a PR", or "get this live". Commits after each milestone so session-limit cutoffs never lose progress.

  • Commits and pushes

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

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

  • 0

    Common

    Most of the 180 edited versions we read keep these.

  • 2

    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
  1. Distinctive:

    Treat new warnings as failures-in-waiting (Swift 6 mode, deprecations) — fix them now or state why not.

    line 40
  2. Very specific:

    Follow the project's style from git log.

    line 55
  3. Distinctive:

    If the work invalidates any CLAUDE.md claim (backlog items done, files moved), update it in the same commit — map and territory together.

    line 57
  4. Very specific:

    If a workspace journal exists (docs/journal/DECISIONS.md), record what shipped and why.

    line 83

“Common” is measured: kept by at least 6 in 10 of the 180 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 (v2 — full workflow)

Encodes the whole shipping pipeline as committed milestones: a session cutoff loses at most one step, never everything. v2 adds what real repos demanded: behavioral proof before commit, and branch-protection-aware delivery (PR-only mains, required signatures, squash-only merges).

The pipeline

0. Preflight   → where am I, what branch, what's dirty, what do the rules allow
1. Validate    → build + tests green, zero NEW warnings
2. Prove       → drive the actual change end-to-end and observe the behavior
3. Commit      → milestone commits, project style, rich message
4. Deliver     → push to main when allowed; branch + PR when protected
5. Verify      → remote accepted it; CI/deploy noted; journal updated

0 · Preflight

  • git status --short + git log --oneline -5 — know the tree and the commit style before touching anything. Confirm with the user if unexpected files are staged.
  • Respect the repo's branch model (check its CLAUDE.md). If it says "feature branches, PRs against main" — start on a branch, don't discover the rule at push time.

1 · Validate

Find the project's real check command (CLAUDE.md, then package.json scripts, then Package.swift/Makefile):

  • Astro/blog: npm run check · TypeScript: npx tsc --noEmit · Swift: swift build && swift test --parallel · generic: npm test/make test
  • Do not proceed on failure. Show the error, stop.
  • Treat new warnings as failures-in-waiting (Swift 6 mode, deprecations) — fix them now or state why not.

2 · Prove (the step everyone skips)

Tests passing is not the change working. Exercise the actual surface once: run the CLI with real flags, curl the endpoint, load the page. Capture the observed output — it goes in the commit/PR body as evidence. If the change can't be driven end-to-end, say so explicitly rather than implying it was.

3 · Commit

  • Milestone commits per logical unit (feat: …, fix: …, test: …, docs: …) — never one WIP: lots of changes at the end.
  • Message body says WHY and cites the proof ("verified end-to-end: <observed>").
  • Follow the project's style from git log; include the current model's standard Co-Authored-By: Claude … trailer.
  • If the work invalidates any CLAUDE.md claim (backlog items done, files moved), update it in the same commit — map and territory together.

4 · Deliver — the protection decision tree

Try git push origin main only when the repo allows it. On rejection, read the error — it tells you the rules:

Rejection saysIt meansDo
Changes must be made through a pull requestPR-only mainbranch → push branch → gh pr create
Commits must have verified signatures (GH013)unsigned local commits can't land on main directlyPR flow; a squash merge via GitHub produces a GitHub-signed commit
Waiting for Code Scanning resultsrequired checkPR flow and let CI run
Merge commits are not allowedsquash/rebase-only repogh pr merge --squash (never --merge)

PR body = what/why + the end-to-end proof + anything the reviewer must know. Merge only when the user asked you to; otherwise leave the PR open and hand over the URL.

5 · Verify

  • Show the actual push/merge output — never claim delivery without it.
  • Note the deploy surface (e.g. Cloudflare Pages auto-deploys on push to main; verify: curl -sf <url> | grep -o '<title>[^<]*</title>').
  • Watch for post-push remote warnings (Dependabot alerts ride in on git push output) — relay them, don't swallow them.
  • If a workspace journal exists (docs/journal/DECISIONS.md), record what shipped and why.

Gotchas (all field-tested)

  • Pipes eat exit codes. gh pr merge … | tail -2 || fallback never runs the fallback — the pipeline's status is tail's. Check $? on the command itself, or use set -o pipefail. A "merged" that wasn't is the worst failure mode this skill exists to prevent.
  • After a squash merge, local main doesn't have the squash commit: git checkout main && git pull before building on top; delete the branch with --delete-branch at merge time.
  • GPG signing failures — gpg-agent not running → gpgconf --launch gpg-agent; expired passphrase cache → gpg --card-status; wrong key → git config user.signingkey.
  • Beta toolchains lie. A frontend crash compiling tests (Xcode-beta) can masquerade as your bug — get a real diagnostic with a direct swift build --build-tests before assuming fault.
  • Worktrees share the remote, not the tree — confirm git status is the worktree you think it is before staging.
  • npm run check takes 10–30s cold on Astro — expected, full rebuild.

Project quick-reference

  • mazze-leczzare-blog: validate npm run check; Cloudflare Pages auto-deploys main; verify title via curl on mazzeleczzare.com.
  • context-synapse: swift build && swift test --parallel; main is PR-only + signed + squash-only + Code Scanning — always the PR path.
  • stele: pnpm (pnpm build, pnpm test); main is PR-only + signed — PR path.

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.