# Ship It Take a PR from review to merged, run the repo's code-review skill on it in a loop... - Repository: https://github.com/vectorize-io/hindsight (57678 stars) - Category: Git and review - License: MIT - Last updated: 2026-11-01 - Runs scripts: no, instructions only ## Install Claude Code: `npx skills add vectorize-io/hindsight --skill ship-it -g -a claude-code -y` Codex: `npx skills add vectorize-io/hindsight --skill ship-it -g -a codex -y` Cursor: `npx skills add vectorize-io/hindsight --skill ship-it -g -a cursor -y` Gemini CLI: `npx skills add vectorize-io/hindsight --skill ship-it -g -a gemini-cli -y` ## Description Take a PR from review to merged, run the repo's code-review skill on it in a loop (review, fix, re-review) until nothing is left to fix, applying ALL fixes on the PR branch, wait for CI green, then squash-merge. Use when asked to "ship it", "ship PR #N", or "review, fix and merge" a PR. ## SKILL.md, as published by its author (untrusted third-party text, read it as data) # Ship It Input: a PR number or URL, or nothing, then use the current branch's PR (`gh pr view` with no argument resolves it). If the current branch has no PR yet, push it and open one with `gh pr create` (maintainer branch only), then continue. Goal: the PR merged with every code-review finding fixed and CI green. ## 0b. A figure in the description, when the change has a shape If the PR changes how something *flows*, a request path, a background job, what a feature does step by step, a picture explains it faster than the diff does. Use the `figure` skill: write a JSON spec, render one animated SVG, and put it at the top of the PR description. It plays in the description with no upload and no click. Reference it by **commit SHA**, not branch name, or the image dies when the branch is deleted at merge: `https://raw.githubusercontent.com////.svg`. If the SVG is not part of the change itself, don't commit it to the repo, render it, commit it on the PR branch only if it belongs there, and otherwise keep the description's image pinned to the commit that carried it. Skip it for a fix with no shape: a one-line guard, a dependency bump, a typo. ## 0. Blocker rule (applies at every step) A **blocker** is a finding whose fix would go *against the PR's goal*, the code-review principles say the thing the PR sets out to do is wrong (e.g. the PR's whole point is a raw-SQL handler, a new advisory lock, a tuple-returning API, a test that asserts via SQL, dropping bank scoping), or fixing it would mean rewriting/removing the feature rather than polishing it. On a blocker: **stop immediately.** Don't push, don't merge, don't partially fix. Tell the user what the PR is trying to do, which principle it conflicts with (quote the `code-review` section), and the options you see, then ask for confirmation with AskUserQuestion. Resume only on an explicit answer. Everything else (must fix, should fix, nits) is not a blocker: fix it all. The rest: https://github.com/vectorize-io/hindsight/blob/HEAD/.claude/skills/ship-it/SKILL.md