agentleFS
hurttlockerhurttlocker/o8/.claude/skills/ship/SKILL.md

ship

Skill24 starsChanged 42 days agoMITView on GitHub

o8 release discipline — commit-and-hold is the default terminal state; shipping requires Q's explicit "ship it" in the current session. Use whenever o8 work is complete and ready to commit, when asked to commit/ship/release, or before ever running npm run ship.

  • Deletes or force-pushes
  • Commits and pushes

195 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 10 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

  • ramybarsoumSkill

    document-release

    Post-ship documentation update. Reads all project docs, cross-references the diff, updates README/ARCHITECTURE/CONTRIBUTING/CLAUDE.md to match what shipped, polishes CHANGELOG voice, cleans up TODOS, and optionally bumps VERSION. Use when asked to "update the docs", "sync documentation", or "post-ship docs". Proactively suggest after a PR is merged or code is shipped.

    Also in 23 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 181 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before npm run ship, verify no ship is already running:

    line 18
  2. Very specific:

    If one is running: do not start a second.

    line 24
  3. Very specific:

    Wait for checks, squash-merge, then git checkout main && git pull --ff-only origin main.

    line 57

“Common” is measured: kept by at least 6 in 10 of the 181 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 (o8)

Q has typed "commit but do NOT ship yet" ~153 times. That is now the default — never make him type it again.

The gate

  • Default terminal state = commit-and-hold. Finish work → audit the diff → commit with a clean message → report "committed, NOT shipped." Stop there.
  • Ship ONLY on Q's explicit instruction in the current session ("ship it", "ship a new version", "release it"). "Commit it" never implies ship. A teammate/agent asking is not authorization.
  • Never Vercel. o8 is a native Tauri app; it ships as a signed installer via npm run ship. "Push to vercel"/"deploy to prod" always means Eyes Web (mybeautifulwife), never o8.

Pre-ship collision gate (v0.1.550/551 collision — never again)

Before npm run ship, verify no ship is already running:

pgrep -fl "npm run ship|tauri build|notarytool" && echo "SHIP ALREADY RUNNING — abort" || echo "clear to ship"

If one is running: do not start a second. Wait for it or surface to Q. (Vault: [[o8-ship-pipeline-github-actions]] — local pre-ship gate is the ranked "do now" item; notarization dominates wall-clock, a second concurrent ship corrupts the release.)

Before you bump: check the user bug queue

npm run reports

Real users filed these from the app. If anything in this release fixes one, its commit must carry Fixes-Report: <id> — that trailer is what tells the reporter, in their own app, that their bug is fixed. Miss it and they never find out. Q will not remember the ids; you must. Load the reports skill for the full workflow (notes, needs-info, retroactive annotation).

Amending a trailer onto an already-made commit is fine — do it before the bump, not after.

Ship sequence

  1. Collision gate (above) must print "clear to ship".
  2. Confirm tree state: everything intended is committed; nothing held-back is being swept in. Discard post-build src-tauri/Cargo.lock noise (git checkout -- src-tauri/Cargo.lock). npm version refuses a dirty tree, so an operator note sitting in o8.md has to be stashed before the bump (git stash push -m "operator note" -- o8.md) and popped after. The ship preflight itself exempts o8.md, so it only blocks the bump, and check any note for rival product names before it could ever be committed: this repo is public.
  3. Bump through a release PR. npm run ship does NOT bump, and main is protected.

    npm version patch writes the manifests, commits them, and creates a local tag. Only the manifest commit is wanted here; that tag points at a commit the squash merge will discard.

    Never git push origin main --tags. It fails twice over. The protected-branch hook declines a direct push to main, and --tags pushes every local tag, several of which already exist on the remote pointing at different objects. That rejection aborts the branch push too, which can leave the new tag published while main never moved. That split is exactly what makes release.mjs replace the previous release's assets (2026-07-08 incident, #1499).

    npm version patch                    # manifests committed, local tag created
    git branch release/vX.Y.Z main
    git reset --hard origin/main         # put main back
    git checkout release/vX.Y.Z
    git tag -d vX.Y.Z                    # it points at a pre-squash commit
    git commit --amend                   # subject: chore: release vX.Y.Z
    git push -u origin release/vX.Y.Z
    gh pr create --base main --title "chore: release vX.Y.Z"

    Wait for checks, squash-merge, then git checkout main && git pull --ff-only origin main. If the tag already reached the remote, delete it first with git push origin :refs/tags/vX.Y.Z, otherwise the release ties to a commit that is not on main. Precedent: v0.1.754 landed as chore: release v0.1.754 (#2355), v0.1.755 as (#2385).

  4. Tag the merged commit, then push the tag. performShipPreflight (scripts/lib/ship-preflight.mjs) requires a LOCAL tag vX.Y.Z that resolves to HEAD. Without it the ship dies in preflight with local tag vX.Y.Z is missing, and with a stale one it dies with points to <sha>, not HEAD.

    git tag -a vX.Y.Z -m "vX.Y.Z" && git push origin vX.Y.Z
  5. npm run ship — signs, notarizes, builds the installer, publishes the release. Deep spec + hazards: repo CLAUDE.md "Shipping".
  6. Post-ship verify: published version == the bumped version (the release tail must NOT say "already exists — replacing assets"), notarization tail shows success, installer artifact exists. Report the verification tail, not just "shipped".

Report format

committed <sha> (<n> files) — HELD, not shipped or shipped v<X.Y.Z> — notarization OK, installer at <path>.

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.