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 marconae/speq-skill --skill speq-planninggit clone --depth 1 https://github.com/marconae/speq-skillWrote 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/marconae/speq-skill/speq-planning)<a href="https://agentmods.dev/skills/marconae/speq-skill/speq-planning"><img src="https://agentmods.dev/badge/skills/marconae/speq-skill/speq-planning.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector pass
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.00044 | $0.02856 |
| Opus 5 | $0.00022 | $0.01428 |
| Sonnet 5 | $0.00009 | $0.00571 |
| Haiku 4.5 | $0.00004 | $0.00286 |
Grade A, and why
speq-planning 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 — 175 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan Authoring
Guiding Principles
- BDD (Gherkin syntax): scenarios use GIVEN/WHEN/THEN; integration tests by default, unit tests only for isolated pure computation
- EARS syntax: spec narratives use unambiguous behavioral clauses
- RFC 2119 keywords: THEN steps use MUST, MUST NOT, SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY (uppercase)
- ADR (Nygard format): design sections capture Goals / Non-Goals / Architecture / Trade-offs / Key Interfaces
Workflow
1. Discover Existing Specs
The orchestrator already ran speq domain list / speq feature list / speq search query and passed the results as this brief's ## Existing Context section. Treat that as the baseline. Do not re-run the same queries. Re-query only for gaps it does not answer:
speq feature get <domain>/<feature> # a specific feature's full spec, if Existing Context only named it
speq search query "<narrower terms>" # only if Existing Context's results do not cover a sub-area you need
Search first when modifying existing behavior. Check Existing Context before you assume a feature does not exist yet.
2. Author Spec Deltas
For each feature in scope:
specs/<domain>/<feature>/spec.md exists?
├─ Yes → DELTA markers (/speq-plan's references/delta-template.md)
└─ No → Full spec (/speq-plan's references/feature-template.md)
Output: specs/_plans/<plan-name>/<domain>/<feature>/spec.md
3. Test Mapping and Verification
Every scenario requires two forms of external proof. No claims, only evidence.
Integration tests (mandatory per scenario):
- Map each scenario to an integration test (file path + test name)
- One test per scenario by default; combine only when scenarios share setup and assertions
- Unit tests only for pure computation with no I/O
Manual invocation (mandatory per feature):
- Concrete commands that invoke the built software
- Expected observable output per command
4. Generate plan.md
Populate plan.md per /speq-plan's references/plan-template.md:
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 Changed · +37 lines 0b12438e9e3c
- 8d ago First seen · 138 lines · 44 tokens per session scan A 59c36431f66c
speq-planning is a skill published in the GitHub repository marconae/speq-skill (50 stars, last pushed 2d ago), licensed MIT. It adds 44 tokens to every session and 2,856 once invoked, about $0.0002 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
mine-plan-review
Strictly review one implemented repository plan against AGENTS.md, architecture, the immutable plan, implementation commits, real runtime behavior, verification evidence, and downstream contracts. Use when the user invokes the host-specific mine-plan-review skill with a plan path, asks whether a plan can be accepted…
aiops-implement
Delivery overlay — orchestrates lean ladder, tdd, prune, review with sub-phase gates; commits only on user approval.
tdd
Test-driven development — vertical red-green-refactor slices through public interfaces.
tdd
Test-driven development — write the failing test first, then the code. Triggers on TDD, test first, write tests, test-driven.
generate-tests
Generate deterministic, executable tests strictly from a canonical verification contract, with requirement traceability, test-oracle independence, artifact integrity validation, and strict separation from production implementation. Prevent interpreter mismatches and pre-flight binary existence loops.
generate-verification
Transform a canonical implementation specification into a deterministic verification protocol with explicit requirement traceability, evidence contracts, testability assessment, and implementation-independent verification methods. Highly stable, failing closed on specification gaps.