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 skills add helderberto/agent-skills --skill refactorgit clone --depth 1 https://github.com/helderberto/agent-skillsWrote 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/helderberto/agent-skills/refactor)<a href="https://agentmods.dev/skills/helderberto/agent-skills/refactor"><img src="https://agentmods.dev/badge/skills/helderberto/agent-skills/refactor/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/skills/helderberto/agent-skills/refactor"><img src="https://agentmods.dev/badge/skills/helderberto/agent-skills/refactor.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.00074 | $0.00649 |
| Opus 5.5 | $0.00030 | $0.00260 |
| Sonnet 5.5 | $0.00015 | $0.00130 |
| Haiku 4.5 | $0.00007 | $0.00065 |
Grade A, and why
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 3d 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 — 43 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Refactor
Target: $ARGUMENTS (file, directory, or module — if blank, use unstaged changes)
Behavior is frozen — the test suite is the contract. Green before and after; if a test's meaning has to change, you've gone too far.
Workflow
1. Scope
- Identify target files (blank → unstaged changes)
- Locate each file's tests using the project's convention (co-located,
__tests__/,tests/,spec/). A file with no tests gets Test gaps items first — Split/Simplify on untested code is unverifiable, so backfill or skip. No test runner at all → ask which to use. UI flows → backfill end-to-end tests: call the Skill tool withtdd, which holds the UI-tests reference. Entrypoint scripts without exports → audit only. - Run the suite. If red, stop — don't refactor broken code
2. Audit
List findings, most-impactful first:
| Bucket | What to look for | Fix |
|---|---|---|
| Split | Functions > 20 lines, multiple responsibilities, I/O mixed with logic | Extract pure logic into named helpers; keep I/O at the edges; preserve the original signature |
| Edge cases | Missing null/empty/boundary checks at system boundaries, unhandled error paths | Test first, then guard |
| Test gaps | Untested public functions, uncovered branches, missing sad-path tests | Backfill through the public interface |
| Simplify | Nesting > 2 levels, dead code / unused params, duplicated logic, dense one-liners, shallow pass-through wrappers, speculative config never used, unclear names / primitive obsession | Guard clauses, delete, extract one helper, expand, inline (call the Skill tool with codebase-design for the deletion test), remove, rename to intent / small type |
Chesterton's Fence: before removing anything, explain why it's there. If you can't, leave it and flag it.
Present the audit as a checklist and ask which items to address — "All items" first, marked (Recommended).
3. Apply — one item at a time
Per approved item: RED (failing test exposing the gap, when the item adds behavior coverage) → GREEN (minimal change) → run tests. Real values over mocks; mock only external I/O (call the Skill tool with tdd for its mocking guide). If red after the change, revert it and flag as blocked. Never batch.
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.
- 3d ago Changed · -6 tokens per session 0429daa8c430
- 15d ago First seen · 43 lines · 80 tokens per session scan A 16286148091e
refactor is a skill published in the GitHub repository helderberto/agent-skills (19 stars, last pushed today), licensed MIT. It adds 74 tokens to every session and 649 once invoked, about $0.0003 per session on Opus 5.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-10-12.
Other skills, from other repositories
test-driven-development
Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. Use when asked to add tests to a function, fix a bug…
browser-testing-with-devtools
Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be…
test-driven-development
Red-green-refactor cycle with meaningful coverage. Tests are written before implementation. Coverage is a side effect of good tests, not the goal.
integration-testing
Test real system boundaries, not mocks of mocks. Integration tests verify that components work together, not that they work in isolation.
constraint-driven-development
A development method for writing a project's quality standards as a lasting, checkable contract. It can cover areas such as test coverage, security, performance, accessibility, and architecture.
test-driven-development
Instructions for test-driven development, or TDD: writing a failing test first, then the smallest code that makes it pass, followed by cleanup.