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/subinium/vibesubinnpx agentmods add skills/subinium/vibesubin/refactor-verifyWrote 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/subinium/vibesubin/refactor-verify)<a href="https://agentmods.dev/skills/subinium/vibesubin/refactor-verify"><img src="https://agentmods.dev/badge/skills/subinium/vibesubin/refactor-verify.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.00120 | $0.06691 |
| Opus 5 | $0.00060 | $0.03345 |
| Sonnet 5 | $0.00024 | $0.01338 |
| Haiku 4.5 | $0.00012 | $0.00669 |
Grade A, and why
refactor-verify 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 7d 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 — 416 lines — stays where its author put it; the contents beside it link to each section on GitHub.
refactor-verify
The operator asked for a change that's supposed to preserve behavior — a refactor, a rename, a split, an extract, a dead-code deletion. Your job is to prove that behavior was preserved, not just produce a diff that looks right.
Behavior-preserving changes are the single biggest source of silent regressions when an LLM touches code. The classic failure is: the AI moves a function, updates the definition, and misses one of several call sites. The tests still pass because coverage was never complete. No one notices until a user hits the broken path.
This skill exists to stop that from happening. It covers two change families:
- Structural refactors — move, rename, split, merge, extract, inline. The behavior is supposed to be identical afterward.
- Safe deletions — removing code the operator has confirmed is dead (usually via
fight-repo-rot). The behavior is supposed to be identical because the code wasn't running.
Both families use the same four verification checks.
The invariant
A change is not done until all four of these pass:
- Symbol-set diff — every public/exported name that existed before the refactor still exists after it (or was deliberately removed). No silent drops.
- AST body diff — every moved function/class body is structurally equivalent to its original, normalizing whitespace and comments.
- Behavioral verification — typecheck, lint, smoke test (can the code even load?), test suite. All green.
- Call-site closure — every reference to the moved symbol has been updated. The count of references before and after must match.
If any of the four fails, fix it and re-run all four. Do not partially claim success.
State assumptions — before acting
Before starting the procedure, write an explicit Assumptions block. Don't pick silently between interpretations; surface the choice. If any assumption is wrong or ambiguous, pause and ask — do not proceed on a guess.
Required block:
Assumptions:
- Change type: <move | rename | split | merge | extract | inline | delete>
- Scope files: <list of files in scope — everything else untouched>
- Baseline status: <green (tests + typecheck + lint pass) | red (report blocks before touching anything)>
- Delete confidence: <N/A | HIGH (auto-ok) | MEDIUM (operator confirms) | LOW (require explicit approval)>
What ships with it
7 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.
- 7d ago First seen · 416 lines · 120 tokens per session scan A d983cd9de2f0
refactor-verify is a skill published in the GitHub repository subinium/vibesubin (50 stars, last pushed 4mo ago), licensed MIT. It adds 120 tokens to every session and 6,691 once invoked, about $0.0006 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-30.
Other skills, from other repositories
impl-validator
Validate whether an implementation matches its stated goal. Use this skill when a skill or agent wants a second opinion on its own output, when the user says "check this implementation", "validate what you did", "is this correct?", "review the output", or "did you do this right?". Also spawned automatically as a…
improve-code-quality
Guided journey from a working-but-untested vibe-coded prototype to a production-ready product with tests, clean structure, a business-rules boundary, and resilience at scale. Orchestrates nine skills phase by phase - working-with-legacy-code, clean-code, refactoring-patterns, software-design-philosophy…
semgrep-rule-variant-creator
Creates language variants of existing Semgrep rules. Use when porting a Semgrep rule to specified target languages. Takes an existing rule and target languages as input, produces independent rule+test directories for each language.
refactor
Refactors code for quality and maintainability. Triggers: refactor, clean up, restructure, improve code, modernize.
prompt-caching-patterns
Anthropic API prompt caching: TTL, breakpoints, stacking, invalidation, hit rate. Triggers: prompt caching, cachecontrol, cache breakpoint, cache TTL, hit rate.
auto-test-code
A structured process for critically reviewing and testing software code. It records review findings, test plans, commands, results, and supporting files in a project workspace.