agentsclimarketplace

Ship discipline

Skill 0xabrar/gstack-distilled/skills/ship-discipline

Distilled decision-making frameworks from Garry Tan's gstack, packaged as 7 focused Agent Skills.

Install
npx -y skills add 0xabrar/gstack-distilled --skill ship-discipline

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

4.4 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

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:

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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.