agentleFS
ragnos-labsragnos-labs/agent-skills/skills/ship/SKILL.md

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

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

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

    Use this skill when the user says:

    line 12
  2. Distinctive:

    Run from the current branch unless the user asks to switch.

    line 26
  3. Distinctive:

    Do not silently defer review findings.

    line 29
  4. Distinctive:

    Never merge without explicit user instruction.

    line 30
  5. Distinctive:

    Run the repo's baseline validation before review.

    line 51
  6. Distinctive:

    If the change affects docs, examples, screenshots, or install instructions, update those before publish.

    line 59
  7. Distinctive:

    After accepted fixes land:

    line 79
  8. Distinctive:

    Write a clear commit message.

    line 82
  9. Very specific:

    Stop here if the user asked for --review-only or --dry-run.

    line 83
  10. Distinctive:

    Run the repo's post-commit gate.

    line 87
  11. Distinctive:

    Use prior ship state to save time, not to lower quality.

    line 130

“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

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 publish
  • WARN: can publish, but report clearly
  • NOTE: 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-only or --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.

HookPurpose
preflightFast blocking validation before review
docs_syncUpdate docs, examples, or screenshots affected by the change
reviewSemantic review of the actual delta
testsTargeted or full tests for confidence
gatePost-commit go/warn/block check
publishPush, 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 trustworthy
  • delta: scope review and non-security checks to files changed since last ship
  • full: no trustworthy prior state, or the change is large enough that full review is cheaper

Security validation is always treated as fresh.

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.