agentleFS
Sign inStart free
OrionArchitektonOrionArchitekton/orion-skills/skills/ship/SKILL.md

ship

Skill2 starsChanged 13 days agoMITView on GitHub

Use when a completed code change is ready to take from green tests through a PR to verified-live, and you need a disciplined end-to-end finish that does not claim done until runtime is independently confirmed.

194 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ios-sync, open-gstack-browser and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Saqlain-811Skill

    ios-sync

    Regenerate the iOS debug bridge against the latest upstream gstack templates. (gstack)

    Also in 6 projects that use this

  • seek888Skill

    open-gstack-browser

    Launch GStack Browser — AI-controlled Chromium with the sidebar extension baked in. Opens a visible browser window where you can watch every action in real time. The sidebar shows a live activity feed and chat. Anti-bot stealth built in. Use when asked to "open gstack browser", "launch browser", "connect chrome", "open chrome", "real browser", "launch chrome", "side panel", or "control my browser". Voice triggers (speech-to-text aliases): "show me the browser".

    Also in 10 projects that use this

  • ayudaySkill

    setup-deploy

    Configure deployment settings for /land-and-deploy. Detects your deploy platform (Fly.io, Render, Vercel, Netlify, Heroku, GitHub Actions, custom), production URL, health check endpoints, and deploy status commands. Writes the configuration to CLAUDE.md so all future deploys are automatic. Use when: "setup deploy", "configure deployment", "set up land-and-deploy", "how do I deploy with gstack", "add deploy config".

    Also in 19 projects that use this

  • ShreyRaviSkill

    landing-report

    Read-only queue dashboard for workspace-aware ship. Shows which VERSION slots are currently claimed by open PRs, which sibling Conductor workspaces have WIP work likely to ship soon, and what slot /ship would pick next. No mutations — just a snapshot. Use when asked to "landing report", "what's in the queue", "show me open PRs", or "which version do I claim next". (gstack)

    Also in 9 projects that use this

  • zebbernSkill

    debug-fix

    Find and fix a bug or issue — from any source (GitHub issue, error message, user report, or observed behavior)

    Also in 4 projects that use this

  • ShreyRaviSkill

    setup-gbrain

    Set up gbrain for this coding agent: install the CLI, initialize a local PGLite or Supabase brain, register MCP, capture per-remote trust policy. One command from zero to "gbrain is running, and this agent can call it." Use when: "setup gbrain", "connect gbrain", "start gbrain", "install gbrain", "configure gbrain for this machine". (gstack)

    Also in 7 projects that use this

  • +1 more from ShreyRavi

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 180 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Core directive: Run tests (RED/GREEN), open a PR, run adversarial self-review for fail-open/auditability gaps, then live-verify before …

    line 13
  2. Distinctive:

    Do NOT use for: brainstorming, mid-implementation work, or anything with no diff to ship.

    line 22

“Common” is measured: kept by at least 6 in 10 of the 180 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Ship

Overview

Take a finished change from passing tests to verified-live without claiming success on faith.

Core directive: Run tests (RED/GREEN), open a PR, run adversarial self-review for fail-open/auditability gaps, then live-verify before reporting done.

Violating the letter of the gates is violating the spirit of the gates. Cheap proxies (a green deploy, green CI, a stale LGTM, "I'm confident") are necessary-at-most, never sufficient.

When to Use

  • A code change is implemented and you believe it is finished.
  • You are about to say "done", "fixed", "deployed", or "shipped".

Do NOT use for: brainstorming, mid-implementation work, or anything with no diff to ship.

Steps

  1. Run tests (RED/GREEN). Confirm the relevant test fails RED before the fix and passes GREEN after. Run the repo's declared test + lint commands (repo-local CLAUDE.md / AGENTS.md / CI contract), a green CI run is not a substitute for re-running the declared tests yourself. No declared test suite RAISES rigor; it is never a license to skip Gate 1. On any security/authz path, hand-roll a failing default-deny check (RED) and make it pass (GREEN) before claiming done. State exactly what you ran.
  2. Open a PR. Re-detect the base branch from repo PR convention even if you think you know it; fall back to git remote show origin default. Never assume main. A prior or verbal LGTM is permission, not evidence: re-request approval on the post-edit diff; never downgrade re-review to an opt-out "flag me if…". Show a diff summary before committing. Never force-push.
  3. Adversarial self-review for fail-open / auditability gaps. Attack your own change: Where does it fail OPEN instead of fail-closed? Which mutation or decision goes unreceipted / unaudited? What state is asserted but never verified? If you find a fail-open or bypass path, first challenge whether it should exist at all, prefer ELIMINATING it over making it "safe". Report findings severity-graded, BLOCKING / WARNING / INFO. Fix BLOCKING before proceeding. This pass is mandatory; it is not optional "ceremony" you skip because tests are green.
  4. Live-verify before reporting done. Independently confirm runtime via the repo/host's declared verification path (container status, systemd status, health endpoint, env render, connectivity). A green deploy/CI is not runtime proof. If independent verification is impossible, say "unverifiable / not done" explicitly, do NOT claim success, and do NOT substitute a forward-promise ("will verify") for the claim.

Quick Reference

PhaseGate
TestsRED before, GREEN after; lint clean; no-suite ⇒ hand-roll, not skip
PRRe-detected base branch, fresh approval on post-edit diff, no force-push
Self-reviewFail-open eliminated or graded; no unaddressed BLOCKING
Live-verifyRuntime confirmed by declared path, or "unverifiable / not done" stated

Rationalizations: and why they fail

Captured verbatim from baseline (RED) testing of agents without this skill:

RationalizationReality
"I'm confident the fix is correct."Confidence is not evidence. Gate 4.
"./deploy.sh exited 0, so it works."A clean deploy proves the script ran, not that the handler serves traffic or fail-closes. Gate 4.
"CI was green, round it up to done."CI green is necessary-not-sufficient; only an independent runtime check closes Gate 4.
"If green: ship." / "tests pass so it works."Green tests never authorize shipping a fail-open-capable surface. Gates 3+4 still mandatory.
"I'm not inventing a verification ritual / ceremony."Gates 3 and 4 are not ceremony. Declining them = shipping on faith.
"Senior already said LGTM, ship it."A stale/verbal LGTM is permission, not approval of the post-edit diff. Gate 2.
"Flag me if any of the delta wants re-review."Re-review is opt-IN, not opt-out. Gate 2.
"No test suite here, so move fast."No suite RAISES rigor; hand-roll RED→GREEN, especially on authz paths. Gate 1.
"I'll make the bypass safe."First ask whether the bypass should exist at all; prefer elimination. Gate 3.

Red Flags: STOP, you are about to ship on faith

  • "Confident" / "probably still pass" → run the tests.
  • "It deployed / CI green, so it works" → live-verify runtime, not the exit code.
  • "No tests configured here" → hand-roll the check; do not skip.
  • "LGTM from earlier" → re-approve the current diff.
  • "Fails safe enough" → eliminate the fail-open path or grade it BLOCKING.
  • "Reporting done" with no independent runtime check → it is not done.

Boundary

This ship is a finish-discipline checklist: it governs the quality gates between green and done. It is not a deploy-mechanics skill and is not authoritative for deploy mechanics. Deploy decisions, targets, and tooling defer to your project's own deploy doctrine (deploy targets, secrets manager, worktree/branch discipline) per your repo's AGENTS.md / CLAUDE.md. This skill only governs whether you may call it done; route the how/where of deploy to your project's canonical deploy process.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free