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 agentmods add skills/sudokar/openspec-plus/openspec-plus-tddnpx skills add sudokar/openspec-plus --skill openspec-plus-tddgit clone --depth 1 https://github.com/sudokar/openspec-plusWrote 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/sudokar/openspec-plus/openspec-plus-tdd)<a href="https://agentmods.dev/skills/sudokar/openspec-plus/openspec-plus-tdd"><img src="https://agentmods.dev/badge/skills/sudokar/openspec-plus/openspec-plus-tdd.svg" alt="Measured on agentmods" 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 | $0.00190 | $0.04306 |
| Opus 5 | $0.00095 | $0.02153 |
| Sonnet 5 | $0.00038 | $0.00861 |
| Haiku 4.5 | $0.00019 | $0.00431 |
Grade A, and why
openspec-plus-tdd 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 today.
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 — 378 lines — stays where its author put it; the contents beside it link to each section on GitHub.
OpenSpec Plus TDD
Mission
Strict RED-GREEN-REFACTOR per test for OpenSpec change implementation. Every test — whether derived from a Gherkin scenario relevant to the slice in spec.md, written for a unit, edge case, helper, or error path — goes through its own atomic cycle before the next test begins. Production code exists only to make a previously-failing test pass. Surgical changes, simplicity first, no speculative abstractions, every changed line traces to a slice task.
Gherkin scenarios in spec.md are the canonical source for acceptance tests: every scenario relevant to the slice MUST become at least one test. The implementer is encouraged to add additional tests — unit tests for individual functions, edge-case tests, helper tests, error-path tests — when fast-feedback granularity is valuable. Every test follows the same cycle.
Loaded by openspec-plus-apply (subagent prompt + inline mode) before any code is written.
RIGID. NEVER write production code before a test fails for the right reason. NEVER write tests for multiple cases before the first one is GREEN. NEVER skip the REFACTOR assessment. NEVER mark a task
[x]while a relevant test is failing or skipped. NEVER add comments for non-complex logic. NEVER refactor code outside the slice. NEVER write any code (test or production) before reading the project's referenced coding/testing standards. NEVER ship without covering every Gherkin scenario in spec.md with at least one test. Letter and spirit are the same.
Red flags — STOP, you are about to violate this skill:
- "I'll write the test after, it's faster"
- "Too simple to need a test"
- "Manually verified, that's enough"
- "Gherkin scenario is vague, generic test is fine"
- "Skip this failing test, circle back later"
- "Mark
.skipto unblock the slice" - "While I'm here, clean up the adjacent code"
- "Add an interface in case we swap implementations"
- "Short comment explains the obvious"
- "Error handling for cases that can't happen"
- "Test passed first run, must be right"
- "Let me write tests for all the cases first, then implement"
- "Test 1 done — I have a clear picture, let me write all the rest at once"
- "I have a clear picture of all 5 cases — let me write them all"
- "Writing one test at a time is slower"
- "These cases are related, I'll batch them"
- "The code I'm about to write covers test 2 anyway, no need to write its test separately first"
- "Acceptance tests cover the happy path — skip the unit/edge tests"
- "Scenarios covered, no need to add granular tests even though the helper has edge cases"
- "Nothing to refactor, skip the assessment"
- "I know the project conventions, no need to re-read AGENTS.md"
- "AGENTS.md has many rules — I'll apply the ones that feel relevant"
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.
- today Changed · +1 lines c9623d638943
- 4d ago First seen · 377 lines · 190 tokens per session scan A 7eac3da809f1
openspec-plus-tdd is a skill published in the GitHub repository sudokar/openspec-plus (166 stars, last pushed today), licensed MIT. It adds 190 tokens to every session and 4,306 once invoked, about $0.0010 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-30.
Other skills, from other repositories
test-assess
Test agentready assess against real GitHub repositories to validate assessor changes. Selects repos relevant to the change being tested, clones them to a temp directory, runs the local checkout's assessor, reports results and output locations, then cleans up. Use when testing a new or modified assessor, verifying a…
implement-type-annotations
Add comprehensive type hints to Python/TypeScript code to improve IDE support, catch errors early, and enable better AI code understanding.
setup-claude-md
Create comprehensive CLAUDE.md files with tech stack, standard commands, repository structure, and boundaries to optimize repositories for AI-assisted development.
pr-review
Review a GitHub pull request and post one formal review — advance the existing discussion and give precision-first, high-signal feedback. Judgement on the diff, not a build gate — CI validates that it builds, and a targeted probe is allowed as evidence. Use when asked to review a PR or on a cron PR scan.
acceptance-orchestrator-v2
Acceptance Orchestrator workflow skill. Use this skill when the user needs a coding task should be driven end-to-end from issue intake through implementation, review, deployment, and acceptance verification with minimal human re-intervention and the operator should preserve the upstream workflow, copied support files…
deep-debugging
Systematic debugging protocol for bugs that resist quick fixes. Use bisection, hypothesis trees, and scientific method when a bug isn't obvious from the stack trace. Goes beyond bugfix-quick for production-grade root cause analysis.