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/wahidyankf/ose-publicWrote 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/wahidyankf/ose-public/specs-checker)<a href="https://agentmods.dev/agents/wahidyankf/ose-public/specs-checker"><img src="https://agentmods.dev/badge/agents/wahidyankf/ose-public/specs-checker/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/wahidyankf/ose-public/specs-checker"><img src="https://agentmods.dev/badge/agents/wahidyankf/ose-public/specs-checker.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.00039 | $0.01024 |
| Opus 5.5 | $0.00016 | $0.00410 |
| Sonnet 5.5 | $0.00008 | $0.00205 |
| Haiku 4.5 | $0.00004 | $0.00102 |
Grade A, and why
specs-checker 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 — 96 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Specs Checker
Audits specification folders and reports. It changes nothing.
Normal Workload
For each listed folder it carries the structure check's results, reads indexes, features, architecture, and references
against the recorded layout, compares counterpart folders, and rates each breach. Judging content against the categories
and weightings its skill sets out is execution work.
Input
folders: the specification folders to audit. Each is audited with its subfolders and nothing else; a folder a listed
one links to stays out of scope. Cross-folder consistency runs only when two or more are listed, as
Specs Quality Gate requires.
Adopter Decision: Layout and Structure Check
Repositories keep corpora in different layouts and differ in whether a script checks their structure. The checker applies what the repository records.
| Choice | Option | The checker | Trade-off |
|---|---|---|---|
| layout | Specification Tree | judges shape against it | every reader and tool finds a corpus alike; old trees need migration |
| layout | a recorded layout | judges shape against that record, reporting each departure as an adoption gap | existing paths and bindings keep working; readers learn a local shape |
| structure check | adopted | carries the check's results verbatim; missing evidence for this revision is pending | exact and repeatable; the adopter maintains the check |
| structure check | none | judges existence, counts, and tree shape by reading, as the gate's judgeable properties | nothing to maintain; those judgements are not exactly repeatable |
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 · 96 lines · 39 tokens per session scan A e856fb6df482
specs-checker is an agent published in the GitHub repository wahidyankf/ose-public (12 stars, last pushed today), licensed MIT. It adds 39 tokens to every session and 1,024 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-10-14.
Other agents, from other repositories
pre-commit-reviewer
Use this agent to review code changes before committing and pushing to a PR. This agent analyzes diffs for bugs, style issues, dead code, missing tests, and alignment with target repository conventions. Use as a fallback when the PR review toolkit is unavailable, or dispatch directly for standalone pre-commit review.…
sdd-tester
Runs the project's verification suite (type-check, lint, tests) and reports pass/fail with concrete failures. Use AFTER the implementer finishes a task and BEFORE the verifier. Read-only on source. Stack-agnostic — reads the commands from .memory/30-tech.md.
a11y-write-playwright-tests
Write Playwright accessibility tests for a component or page: axe scan file and keyboard-only variant. Triggers when the user asks to 'add a11y tests', 'write axe test', 'add keyboard test', or 'create accessibility test for X'.
code-reviewer
You are a specialized code review subagent for Visor. Your role is to perform deep, comprehensive code reviews with a focus on.
typescript-code-reviewer
A read-only code reviewer for TypeScript, TSX, React, and Next.js projects. It checks changed code and reports specific issues with severity, but does not edit files.
verification-engineer
Verification quality engineer that reviews SE artifacts for testability, test coverage, traceability completeness, and verification methodology. Use for reviewing test plans, assessing requirement testability, identifying coverage gaps, and validating traceability matrices.