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 agagniere/speky --skill write-test-plansgit clone --depth 1 https://github.com/agagniere/spekyWrote 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/agagniere/speky/write-test-plans)<a href="https://agentmods.dev/skills/agagniere/speky/write-test-plans"><img src="https://agentmods.dev/badge/skills/agagniere/speky/write-test-plans.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.1 | $0.00026 | $0.01375 |
| Opus 5 | $0.00013 | $0.00687 |
| Sonnet 5 | $0.00005 | $0.00275 |
| Haiku 4.5 | $0.00003 | $0.00137 |
Grade A, and why
write-test-plans 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 7d 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 — 128 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are helping the user expand their project's test plan coverage for a specific area. Follow these steps in order.
Step 1 — Identify the area of interest
If $ARGUMENTS is provided, use it as the area of interest (e.g. "search", "authentication", "file output").
Otherwise ask the user:
"What area or feature would you like to focus on? (e.g. a functional area, a component name, or a keyword)"
Step 2 — Discover relevant tags
Call list_all_tags to retrieve all tags used in the specification.
From the returned list, select all tags that relate to the area of interest. Use the full tag string including namespace (e.g. mcp:tools, not just tools).
Tell the user which tags you selected and why, and ask them to confirm or adjust before continuing:
"I identified these tags as relevant:
tag-a,tag-b. Does that look right, or would you like to add or remove any?"
Step 3 — Find requirements needing test plans
For each selected tag, call least_tested_requirements with that tag and count: 3. Merge and deduplicate the results across all tags, then sort by test_plans ascending (then automated_test_plans ascending). Keep the top 3.
Tell the user which requirements you will write test plans for, and wait for their approval before proceeding.
Step 4 — Study each target requirement
For each target requirement, gather full context before designing anything:
- Call
get_requirement— read itslongdescription,tags,ref,referenced_by, andtested_by. Note thesource_filefield: it tells you which spec file the requirement lives in, which determines where the test file will go. - For each ID in
refandreferenced_by, callget_requirementto understand related requirements and shared context. - For each ID in
tested_by(if any), callget_testto understand what is already tested — avoid designing scenarios that duplicate existing tests.
Step 5 — Design new test scenarios
Using what you learned, design 2 to 5 new test scenarios per requirement. Think across these angles:
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 7d ago First seen · 128 lines · 26 tokens per session scan A 8e516edb1bb5
write-test-plans is a skill published in the GitHub repository agagniere/speky (2 stars, last pushed 3mo ago), licensed MIT. It adds 26 tokens to every session and 1,375 once invoked, about $0.0001 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
runtime-observation
Cross-cutting skill for runtime observation methodology. Five-phase observation discipline, container interaction patterns, observation record format, claim extraction, environment variation. Loaded by the analyzer agent for runtime observation roles.
test-suite-analysis
Layer 1 skill for extracting behavioral intelligence from test suites. Framework detection, test code reading strategy, test execution strategy, behavioral claim extraction with Given/When/Then mapping, e2e vs unit value classification. Loaded by the analyzer agent during Layer 1.
validation-methodology
Cross-cutting validation discipline. Acceptance criteria format, definition of done checklists, quality gate criteria, verification methods. Loaded by every analysis agent.
source-completeness
Validates that all user-facing surfaces discovered in source code are captured in the behavioral specs. Catches coverage gaps where the analysis pipeline missed features, tools, env vars, CLI flags, or other behavioral interfaces. Run AFTER Layer 3 specs are written, BEFORE sanitization.
fidelity-validation
Cross-validates sanitized output specs against raw source specs to detect lost behavioral detail, dropped constants, missing features, or diluted precision. Run AFTER sanitization and AFTER contamination audit passes.
live-preview
Mid-build visual verification loop. Takes screenshots of components during construction, not just after. Catches visual regressions and invisible features before they compound. Requires Playwright or similar screenshot tool.