Menu
When to ship vs not ship. The single ship gate, six auto-decision principles for plan reviews, and the Confusion Protocol for when to stop and ask.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Working with AI coding agents — User Sovereignty, agreement-as-signal, Karpathy/Willison framing, per-model overlays, and the rule to measure your prompt nudges.
Estimate work and scope decisions in the AI-coding era. Boil the Lake, AI compression ratios, three-layer search before building.
Compound knowledge across sessions. Plan-tune dual-track psychographic profile (declared vs behavior), retro philosophy that demotes LOC, the keep-or-toss test for learnings.
Code review, debugging, and incident discipline. Confidence calibration, root-cause iron law, alert-on-changes rule, the pre-existing blame protocol.
UX quality bar — Krug's three laws of usability, the eight DevEx first principles, time-to-hello-world tiers, the Goodwill Reservoir, the Pit of Success.
Decide what to build using YC's six forcing questions and the four CEO scope modes. Use before any new feature, product bet, or GTM angle.
| name | ship-discipline |
| author | 0xabrar |
| description | When to ship vs not ship. The single ship gate, six auto-decision principles for plan reviews, and the Confusion Protocol for when to stop and ask. |
Heuristics for shipping. Pick a single gate; let the rest be informational.
Source: gstack ship/SKILL.md, autoplan/SKILL.md, land-and-deploy/SKILL.md.
The ship gate is one thing only: Eng Review passing.
CEO / Design / Adversarial / Outside-Voice reviews are shown but never block shipping.
For solo founders: pick one hard gate per workflow and refuse to let optional reviews accumulate veto power.
When deciding between approaches in a plan review, apply in order:
Three categories. Treat each differently:
| Type | Action |
|---|---|
| Mechanical (one obviously correct answer) | Decide silently, mention in summary |
| Taste (close call, defensible either way) | Auto-decide, surface at the end for user review |
| User Challenge (both AI models disagree with the user) | NEVER auto-decide. Force the models to make the case |
User Challenge framing: "The user's original direction is the default." Models must argue against it.
STOP and ask only on:
Never stop for:
"If you catch yourself writing fewer than 3 sentences for any review section, you are likely compressing."
These are non-negotiable in code review:
rescue StandardError / except Exception is ALWAYS a smellRead/Edit/Grep over Bash equivalents when a dedicated tool fitsPersona: a release engineer who has deployed thousands of times.
"The two worst feelings in software: the merge that breaks prod, and the merge that sits in queue for 45 minutes while you stare."
Two hard gates remain even when automated:
Tone rule: narrate, don't go silent.
"Explain why before asking — 'Deploys are irreversible, so I check X.'"
First run = teacher mode. Subsequent runs = efficient.
Single-pass verification (not continuous monitoring — that's canary's job).
"AI makes completeness near-free… A 'lake' is boilable; an 'ocean' is not. Boil lakes, flag oceans."
"'Ship the shortcut' is legacy thinking from when human engineering time was the bottleneck."
The asymmetry is the point: the one hard gate is named. Everything else is information.