ship
Skill8 starsChanged 48 days agoMITView on GitHub
Orchestrates the current branch from "code done" to "merged": runs the review-code skill, then any project-specific pre-merge checks it detects (visual regression like `just visual-diff`, tests, lint), then a conventional commit per git-commit, a PR per git-create-pr, and optionally watches CI and merges on green. Use when the user says "ship it", "ship this", "ship train", "get this merged", or wants the whole review-to-merge pipeline in one go. Reuses the sibling skills and stops on the first red gate (failing review, failing check, red CI). Owns "ship it" for the default case: a feature branch merging straight to its base. Not for a single step in isolation (use review-code, git-commit, or git-create-pr directly). Not for release/hotfix branch topology, versioning, or promoting dev to main, use gitflow for that, including "ship it" said in a repo that runs gitflow.
- Installs packages
- Commits and pushes
194 other projects use a version of this.
Adopted by
Most recently taken up by
- wboayue/rust-ibapitheir own version, first seen Nov 9, 2026
- haiggoh/run-to-completiontheir own version, first seen Nov 8, 2026
- sanmidable/skillstheir own version, first seen Nov 8, 2026
- Yesterday-AI/ytstacktheir own version, first seen Nov 8, 2026
- gaoyu06/harnesstheir own version, first seen Nov 8, 2026
- PeanutGT/NutsSkillstheir own version, first seen Nov 8, 2026
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-811Skillios-sync
Regenerate the iOS debug bridge against the latest upstream gstack templates. (gstack)
Also in 6 projects that use this
seek888Skillopen-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
ayudaySkillsetup-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
ShreyRaviSkilllanding-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
zebbernSkilldebug-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
ramybarsoumSkilldocument-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
Other versions194 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 194
- garrytan/gstack★ 141ksame name
- rtk-ai/rtk★ 86ksame name
- simstudioai/sim★ 30ksame name
- millionco/react-doctor★ 15ksame name
- BuilderIO/agent-native★ 7.6ksame name
- nightly-labs/openbot★ 6.3ksame name
- fallow-rs/fallow★ 5.3ksame name
- puncsky/system-design-and-architecture★ 3.6ksame name
- plugin87/ux-ui-agent-skills★ 3.1ksame name
- ShenSeanChen/waku-agent★ 2ksame name
184 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository53 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agent-browserSkill
- anything-to-skillSkill
- ci-generateSkill
- ci-localSkill
- clotho-researchSkill
- codex-imagegenSkill
- create-ruleSkill
- create-skillSkill
- db-migrateSkill
- docker-initSkill
- docs-adrSkill
- docs-checkSkill
- docs-diagramSkill
- docs-initSkill
- docs-rfcSkill
- docs-updateSkill
- env-setupSkill
- find-skillsSkill
- fix-bugSkill
- git-commitSkill
- git-create-prSkill
- gitflowSkill
- git-releaseSkill
- git-syncSkill
- i18n-checkSkill
- implement-featureSkill
- improve-skillSkill
- inject-docsSkill
- jira-cliSkill
- motion-studioSkill
- optimize-ai-setupSkill
- orchestrateSkill
- oss-launchSkill
- prd-to-issuesSkill
- product-design-specSkill
- product-design-tokensSkill
- product-prdSkill
- project-illustratorSkill
- project-plannerSkill
- refactorSkill
- renderSkill
- review-codeSkill
- review-depsSkill
- review-designSkill
- review-perfSkill
- review-planSkill
- review-securitySkill
- stopslopSkill
- test-suiteSkill
- vrt-checkSkill
- wtfSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 1 is distinctive, and 5 are very specific to this project.
0
Common
Most of the 180 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
5
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
- Very specific: line 92
Follow the git-commit skill's conventions (invoke it if available, otherwise apply the same rules inline): Conventional Commits format, …
- Very specific: line 96
Follow the git-create-pr skill's conventions (invoke it if available, otherwise apply the same rules inline): conventional-commit-style …
- Very specific: line 100
If --no-merge was passed, or the user only asked to get the PR open, stop here and report the PR URL.
- Distinctive: line 103
Green CI: only merge if the user asked to get this merged (e.g.
- Very specific: line 104
When merging, use squash unless the repo's own convention says otherwise (check for a CONTRIBUTING.md or existing merge history via gh pr …
- Very specific: line 110
If everything went green and merged, say so plainly, the user should not have to re-check gh pr view.
“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.
Files
Ship
Take the current branch from "code done" to "merged" in one pass. This is a thin orchestrator: every step delegates to the sibling skill that already owns that logic. Do not re-implement review rules, commit conventions, or PR templates here: invoke the skill.
Pipeline integrity
Every stage's reported result must quote the actual command you ran and its actual exit status or output. A stage you did not run is reported as SKIPPED: <reason>, never as passed, never estimated, never inferred from a similar-looking earlier run. The whole value of a ship train is that green means green; one fabricated gate poisons every stage after it, because the human trusts stage 6 only because they trust stages 1-5.
The train
Copy this checklist, tick each step as it passes, and follow the gates. Stop at the first gate that exhausts its rounds and report it; do not skip a step or push through a failure.
- [ ] 1. Pre-flight: a diff exists, working tree state known, base branch chosen
- [ ] 2. Code review (review-code on the diff vs base)
Critical/High finding: fix it (or user accepts the risk), then re-run step 2
- [ ] 3. Pre-merge checks (auto-detected project gates)
Any check red: fix it, then re-run step 3
- [ ] 4. Commit (git-commit conventions)
- [ ] 5. PR (git-create-pr conventions)
- [ ] 6. CI + merge (optional)
CI red: fix, return to step 3 to re-run local checks, then push and re-watch
Cap: 3 fix rounds per gate, then stop and report what still failsEach step's details are in its section below. TodoWrite can hold the same lines so the user sees where the train is if a gate stops it.
Step 1: Pre-flight
git branch --show-current: refuse to run onmain/master/devdirectly (nothing to ship from a target branch).git status --porcelain: if dirty, useAskUserQuestion(or ask in plain text if that tool isn't available) whether to include the changes or stop.- Requires
gh(brew install gh): confirmgh auth statussucceeds, else stop and tell the user to rungh auth login. - Determine base branch: use
--baseif given, elsegh repo view --json defaultBranchRef -q .defaultBranchRef.name, elsemain. git log <base>..HEAD --oneline: if empty, there's nothing to ship; stop and say so.
Step 2: Code review
Invoke the review-code skill (via the Skill tool where available, otherwise apply its review dimensions inline) scoped to the diff against the base branch. This is analysis only: it does not touch files.
- Any Critical/High finding: report it with file:line, then fix it and re-run this step, or let the user explicitly accept the risk. Do not proceed silently. After 3 rounds with a finding still open, stop and report it.
- Medium/Low findings: report them but continue, they don't block the train.
Step 3: Pre-merge checks (auto-detected)
The project's own gates matter more than a generic test run. Detect what's actually configured before running anything, never invent a command:
justfile: look forvisual-diff,test,checkrecipes (just --listif present).Makefile: look fortest,check,linttargets.package.json: look atscriptsfortest,lint,typecheck,e2e.- Framework-native fallback (
pytest,cargo test, etc.) only if none of the above exist.
A Haiku Explore subagent is the cheap way to do this detection without burning main-thread context:
Task tool with Explore agent:
- prompt: "Find pre-merge check commands for this repo: look for a justfile
(especially a visual-diff or visual regression recipe), Makefile targets,
and package.json scripts. Return the exact commands to run, do not invent any."
- subagent_type: "Explore"
- model: "haiku"No Task tool available: run the same detection inline: just --list (or read the justfile), grep the Makefile's target names, cat package.json's scripts block, then run whatever it finds directly.
Run every command found. Any non-zero exit: show the failing output, fix it, and re-run the check; do not commit until it is green. After 3 rounds still red, stop and report what fails. This includes visual regression diffs: a passing test suite with a failing visual diff is still a red gate.
Step 4: Commit
Follow the git-commit skill's conventions (invoke it if available, otherwise apply the same rules inline): Conventional Commits format, imperative mood, stage only the files that belong to this change, split into multiple commits if the diff mixes unrelated concerns.
Step 5: Pull request
Follow the git-create-pr skill's conventions (invoke it if available, otherwise apply the same rules inline): conventional-commit-style title, PR body filled from the actual commits/diff (no invented claims), push the branch, open against the base branch determined in Step 1.
Step 6: CI + merge (optional)
- If
--no-mergewas passed, or the user only asked to get the PR open, stop here and report the PR URL. - Otherwise watch CI:
gh pr checks <number> --watchor pollgh pr checks <number>every couple of minutes, don't tight-loop. - Red CI: show the failing check name and a log excerpt, do not merge. Fix the cause (never retry blindly), re-run the local checks from Step 3, then push and re-watch. After 3 rounds still red, stop and report.
- Green CI: only merge if the user asked to get this merged (e.g. "get this merged", "merge when green") or confirms when asked. Otherwise just report green and let the user merge themselves.
- When merging, use squash unless the repo's own convention says otherwise (check for a CONTRIBUTING.md or existing merge history via
gh pr list --state merged --limit 5). Never force-push, never bypass hooks or required checks to get a merge through.
Reporting
Every report (stopped or completed) ends with a stage table: # | Stage | Command | Result. One row per step in "The train", in order. Command is the literal command (or skill invocation) you actually ran for that stage; Result is its actual exit status or a one-line summary of its actual output. Any stage not reached gets Command: — and Result: SKIPPED: not reached. This table is what makes fabrication visible: never fill a row from what a stage "should" produce, only from what it did.
If everything went green and merged, say so plainly, the user should not have to re-check gh pr view. Every number, check name, or pass/fail verdict in the table must come from a command actually run this session.
Example: stopped at code review (Step 2)
Ship train stopped at step 2/6: code review.
| # | Stage | Command | Result |
|---|--------------|-----------------------------------|--------------------------------------|
| 1 | Pre-flight | git log main..HEAD --oneline | 4 commits ahead, OK |
| 2 | Code review | Skill: review-code (diff vs main)| 1 High: session.ts:42 uses `==` on token, BLOCKED |
| 3 | Pre-merge | — | SKIPPED: not reached |
| 4 | Commit | — | SKIPPED: not reached |
| 5 | PR | — | SKIPPED: not reached |
| 6 | CI + merge | — | SKIPPED: not reached |
Fix the finding and re-run, or tell me to accept the risk and continue.Example: stopped at a pre-merge check (Step 3)
Ship train stopped at step 3/6: pre-merge checks.
| # | Stage | Command | Result |
|---|--------------|---------------------|------------------------------------------|
| 1 | Pre-flight | git log main..HEAD | 6 commits ahead, OK |
| 2 | Code review | Skill: review-code | 0 Critical/High, OK |
| 3 | Pre-merge | just visual-diff | exit 1, 3 snapshots differ, BLOCKED |
| 4 | Commit | — | SKIPPED: not reached |
| 5 | PR | — | SKIPPED: not reached |
| 6 | CI + merge | — | SKIPPED: not reached |
Fix the diffs (or run `just visual-update` if they're intended) and re-run.Example: full train, merged on green
Ship train complete: merged.
| # | Stage | Command | Result |
|---|--------------|---------------------------------------------|--------------------------------------------|
| 1 | Pre-flight | git log main..HEAD --oneline | feature/search-filters, 4 commits ahead |
| 2 | Code review | Skill: review-code (diff vs main) | 0 Critical/High, 2 Low (non-blocking) |
| 3 | Pre-merge | just test; just visual-diff | 42 passed; 0 diffs |
| 4 | Commit | git commit -m "feat(search): ..." | committed 4f2a91c |
| 5 | PR | gh pr create ... | https://github.com/org/repo/pull/213 |
| 6 | CI + merge | gh pr checks 213 --watch; gh pr merge --squash | lint/test/build green, squash-merged |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
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.

