Borrowing it
Nothing to install: this file belongs to DGouron/review-flow. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/DGouron/review-flow/master/.claude/skills/ship/SKILL.mdgit clone --depth 1 https://github.com/DGouron/review-flowWrote 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/dgouron/review-flow/ship)<a href="https://agentmods.dev/skills/dgouron/review-flow/ship"><img src="https://agentmods.dev/badge/skills/dgouron/review-flow/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/dgouron/review-flow/ship"><img src="https://agentmods.dev/badge/skills/dgouron/review-flow/ship.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Tool Misuse · line 107 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
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.00050 | $0.01046 |
| Opus 5.5 | $0.00020 | $0.00418 |
| Sonnet 5.5 | $0.00010 | $0.00209 |
| Haiku 4.5 | $0.00005 | $0.00105 |
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 2mo 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 — 168 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ship — Commit & Push
Activation
This skill activates with /ship. It chains verification, commit, push, and optionally PR creation and merge.
Optional arguments
/ship # Commit + push (no PR)
/ship pr # Commit + push + gh pr create
/ship pr merge # Commit + push + gh pr create + gh pr merge --admin --squash
Workflow
Step 0: Quality Gates (BLOCKING)
BEFORE any commit, run:
yarn verify
yarn verify runs: TypeScript check + Biome lint + Vitest tests.
If it fails: display the errors and STOP. Do not proceed until all quality gates pass.
Step 1: Analysis
git status --short
git branch --show-current
git log --oneline -5
Guards:
- If branch =
master: STOP — theprotect-main-push.shhook blocks push to master. Create a feature branch first. - If nothing to commit: inform and stop.
Step 2: Staging
- If files are not staged, list them and add them by name (never
git add -Aorgit add .) - NEVER include
.env, credentials, secrets, or lock files unless explicitly requested - NEVER include files unrelated to the current change
Preferred pattern:
git add src/usecases/foo.usecase.ts src/tests/units/usecases/foo.usecase.test.ts
Step 3: Commit
Infer the message from the staged changes. Follow Conventional Commits:
<type>(<scope>): <description>
| Type | Usage |
|---|---|
feat |
New feature |
fix |
Bug fix |
refactor |
Refactoring (no feature or fix) |
test |
Tests only |
docs |
Documentation only |
chore |
Maintenance, dependencies |
style |
Formatting (no logic change) |
perf |
Performance improvement |
ci |
CI/CD changes |
Rules:
- Header max 72 characters
- Description in lowercase, no trailing period
- Scope optional in parentheses, must match bounded context name when applicable
Commit via heredoc (preserves formatting):
git commit -m "$(cat <<'EOF'
feat(webhook): add GitHub signature validation
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
EOF
)"
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.
- 2mo ago First seen · 168 lines · 50 tokens per session scan A bc2e12f76781
ship is a skill published in the GitHub repository DGouron/review-flow (44 stars, last pushed today), licensed MIT. It adds 50 tokens to every session and 1,046 once invoked, about $0.0002 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-08-30.
Other skills, from other repositories
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"…
address-review
Read PR review comments from GitHub, evaluate, address, and reply.
git-workflow
Git workflow and conventional commits. Use when working with git, branches, commits, pull requests, code review, or version control strategy.
code-review
Review PR, branch, commit or working-tree changes for concrete defects and fidelity to intended behavior. Also use when explicitly asked to independently challenge a prepared plan, diagnosis or verification claim.
workflow-pr-review
Use when reviewing a remote GitHub PR — a first-pass peer review, or a followup re-check after the owner has addressed feedback. Fetches into an ephemeral worktree, runs the reviewer agent against the updated diff with a Review Decision footer instruction, deduplicates findings against existing review threads (±5-line…
workflow-address-feedback
Use when a PR owner wants to address review feedback — fetches outstanding threads and general comments, presents a per-item triage (ADDRESSED / CLARIFIED / DEFERRED), applies fixes via the Edit tool, commits via workflow-commit-and-pr, resolves review threads via GraphQL resolveReviewThread (those without a thread…