Type /ship and Mean It

The code is done. Tests pass. Then the PR tax kicks in.

Rebase. Lint. Type-check. Build. Update the changelog. Check the docs. Write a PR description. Push. Open the PR. Hope you remembered everything.

Every team has this checklist. Nobody follows it the same way every time.

So I turned ours into a coding-agent skill. Now I type /ship.

One command, six steps

The skill runs the same pipeline for every PR:

1. Preflight: rebase, inspect git state, and create the right branch if needed.
2. Quality gates: detect and run lint, type-check, test, and build commands.
3. Documentation: inspect the diff and propose relevant README or agent-guide updates.
4. Changelog: classify the change, bump the version, and draft the entry.
5. Pull request: push the branch and write the summary and test plan from the diff.
6. Report: return the PR URL, completed checks, version bump, and warnings.

If a step fails, the agent stops. It fixes routine problems when it can and hands judgment calls back to me.

That boundary matters.

CI enforces. The agent navigates.

CI already runs lint, tests, and builds. Running them before push is intentional: feedback arrives while I’m still working, not five minutes later in a red check.

But the useful part is everything CI cannot express cleanly in YAML:

• Does this new environment variable belong in the README?
• Is this change a patch or a minor release?
• Should the branch be fix/ or chore/?
• Should a failed rebase be resolved or aborted?

Shell scripts gather facts. The agent reads the diff, interprets failures, and decides whether to fix, retry, or stop.

The skill itself is mostly Markdown plus a few small shell scripts. No custom app. No new dashboard. Just an executable version of the checklist we already had.

That is the pattern worth stealing: turn repeated team ceremony into agent instructions, then keep humans at the judgment points.

If your shipping checklist lives in a wiki, make the wiki executable.

Resources

• /ship skill on GitHub