Best for
- Use when local changes are ready to hand off to review — e.
griffinwork40/agent-afk/src/bundled-plugins/awa-bundled/skills/ship/SKILL.md
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.
Decision brief
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."
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/griffinwork40/agent-afk --skill "src/bundled-plugins/awa-bundled/skills/ship"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
Review the “Verification” section in the pinned source before continuing.
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.
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."
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 the “your file-writing tool. The content never passes through the shell.” section in the pinned source before continuing.
Permission review
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`: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) usingThe documentation asks the agent to run terminal commands or scripts.
git commit -F .git/COMMIT_BODY.txtThe documentation asks the agent to read local files, directories, or repositories.
# 2. Open the PR from that file:Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 92/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 45 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
/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:
main/master) — ask the user for a feature branch.--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):
/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.main/master or merges without a PR. If you find yourself about to run git push origin main (or equivalent), stop./ship means "skip the PR step."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./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:
origin/<default> (stale — user needs to rebase/merge first)Phase 2 — Test gate. Detect the project's test harness by scanning, in order:
package.json → scripts.test (run via the project's package manager: pnpm/yarn/npm)pyproject.toml → pytest if configured, or scripts.testCargo.toml → cargo testgo.mod → go test ./...Makefile → test targetIf 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:
feat, fix, chore, refactor, docs, etc.)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.
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.git push -u origin <branch>git pushgit 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:
CONFIRM / REFINE / CONTRADICT with file:line evidence.If any verifier returns CONTRADICT → surface 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:
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./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./ship should not try to auto-recover.Alternatives
K-Dense-AI/scientific-agent-skills
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.
github/awesome-copilot
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
github/awesome-copilot
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.
obra/superpowers
Use when creating new skills, editing existing skills, or verifying skills work before deployment