← ClaudeAtlas

shiplisted

Drive a change from working tree to a merge-ready pull request — reproduce the gates exactly as CI runs them, triage reds correctly, and sequence the merge. Use when committing, pushing, opening a PR, or when a pre-commit hook or CI check has gone red and you need to decide whether to fix, defer, or stop. Terminates at green-awaiting-approval; it never merges.
lemur47/logic · ★ 2 · Code & Development · score 68
Install: claude install-skill lemur47/logic
# Ship — Commit to Merge-Ready A repository with good gates does not need an agent to invent checks. The checks exist, they are deterministic, and they are the same every time. What costs time is everything around them: - **Reproducing a gate wrongly**, and drawing a confident conclusion from the wrong answer. - **Triaging a red that is not yours** — deciding between fix, defer, and stop. - **Sequencing** — which pull request merges first, and what must be updated after it does. This skill is those three things. It is not a licence to make checks pass. ## The One Rule That Matters Most > **Never make a gate pass by weakening the gate.** An automated loop optimises for "the check is green". In a repository whose gates are security controls, the cheapest route to green is almost always to lower the bar — and every one of those routes looks like a fix: | Looks like a fix | Actually is | |---|---| | Adding an ignore/waiver entry for the finding | Deleting the finding | | Extending a waiver's review-by date | Making a deferral permanent | | Adding a lint or type ignore comment | Hiding the defect | | `--no-verify`, `--force`, skipping a hook | Removing the control entirely | | Loosening a version pin to resolve a conflict | Trading a known-good for an unknown | | Deleting or skipping the failing test | The worst of all of these | Every one of these may occasionally be the right answer. **None of them is ever this loop's call.** They are a separate, explicitly approved