Ship discipline

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.

One gate, named explicitly

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.

Six auto-decision principles

When deciding between approaches in a plan review, apply in order:

1. Choose completeness — pick the approach that covers more edge cases.
2. Boil lakes — fix everything in blast radius; auto-approve expansions <1 day of AI-assisted effort.
3. Pragmatic — "5 seconds choosing, not 5 minutes."
4. DRY — duplicates existing functionality? Reject.
5. Explicit over clever — "10-line obvious fix > 200-line abstraction. Pick what a new contributor reads in 30 seconds."
6. Bias toward action — "Merge > review cycles > stale deliberation. Flag concerns but don't block."

Phase tiebreakers

• CEO review → P1+P2 (completeness, boil lakes) dominate
• Eng review → P5+P3 (explicit, pragmatic)
• Design review → P5+P1 (explicit, completeness)

Decision classification

Three categories. Treat each differently:

User Challenge framing: "The user's original direction is the default." Models must argue against it.

The Confusion Protocol

STOP and ask only on:

• Architectural / data-model ambiguity
• Destructive scope unclear
• Contradicting patterns in the codebase

Never stop for:

• Routine work
• Uncommitted changes
• Version bumps
• CHANGELOG updates
• Commit messages

"If you catch yourself writing fewer than 3 sentences for any review section, you are likely compressing."

9 prime directives (eng review)

These are non-negotiable in code review:

• Zero silent failures — every error has a name
• Catch-all rescue StandardError / except Exception is ALWAYS a smell
• Data flows have shadow paths — trace happy + nil + empty + upstream-error, all four
• Diagrams are mandatory for architectural changes
• Everything deferred must be written down — "vague intentions are lies. TODOS.md or it doesn't exist."
• Optimize for the 6-month future, not the 6-day present
• Test coverage is non-optional — see review-and-debug for confidence calibration
• Prefer Read/Edit/Grep over Bash equivalents when a dedicated tool fits
• No string-matching error messages to dodge linters

Land and deploy

Persona: 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:

1. First-run dry-run validation — you need to see the deploy infra once
2. Pre-merge readiness — reviews / tests / docs

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).

Ship's central doctrine

"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."

What ship explicitly does NOT block on

• CEO / scope-expansion suggestions (informational)
• Design review findings (informational)
• Adversarial review (informational)
• Outside-voice critique (informational)
• Uncommitted changes from unrelated work
• Version bumps
• CHANGELOG voice / formatting

What ship explicitly DOES block on

• Eng review failures
• Test failures (any tier)
• Plan failures
• TODOS reorg if requested

The asymmetry is the point: the one hard gate is named. Everything else is information.