Source profileQuality 92/100Review permissions

griffinwork40/agent-afk/src/bundled-plugins/awa-bundled/skills/ship/SKILL.md

ship

Release pipeline for already-done local work. Dispatches /ground-state pre-flight, runs the project test suite, drafts a commit message, pushes, and opens a PR with a structured verification summary. Use when local changes are ready to hand off to review — e.g. 'ship this', 'push and open a PR', 'release this work'. Add --verify to trigger an adversarial verifier wave on the diff before a human reads the PR.

Source repository stars
45
Declared platforms
0
Static risk flags
3
Last source update
2026-07-28
Source checked
2026-07-28

Decision brief

What it does—and where it fits

Release pipeline for work that is already done locally. This skill does NOT build, implement, or fix — if the task needs code, route to /mint; if a bug needs diagnosis, route to /diagnose. This skill's job is the hand-off from "done locally" to "visible in a PR."

Best for

  • Use when local changes are ready to hand off to review — e.

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/griffinwork40/agent-afk --skill "src/bundled-plugins/awa-bundled/skills/ship"
Safe inspection promptEditorial

Inspect the Agent Skill "ship" from https://github.com/griffinwork40/agent-afk/blob/803066d4f1e0cd57e983658dc670d647fcd893c9/src/bundled-plugins/awa-bundled/skills/ship/SKILL.md at commit 803066d4f1e0cd57e983658dc670d647fcd893c9. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Verification

    Review the “Verification” section in the pinned source before continuing.

    Review and apply the “Verification” source section.
  2. 02

    1. Write the Phase 7 PR body to a temp file (e.g. .git/PRBODY.md) using your

    Review the “1. Write the Phase 7 PR body to a temp file (e.g. .git/PRBODY.md) using your” section in the pinned source before continuing.

    Review and apply the “1. Write the Phase 7 PR body to a temp file (e.g. .git/PRBODY.md) using your” source section.
  3. 03

    Sub-agent contract

    Release pipeline for work that is already done locally. This skill does NOT build, implement, or fix — if the task needs code, route to /mint; if a bug needs diagnosis, route to /diagnose. This skill's job is the hand-off from "done locally" to "visible in a PR."

    Working tree is clean (nothing to ship — tell the user).Current branch is the default branch (main/master) — ask the user for a feature branch.User invokes with --dry-run → produce the plan but take no git actions.
  4. 04

    1. Write the subject + body to a temp file (e.g. .git/COMMITBODY.txt) using

    Review the “1. Write the subject + body to a temp file (e.g. .git/COMMITBODY.txt) using” section in the pinned source before continuing.

    Review and apply the “1. Write the subject + body to a temp file (e.g. .git/COMMITBODY.txt) using” source section.
  5. 05

    your file-writing tool. The content never passes through the shell.

    Review the “your file-writing tool. The content never passes through the shell.” section in the pinned source before continuing.

    Review and apply the “your file-writing tool. The content never passes through the shell.” source section.

Permission review

Static risk signals and limitations

Writes files

medium · line 55

The documentation asks the agent to create, modify, or delete local files.

Stage only the confirmed files, then write the commit message to a temp file with your file-writing tool — **NOT** a shell heredoc — and commit with `-F`:

Writes files

medium · line 58

The documentation asks the agent to create, modify, or delete local files.

# 1. Write the subject + body to a temp file (e.g. .git/COMMIT_BODY.txt) using

Runs scripts

medium · line 61

The documentation asks the agent to run terminal commands or scripts.

git commit -F .git/COMMIT_BODY.txt

Reads files

low · line 110

The documentation asks the agent to read local files, directories, or repositories.

# 2. Open the PR from that file:

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score92/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars45SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
griffinwork40/agent-afk
Skill path
src/bundled-plugins/awa-bundled/skills/ship/SKILL.md
Commit
803066d4f1e0cd57e983658dc670d647fcd893c9
License
Apache-2.0
Collected
2026-07-28
Default branch
main
View the original SKILL.md

Sub-agent contract

/contract

Release pipeline for work that is already done locally. This skill does NOT build, implement, or fix — if the task needs code, route to /mint; if a bug needs diagnosis, route to /diagnose. This skill's job is the hand-off from "done locally" to "visible in a PR."

Skip when:

  • Working tree is clean (nothing to ship — tell the user).
  • Current branch is the default branch (main/master) — ask the user for a feature branch.
  • User invokes with --dry-run → produce the plan but take no git actions.

Arguments:

  • --verify — force the optional adversarial verifier wave (Phase 6), regardless of diff size.
  • --draft — open the PR as a draft.
  • --dry-run — run phases 1–5 but stop before Phase 7 (no push, no PR).

Hard rules (non-negotiable — these override any inferred convention):

  • Branch lock. Whatever branch is checked out when /ship starts is the only branch you may commit and push from. NEVER git checkout to a different branch during this skill — not to main, not to master, not to a sibling feature branch. If pre-flight finds you on the default branch, abort. Do not "recover" by switching branches yourself.
  • Never push to the default branch. Phase 5 pushes the CURRENT (feature) branch. Phase 8 opens a PR. There is no path through this skill that pushes to main/master or merges without a PR. If you find yourself about to run git push origin main (or equivalent), stop.
  • User intent is absolute. If the user said "make a PR," "open a PR," "submit for review," or anything synonymous, you MUST complete Phase 8. "Ship" / "release" alone also implies PR — there is no interpretation under which /ship means "skip the PR step."
  • Do not invent project convention. Never assert "this project uses direct-to-main flow," "this repo merges direct," or any equivalent justification for bypassing the PR step. If you genuinely cannot tell whether the project uses PRs, run gh pr list --state merged --limit 5; ≥3 merged PRs in the last week ⇒ PR is the convention. If still ambiguous, ask the user. Default to PR — it is the safer choice.
  • Anchor cwd. When /ship is invoked, pwd at that moment is the only working directory you operate in. All git commands and file reads must run inside that directory — never cd to a sibling worktree, the parent repo, or any other path during this skill. If you find yourself reading state from a path other than the invocation cwd (e.g. git log returning unrelated commits, or a file diff that doesn't match what was just edited), stop and re-anchor on the original cwd. Worktrees and sibling repos look almost identical; cwd is the only disambiguator.

Phase 1 — Pre-flight (mandatory, runs BEFORE any git mutation). Invoke ground-state via the Skill tool. Abort and surface the blocker with remediation steps if ground-state reports any of:

  • Uncommitted changes in files unrelated to the declared scope
  • Branch behind origin/<default> (stale — user needs to rebase/merge first)
  • Current branch IS the default branch
  • Wrong-repo context (user's cwd doesn't match the branch's purpose)

Phase 2 — Test gate. Detect the project's test harness by scanning, in order:

  1. package.jsonscripts.test (run via the project's package manager: pnpm/yarn/npm)
  2. pyproject.tomlpytest if configured, or scripts.test
  3. Cargo.tomlcargo test
  4. go.modgo test ./...
  5. Makefiletest target

If found → run it. Non-zero exit → abort; surface the failing output and recommend /diagnose. Do not proceed to commit.

If no harness detected → warn the user: "No test harness detected. Ship without running tests?" Require explicit yes. Do not silently skip.

Phase 3 — Draft commit message. Read the cumulative diff: git diff --stat origin/<default>...HEAD + full git diff. Synthesize a commit message:

  • Subject (≤70 chars): imperative, Conventional Commits format (feat, fix, chore, refactor, docs, etc.)
  • Body: 2–5 bullets on WHY — the motivation, constraint, or trade-off. Skip the WHAT — the diff speaks for itself.

Before committing, review the file list to stage — don't sweep in untracked config/scratch/secret files. Print the draft message + file list to the user as info-only output, then immediately invoke Phase 4. This is not a gate. Do not ask "does this look good?" Do not wait for approval. The user surface is one continuous turn: draft → commit → push → PR URL.

Phase 4 — Commit. Stage only the confirmed files, then write the commit message to a temp file with your file-writing tool — NOT a shell heredoc — and commit with -F:

# 1. Write the subject + body to a temp file (e.g. .git/COMMIT_BODY.txt) using
#    your file-writing tool. The content never passes through the shell.
# 2. Commit from that file:
git commit -F .git/COMMIT_BODY.txt

Going through a file keeps backticks, $(...), and quotes in the message literal. Never assemble the message inline as git commit -m "$(cat <<'EOF' … EOF)" — a backtick or $( in the body is parsed by the shell before git runs, so the commit fails or records a mangled message. .git/ is never staged, so the temp file can't sneak into the commit (in a linked worktree .git is a file, not a dir — write to the path printed by git rev-parse --git-dir instead).

Never --amend (creates a new commit each time). Never bypass hooks (--no-verify).

Phase 5 — Push.

  • Assertion (before any push): git rev-parse --abbrev-ref HEAD must NOT equal the default branch. If it does, abort with the same error as Phase 1 — Branch lock was violated somewhere upstream.
  • Upstream unset → git push -u origin <branch>
  • Upstream set → git push
  • Non-fast-forward rejection → abort; do not force-push. Surface and let the user decide.
  • Never git push origin main (or master). Pushing the feature branch is the only allowed form.

Phase 6 — Optional adversarial verifier wave. Trigger when $ARGUMENT contains --verify, OR when the cumulative diff exceeds 100 changed lines (rough proxy for "big enough that a human reviewer will miss something"). Skip for diffs under 100 lines unless --verify is explicit.

Dispatch an adversarial verifier sub-agent via the Agent tool. Use subagent_type: "research-agent" (read-only, no Edit/Bash-that-mutates). Brief it with:

  • The cumulative branch diff
  • The draft PR body (Phase 7)
  • Instruction: from the diff alone — without consulting the draft's reasoning — independently re-derive the 2–3 load-bearing claims the PR body makes. Return per claim: CONFIRM / REFINE / CONTRADICT with file:line evidence.

If any verifier returns CONTRADICTsurface to the user before opening the PR. Append the counter-claim to the PR body's Verification section. User decides whether to proceed, revise, or abort.

Phase 7 — Synthesize PR body. Structure:

## Summary
<2–4 bullets: what changed, why>

## Test results
- <command>: <passed/failed + counts>
<repeat per test invocation>

## Verification
<if --verify ran: per-claim verdict + evidence>
<if skipped: "No adversarial verify requested (diff under threshold).">

## Out of scope
<anything touched but not central to this PR, if any; omit section otherwise>

Phase 8 — Open PR. Write the PR body (from Phase 7) to a temp file with your file-writing tool — NOT a shell heredoc — then pass it with --body-file:

# 1. Write the Phase 7 PR body to a temp file (e.g. .git/PR_BODY.md) using your
#    file-writing tool. The body never passes through the shell.
# 2. Open the PR from that file:
gh pr create \
  --title "<subject line of the commit>" \
  --body-file .git/PR_BODY.md \
  --base <default-branch> \
  [--draft]

PR bodies are markdown: they routinely carry backticks (inline code), $(...), and quotes. Never inline the body as --body "$(cat <<'EOF' … EOF)" — the shell parses backticks/$( inside the command substitution before gh ever runs, so the call fails (or worse, opens the PR with a truncated/garbled body and you don't notice). --body-file reads the file verbatim: no shell quoting, no escaping. Only --title stays inline — keep it a single plain line with no backticks.

Phase 9 — Reclaim the worktree. Skip entirely unless the work you just shipped lives under .afk-worktrees/ (check the invocation cwd from Phase 1 — if the path has no .afk-worktrees/ segment, there is nothing to reclaim; go straight to the PR URL).

A worktree is scaffolding, not an artifact. Once Phase 8 succeeds the branch is pushed and the PR holds the work, so the checkout has no remaining job. Do not leave it for the background sweep — the sweep never reaps a locked tree, and a preserved commits-ahead tree is exactly the kind that gets locked, so "the sweep will get it" is false for the common case.

Two cases, and they behave differently:

  • A worktree you (or a sub-agent) created for this work, that you are NOT currently inside — reclaim it now, using the worktree tool rather than git worktree in bash. Two refusals to expect, in this order: a locked tree must be released first (remove refuses a locked tree, so the order is mandatory, not stylistic), and a tree with commits ahead of base is refused unless you pass force: true. After a successful push that force is safe and correct: the tool never deletes the branch ref, so the commits remain on the branch and on the remote — you are discarding a directory, not history. Do not pass force before the push has landed.
  • The worktree you are running in (your own cwd)do not remove it. Deleting your own working directory strands every subsequent tool call on a path that no longer exists, and /ship still has output to produce. Session-end cleanup already removes a clean worktree on exit. Say so instead, in one line: which branch carries the work, and that the checkout is reclaimed when the session ends.

Never delete the branch as part of this phase — the open PR depends on that ref.

Return the PR URL to the user, plus a one-line worktree disposition (reclaimed <path> / preserved <path> — reclaimed at session end / omit if not in a worktree). Done.


Failure modes to watch:

  • /ground-state unavailable → skip Phase 1 with a loud warning; do not proceed silently.
  • gh CLI not authenticated → abort Phase 8 with the exact gh auth login command.
  • Detached HEAD or shallow clone → abort at Phase 1; these are edge cases /ship should not try to auto-recover.
  • Worktree reclaim fails in Phase 9 → the PR is already open and that is the deliverable; report the failure and the path, never retry-loop or walk back the PR.

Alternatives

Compare before choosing

Computed 9531,966

K-Dense-AI/scientific-agent-skills

simpy

Build, inspect, test, and analyze bounded process-based discrete-event simulations with SimPy, including events, resources, interrupts, monitoring, replications, warm-up, and reproducible output analysis.

Computed 9337,126

github/awesome-copilot

flowstudio-power-automate-build

Build, scaffold, and deploy Power Automate cloud flows using the FlowStudio MCP server. Your agent constructs flow definitions, wires connections, deploys, and tests — all via MCP without opening the portal. Load this skill when asked to: create a flow, build a new flow, deploy a flow definition, scaffold a Power Automate workflow, construct a flow JSON, update an existing flow's actions, patch a flow definition, add actions to a flow, wire up connections, or generate a workflow definition from

Computed 9337,126

github/awesome-copilot

salesforce-apex-quality

Apex code quality guardrails for Salesforce development. Enforces bulk-safety rules (no SOQL/DML in loops), sharing model requirements, CRUD/FLS security, SOQL injection prevention, PNB test coverage (Positive / Negative / Bulk), and modern Apex idioms. Use this skill when reviewing or generating Apex classes, trigger handlers, batch jobs, or test classes to catch governor limit risks, security gaps, and quality issues before deployment.

Computed 91262,331

obra/superpowers

writing-skills

Use when creating new skills, editing existing skills, or verifying skills work before deployment