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 via CLI
openskills install 0xabrar/gstack-distilled---
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.
---
# 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:
| 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.
## 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.
No comments yet. Be the first to comment!