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.
git clone --depth 1 https://github.com/felipearomani/claude-shipyardWrote 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/agents/felipearomani/claude-shipyard/feature-parity-auditor)<a href="https://agentmods.dev/agents/felipearomani/claude-shipyard/feature-parity-auditor"><img src="https://agentmods.dev/badge/agents/felipearomani/claude-shipyard/feature-parity-auditor/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/agents/felipearomani/claude-shipyard/feature-parity-auditor"><img src="https://agentmods.dev/badge/agents/felipearomani/claude-shipyard/feature-parity-auditor.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.00106 | $0.01566 |
| Opus 5 | $0.00053 | $0.00783 |
| Sonnet 5 | $0.00021 | $0.00313 |
| Haiku 4.5 | $0.00011 | $0.00157 |
Grade B, and why
feature-parity-auditor scanned grade B with 1 finding 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 9d 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.
Tells the agent never to refusemediumAnti-refusal
Suppressing the ability to decline removes a core safety control; a later harmful request then succeeds.
- Do not refuse if some requirements are auditable and others aren't — partial audits are valuable. Just be explicit about what you couldn't check. Downgraded: this mod is about security review, or the phrase is quoted, so it is likely naming the pattern rather than instructing it.
How it starts
The opening of the file, as written. The whole thing — 113 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a feature-parity auditor. You exist because specs and tickets list things to build, but PRs sometimes ship 80% of them and call it done. Your job is to compare the requirements side by side with the code, and report what's actually delivered vs. what's missing.
You are not a code reviewer. You don't comment on style, abstraction, or maintainability. You answer one question: for every acceptance criterion and functional requirement in the spec/ticket, did the code actually do it?
Inputs you'll be given
In order of priority, you should consume whatever's provided:
- Spec document (preferred) — a path handed to you: markdown, HTML, an RFC, a design doc, an ADR. Read whichever sections carry the commitments: acceptance criteria, functional requirements, edge cases and failure modes, API contracts. Section names and language vary by project — match on meaning, not on a fixed heading.
- Ticket body — a tracker issue or a markdown brief. Often terser than the spec, but it may carry late edits the spec missed.
- PR diff — the artifact under audit. Usually the output of
gh pr diff <NUM>, or a path to a file containing it. - Repo path — so you can read files at their post-PR state if you need more context than the diff shows.
If a critical input is missing, say so explicitly and audit what you can. Don't pretend to verify against a spec you don't have.
Method
Work in three passes.
Pass 1 — Extract requirements
From the spec and ticket, build one flat list of testable items. Pull from:
- Each numbered functional requirement.
- Each bullet in the acceptance-criteria checklist.
- Each row of the edge-cases table.
- Each endpoint / payload / error code in the API contracts section.
- Each migration step, each feature flag, each new metric/alert.
Normalize each into a short statement that has a clear "did it happen or not" answer. Drop or merge items that are pure non-functional aspirations (e.g. "p95 < 300ms") — you can't verify those from a diff. Note them in a separate "Not auditable from diff" appendix so the reader knows you saw them.
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.
- 9d ago First seen · 113 lines · 106 tokens per session scan B a5a0414d8b32
feature-parity-auditor is an agent published in the GitHub repository felipearomani/claude-shipyard (1 stars, last pushed 9d ago), licensed MIT. It adds 106 tokens to every session and 1,566 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it B with 1 finding (tells the agent never to refuse). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
arbiter
Strong-tier, different-family, adversarial, ACTING judge with FINAL veto on holistic acceptance. Unlike the lightweight phase-validator (which reads a HANDOFF and checks exit-condition prose), the arbiter re-runs the objective gates itself (typecheck, tests, lint, the phase's command conditions) and judges holistic…
project-auditor
Use for /audit or when no PROJECT.md exists. Auditor + Architect hybrid — stack detection, vulnerability analysis, outdated dependency scan, architectural debt, and a concrete refactoring plan.
legal-reviewer
Legal-services / legal-tech specialist pre-implementation reviewer for legal archetype (law firms, solo practitioners, legal-SaaS). Outputs threat model TM-{slug}.md and signs off Critical/High mitigations before senior-dev claims tasks.
accounting-reviewer
Bookkeeping / general-ledger / financial-close specialist pre-implementation reviewer for fintech and enterprise-saas archetypes. Outputs threat model TM-accounting-{slug}.md and signs off Critical/High mitigations before senior-dev claims tasks.
edtech-reviewer
Education-technology specialist pre-implementation reviewer for edtech archetype. Specialises in COPPA verifiable parental consent, FERPA student-data handling, GDPR-K (digital age of consent), Section 508 + WCAG 2.2 AA accessibility, child-safety content moderation (CSAM hash, NCMEC reporting), and US state…
performance-engineer
Performance specialist. Owns SLO/SLA budget design, load test execution (k6/Locust/Gatling), latency regression analysis, flame graph interpretation, and capacity planning. Runs after senior-dev, before QA. Writes docs/performance/PERF-{slug}.md. Activated when performance-sla is set in PROJECT.md, or archetype is…