agentleFS
Sign inStart free
CrystalPlatformsCrystalPlatforms/ADM-CLI/.claude/skills/ship/SKILL.md

ship

Skill1 starsChanged 6 months agoMITView on GitHub

Lint, type-check, commit, and push in one flow. Use when user says /ship or asks to commit+push.

  • Reads credentials
  • Deletes or force-pushes
  • 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

Show its rules and text

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 180 edited versions we read keep these.

  • 13

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run all steps in order. Stop immediately on any failure.

    line 8
  2. Distinctive:

    Before running checks, detect what tooling is available:

    line 12
  3. Very specific:

    Check if package.json exists in the repo root.

    line 14
  4. Very specific:

    If it does, look for the lint:ci and types scripts inside it.

    line 15
  5. Distinctive:

    Run only the scripts that exist — in parallel:

    line 16
  6. Very specific:

    If package.json does not exist or neither script is defined, skip this step entirely and proceed to Step 2.

    line 19
  7. Distinctive:

    If any executed check fails, show the errors and stop.

    line 21
  8. Distinctive:

    Run all three in parallel:

    line 25
  9. Distinctive:

    If there are no changes to commit, inform the user and stop.

    line 33
  10. Distinctive:

    Do NOT stage files that likely contain secrets (.env, credentials, etc.)

    line 38
  11. Distinctive:

    Wait for user confirmation before committing

    line 41
  12. Distinctive:

    Use HEREDOC format for the commit message with Co-Authored-By trailer

    line 42
  13. Distinctive:

    Always pull before push to avoid rejection:

    line 46
  14. Distinctive:

    If rebase has conflicts, show them and stop — let the user decide.

    line 52
  15. Very specific:

    Never skip hooks (--no-verify)

    line 57
  16. Distinctive:

    Never amend existing commits unless user explicitly asks

    line 58
  17. Distinctive:

    If any step fails, stop and report — don't retry automatically

    line 59

“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 — Lint, Commit & Push

Run all steps in order. Stop immediately on any failure.

Step 1 — Pre-flight checks (conditional, parallel)

Before running checks, detect what tooling is available:

  1. Check if package.json exists in the repo root.
  2. If it does, look for the lint:ci and types scripts inside it.
  3. Run only the scripts that exist — in parallel:
    • pnpm lint:ci (if script lint:ci is defined)
    • pnpm types (if script types is defined)
  4. If package.json does not exist or neither script is defined, skip this step entirely and proceed to Step 2.

If any executed check fails, show the errors and stop. Do not commit broken code.

Step 2 — Gather git context (parallel)

Run all three in parallel:

git status
git diff --staged && git diff
git log --oneline -5

If there are no changes to commit, inform the user and stop.

Step 3 — Stage & Commit

  • Stage only the relevant changed files by name — never git add -A or git add .
  • Do NOT stage files that likely contain secrets (.env, credentials, etc.)
  • Analyze the diff and recent log to draft a commit message matching the repo's style (conventional commits, concise)
  • Show the user the proposed commit message and files to be staged
  • Wait for user confirmation before committing
  • Use HEREDOC format for the commit message with Co-Authored-By trailer

Step 4 — Pull & Push

Always pull before push to avoid rejection:

git pull --rebase && git push

If rebase has conflicts, show them and stop — let the user decide.

Rules

  • Never git push --force
  • Never skip hooks (--no-verify)
  • Never amend existing commits unless user explicitly asks
  • If any step fails, stop and report — don't retry automatically

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