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 agentmods add skills/timwukp/agent-skills-best-practice/legacy-code-testingnpx skills add timwukp/agent-skills-best-practice --skill legacy-code-testinggit clone --depth 1 https://github.com/timwukp/agent-skills-best-practiceWrote 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/timwukp/agent-skills-best-practice/legacy-code-testing)<a href="https://agentmods.dev/skills/timwukp/agent-skills-best-practice/legacy-code-testing"><img src="https://agentmods.dev/badge/skills/timwukp/agent-skills-best-practice/legacy-code-testing.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.00106 | $0.01133 |
| Opus 5 | $0.00053 | $0.00566 |
| Sonnet 5 | $0.00021 | $0.00227 |
| Haiku 4.5 | $0.00011 | $0.00113 |
Grade A, and why
legacy-code-testing 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 6d 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 — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Legacy Code Testing
Untested code you must change is a trap: you can't refactor safely without tests, and you can't test cleanly without refactoring. The way out is characterization testing — pin down what the code currently does (not what it should do), then refactor under that safety net.
The golden rule: before refactoring, tests assert current behavior — even buggy behavior. A characterization test that "fails" because the code has a bug is wrong; the test must pass against today's code. Log suspected bugs separately for the team to triage.
Process
- Scope and rank. Identify what actually needs a safety net: code you're about to change, plus its blast radius (callers and shared state). Rank by
change-likelihood × consequence-of-breaking. Do not attempt whole-codebase coverage — legacy coverage is bought module by module, just-in-time. - Find the seams. For each target, identify where behavior can be observed and where dependencies can be substituted without editing the logic under test (see Seams table). If there is no seam, apply the minimal enabling refactor (extract method, parameterize constructor, wrap static call) — mechanical, behavior-preserving, small enough to eyeball.
- Write characterization tests.
- Start with the happy path for the most common input; then boundaries (empty, null, max, malformed); then the weird branches the code visibly handles.
- When you don't know the expected output, run the code and capture it: write the assertion against the observed result. If you can't execute it, write the assertion as your best reading of the code and mark it
// CHARACTERIZATION: verify against production behavior before trusting. - For outputs too large/complex to assert piecewise, use snapshot/golden-master testing: capture the full output once, assert future runs match byte-for-byte (or with explicit normalization for timestamps/ids).
- Log suspected bugs, don't fix them. Maintain a
SUSPECTED-BUGS.md(or ticket list): behavior pinned by a test that looks wrong, with the test name, why it looks wrong, and the blast radius of fixing it. Fixing comes after the net exists, as separate, deliberate changes. - Refactor under the net. Only after the characterization suite is green and running in CI: refactor in small steps, keeping the suite green at each step. As real intent becomes clear, graduate characterization tests into proper specification tests (rename, assert intent, delete redundant pins).
- Report. Deliver: tests written, observed coverage of the target module, seams introduced (with the enabling refactors listed), suspected bugs logged, and what remains unprotected.
What ships with it
2 files 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.
- 6d ago First seen · 60 lines · 106 tokens per session scan A 4dbab26417de
legacy-code-testing is a skill published in the GitHub repository timwukp/agent-skills-best-practice (10 stars, last pushed yesterday), licensed MIT. It adds 106 tokens to every session and 1,133 once invoked, about $0.0005 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
ec2
AWS EC2 virtual machine management — instances, security groups, key pairs, AMIs, EBS volumes, Auto Scaling Groups, Spot Instances, Session Manager, placement groups, and instance lifecycle automation. Trigger on ANY of these, even when EC2 isn't named explicitly: - Launching or provisioning: "spin up a server"…
bedrock
AWS Bedrock foundation models for generative AI. Use when invoking foundation models, building AI applications, creating embeddings, configuring model access, or implementing RAG patterns.
cloudwatch
AWS CloudWatch monitoring for logs, metrics, alarms, and dashboards. Use when setting up monitoring, creating alarms, querying logs with Insights, configuring metric filters, building dashboards, or troubleshooting application issues.
ecs
AWS ECS container orchestration for running Docker containers. Use when deploying containerized applications, configuring task definitions, setting up services, managing clusters, or troubleshooting container issues.
api-gateway
AWS API Gateway for REST and HTTP API management. Use when creating APIs, configuring integrations, setting up authorization, managing stages, implementing rate limiting, or troubleshooting API issues.
cloudformation
AWS CloudFormation infrastructure as code for stack management. Use when writing templates, deploying stacks, managing drift, troubleshooting deployments, or organizing infrastructure with nested stacks.