agentleFS
nicodiansknicodiansk/turboflow/skills/ship/SKILL.md

ship

Skill3 starsChanged 32 days agoMITView on GitHub

Use when implementation and review are complete and you need to integrate the work, or to triage a pull request's review comments saved to a file or pasted (verifies each, fixes the valid ones, drafts the replies). Verifies tests, presents options to merge, open a PR, or keep the branch; discards only on explicit request, and handles cleanup.

  • Commits and pushes

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

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

  • 0

    Common

    Most of the 179 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If tests fail: Stop. Show failures. Cannot proceed.

    line 21
  2. Very specific:

    Only when the user explicitly asks to throw the work away.

    line 74

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

Complete development work by verifying tests and presenting integration options.

Announce: "Using ship to finalize this work."

Routing. If the request is to triage review comments (in a file or pasted into the conversation), run Step 1 (tests), then go straight to Triage review comments and skip the menu. If it names only a PR, ask the user to save its comments to a file or paste them. To watch a PR's checks and comments instead, Claude Code has /autofix-pr.

Step 1: Verify Tests

# Run project's test suite
npm test / cargo test / pytest / go test ./...

If tests fail: Stop. Show failures. Cannot proceed. If tests pass: Continue.

Step 2: Determine Base Branch

git merge-base HEAD main 2>/dev/null || git merge-base HEAD develop 2>/dev/null || git merge-base HEAD master 2>/dev/null

Step 3: Present Options

Implementation complete. What would you like to do?

1. Merge back to <base-branch> locally
2. Push and create a Pull Request
3. Keep the branch as-is (I'll handle it later)

Which option?

Present the menu exactly as written. Discarding the work is not an option on it: it happens only when the user explicitly asks (see below).

The menu waits for the user's pick, even when Claude invoked ship on its own. Never merge (Option 1) or discard unless the user picked it or asked for it in this conversation.

Step 4: Execute Choice

Option 1: Merge Locally

git checkout <base-branch>
git pull
git merge <feature-branch>
# Verify tests on merged result
git branch -d <feature-branch>

Option 2: Push and Create PR

git push -u origin <feature-branch>
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
<2-3 bullets>

## Test Plan
- [ ] <verification steps>
EOF
)"

Option 3: Keep As-Is

Report: "Keeping branch. Worktree preserved at <path>."

Discard (only on explicit request)

Only when the user explicitly asks to throw the work away. Require typed "discard" confirmation: list the branch and its commits that will be deleted, and wait for the exact word discard. "Yeah, get rid of it" is not the confirmation. Then:

git checkout <base-branch>
git branch -D <feature-branch>

Triage review comments

Reached from routing: a pull request's review comments, handed over in a file or pasted. Triage changes the branch locally and nothing else: it never pushes and never posts. The user posts the drafted replies.

Each comment becomes an item: id, kind (inline or issue), author, path:line (inline), body, url. Skip a comment the file shows already answered.

Verify. Each item goes to turbocharge:verifier through the Agent tool. The prompt holds the comment, its path:line, the branch and its base, and asks "is this comment right about the current code?". Send independent items together and wait for every completion notification. Never verify an item yourself while the Agent tool can dispatch the verifier, even when the comment looks obviously right or wrong: a reply or a fix needs a check that didn't come from the session making the fix. Only with no Agent tool, or with the verifier not registered, verify inline by the same rules (try to refute; quote the code) and say so in the report.

Classify. CONFIRMED + defect = valid. CONFIRMED + nit = nit. REFUTED = false positive. UNCERTAIN = the user's batch, because a reply needs evidence.

Conflict stop. A comment that asks to change something the user decided earlier (this conversation, the plan's Rulings, a design doc, CLAUDE.md) makes triage stop. Bring it to the user, quoting the decision.

Valid: fix it inline, or through turbocharge:builder when it is larger. Run the tests, then commit by pathspec. Draft a reply naming the fix commit.

False positive: draft a reply with evidence (file:line, what the code or test shows).

Nits and uncertain: a nit is never edited, even when it touches a line you are changing for a valid comment. Nits and uncertain items go only in one batched list for the user; nothing changes.

Report, per item: its class, verified by (turbocharge:verifier or inline, with why), the action, the commit and the drafted reply. Add the batch.

Step 5: Cleanup Worktree (Options 1 and 2, or after a discard)

git worktree list | grep $(git branch --show-current)
# If in worktree:
git worktree remove <path>

Workflow Position

review → ship

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.