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 blakecyze/kanso --skill kanso-refactorgit clone --depth 1 https://github.com/blakecyze/kansoWrote 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/blakecyze/kanso/kanso-refactor)<a href="https://agentmods.dev/skills/blakecyze/kanso/kanso-refactor"><img src="https://agentmods.dev/badge/skills/blakecyze/kanso/kanso-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/blakecyze/kanso/kanso-refactor"><img src="https://agentmods.dev/badge/skills/blakecyze/kanso/kanso-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.00055 | $0.02370 |
| Opus 5 | $0.00028 | $0.01185 |
| Sonnet 5 | $0.00011 | $0.00474 |
| Haiku 4.5 | $0.00006 | $0.00237 |
Grade A, and why
kanso-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 8d 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 — 206 lines — stays where its author put it; the contents beside it link to each section on GitHub.
kanso-refactor
Behaviour-preserving cleanup. Removes dilution, tightens code, deletes cruft. Never changes behaviour. If a change would alter behaviour, the skill surfaces it as a question instead of making the change.
The principles from kanso-principles apply. The anti-dilution taxonomy is the primary target.
Always run inline
This skill runs in the calling chat — including when invoked as the follow-up to /kanso-audit. Never dispatch via the Agent or Task tool, never run as a subagent, never split work into a parallel runner whose output lands in a side window. Edits, summaries, and any clarifying questions all happen in the user's current transcript.
The hard rule
Refactoring must not alter behaviour. Behaviour changes must avoid refactoring.
Mixing the two obscures intent, breaks cherry-picking, and ruins git bisect. If a task requires both, do them in separate commits, each with a single purpose.
Before making any change, ask: would this change produce different outputs for any input the existing tests or usage patterns cover? If yes, it's not a refactor. Stop and ask the user.
Cases where the boundary is tested:
- Removing a defensive try/catch that swallowed errors silently → behaviour change. The caller now sees the error. Ask.
- Inlining a filler variable → refactor. Identical behaviour.
- Replacing a manual loop with
itertools.chain→ refactor only if the iterator semantics are identical. Double-check laziness. - Removing dead code that was unreachable → refactor.
- Removing dead code that was reachable but had no test coverage → behaviour change. Ask.
- Collapsing a premature abstraction → refactor if call sites are updated atomically. Verify.
- Renaming a variable → refactor if scope is local. If the name is exported, it's a behaviour change (API change). Ask.
When in doubt, treat it as a behaviour change and ask.
Resolve the scope
$ARGUMENTS is one of:
diff→ the working tree changes (default)- a path like
src/billing/invoice.ts→ that file or directory audit-report→ the user will paste or reference a prior/kanso-auditreport; act on its Tier 1 and Tier 2 refactor-category findingscurrent-file→ whatever file is in focus
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.
- 8d ago First seen · 206 lines · 55 tokens per session scan A d5591bcd72e1
kanso-refactor is a skill published in the GitHub repository blakecyze/kanso (3 stars, last pushed 5d ago), licensed MIT. It adds 55 tokens to every session and 2,370 once invoked, about $0.0003 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
code-reviewer
Code review knowledge base: quality, security (OWASP Top 10), error-handling, performance, and test-coverage checklists with severity-ranked output format. Use when reviewing code changes, PRs, or before commits. Loaded automatically by the code-reviewer agent.
review
Structured code review with parallel audit agents, confidence-scored triage, and optional auto-fix. Examines uncommitted changes, staged diffs, commit ranges, or specific paths. Produces a tiered report (MUST-FIX / RECOMMENDED / NIT) backed by evidence, then optionally applies fixes with verification.
db-audit
Database performance and safety audit. 70+ checks across 13 dimensions (DB1-DB13): query patterns, indexes, schema design, connections, transactions, migrations, caching, query optimization, ORM anti-patterns, observability, data lifecycle, DB security, and migration deployment safety. Code-level checks for all ORMs.…
mutation-test
Mutation testing with two engines. Uses the project's NATIVE mutation runner (StrykerJS / Infection / mutmut / PIT / cargo-mutants) when one is configured — installing it on explicit consent when it is not — for a reproducible, comparable score; and an LLM-guided engine for the mutation classes native mutators cannot…
write-tests
Write tests for existing production code. Processes ONE file at a time through a full pipeline: analyze, inventory (frozen BEFORE writing), write, executable coverage gate, verify, blind coverage audit, adversarial review, log. Uses CodeSift for discovery and analysis when available. Modes: [path] (specific target)…
code-audit
Batch audit of production files against CQ1-CQ40 quality gates and CAP1-CAP29 anti-patterns. Tiered output (A/B/C/D), critical gate enforcement, evidence-backed scoring, cross-file pattern analysis, and prioritized execution plan. Flags: zuvo:code-audit all | [path] | [file] | --deep | --quick | --services |…