From code-quality-ship
Full code quality pass that auto-merges the PR when CI is green and the change is simple enough. Runs /msilvis:code-quality, then gates a squash-merge on a strict simplicity checklist. Use when the user wants to ship a small PR end-to-end with one command.
How this skill is triggered — by the user, by Claude, or both
Slash command
/code-quality-ship:code-quality-shipThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Extends `/msilvis:code-quality`: run the full review + simplify pass, then — only if the change is small and safe — wait for CI and squash-merge the PR. If anything trips the simplicity gate, stop and hand control back to the user instead of merging.
Extends /msilvis:code-quality: run the full review + simplify pass, then — only if the change is small and safe — wait for CI and squash-merge the PR. If anything trips the simplicity gate, stop and hand control back to the user instead of merging.
This skill is only for shipping an open PR. Before doing anything else:
gh pr view --json number,state,headRefOid,isDraft -q '{num: .number, state: .state, sha: .headRefOid, draft: .isDraft}'Run /msilvis:code-quality against the current branch. Follow that skill exactly: review, fix everything, run all simplify passes for the detected stack, commit, push, and post the reviewed sentinel.
Do not skip any of its steps. If /msilvis:code-quality finds issues that require user judgment (it asks a question, hits something ambiguous, or the rerun confirmation in its Step 0), stop and let the user decide — do not auto-merge.
After the quality pass commits and pushes, decide whether the PR is safe to auto-merge. The gate has three pillars: no unresolved review findings, no schema changes, and low complexity. Long PRs are fine — what matters is that the change is mechanical/obvious and has no data-shape implications.
If anything below trips, stop and hand off. Don't merge.
Compute the diff against the PR base:
base=$(gh pr view --json baseRefName -q '.baseRefName')
git fetch origin "$base"
git diff --name-only "origin/$base"...HEAD
git diff "origin/$base"...HEAD
Before evaluating the schema and complexity pillars, read the sentinel comment that Step 2 posted and check for an unresolved-review-findings block. These are concerns /review surfaced that the model couldn't safely auto-fix; they need human judgment before the PR can ship.
findings=$(gh pr view --json comments -q '.comments[].body' \
| awk '/unresolved-review-findings:start/{flag=1;next} /unresolved-review-findings:end/{flag=0} flag')
If $findings is non-empty, the gate trips on this signal alone — proceed straight to "If the gate trips" below and use the Pillar 0 template, which leads with the unresolved findings rather than burying them under a complexity-gate framing. Do not also post a Pillar B comment; the findings are the headline.
If $findings is empty, proceed to Pillar A.
prisma/schema.prisma editedprisma/migrations/ or any migrations/**/*.sql, db/migrate/***.proto, *.graphql, OpenAPI specs)Schema changes ship behind a human merge. Always.
Read the diff and decide whether a reviewer would call this "obvious" or "needs thinking." A long PR full of mechanical edits (renames, formatting, extracting a helper used in one place, deleting dead code, doc/comment changes, test additions for existing behavior) is fine to merge. A short PR that introduces new behavior or new patterns is not.
Trips the gate — needs a human:
package.json, pnpm-lock.yaml, Podfile, Package.swift, Gemfile, go.mod, pyproject.toml, requirements*.txt, .mise.toml).github/workflows/, .circleci/, Dockerfiles, docker-compose*, deployment manifests, env files)Does NOT trip the gate (mechanical, ship it):
do-not-merge, wip, or blocked (gh pr view --json labels -q '.labels[].name')gh pr view --json reviewDecision -q '.reviewDecision' is not CHANGES_REQUESTEDCHANGES_REQUESTED state (gh pr view --json reviews -q '[.reviews[] | select(.state=="CHANGES_REQUESTED")] | length' is 0)(Unresolved /review findings are handled by Pillar 0 above, not here.)
Post a single PR comment that leads with the highest-precedence reason. Order: Pillar 0 → Pillar A → Pillar B → Pillar C. If multiple pillars tripped, mention each briefly but use the highest-precedence template as the headline. Then stop — don't merge.
Pillar 0 — unresolved review findings (use this whenever $findings from Pillar 0 is non-empty, even if other pillars also tripped):
🛑 **Auto-merge blocked — `/review` flagged concerns that need your judgment.**
The code-quality pass at `<short_sha>` surfaced these issues but did not auto-fix them:
<paste $findings here, verbatim>
Please address them in this PR (or call them out as known/intentional in a reply), then re-run `/msilvis:code-quality-ship`.
Pillar A / B / C — only when there are no unresolved findings: post a brief PR comment naming which pillar/specific item blocked the merge (e.g. "Skipped auto-merge: introduces a new retry helper in lib/fetch.ts — wants a human eye"). Then stop. Don't merge.
Only reached if Step 3 passed every check.
gh pr checks <pr-number> --watch — wait for all required checks. Timeout after 15 minutes.gh pr checks <pr-number> and gh run view <run-id> --log-failedgh pr merge <pr-number> --squash --delete-branchgh pr view <pr-number> --json state -q '.state' should be MERGED.CHANGES_REQUESTED.--admin or --no-verify to bypass branch protection or hooks. If the merge is blocked, surface the reason and stop.Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub mikesilvis/ai-skills --plugin code-quality-ship