agentleFS
catlog22catlog22/Claude-Code-Workflow/.claude/skills/ship/SKILL.md

ship

Skill2.1k starsChanged 7 months agoMITArchived repositoryView on GitHub

Structured release pipeline with pre-flight checks, AI code review, version bump, changelog, PR creation, platform publish, and GitHub release. Triggers on "ship", "release", "publish".

  • 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

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 179 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every execution terminates with one of:

    line 100

“Common” is measured: kept by at least 6 in 10 of the 179 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

Structured release pipeline that guides code from working branch to a published release through 7 gated phases: pre-flight checks, automated code review, version bump, changelog generation, PR creation, platform publish (npm/PyPI/etc.), and GitHub release.

Phases 5 (PR) and 6 (Publish) are conditionally skippable — trunk-based workflows that commit directly to main skip Phase 5; private packages skip Phase 6. Phase 7 (GitHub release) is the terminal phase and always runs unless the publish step failed.

Key Design Principles

  1. Phase Gates: Each phase must pass before the next begins — no shipping broken code
  2. Multi-Project Support: Detects npm (package.json), Python (pyproject.toml), and generic (VERSION) projects
  3. AI-Powered Review: Uses CCW CLI to run automated code review before release
  4. Audit Trail: Each phase produces structured output for traceability
  5. Safe Defaults: Warns on risky operations (direct push to main, major version bumps)

Architecture Overview

User: "ship" / "release" / "publish"
         |
         v
┌──────────────────────────────────────────────────────────┐
│  Phase 1: Pre-Flight Checks                              │
│  → git clean? branch ok? tests pass? build ok?           │
│  → Output: preflight-report.json                         │
│  → Gate: ALL checks must pass                            │
├──────────────────────────────────────────────────────────┤
│  Phase 2: Code Review                                    │
│  → detect merge base, diff against base                  │
│  → ccw cli --tool gemini --mode analysis                 │
│  → flag high-risk changes                                │
│  → Output: review-summary                                │
│  → Gate: No critical issues flagged                      │
├──────────────────────────────────────────────────────────┤
│  Phase 3: Version Bump                                   │
│  → detect version file (package.json/pyproject.toml/VERSION)
│  → determine bump type from commits or user input        │
│  → update version file                                   │
│  → Output: version change record                         │
│  → Gate: Version updated successfully                    │
├──────────────────────────────────────────────────────────┤
│  Phase 4: Changelog & Commit                             │
│  → generate changelog from git log since last tag        │
│  → update CHANGELOG.md                                   │
│  → create release commit, push to remote                 │
│  → Output: commit SHA                                    │
│  → Gate: Push successful                                 │
├──────────────────────────────────────────────────────────┤
│  Phase 5: PR Creation (skippable for trunk-based)        │
│  → gh pr create with structured body                     │
│  → auto-link issues from commits                         │
│  → Output: PR URL                                        │
│  → Gate: PR created OR skipped (direct-to-main)          │
├──────────────────────────────────────────────────────────┤
│  Phase 6: Platform Publish (skippable if private)        │
│  → detect registry (npm / PyPI / crates.io)              │
│  → npm publish / twine upload / cargo publish            │
│  → verify new version is live on registry                │
│  → Output: published artifact metadata                   │
│  → Gate: registry confirms version OR skipped (private)  │
├──────────────────────────────────────────────────────────┤
│  Phase 7: GitHub Release                                 │
│  → git tag -a vX.Y.Z + push tag                          │
│  → gh release create with structured notes               │
│  → Output: release URL                                   │
│  → Gate: release URL returned                            │
└──────────────────────────────────────────────────────────┘

Execution Flow

Execute phases sequentially. Each phase has a gate condition — if the gate fails, stop and report status.

  1. Phase 1: Pre-Flight Checks -- Validate git state, branch, tests, build
  2. Phase 2: Code Review -- AI-powered diff review with risk assessment
  3. Phase 3: Version Bump -- Detect and update version across project types
  4. Phase 4: Changelog & Commit -- Generate changelog, create release commit, push
  5. Phase 5: PR Creation -- Create PR with structured body and issue links (skip for trunk-based)
  6. Phase 6: Platform Publish -- Publish to npm / PyPI / crates.io (skip for private packages)
  7. Phase 7: GitHub Release -- Tag release commit and publish GitHub release notes

Pre-Flight Checklist (Quick Reference)

CheckCommandPass Condition
Git cleangit status --porcelainEmpty output
Branchgit branch --show-currentNot main/master
Testsnpm test / pytestExit code 0
Buildnpm run build / python -m buildExit code 0

Completion Status Protocol

This skill follows the Completion Status Protocol defined in SKILL-DESIGN-SPEC.md sections 13-14.

Every execution terminates with one of:

StatusWhen
DONEAll applicable phases completed, GitHub release published
DONE_WITH_CONCERNSRelease published but with review warnings, skipped publish (private pkg), or non-critical issues
BLOCKEDA gate failed (dirty git, tests fail, push rejected, publish failed, tag conflict)
NEEDS_CONTEXTCannot determine bump type, ambiguous branch target, unclear registry target

Escalation

Follows the Three-Strike Rule (SKILL-DESIGN-SPEC section 14). On 3 consecutive failures at the same step, stop and output diagnostic dump.

Reference Documents

DocumentPurpose
phases/01-preflight-checks.mdGit, branch, test, build validation
phases/02-code-review.mdAI-powered diff review
phases/03-version-bump.mdVersion detection and bump
phases/04-changelog-commit.mdChangelog generation and release commit
phases/05-pr-creation.mdPR creation with issue linking (skippable)
phases/06-platform-publish.mdnpm / PyPI / crates.io publish (skippable)
phases/07-github-release.mdTag and GitHub release notes
../_shared/SKILL-DESIGN-SPEC.mdSkill design spec (completion protocol, escalation)

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.