ship

A release workflow for finished local code. It checks the work, runs the tests, creates a commit, pushes the branch, and opens a pull request for review.

In plain words
What is it for?
Use it when changes are ready to review, such as when you want to ship, push, and open a pull request. It can also prepare the steps without pushing anything.
Why use it?
It removes the repetitive hand-off steps between finishing code locally and sending it to teammates. It also records what was checked in the pull request.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/griffinwork40/agent-framework/ship
Any agent
npx skills add griffinwork40/agent-framework --skill ship
Clone the repo
git clone --depth 1 https://github.com/griffinwork40/agent-framework

Made for: Claude Code, Codex.

Per session 93 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,803 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin 95% copy Near-identical to another mod in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00093 $0.02803
Opus 5 $0.00046 $0.01401
Sonnet 5 $0.00019 $0.00561
Haiku 4.5 $0.00009 $0.00280

Measured 2d ago against content hash 4b082cdcbfe5, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

ship scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

Origin

This is a copy

95% identical to ship — 1 line differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

skills/ship/SKILL.md · 147 lines

How it starts

The opening of the file, as written. The whole thing — 147 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Sub-agent contract

/contract

Release pipeline for work that is already done locally. This skill does NOT build, implement, or fix — if the task needs code, route to /mint; if a bug needs diagnosis, route to /diagnose. This skill's job is the hand-off from "done locally" to "visible in a PR."

Skip when:

  • Working tree is clean (nothing to ship — tell the user).
  • Current branch is the default branch (main/master) — ask the user for a feature branch.
  • User invokes with --dry-run → produce the plan but take no git actions.

Arguments:

  • --verify — force the optional adversarial verifier wave (Phase 6), regardless of diff size.
  • --draft — open the PR as a draft.
  • --dry-run — run phases 1–5 but stop before Phase 7 (no push, no PR).

Hard rules (non-negotiable — these override any inferred convention):

  • Branch lock. Whatever branch is checked out when /ship starts is the only branch you may commit and push from. NEVER git checkout to a different branch during this skill — not to main, not to master, not to a sibling feature branch. If pre-flight finds you on the default branch, abort. Do not "recover" by switching branches yourself.
  • Never push to the default branch. Phase 5 pushes the CURRENT (feature) branch. Phase 8 opens a PR. There is no path through this skill that pushes to main/master or merges without a PR. If you find yourself about to run git push origin main (or equivalent), stop.
  • User intent is absolute. If the user said "make a PR," "open a PR," "submit for review," or anything synonymous, you MUST complete Phase 8. "Ship" / "release" alone also implies PR — there is no interpretation under which /ship means "skip the PR step."
  • Do not invent project convention. Never assert "this project uses direct-to-main flow," "this repo merges direct," or any equivalent justification for bypassing the PR step. If you genuinely cannot tell whether the project uses PRs, run gh pr list --state merged --limit 5; ≥3 merged PRs in the last week ⇒ PR is the convention. If still ambiguous, ask the user. Default to PR — it is the safer choice.
  • Anchor cwd. When /ship is invoked, pwd at that moment is the only working directory you operate in. All git commands and file reads must run inside that directory — never cd to a sibling worktree, the parent repo, or any other path during this skill. If you find yourself reading state from a path other than the invocation cwd (e.g. git log returning unrelated commits, or a file diff that doesn't match what was just edited), stop and re-anchor on the original cwd. Worktrees and sibling repos look almost identical; cwd is the only disambiguator.

Phase 1 — Pre-flight (mandatory, runs BEFORE any git mutation). Invoke ground-state via the Skill tool. Abort and surface the blocker with remediation steps if ground-state reports any of:

  • Uncommitted changes in files unrelated to the declared scope
  • Branch behind origin/<default> (stale — user needs to rebase/merge first)
  • Current branch IS the default branch
  • Wrong-repo context (user's cwd doesn't match the branch's purpose)

Phase 2 — Test gate. Detect the project's test harness by scanning, in order:

  1. package.jsonscripts.test (run via the project's package manager: pnpm/yarn/npm)
  2. pyproject.tomlpytest if configured, or scripts.test
  3. Cargo.tomlcargo test
  4. go.modgo test ./...
  5. Makefiletest target

If found → run it. Non-zero exit → abort; surface the failing output and recommend /diagnose. Do not proceed to commit.

If no harness detected → warn the user: "No test harness detected. Ship without running tests?" Require explicit yes. Do not silently skip.

Phase 3 — Draft commit message. Read the cumulative diff: git diff --stat origin/<default>...HEAD + full git diff. Synthesize a commit message:

  • Subject (≤70 chars): imperative, Conventional Commits format (feat, fix, chore, refactor, docs, etc.)
  • Body: 2–5 bullets on WHY — the motivation, constraint, or trade-off. Skip the WHAT — the diff speaks for itself.

Read the full file on GitHub · 147 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 147 lines · 93 tokens per session scan A 4b082cdcbfe5

Subscribe to this mod's changes

ship is a skill published in the GitHub repository griffinwork40/agent-framework (23 stars, last pushed 8d ago), licensed Apache-2.0. It adds 93 tokens to every session and 2,803 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. It is 95% identical to ship, differing in 1 line, and is treated as a copy.

Related

Other skills, from other repositories

systematic-debugging

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.

obra/superpowers · 21 tokens

brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

obra/superpowers · 37 tokens

auto-perf-optimize

Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.

microsoft/vscode · 62 tokens

chat-perf

Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.

microsoft/vscode · 51 tokens

chat-pet-sprite-creation

Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.

microsoft/vscode · 53 tokens

cpu-profile-analysis

Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…

microsoft/vscode · 71 tokens