agentleFS
BSSE23047BSSE23047/nauraiz-dev/skills/ship/SKILL.md

ship

Skill2 starsChanged 14 days agoMITView on GitHub

Push the task branch and open its pull request: rebase on a moved base, settle approval lines, commit the plan, re-run the gate, write the PR body in the repo's own format, push, gh pr create. Run only when the owner asks. Not for merging, force-pushing or reviewing a PR.

  • 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

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

  • 0

    Common

    Most of the 180 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Never --force or --force-with-lease, never rewrite history beyond step 2's rebase, never push to <base>, never merge, never enable …

    line 23
  2. Distinctive:

    Never write that the owner approved anything they did not say in this session.

    line 25
  3. Very specific:

    No issue, and git ls-remote --heads origin <branch> lists the branch: read git log --format='%an <%ae>' origin/<base>..origin/<branch>.

    line 34
  4. Very specific:

    Base: If git status --porcelain --untracked-files=no, leaving out the plan file (step 4 commits it), prints anything, stop and ask the …

    line 38
  5. Distinctive:

    If the rebase refuses to start (not a conflict): stop and quote its message.

    line 46
  6. Very specific:

    Plan commit: Commit the plan as its own commit (docs: plan for #<issue>.

    line 55
  7. Very specific:

    Gate: Run node "${CLAUDE_PLUGIN_ROOT}/scripts/gate/run.mjs" --plan <plan> (no plan: drop --plan) once, from any folder in the project.

    line 62
  8. Very specific:

    PR body: If gh pr view <branch> --json url,state shows an OPEN PR, skip this step.

    line 71
  9. Distinctive:

    Write it to the path git rev-parse --git-path nauraiz-dev-pr-body.md prints, never into the working tree.

    line 84

“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

Push the current branch and open its PR. Only on the owner's request in this session to push or open a PR; running /nauraiz-dev:ship is that request, so do not ask again whether to push or open the PR. Do the steps in order.

Config: .claude/nauraiz-dev.json, with .claude/nauraiz-dev.local.json over it. Keys: branch.base (default main), plan.dir (default .work/tasks), pr.sections, gate. Local mode: the local file exists and the project file does not. Plan: the file under plan.dir whose branch: is this branch.

Rules for every step:

  • "Stop" and "ask" mean: end your turn with the question and wait. Ask only what this skill cannot know.
  • Never --force or --force-with-lease, never rewrite history beyond step 2's rebase, never push to <base>, never merge, never enable auto-merge.
  • Never write that the owner approved anything they did not say in this session.

Steps

  1. Collision check. git branch --show-current is <branch>; if it is <base>, stop. Run git fetch origin. Issue: from the plan or the branch name (feature/12-x is 12). Run node "${CLAUDE_PLUGIN_ROOT}/scripts/task/collision.mjs" <issue> --branch <branch>. taken: stop; say who and where (reason, remoteBranch name and authors, open PRs). unknown or no verdict: ask whether to go on, quoting reason. ours or free: go on. No issue, and git ls-remote --heads origin <branch> lists the branch: read git log --format='%an <%ae>' origin/<base>..origin/<branch>. If any author matches neither git config user.name nor git config user.email, stop and name them.
  2. Base. If git status --porcelain --untracked-files=no, leaving out the plan file (step 4 commits it), prints anything, stop and ask the owner to commit or stash it: the gate runs on the working tree, but the push sends HEAD. Then git rev-list --count HEAD..origin/<base>. If 0, go on. Otherwise read git log --oneline origin/<base>..HEAD:
    • Branch already on origin: rebasing would need a force push. Stop; say how far behind it is and ask: merge origin/<base> into it, or ship as it is.
    • Commits that are not this task's (another issue, another author): stop and list them.
    • Otherwise git rebase origin/<base>.
    • On a conflict: git rebase --abort, stop, name the conflicting files.
    • If the rebase refuses to start (not a conflict): stop and quote its message.
  3. Approvals. Find every *_approval key in the plan whose value does not start with pending. None: go on. Otherwise one AskUserQuestion call, one question per value (more than four: one question for all), quoting the key and value, options "Keep as given" and "Set to pending". Headless (the run is unattended, or AskUserQuestion is unavailable, errors or returns no answer): set every one to pending owner confirmation. Never choose for the owner.
  4. Plan commit. Commit the plan as its own commit (docs: plan for #<issue>; no issue: docs: plan for <branch>) when git status --porcelain -- <plan> shows a change and it is tracked (git ls-files <plan> prints it) or the project commits plans (git ls-tree -r --name-only origin/<base> -- <plan.dir> lists a file). Never commit an untracked plan in local mode. Committing before the gate makes the pushed HEAD the gated HEAD with no rewrite. That covers tracked files only: an untracked file the gate reads is not pushed; tell the owner to add it or ignore it.
  5. Gate. Run node "${CLAUDE_PLUGIN_ROOT}/scripts/gate/run.mjs" --plan <plan> (no plan: drop --plan) once, from any folder in the project; it prints every exit code, so never append echo $?, pipes or cd; re-run only after you changed code, or once with --plan <path> when a row says no plan for this branch. Exit 1: stop and paste the output. Exit 2: quote every nauraiz-dev: line first. A line other than no gate configured … that names a config file means the config failed to load: stop, say it needs fixing, and never offer to ship without a gate. Otherwise ask "No gate configured. Ship without one?". Exit 3 (the runner failed): stop and quote the output. Any other non-zero exit: the same. Keep the output for step 6.
  6. PR body. If gh pr view <branch> --json url,state shows an OPEN PR, skip this step. Headings, first match wins: gh pr list --state merged --author @me --limit 1 --json number, then gh pr view <n> --json body, and take that body's ## headings in order; else pr.sections. Run node "${CLAUDE_PLUGIN_ROOT}/scripts/show.mjs" templates/PR_TEMPLATE.md once for what each section holds.
    • Fill every section from the plan, the commits and this session; write "None" rather than drop one. Approvals set to pending go under the decisions to confirm.
    • The gate output from step 5, verbatim, under the gate heading (or ## Gate output).
    • What was not verified, under the heading for it (such as Unverified), else add ## Not verified.
    • Closes #<issue> when there is an issue. End with the PR attribution line your instructions give, if any. Write it to the path git rev-parse --git-path nauraiz-dev-pr-body.md prints, never into the working tree.
  7. Push and open. git push -u origin <branch>; if it is rejected, stop and say why. An open PR from step 6: print its URL instead of gh pr create. Otherwise gh pr create --base <base> --head <branch> --title "<title>" --body-file <file>, title from the issue or the plan. Print the PR URL and stop: never merge.

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.