A workflow for taking one coding goal from clarification to a merged pull request. It uses test-driven development, or TDD, which means writing tests before the code, then repeatedly implementing and checking the change.

Use it for end-to-end feature or bug delivery, including implementation, tests, local review, continuous integration, pull-request updates, and merging.

It keeps unfinished work, review findings, failed checks, conflicts, and merge requirements in one loop until the goal is complete or a human-only blocker remains.

ship — Skill for Claude Code and Cursor by fmflurry/settings-opencode

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Any agent

npx skills add fmflurry/settings-opencode --skill ship

Clone the repo

git clone --depth 1 https://github.com/fmflurry/settings-opencode

Made for: Claude Code, Cursor.

Or install fmflurry-harness, the plugin that ships this one along with the rest of its 21 skills.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

README.md

[![agentmods](https://agentmods.dev/badge/skills/fmflurry/settings-opencode/ship/github.svg)](https://agentmods.dev/skills/fmflurry/settings-opencode/ship)

Your own site

<a href="https://agentmods.dev/skills/fmflurry/settings-opencode/ship"><img src="https://agentmods.dev/badge/skills/fmflurry/settings-opencode/ship/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

Your own site · 80×15

<a href="https://agentmods.dev/skills/fmflurry/settings-opencode/ship"><img src="https://agentmods.dev/badge/skills/fmflurry/settings-opencode/ship.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

Per session 77 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.

When invoked 2,762 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5.1	$0.00077	$0.02762
Opus 5.5	$0.00031	$0.01105
Sonnet 5.5	$0.00015	$0.00552
Haiku 4.5	$0.00008	$0.00276

Measured yesterday against content hash df428c7d1ebc, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

ship scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/fmflurry-harness/skills/ship/SKILL.md · 160 lines

How it starts

The opening of the file, as written. The whole thing — 160 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Ship

/ship <goal> drives one goal from clarification to a merged PR (method per repo) on the base branch. The goal state lives in .claude/state/goal.json. In Claude Code, the Stop hook keeps the session working until the PR is merged or the goal escalates.

The goal text is $ARGUMENTS.

The ship loop

In autonomous mode the run is a loop, not a checklist. It repeats until the PR merges:

Implement. Tests first, then code, through tdd-guide and coder.
Verify. Run the project checks yourself.
Push and open the PR (draft).
Thorough local review of the PR diff.
CI. Wait for the required checks and the optional review status. Read the review threads.
Merge with agent-harness ship-merge. This is the only merge path. It checks hard facts. Its refusal is input to the loop, not the end of the run.

Any blocker (see Blockers) sends the run back to fix, then review again, then retry the merge. The run ends only in one of two states: done (the PR is merged), or a genuine human-only blocker. A no-progress iteration is also an escalation (see Stop conditions).

Config

Read .claude/agent-harness.json in the target repo before stage 1. All keys are optional: base, requiredChecks, reviewStatus, reviewStatusCreator, verify, protectedPaths. Defaults are in the "Autonomous mode" section of this repo's README.

Modes

Mode	Flag	Clarify	Merge
Interactive	off	One AskUserQuestion round on load-bearing unknowns	Ask first, then run `agent-harness ship-merge <pr> --confirmed`
Autonomous	on (`/autonomous on`)	Skipped. Assumptions are logged and pinned in the PR	`agent-harness ship-merge <pr>` (the flag gates it)

Check the mode with agent-harness autonomy status. The rules behind both modes are in the autonomy rule (.claude/rules/common/autonomy.md).

Stages

Clarify. Ask one dependency-safe AskUserQuestion round, with a recommended option per question. In autonomous mode skip it and log each assumption with show-your-work.
Set the goal. agent-harness goal set "$ARGUMENTS" <criteria...>. Criteria: PR merged to the base branch, every requiredChecks entry green, the verify commands green, the reviewStatus status successful on the head (when configured), zero open review threads. 2b. Check open PRs. Follow open-pr-check.md before planning or implementing. Record each overlapping PR's decision; a Wait or cancel outcome escalates.
Plan. Dispatch the planner agent. Keep the plan in the log, not in chat.
Branch or worktree. The branch MUST follow the branch convention <type>/<scope>-<short-description> from the git-workflow skill (for example fix/ship-branch-naming); git-specialist names it. See lifecycle step 4 for the commands. Never remove a worktree; see the worktree destruction rule (.claude/rules/common/worktree-destruction-safety.md).
Implement. tdd-guide writes the failing tests, then coder implements. Both get a 6-field brief per the brief contract rule. Commits go through git-specialist.
Verify. Run the verification yourself, not through a subagent's self-report. Commands are in lifecycle.md.
Draft the PR. Dispatch git-specialist to push the branch and open a draft PR with the body sections ## Content, ## QA tests, ## Locked decisions, ## Non-blocking follow-ups. Put every assumption under ## Locked decisions. Then agent-harness goal pr <n>.
Thorough review (local). Still draft. Dispatch in one message, so they run in parallel, each on git diff <base>...HEAD: code-reviewer (correctness), security-reviewer (auth, secrets, input, CI, permissions), and the stack cop when it applies: angular-cop for Angular/TS, dotnet-cop for .NET. database-reviewer when SQL changed. Verify each finding against the code and drop the ones you cannot confirm. Every confirmed CRITICAL and HIGH finding is a blocker: fix it, push through git-specialist, run agent-harness goal sha <sha>, then review again on the new diff. There is no round cap; the no-progress rule below decides when to stop. When the review ends, post one summary PR comment in the format of review-format.md. It is an audit trail for a human. It is not a GitHub status, and ship-merge does not read it.
Mark ready. gh pr ready <n>. ship-merge refuses drafts and never marks a PR ready, so this step is required.
Wait for CI. gh pr checks <n> --watch. On a failed check, use the loop-on-ci skill, which routes failures through the fix-ci skill. When the repo sets reviewStatus, also check that status on the head. On a failure, fix the cause, push through git-specialist, then agent-harness goal sha <sha>. Run agent-harness goal bump before each fix round.
Comments. Run the get-pr-comments skill to list open threads. Address each one with a fix or a reply that says why not, then resolve the threads you addressed. See lifecycle step 11.
Merge. Autonomous mode: agent-harness ship-merge <pr>. Interactive mode: add --confirmed after the user says yes. The merge method is chosen with --method squash|rebase|merge; without it the script uses mergeMethod from .claude/agent-harness.json, else the repo's first allowed method (squash, rebase, merge). It enforces the merge rails listed in the README. On a refusal, read the reason and go back to the loop (see Blockers).
Post-merge cleanup. After a successful merge, ship-merge runs agent-harness cleanup <pr>. Read the cleanup: lines it prints (remote, local, checkout, backup, worktree). For an item kept for a fixable reason (for example a checkout switch that failed on a dirty tree), fix the cause without discarding changes, then run agent-harness cleanup <pr> once more. Never remove a worktree; cleanup only reports it. Then agent-harness notify done "<msg>" <pr> and agent-harness goal status.

Read the full file on GitHub · 160 lines

Files

What ships with it

2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

yesterday Changed df428c7d1ebc
2d ago Changed · +7 lines b8b0bdbf4934
3d ago Changed · +2 lines d47fbcd82a78
4d ago First seen · 151 lines · 77 tokens per session scan A 44c039942e06

Subscribe to this mod's changes

ship is a skill published in the GitHub repository fmflurry/settings-opencode (171 stars, last pushed yesterday), licensed MIT. It adds 77 tokens to every session and 2,762 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-12.

Project management TDD Testing

conductor-implement

Execute tasks from a track's implementation plan following TDD workflow.

rmyndharis/antigravity-skills · 17 tokens

gh-issue

Size-audit, write, and split BanyanDB issues that somebody else or an automated TDD workflow can implement. Use whenever the user asks to file or revise an issue, decide whether an issue is too large, make an issue TDD-ready, turn a design into tickets, or split an umbrella into executable leaves. Do not draft or file…

apache/skywalking-banyandb · 91 tokens

implement-feature

Implement an approved feature plan with fresh-context slices, TDD, revision-bound evidence, and PR-ready output.

HoangNguyen0403/agent-skills-standard · 25 tokens

product

Consolidated Galyarder Framework Product intelligence bundle.

skillmds/skillmd · 13 tokens

ring:implementing-tasks

Implementing a single planned task (Task N.M.T) end-to-end: selects the right backend agent by language and service type, drives one TDD RED->GREEN turn, then verifies coverage, lint, license headers, runtime, and delivery before handoff. Runs as Gate 0 before ring:reviewing-code. Use to drive ONE task inside an…

LerianStudio/ring · 103 tokens

create-issues

Creates GitHub issues following test-driven development principles and proper labeling conventions. This skill should be used when the user asks to "create an issue", "file a bug", or needs to document new requirements, epics, or PR-scoped tasks.

FradSer/dotclaude · 54 tokens