agentsclimarketplace

Ship mini

Skill tmusser/ai-engineering-skills/skills/ship-mini

Portable AI-engineering skills for Claude Code, Codex, and coding agents: bounded scope, mini-specs, vertical slices, verification, ship gates, and handoff.

Install
npx -y skills add tmusser/ai-engineering-skills --skill ship-mini

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

One thing to look at

  • 3 stars3 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

Run a lightweight activation GO or NO-GO gate only when verified work is about to gain material real-world side effects, autonomy, permissions, or production/shared-state impact.

SKILL.md

4.7 KB, as published. Nobody here has run it

Ship Mini

Purpose

Decide whether verified work is safe and authorized to activate in a real operating environment.

verify-contract owns correctness and evidence. ship-mini does not re-verify the implementation; it owns the additional operational question: should this verified thing be allowed to act on the world now?

When to use

Use after verification when activation introduces one or more material operational risks:

  • production or shared-state writes
  • scheduled, autonomous, or unattended execution
  • sending, publishing, triggering jobs, or other external side effects
  • new or expanded tool permissions
  • secrets, credentials, PII, or sensitive-data access
  • destructive or difficult-to-reverse actions
  • a required human approval boundary
  • a meaningful rollback, audit, or owner-notification requirement

Skip ship-mini for ordinary local or interactive changes whose effects remain reviewable and reversible. A user-facing change, shared report, dashboard update, model result, or successful verify-contract does not require ship-mini merely because it may be released or seen by others.

Do not create SHIP.md when no material activation risk exists.

Inputs

  • VERIFY.md status and evidence reference
  • What will be activated and where
  • Allowed tools / actions
  • Forbidden tools / actions
  • Target environment or shared state
  • Destructive or irreversible operations
  • Secrets, credentials, PII, or sensitive-data scope
  • Dry-run or staged activation path when relevant
  • Human approval gates
  • Audit logging
  • Rollback / disable path
  • Owner notification
  • Stop conditions

Workflow

  1. Confirm the implementation already has sufficient verification evidence. Reference VERIFY.md; do not replay correctness checks merely because ship-mini is invoked.
  2. Classify activation risk:
    • NONE — no material side effect, autonomy, permission, data, or rollback boundary exists. Stop without creating SHIP.md.
    • PRESENT — one or more material activation risks exist. Continue.
  3. Name the exact activation surface: what will run, write, send, publish, trigger, access, or mutate, and in which environment.
  4. Record allowed and forbidden actions, permission/data boundaries, destructive operations, and required human gates.
  5. Confirm the smallest practical dry-run or staged activation path when one exists.
  6. Confirm rollback or disable path before irreversible or shared-state effects are enabled.
  7. Confirm audit logging, owner notification, and stop conditions when unattended or externally visible effects are possible.
  8. Resolve any REVIEW_REQUIRED verification item that affects activation safety. A functional FAIL cannot be shipped.
  9. Create or update SHIP.md with the activation decision and only the operational evidence needed for GO / NO-GO.

Do not rerun tests, builds, lint, data-quality checks, or model validation unless activation changed the environment or inputs in a way that invalidates the existing verification evidence.

Activation gate

Status: GO | NO-GO

  • GO only when verification is trustworthy for the activated state and every material activation boundary is explicit enough to operate safely.
  • NO-GO when a required approval, permission boundary, data boundary, rollback path, audit path, owner notification, or stop condition is unresolved.
  • NO-GO when verification is FAIL.
  • REVIEW_REQUIRED verification may proceed only after a human explicitly resolves or accepts the item and it does not hide a functional failure.

Outputs

When activation risk is PRESENT:

  • SHIP.md
  • GO / NO-GO decision
  • Activation surface
  • Operational blockers
  • Accepted operational risks
  • Human gates
  • Rollback / disable path
  • Audit / notification / stop conditions when relevant

When activation risk is NONE:

  • No SHIP.md
  • Continue from verification to the next appropriate workflow step

Stop conditions

  • Activation risk is NONE; skip the skill artifact.
  • GO is recorded with operational boundaries explicit.
  • NO-GO is recorded because a material activation boundary remains unresolved.

Anti-patterns

  • Running ship-mini after every successful verify-contract.
  • Re-running correctness checks already captured in VERIFY.md without evidence they became stale.
  • Treating ordinary release, sharing, or visibility as activation risk by itself.
  • Creating SHIP.md when no material side effect or operational boundary exists.
  • Shipping autonomous or external side effects without approval, rollback, audit, or stop conditions appropriate to the risk.

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.