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/yeaight7/agent-powerups/test-preserving-refactornpx skills add yeaight7/agent-powerups --skill test-preserving-refactorgit clone --depth 1 https://github.com/yeaight7/agent-powerupsWrote 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/yeaight7/agent-powerups/test-preserving-refactor)<a href="https://agentmods.dev/skills/yeaight7/agent-powerups/test-preserving-refactor"><img src="https://agentmods.dev/badge/skills/yeaight7/agent-powerups/test-preserving-refactor.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.00027 | $0.00592 |
| Opus 5 | $0.00014 | $0.00296 |
| Sonnet 5 | $0.00005 | $0.00118 |
| Haiku 4.5 | $0.00003 | $0.00059 |
Grade A, and why
test-preserving-refactor 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 — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
Refactoring is only safe if it is backed by tests. Work in a strict loop — green baseline, one structural change, immediate re-run, revert on red — so you are never trapped in an uncompilable state.
When to Use
- Code needs restructuring (extract/inline/move) without behavior change
- A previous refactor spiraled into a broken, hard-to-recover state
- Tests covering the target area exist or can be run
Inputs
- The target area and the command that runs just its tests
Workflow
-
Run tests first. Before touching any code, run the tests covering the target area. They MUST be green. If they are red, stop and fix the tests (or the code) first:
npx jest path/to/target # or: pytest tests/test_target.py -q -
Small steps. Make one structural change at a time (e.g., extract a method).
-
Run tests immediately after the single structural change. The per-change loop:
# repeat per structural change: edit -> test -> commit (green) | revert (red) npx jest path/to/target && git commit -am "refactor: extract X" || git checkout -- . -
Revert on red. If the tests fail, you made a mistake. Revert the change (
git checkout -- .orgit restore .) and try a different approach. Do not attempt to "fix" the refactor while tests are failing. -
Commit on green. Once the small change is green, consider it a safe checkpoint.
This strict loop prevents you from getting trapped in an uncompilable state.
Output
- A chain of small, individually green commits
- The final test run output proving unchanged behavior
Verification
- Baseline test run was green before the first edit
- Exactly one structural change per test cycle
- Every red result handled by revert, not forward-fixing
- Each green step committed as a checkpoint
- No test was modified to make the refactor pass
Failure Modes
- Refactoring on red — starting from failing tests means you cannot tell what you broke.
- Step batching — three changes per test run; when it fails, you don't know which one did it.
- Forward-fixing a broken refactor — "fixing" while red digs the hole deeper; revert is cheaper.
- Bending the tests — editing assertions to match new behavior is a behavior change, not a refactor.
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 · 62 lines · 27 tokens per session scan A b1a2f6d4b2c1
test-preserving-refactor is a skill published in the GitHub repository yeaight7/agent-powerups (6 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 27 tokens to every session and 592 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 skills, from other repositories
skill-authoring
Author SKILL.md: frontmatter, structure, writing principles.
systematic-debugging
4-phase root cause debugging: understand bugs before fixing.
github-code-review
Review PRs: diffs, inline comments via gh or REST.
simplify-code
Sequential 3-lens cleanup of recent code changes.
test-driven-development
TDD: enforce RED-GREEN-REFACTOR, tests before code.
academic-paper-review
Structured peer-review of academic papers.