How to use the Ship a Change agent skill (workflow-ship-change)

What the skill makes the agent do

The skill defines a fixed end-of-change checklist. A change counts as done only when the report shows each item: screenshots of the start, the key moment and the result; its own changelog version with pictures; passing tests; one commit containing only the agent's own files; a fast-forward push to main; a live publish of that exact main; and measured sizes for the commit, push and any upload.

It applies to feature, fix, tweak, art, balance and polish changes. It also tells the agent to stop and ask you before any upload over 50 MB, before any force-push, and when a permission check blocks a deploy.

Install the skill from the ZIP

Download the workflow-ship-change ZIP from this page, then choose one of two locations. For a personal install, unzip it into ~/.claude/skills/. For a single project, unzip it into that project's .claude/skills/ folder.

If you use the Claude apps instead, upload the ZIP under Settings → Capabilities → Skills.

• Personal install: ~/.claude/skills/
• Project install: the project's .claude/skills/ folder
• Claude apps: Settings → Capabilities → Skills, then upload the ZIP

Check what you need before triggering it

The skill assumes a working environment. It needs git with access to the repository's origin remote, a bash shell with standard Unix tools (awk, find, stat, du, wc), the project's test tooling (the skill mentions node and pnpm), and a live hosting account such as Netlify or Supabase as the project references.

For screenshots it expects headless browser capture via CDP, and it references the workflow-progress-screenshots skill. Project-specific rules can go in an optional local references/<project>.md file next to the skill.

• git with access to the origin remote
• bash with awk, find, stat, du and wc
• project test tooling (node, pnpm mentioned)
• a live hosting account for publishing
• headless browser capture via CDP for screenshots

Trigger the skill with natural requests

You do not need a special command. The skill is meant to run at the end of a change, and it also responds to everyday wording. The source names these trigger phrases: ship it, commit, push, merge, publish, deploy, go live and update the changelog.

A request such as "ship it" at the end of a feature, or "update the changelog and go live" after a balance tweak, should cause the agent to load the checklist. Say so explicitly if you want the full run rather than a single step.

• "Ship it."
• "Commit and push this fix."
• "Update the changelog for the new level art."
• "Publish this and go live."

Read the scripts and safety limits

The skill runs helper scripts and uses the network. scripts/commit-size.sh and scripts/upload-size.sh measure sizes, scripts/push-main.sh performs the safe push, and scripts/verify-live.sh checks that the live pages and assets load after a publish.

The scripts assume macOS-style stat flags, pnpm, Netlify and Supabase. If your repository uses different tools, the steps will fail or need local rewriting. Review the scripts before the first run, since the agent executes them.

The skill never publishes anything except the clean, pushed origin/main, never stages .env files, node_modules or build output, and never uses git add -A in a shared checkout. It also never runs the broad image optimizer, which can rewrite other sessions' pending images.

• Uploads over 50 MB: the agent measures first and asks you.
• Force-pushes, history rewrites, visibility changes: the agent asks you.
• Large media goes to Supabase Storage, not Netlify.
• If live is broken after a publish, the agent reports it first with a rollback path.

Tips for getting reliable results

Give the agent a clear end state, such as "ship it to live" or "commit and push but don't publish", so it knows where to stop. Keep your project rules in references/<project>.md, because the skill says project rules win over its defaults.

Expect a full test run to take a long time. The source says the full suite can take 10 to 40 minutes on a busy machine, and the agent is told to run it in the background and read the log.

• Name the end state you want (commit only, push, or publish live).
• Put project hosting and changelog rules in references/<project>.md.
• Run the full suite in the background and expect it to take a while.