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 skills add vasuag09/harness-claude --skill shipgit clone --depth 1 https://github.com/vasuag09/harness-claudeWrote 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/vasuag09/harness-claude/ship)<a href="https://agentmods.dev/skills/vasuag09/harness-claude/ship"><img src="https://agentmods.dev/badge/skills/vasuag09/harness-claude/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/vasuag09/harness-claude/ship"><img src="https://agentmods.dev/badge/skills/vasuag09/harness-claude/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.00041 | $0.00642 |
| Opus 5 | $0.00020 | $0.00321 |
| Sonnet 5 | $0.00008 | $0.00128 |
| Haiku 4.5 | $0.00004 | $0.00064 |
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 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 — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/ship — docs sync & merge prep
Goal: leave the change merge-ready, with docs in sync and a clear summary — without performing git actions you didn't ask for.
Do this
-
Docs sync — update every doc the change touches, not just the spec. Remove stale references; keep docs lean and accurate. Before a release, sweep for anything the change made stale and reconcile it before committing, not after:
- Counts & inventories — any README/manifest that tallies features (components, commands, endpoints, supported versions) must include what you added; reconcile against the source of truth, don't eyeball it.
- Version & status docs — bump version manifests; flip roadmap/changelog/status entries to match what actually shipped.
- Reference docs — API/config/usage docs and the spec's own status + acceptance-criteria checkboxes.
- Doc shape & examples — keep the four doc kinds distinct (tutorial · how-to · reference · explanation); don't blur a reference into a tutorial. Every code example you add or touch must actually run — paste-and-execute it, don't trust it by eye.
(Project-specific files to touch live in the project's own context — for this repo, see CLAUDE.md → "Release docs sweep".)
-
Change summary — assemble from the full diff (
git diff <base>...HEAD), not just the last edit:## Summary — what & why ## Changes (grouped by area) ## Test plan — how it was verified (link the /verify evidence) ## Risks / follow-ups -
CI readiness — confirm build, types, lint, tests are green locally; no secrets, no debug logs, no
--no-verify.
Git boundary (important)
Do not run git commit, git push, or open a PR unless the user explicitly asks — and
create no new branches here (the feature branch already exists, made at first write per
rules/git.md). Prepare, then stop:
- Commit message in Conventional Commits v1.0.0 form:
type(scope): imperative subject ≤72 chars,BREAKING CHANGE:footer when applicable (seerules/git.md). - PR path: push the feature branch with
-u, open the PR (draft until verify passed), squash-merge by default — merge-commit only if the project's own history shows non-squash merges. - Report "ready to commit/PR — say the word."
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 First seen · 52 lines · 41 tokens per session scan A 2abec635cc88
ship is a skill published in the GitHub repository vasuag09/harness-claude (2 stars, last pushed 2mo ago), licensed MIT. It adds 41 tokens to every session and 642 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
catchup
Restore context after /clear by summarizing recent work and project state.
validate-changes
Evaluate staged changes using LLM-as-a-Judge before committing.
sc-diff-report
Incremental security scan for changed files only — optimized for PR and commit-level reviews.
security-pipeline
Use when security verification is needed - pre-commit security checks, vulnerability scanning, STRIDE threat analysis. Integrates with /handoff-verify --security and /commit-push-pr. CWE Top 25 based.
pr-triage
4-phase PR backlog management with audit, deep code review, validated comments, and optional worktree setup. Use when triaging pull requests, catching up on pending code reviews, or managing a backlog of open PRs. Args: 'all' to review all, PR numbers to focus (e.g. '42 57'), 'en'/'fr' for language, no arg = audit…
git-commit
Safely create a git commit by validating repository state, staging intended changes, scanning for secrets/conflicts, generating a Conventional Commits message (repository convention first, else an English Angular default) from the staged diff, and committing without amend.