Getting it into your agent
There is no command for this one: it runs only inside a plugin, and the catalogue could not identify which plugin ships it. The source is linked below.
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.
[](https://agentmods.dev/skills/dominikwozniak/dw-solo-skills/dw-ship)<a href="https://agentmods.dev/skills/dominikwozniak/dw-solo-skills/dw-ship"><img src="https://agentmods.dev/badge/skills/dominikwozniak/dw-solo-skills/dw-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.
<a href="https://agentmods.dev/skills/dominikwozniak/dw-solo-skills/dw-ship"><img src="https://agentmods.dev/badge/skills/dominikwozniak/dw-solo-skills/dw-ship.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00043 | $0.00855 |
| Opus 5 | $0.00022 | $0.00428 |
| Sonnet 5 | $0.00009 | $0.00171 |
| Haiku 4.5 | $0.00004 | $0.00085 |
Grade A, and why
dw-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 8d ago.
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.
How it starts
The opening of the file, as written. The whole thing — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
dw-ship — merge, clean up, sync
One decision — the squash — and it takes no arguments. Everything before it happened at dw-land;
everything after is teardown.
What it reads
The branch state, the PR's checks, and ## Git conventions, which every git mechanic here
follows. It writes no .ai/ artifact: its output is a merged PR and a clean tree.
Workflow
1. Preconditions
- Clean tree (
git status --porcelain) — leftover work gets committed per## Git conventions, or deliberately stashed; never shipped around. - Landed first, and that is a refusal. A
CHANGE.mdstill matching this branch (the same grepdw-nextuses) means the change isn't closed: say so, say/dw-land, and stop.
2. Pick the path
- Already on the default branch (the one
## Git conventionsnames) and it isn't protected → fast path: plaingit pushis the whole ship — and this change's first CI, so watch any resultdw-landleft pending on the push. - Any other branch → the merge below.
- No
originat all → offer the local ending: switch to the default branch, merge, delete the branch. Never pretend to have pushed.
3. Merge the PR
- Read the checks first:
gh pr checks— a pending or failing check is a reason to wait and say so, not a footnote under the go. gh pr merge --squash --subject "<the PR title>"—--subject, not--title(whichgh pr mergedoesn't have), so the squash lands under the conventional subject. Not--delete-branch: with the branch checked out in a worktree its local half fails and the remote half never runs — step 4 deletes the remote branch instead.- No PR on the branch →
dw-landnever ran or its PR was closed; stop and say which.
4. Clean up
Leave the worktree first (the ExitWorktree tool where the session offers it, else cd to the main
tree), then:
bash "${CLAUDE_PLUGIN_ROOT}/scripts/worktree.sh" remove <slug>
For a plain branch with no worktree: git switch <default-branch>, git branch -D <branch>. Then
the remote branch, now that nothing holds it locally:
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.
- 8d ago Changed 47b477d5230b
- 12d ago First seen · 80 lines · 43 tokens per session scan A 6183f2f4f1ca
dw-ship is a skill published in the GitHub repository dominikwozniak/dw-solo-skills (2 stars, last pushed today), licensed MIT. It adds 43 tokens to every session and 855 once invoked, about $0.0002 per session on Opus 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-08-31.
Other skills, from other repositories
flow-next-land
Autonomous PR babysitter tick. Fixes CI, resolves feedback, merges when converged, closes the spec, releases. Emits LANDVERDICT. Use when asked to land PRs.
release
CONTRIBUTOR TOOL - Cut a plugin release: bump plugin.json version, finalize CHANGELOG, update README if needed, gate on make ci, commit, tag vX.Y.Z, and create the GitHub release. Use when shipping a new plugin version. NOT distributed.
release
Cut a brooks-lint release: set the version in package.json, propagate it across all four plugin manifests and every version-bearing text file (README badges, docs site metadata), write the CHANGELOG entry, validate, then commit, push, tag, and publish the GitHub release. Triggers when the maintainer asks to "release"…
share-a-library
Use when a managed library is ready to publish to GitHub and hand to teammates as an install command. Run the GitHub publishing steps, then return the exact shareable install command.
development-workflow
Detailed development workflow with modular patterns for git, review, testing, and deployment.
push-ci
Push to remote and monitor CI. Validates branch safety, executes git push WITH explicit user approval, then monitors CI run status via gh CLI. Use when: user says 'push', 'push and watch CI', 'ship it', 'push-ci'. Not for: committing (use /smart-commit), creating PRs (use /create-pr), merging (use /merge-prep).