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/tommymorgan/claude-pluginsnpx agentmods add commands/tommymorgan/claude-plugins/migrate-to-living-specsWrote 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/tommymorgan/claude-plugins/migrate-to-living-specs)<a href="https://agentmods.dev/commands/tommymorgan/claude-plugins/migrate-to-living-specs"><img src="https://agentmods.dev/badge/commands/tommymorgan/claude-plugins/migrate-to-living-specs/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/tommymorgan/claude-plugins/migrate-to-living-specs"><img src="https://agentmods.dev/badge/commands/tommymorgan/claude-plugins/migrate-to-living-specs.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.00024 | $0.00558 |
| Opus 5 | $0.00012 | $0.00279 |
| Sonnet 5 | $0.00005 | $0.00112 |
| Haiku 4.5 | $0.00002 | $0.00056 |
Grade A, and why
tommymorgan:migrate-to-living-specs 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 10d 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 — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Migrate Historical Plans to Living Specifications
One-time migration that creates living .feature files from historical plan files.
Usage
/tommymorgan:migrate-to-living-specs [project-path]
If no path provided, uses current project (inferred from working directory).
What This Does
- Scans plans/ directory for historical plan files
- Extracts Gherkin scenarios from User Requirements and Technical Specifications
- Groups scenarios by feature area using semantic similarity
- Tags scenarios appropriately (@user, @technical)
- Creates .feature files in features/ directory
- Reports progress with success/failure counts
Process
cd $PROJECT_PATH
# Run migration tool
python3 tools/claude-plugins/tommymorgan/migration/commands/migrate.py .
# Results will be in features/ directory
ls features/*.feature
Output
Creates .feature files in <project>/features/ directory:
features/
authentication.feature
user-management.feature
analytics.feature
Each .feature file contains:
Feature: <Feature Name>
@user
Scenario: User-facing behavior
Given user context
When user action
Then user outcome
@technical
Scenario: Technical requirement
Given system state
When technical action
Then technical outcome
Summary Report
After completion, shows:
Migration complete!
Processed: 15 plans
Successes: 12
Failures: 3
Created: 5 .feature files
Errors:
- plan-old.md: No scenarios found
- plan-broken.md: Parse error
- plan-incomplete.md: No Gherkin blocks
Check features/ directory for living specifications.
When to Use
Run this ONCE to bootstrap living documentation from historical plans.
After migration:
- New plans will reference existing living specs (interactive reconciliation)
- Work tool will automatically update living specs
- Never run migration again (living specs are maintained going forward)
Important Notes
- Historical plans remain unchanged (valuable record)
- Semantic similarity groups related scenarios (0.8 threshold)
- Processes in batches for memory efficiency
- Continues on errors, reports all issues at end
- Scenarios below 0.8 similarity flagged for manual review
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.
- 10d ago First seen · 108 lines · 24 tokens per session scan A eba53140bea5
tommymorgan:migrate-to-living-specs is a command published in the GitHub repository tommymorgan/claude-plugins (4 stars, last pushed 1mo ago), licensed MIT. It adds 24 tokens to every session and 558 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 commands, from other repositories
prototype
You are building a proof-of-concept for the current Grainulator sprint. Read CLAUDE.md for sprint context and claims.json for existing research claims.
verify
Run repository verification using the verification-loop skill.
qa-changes
This skill should be used when the user asks to "QA a pull request", "test PR changes", "verify a PR works", "functionally test changes", or when an automated workflow triggers QA validation of code changes. Provides a structured methodology for setting up the environment, exercising changed behavior, and reporting…
test-coverage
Analyze test coverage and identify the highest-value gaps to fill.
tdd
A command that follows test-driven development (TDD), a method where you write tests before the code they check. It moves through writing a failing test, adding the smallest implementation, and then improving the code.
check-dev
Type-check a Z specification with fuzz.