Ship
Full pipeline — audit, review+fix, docs, push PR. One command to go from "done coding" to "PR ready for review." Does NOT deploy — your CI/CD handles that after merge.From its SKILL.md
npx -y skills add cloverink/shipwright --skill shipAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.5 KB, 575 tokens by cl100k_base, as published. Nobody here has run it
/ship
One-command pipeline that takes your finished work through quality gates and opens a PR.
Pipeline
Phase A (Audit) → find issues → auto-fix Critical/Major → verify fixes
Phase R (Review) → code review + UX review → fix until gates pass
Phase D (Docs) → sync documentation → verify accuracy
Phase S (Ship) → push branch + open PR with full description
Execution Strategy
- Pre-flight check — verify there are actual changes to ship (staged, unstaged, or commits ahead of main)
- Spawn a subagent for the heavy lifting (keeps main context clean for long pipelines)
- Run phases A → R → D → S sequentially — each phase gates the next
- Report back with PR URL when done
Pre-flight Gates
Before running, verify:
- Not on
mainbranch - Has changes to ship (diff or commits ahead of main)
- Lint + typecheck pass
Phase Gates
| Phase | Gate | Fails when |
|---|---|---|
| A (Audit) | Auto-fix succeeds | Critical issues can't be auto-fixed |
| R (Review) | Code >9, UX 10/10 | Score below threshold after 3 fix rounds |
| D (Docs) | No stale references | Dead links or missing doc updates |
| S (Ship) | Clean working tree | Uncommitted changes after phases A-D |
Commit Strategy
Each phase gets its own commit:
Phase A: refactor(<scope>): audit fixes — <summary>
Phase R: fix(<scope>): review fixes — <summary>
Phase D: docs(<scope>): sync documentation
Phase S: (no commit — push + open PR)
<!-- CONFIGURE: Adjust commit format to match your project's conventions -->
What it does NOT do
- Does not deploy — it opens a PR. Your CI/CD deploys after merge.
- Does not merge — the PR is opened for human review. Use
/merge-prafter approval. - Does not auto-approve — even though automated review passes, a human should still look at the PR.
Dependencies
This skill orchestrates other skills in the pipeline:
- Phase A:
/audit-full - Phase R:
/review-full(dispatches to/review-code-fix+/review-ux-fixbased on diff scope) - Phase D:
/update-docs+/review-docs - Phase S:
/push
Phases are modular — remove or replace any phase that doesn't apply to your project.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most ship operate skills give in 575 tokens
Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07
- Document a rollback plan before deploymentin 41 of 779, across 22 files
- Update the changelogin 21 of 779, across 19 files
- Run the test suitein 20 of 779
- Create an annotated git tagin 20 of 779
- Clean up feature flags after full rolloutin 18 of 779, across 10 files
- Verify deployment health after launchin 18 of 779, across 10 files
- Test both feature flag statesin 17 of 779, across 9 files
- Verify the working tree is cleanin 17 of 779
- Make database migrations backward-compatiblein 16 of 779, across 8 files
- Set up error monitoring before launchin 15 of 779, across 7 files
- Monitor metrics at each rollout stagein 14 of 779, across 5 files
- Create a GitHub releasein 14 of 779
Said here and by no other author read
- verify changes exist to ship
- run audit, review, docs, and ship phases sequentially
- auto-fix critical and major audit issues
- iterate review fixes until score thresholds pass
- sync documentation and verify accuracy
- commit after each pipeline phase
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.