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.
npx agentmods add skills/heliohq/ship/devnpx skills add heliohq/ship --skill devgit clone --depth 1 https://github.com/heliohq/shipWhat 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 | $0.00056 | $0.05702 |
| Opus 5 | $0.00028 | $0.02851 |
| Sonnet 5 | $0.00011 | $0.01140 |
| Haiku 4.5 | $0.00006 | $0.00570 |
Grade A, and why
dev 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 2d 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 — 581 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ship: Implement
HOST IMPLEMENTS. PEER CROSS-VALIDATES.
EVERY FINDING NEEDS FILE:LINE + EVIDENCE.
Runtime Resolution
Path note: ../shared/*.md references resolve against this skill's base
directory (announced as "Base directory for this skill" when the skill
loaded), not your working directory.
See ../shared/runtime-resolution.md for the host/peer concept and
dispatch commands. In /ship:dev, the host is the primary implementer
and the peer is the independent reviewer — the reviewer MUST differ
from whoever implemented the story. Prefer a non-host provider for
cross-model validation; if unavailable, use a fresh same-provider
session and record the weaker independence in the report.
Two wave shapes, different dispatch patterns (fix routing — whoever implemented, fixes — is specified in Step C):
| Wave shape | Implementer | Reviewer |
|---|---|---|
| Single-story (most common) | Host (you), on current branch | Peer agent |
| Multi-story parallel | Fresh Agent subagents per story, all on the current branch (dependency analysis guarantees their file scopes don't overlap — no worktrees needed) | Peer per story |
| Fix mode (/ship:auto review_fix/qa_fix/e2e_fix dispatch) | Host — you | (next phase re-runs its own verification) |
Quality Gates
| Gate | Condition | Fail action |
|---|---|---|
| Spec + plan read | Acceptance criteria extracted, TEST_CMD found | AskUserQuestion |
| Implement → Review | Story produced at least one commit (from subagent report, or HEAD moved since WAVE_BASE_SHA for single-story waves) | BLOCKED |
| Review → Next story | Verdict is PASS or PASS_WITH_CONCERNS | Targeted fix (progress-governed — see Step C) |
| All stories → Done | Full test suite passes | Targeted fix for regression |
Red Flag
Never:
- Skip the peer review — every story goes through peer review (or fallback) before the wave merges. This is the only cross-validation in the pipeline until /ship:review runs.
- Parallelize stories that share files without dependency analysis
- Re-implement a full story on FAIL — make targeted surgical fixes
- Advance to next story without getting a reviewer verdict
- Soften a test assertion to make it pass instead of fixing the code
- Reuse a reviewer dispatch across stories — fresh peer call each time
- Let the peer reviewer become your coder — if the reviewer suggests a fix, YOU apply it; don't ask the reviewer to write patches
- Tell a reviewer what not to flag, or pre-rate a finding's severity. Tripwire: if the dispatch you are composing contains "do not flag", "don't treat X as a defect", or "at most minor" — stop; you are pre-judging, usually to spare yourself a review round. Let the reviewer raise it and adjudicate the verdict yourself.
- Re-implement a story the dev ledger already marks complete — after a
compaction or resume, trust
dev-ledger.mdandgit logover your own recollection
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.
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.
- 2d ago First seen · 581 lines · 56 tokens per session scan A 771ee2a6c7f4
dev is a skill published in the GitHub repository heliohq/ship (92 stars, last pushed 2mo ago), licensed MIT. It adds 56 tokens to every session and 5,702 once invoked, about $0.0003 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-30.
Other skills, from other repositories
joedevflow
Development workflow. Use when building a feature, creating an MVP, refactoring code, fixing a bug, or any task that involves writing or changing implementation code.
casely
Intelligent QA assistant that automates writing test cases from project documentation. Use when the user wants to generate test cases from requirements, runs /init, /parse, /style, /plan, /generate, /export, or works with PDF/DOCX/XLSX requirement documents and TestRail-ready Excel export.
human-approval
Request human approval before performing a SAFETY-CRITICAL, IRREVERSIBLE, or SCOPE-EXPANDING action — submit a structured context (action, scope, risk, consequence) plus options, then STOP the current turn. The platform redispatches the agent after the human decides. NEVER use for routine deliverables (writing docs /…
firebase-analytics
Use when logging analytics events, setting user properties, configuring default event parameters, building funnels, or adding screen-view tracking.
firebase-remote-config
Use when implementing feature flags, running A/B tests, setting parameter defaults, fetching/activating config, or enabling real-time config updates.
git-master
MUST USE whenever a task needs a commit or git-history investigation. Covers atomic commits, staging, commit-message style, rebase, squash, fixup/autosquash, blame, bisect, reflog, git log -S/-G, and questions like who wrote this or when was this added. Do not use for ordinary code edits unless the user asks for git…