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 Obsidian-Owl/specwright --skill gate-specgit clone --depth 1 https://github.com/Obsidian-Owl/specwrightWrote 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/obsidian-owl/specwright/gate-spec)<a href="https://agentmods.dev/skills/obsidian-owl/specwright/gate-spec"><img src="https://agentmods.dev/badge/skills/obsidian-owl/specwright/gate-spec/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/obsidian-owl/specwright/gate-spec"><img src="https://agentmods.dev/badge/skills/obsidian-owl/specwright/gate-spec.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.00033 | $0.00948 |
| Opus 5.5 | $0.00013 | $0.00379 |
| Sonnet 5.5 | $0.00007 | $0.00190 |
| Haiku 4.5 | $0.00003 | $0.00095 |
Grade A, and why
gate-spec 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 1mo 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 — 101 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Gate: Spec Compliance
Goal
Prove that the implementation actually does what was asked for. Every acceptance criterion in the spec must map to implementation evidence (file:line) and test evidence (test name at file:line). This is the gate that closes the loop.
Inputs
{workDir}/spec.md-- acceptance criteria{repoStateRoot}/work/{selectedWork.id}/workflow.json-- selected work unit- The codebase (implementation and tests)
Outputs
- Evidence file at
{workDir}/evidence/spec-compliance.md - Compliance matrix: each criterion → implementation ref + test ref + status
- Gate status in the selected work's
workflow.json - The compliance matrix remains the canonical AC / IC proof surface that
downstream
review-packet.mdsynthesis summarizes or references
Constraints
Criteria extraction (LOW freedom):
- Parse spec.md for all acceptance criteria (lines matching
- [ ] AC-*). - Number them. Every single one must be mapped. No skipping.
- On the final work unit of a multi-WU design: also parse behavioral integration
criteria (IC-B{n} entries) from
integration-criteria.mdin the design-level directory. IC-B entries are added to the compliance matrix alongside ACs. When not on the final work unit, whenintegration-criteria.mddoes not exist, or whenintegration-criteria.mdhas no IC-B entries, gate-spec operates exactly as before — no behavioral IC mapping.
Evidence mapping (HIGH freedom):
- For each criterion, search the codebase for implementation evidence.
- For each criterion, search test files for test evidence.
- Delegate to
specwright-reviewerfor thorough analysis if needed. - For behavioral criteria (execution-path claims, not structural checks), trace premises from the spec and code, derive claims from those premises, and draw conclusions without adding uncited evidence.
- Evidence must be specific: file path and line number, not "somewhere in src/".
Verdict (LOW freedom):
- Follow
protocols/evidence.md#verdict-rendering. - Criterion with both implementation AND test evidence = PASS.
- Criterion with implementation but no test = WARN.
- Criterion with neither = FAIL.
- Overall: if ANY criterion is FAIL, gate is FAIL.
- IC-B entries (when present): IC-B with both implementation and test evidence = PASS. IC-B without test evidence = FAIL (gate-spec's standard verdict vocabulary). Note: gate-spec FAIL for IC-Bs and deliverable verification BLOCK for IC-Bs are complementary — gate-spec reports the finding within its standard framework, deliverable verification enforces the action. gate-spec runs first (as part of the 6 standard gates); deliverable verification runs after all gates.
- Reference discovered behaviors at INFO level per
protocols/build-quality.md. Does not alter PASS/WARN/FAIL verdict.
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.
- 1mo ago First seen · 101 lines · 33 tokens per session scan A ba157ee86372
gate-spec is a skill published in the GitHub repository Obsidian-Owl/specwright (10 stars, last pushed 5mo ago), licensed MIT. It adds 33 tokens to every session and 948 once invoked, about $0.0001 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-31.
Other skills, from other repositories
integration-e2e-testing
Integration and E2E test design principles, ROI calculation, test skeleton specification, and review criteria. Use when designing integration tests, E2E tests, or reviewing test quality.
brooks-sweep
Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user…
brooks-health
Combined codebase health dashboard that scores a project across all four quality dimensions — PR quality, architecture, tech debt, and test quality — in a single pass, drawing on twelve classic engineering books. Triggers when: user wants an overall quality assessment, asks "how healthy is this codebase?", "run all…
brooks-test
Test quality review drawing on twelve classic engineering books — with primary focus on xUnit Test Patterns, The Art of Unit Testing, How Google Tests Software, and Working Effectively with Legacy Code — that diagnoses structural problems in an existing test suite: brittleness, mock abuse, coverage illusions, slow…
recipe-add-integration-tests
Add integration/E2E tests to existing codebase using Design Docs.
testing-principles
Language-agnostic testing principles for choosing which tests a change needs, test quality, and proof ownership, with frontend and browser E2E implementation references. Use when writing tests, deciding test scope, or reviewing test quality.