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-validateWrote 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-validate)<a href="https://agentmods.dev/commands/alfredoperez/speckit-companion/speckit.companion.living-validate"><img src="https://agentmods.dev/badge/commands/alfredoperez/speckit-companion/speckit.companion.living-validate/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-validate"><img src="https://agentmods.dev/badge/commands/alfredoperez/speckit-companion/speckit.companion.living-validate.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.00047 | $0.00786 |
| Opus 5 | $0.00023 | $0.00393 |
| Sonnet 5 | $0.00009 | $0.00157 |
| Haiku 4.5 | $0.00005 | $0.00079 |
Grade A, and why
speckit.companion.living-validate 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 yesterday.
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 — 50 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec Shape
Check that every living spec, and every active feature spec's delta sections, are shaped the way every reader of them assumes. A living spec is only worth keeping if what gets folded into it is trustworthy, and until something checked, a requirement with no scenario or a delta pointing at a heading that does not exist landed silently and was found weeks later by a person reading the file.
Read-only — it never edits anything, and it never fails (always exits success). The fold consumes the same checks and refuses to write on an error; this command only reports. A surrounding workflow may treat findings as a gate; the command itself does not.
This is opt-in. With living specs disabled (or no config), it reports nothing and exits clean.
Prerequisites
- Verify Python is available by running
python3 --version. - If
python3is not available, warn the user and skip:[companion] Warning: python3 not detected; skipped the spec shape check.
Execution
Run the checker from the repository root:
python3 .specify/extensions/companion/scripts/living_validate.py
Add --json when a caller needs the machine-readable object rather than the list. Each finding carries a severity, a stable code, the path, the line, a sentence saying what is wrong, and a one-line fix.
What it reports
| Code | Severity | Raised when |
|---|---|---|
requirement-without-scenario |
warning | A requirement states a rule and never says how anyone would know it held. |
scenario-missing-half |
error | A scenario has a condition and no outcome, or an outcome and no condition. The keywords are recognised with or without emphasis, so - WHEN … counts exactly as - **WHEN** … does. |
duplicate-requirement |
error | Two requirements in one capability share a heading, which is the join key fold-back and coverage use. |
unknown-capability |
error | A delta block is marked for a capability the registry does not list. |
delta-heading-not-found |
warning | A MODIFIED or REMOVED entry names a heading the target spec does not carry. The fold promotes an unmatched modification into an addition, so this is a defined outcome rather than damage. |
unmatched-touches-glob |
warning | A file marker names a pattern matching nothing on disk. |
requirements-outside-capability— every file marker names code the capability does not claim, so nothing resolves for that behaviour.capability-claims-undescribed-code— the capability claims code no requirement describes, so a change there is briefed with nothing. |unbalanced-fence| warning | A code fence is opened and never closed, so everything after it is invisible to every reader. |
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.
- yesterday Changed · +2 lines dfb01ffbeaf2
- 5d ago Changed 7916cf75faf9
- 6d ago First seen · 48 lines · 47 tokens per session scan A e29b4354b823
speckit.companion.living-validate is a command published in the GitHub repository alfredoperez/speckit-companion (90 stars, last pushed today), licensed MIT. It adds 47 tokens to every session and 786 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-09-06.
Other commands, from other repositories
sddp-implement-qc-loop
Command description: Run implement and QC in a continuous loop. Argument hint: [optional: feature directory or branch name] Command category: orchestration Prerequisites: spec, plan, tasks.
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.
test-plan-review-team
Parallel multi-lens adversarial critique of a spec's test plan (the ## Test plan section), with a bounded revise loop that tightens it. Dispatches 6 test-design lenses, merges findings, optionally revises, reports a verdict. Report-only, never blocks /kit:execute.
verify
Re-run the test levels (task-verifier + integration-verifier + acceptance-verifier + system-verifier) on the current spec/branch read-only, no rebuild. The on-demand executor of the complete V-model right arm.
speckit.hashloom.gate
Verify the feature's seams through the hashloom cache: cached-green precheck before implementation, hard verify --radius gate after.
implement-approved-slice
Implement only the approved slice with minimal, explicit, review-friendly changes, then persist execution evidence in slice notes and TASKSTATE.md. The single official execution path of the workflow. Supports an opt-in test-first (TDD) mode, enabled per slice or via --tdd, that writes the failing test before the code…