Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/alfredoperez/speckit-companionnpx agentmods add commands/alfredoperez/speckit-companion/speckit.companion.living-coverageWrote 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/commands/alfredoperez/speckit-companion/speckit.companion.living-coverage)<a href="https://agentmods.dev/commands/alfredoperez/speckit-companion/speckit.companion.living-coverage"><img src="https://agentmods.dev/badge/commands/alfredoperez/speckit-companion/speckit.companion.living-coverage/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/commands/alfredoperez/speckit-companion/speckit.companion.living-coverage"><img src="https://agentmods.dev/badge/commands/alfredoperez/speckit-companion/speckit.companion.living-coverage.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.00029 | $0.00584 |
| Opus 5 | $0.00015 | $0.00292 |
| Sonnet 5 | $0.00006 | $0.00117 |
| Haiku 4.5 | $0.00003 | $0.00058 |
Grade A, and why
speckit.companion.living-coverage 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 — 46 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec Coverage
Show, for each living-spec capability, which of its requirements have a test mapped in the capability's coverage-tier sibling (the *.coverage.md next to its spec — spec.coverage.md for a centralized capabilities/<name>/<name>.spec.md, or <base>.coverage.md for a colocated spec) and which are still uncovered. A living spec's requirements file says what the area must do; its coverage tier says which test proves each one. This command reads both and reports the gap. Read-only — it never edits anything — and it never fails (always exits success). It's the conformance on-ramp, a signal you act on, not a gate that blocks you (the same contract as speckit.companion.living-drift).
This is opt-in. With living specs disabled (or no config), it reports nothing and exits clean. A capability that ships only a .spec.md with no .coverage.md sibling reports every requirement uncovered — never an error.
Prerequisites
- Verify Python is available by running
python3 --version. - If
python3is not available, warn the user and skip:[companion] Warning: python3 not detected; skipped coverage. Do not fail the host command.
Execution
Run the coverage checker from the repository root:
python3 .specify/extensions/companion/scripts/check-coverage.py
The script reads the capability registry (living-specs.yml), reuses the
resolver for the capability and tier paths, extracts each requirement id
(FR-NNN / NFR-NNN) from the capability's .spec.md, and looks each id up in
its .coverage.md map. A requirement is covered when its id appears in the
coverage file on a line that also names at least one test (a .test. / .spec.
path, a tests/... reference, or a file::TestCase nodeid); otherwise it's
uncovered.
Restrict to one capability by name, or get a machine-readable object:
python3 .specify/extensions/companion/scripts/check-coverage.py --capability billing
python3 .specify/extensions/companion/scripts/check-coverage.py --json
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 0828681f84b1
- 3d ago Changed 0ee7902ad864
- 9d ago First seen · 46 lines · 29 tokens per session scan A 4c038afd3ce1
speckit.companion.living-coverage is a command published in the GitHub repository alfredoperez/speckit-companion (90 stars, last pushed yesterday), licensed MIT. It adds 29 tokens to every session and 584 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-09-03.
Other commands, from other repositories
sddp-qc
Command description: Run quality control against the implemented feature. Argument hint: [optional: testing focus such as unit tests, security audit, requirements sync] Command category: feature-delivery Prerequisites: spec, plan, tasks, implementation:complete.
pr-ready
Run the project's pre-commit review loop to determine whether the current branch is ready to push — lint, tests, parallel pr-review-toolkit agents plus an over-engineering audit, fix-and-re-run until convergence.
battery
The full independent-verification battery for a finished branch: a fresh-context acceptance verifier that RE-EXECUTES the verification commands against a stated baseline, a multi-lens review (single-pass minimum, domain lenses on escalation), and the advisor extra lens, dispatched in parallel at prescribed model…
code-permutation-tester
Test multiple code variations through simulation before implementation with quality gates and performance prediction.
boundary-heatmap
Generate a visual heatmap of knowledge boundaries showing safe zones, risk areas, and semantic coverage.
prepare-release
Command "prepare-release" from qdhenry/Claude-Command-Suite, covering prepare release command, instructions, emergency hotfix process, make minimal fix and fast-track testing and deployment.