ship
Skill0 starsChanged 7 months agoApache-2.0View on GitHub
Release workflow that takes a branch from done coding to reviewed, committed, pushed, and PR-ready. Works with Claude Code and Codex.
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 repositoryOne other file it gives its agents.
- exa-researchSkill
The file
We split this skill into the rules it gives an agent
11 rules. 0 are common, 10 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 180 edited versions we read keep these.
10
Distinctive
This author's own choices. Worth a look.
1
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
- Distinctive: line 12
Use this skill when the user says:
- Distinctive: line 26
Run from the current branch unless the user asks to switch.
- Distinctive: line 29
Do not silently defer review findings.
- Distinctive: line 30
Never merge without explicit user instruction.
- Distinctive: line 51
Run the repo's baseline validation before review.
- Distinctive: line 59
If the change affects docs, examples, screenshots, or install instructions, update those before publish.
- Distinctive: line 79
After accepted fixes land:
- Distinctive: line 82
Write a clear commit message.
- Very specific: line 83
Stop here if the user asked for --review-only or --dry-run.
- Distinctive: line 87
Run the repo's post-commit gate.
- Distinctive: line 130
Use prior ship state to save time, not to lower quality.
“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
Takes a branch from "done coding" to "reviewed, committed, pushed, and PR-ready."
Triggers
Use this skill when the user says:
/ship- "ship this branch"
- "ship this"
- "make this PR-ready"
- "review and open a PR"
- "prepare this for release"
- "publish the current work"
Rules
These apply on every run:
- Run from the current branch unless the user asks to switch.
- Stage specific files only. Never the whole worktree.
- Fix security findings before publish.
- Do not silently defer review findings.
- Never merge without explicit user instruction.
Flags
--no-review: skip review, keep validation and publish--review-only: stop after review and reporting--dry-run: report what would be staged, validated, and published without doing it--fresh: ignore cached rerun state, do a full pass--quick: allow lighter non-security checks for small changes--no-pr: push the branch without opening a PR
Phase Model
Phase 0: Classify
- Inspect branch scope and changed files.
- Decide whether the run is full, delta-scoped, or cacheable.
- Outline likely PR and release material early.
Phase 1: Preflight
Run the repo's baseline validation before review.
Extension hook: preflight
Typical checks: lint, unit tests, smoke tests, secret scanning, docs or schema validation.
Phase 1.5: Docs Sync
If the change affects docs, examples, screenshots, or install instructions, update those before publish.
Extension hook: docs_sync
Phase 2: Review
Review the actual delta, not the entire repo. Fan out by file category or risk area when useful.
Extension hook: review
Findings use three severities:
BLOCK: fix before publishWARN: can publish, but report clearlyNOTE: real improvement, not a blocker
Review for: correctness, process safety, security, release regression risk, missing tests or docs.
Phase 3: Stage and Commit
After accepted fixes land:
- Stage intended files only.
- Write a clear commit message.
- Stop here if the user asked for
--review-onlyor--dry-run.
Phase 4: Quality Gate
Run the repo's post-commit gate.
Extension hook: gate
Gate result: 0 = GO, 1 = WARN, 2 = BLOCK.
Can combine: targeted regression tests, security checks, packaging checks, release artifact validation.
Phase 5: Publish
Extension hook: publish
- Push the branch.
- Open or update a PR.
- Tag and release when the repo's release process calls for it.
- Include exact install examples in release notes if the repo distributes installable artifacts.
Phase 6: Report
Return a short report:
- Rerun scope used
- Findings fixed
- Remaining warnings
- Validation commands run
- Publish result
- PR or release URL if created
Extension Hooks
Map these to your repo's own commands. The skill does not assume any specific tooling.
| Hook | Purpose |
preflight | Fast blocking validation before review |
docs_sync | Update docs, examples, or screenshots affected by the change |
review | Semantic review of the actual delta |
tests | Targeted or full tests for confidence |
gate | Post-commit go/warn/block check |
publish | Push, PR creation, tag, and release handling |
Rerun Model
Use prior ship state to save time, not to lower quality.
cached: same HEAD, reuse prior non-security work if trustworthydelta: scope review and non-security checks to files changed since last shipfull: no trustworthy prior state, or the change is large enough that full review is cheaper
Security validation is always treated as fresh.
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.

