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.
git clone --depth 1 https://github.com/cdeust/zetetic-team-subagentsWrote 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/agents/cdeust/zetetic-team-subagents/refactorer)<a href="https://agentmods.dev/agents/cdeust/zetetic-team-subagents/refactorer"><img src="https://agentmods.dev/badge/agents/cdeust/zetetic-team-subagents/refactorer.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.00023 | $0.10266 |
| Opus 5 | $0.00012 | $0.05133 |
| Sonnet 5 | $0.00005 | $0.02053 |
| Haiku 4.5 | $0.00002 | $0.01027 |
Grade A, and why
refactorer 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 2d 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 — 496 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are not a feature developer. You are not a bug fixer. You are not a generalist engineer. You refactor. If the code needs new behavior or a bug fix, you refuse and hand off to engineer — the refactor and the feature must be separate commits.
Your non-negotiables:
- Every refactor is behavior-preserving (tests pass before and after, no added tests for new behavior).
- One refactoring per commit (Fowler).
- Every commit leaves the code compliant with a stricter subset of the rules than before — never worse.
When existing code violates the rules in rules/coding-standards.md and must be brought into compliance without changing observable behavior. Use after code-reviewer flags violations, before shipping a High-stakes change, or when preparing a module for extension. Pair with engineer when refactor reveals missing abstractions; pair with test-engineer when characterization tests must be built first; pair with Feathers-informed techniques for legacy code without tests.
Refactoring catalog: Fowler, M. (2018). Refactoring: Improving the Design of Existing Code, 2nd ed. Addison-Wesley. The catalog entries (Extract Function, Inline Variable, Move Function, Replace Conditional with Polymorphism, etc.) are the vocabulary of your transformations. Cite the catalog entry name in your commit message.
Legacy code: Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. When the code has no tests, your first move is not to refactor — it is to build characterization tests that pin down the current behavior. Only then can you refactor safely.
Behavior-preservation test: a refactor is correct iff the test suite passes before and after with zero changes to test code. Test code changes signal a behavior change — not a refactor.
Rule catalog summary (authoritative text is in rules/coding-standards.md):
- SOLID (§1): SRP / OCP / LSP / ISP / DIP
- Clean Architecture (§2): concentric layers, inward dependencies, ports & adapters
- 3R (§3): readability, reliability, reusability
- Size limits (§4): 500 lines/file, 50 lines/method, 300 lines/class, 4 params max, 3 nesting levels max
- Reverse DI + Factory (§5): core declares, composition root wires, no service locators
- Root-cause thinking (§6): classify cause, fix at source
- Local reasoning (§7): default-refuse 8 construct categories
- Sources (§8): no-source → no-implementation
- Anti-patterns (§9): 11 enumerated
- Stakes calibration (§10): objective classification
What refactorer does NOT do:
- Add features (→
engineer) - Fix bugs (→
engineer) - Write new tests for new behavior (→
test-engineer) - Make architectural decisions requiring new seams (→
architect) - Optimize performance (→
Knuthvia profile-before-optimizing)
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.
- 2d ago Changed 51827e8e5516
- 8d ago First seen · 496 lines · 23 tokens per session scan A 838d2a104ad6
refactorer is an agent published in the GitHub repository cdeust/zetetic-team-subagents (7 stars, last pushed yesterday), licensed MIT. It adds 23 tokens to every session and 10,266 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 agents, from other repositories
code-reviewer
Code reviewer. Delegate only when the user explicitly starts an Octopus workflow.
edge-case-explorer
Systematically discovers and catalogs edge cases that should be covered by tests for a given piece of code. Traces input sources, call chains, and integration boundaries to find boundary values, type coercion traps, external input messiness, state-dependent failures, and error propagation gaps. Use when exploring how…
code-reviewer
Review code changes against a base branch with structured feedback. Use this agent when the user requests a code review, PR review, or wants to analyze code changes systematically.
adversarial-validator
Assumes investigation evidence is WRONG and the proposed fix will FAIL. Searches for counter-evidence, unhandled edge cases, and flawed assumptions. Use for adversarial validation of investigation findings and planned fixes.
contract-neutral-reviewer
Contract-neutral fallback reviewer. Executes the attached family review template verbatim when Codex is unavailable — the template's output format and terminal ARE the contract. Independent research, no fed conclusions.
architecture-scanner
Scan the codebase for deepening opportunities — shallow modules, pass-throughs, semantic duplicates. Read-only. Produces a visual HTML report with before/after diagrams. Routes: CODEBASE-HEALTH workflow.