Code Slimming: Read-Only Refactor Opportunity Audit

Find behavior-preserving opportunities to make a codebase smaller, clearer, and less repetitive. This skill reports opportunities only. It does not edit code and does not write tests.

The goal is not fewer lines at any cost. The goal is lower maintenance burden with behavior, performance, readability, and validation made explicit.

When to use

• Finding opportunities to simplify a repository, package, module, or PR
• Finding behavior-preserving refactor opportunities without implementing them
• Auditing duplicated logic, classes, structs, helpers, types, schemas, handlers, or adapters
• Looking for safe centralization candidates before a cleanup/refactor PR
• Reviewing a bot or human cleanup PR that claims to reduce code size
• Ranking maintainability refactors by value, risk, and validation needs
• Handling duplicate code only when the main goal is smaller behavior-preserving structure, not general cleanliness or AI-slop detection

When NOT to use

• Bug-focused reviews, regressions, races, edge cases, or crashes - use code-review
• General cleanup, naming, comments, AI tells, dependency creep, overengineering, or duplicate-code-as-slop without an explicit slimming goal - use anti-slop
• Security vulnerabilities, secret scanning, auth flaws, or exploitability - use security-audit
• Writing, debugging, or adding validation tests for a slimming recommendation - use testing
• Broad quick merge checks - use full-review
• Comprehensive repo audits across all applicable dimensions - use deep-audit
• Direct implementation work - use the relevant language, framework, or domain skill

Routing boundaries

Do not activate this skill for generic review, cleanup, or audit wording unless the user explicitly asks for slimming, deduplication, deletion, wrapper removal, or behavior-preserving size reduction.

AI Self-Check

Before returning a code-slimming audit, verify:

• Read-only boundary held: no source files were edited and no tests were written
• Behavior preserved: every recommendation names the behavior that must stay identical
• Value explained: every recommendation states why the slimmer shape is better
• Tradeoffs assessed: performance, coupling, readability, bundle size, allocation count, and test brittleness were considered where relevant
• Validation named: each Do now or Do with tests item lists concrete validation commands or test coverage needs
• No abstraction theater: no vague "make this generic" or "create a base class" advice without the proposed shape
• Duplication judged in context: likely divergence, framework conventions, and explicitness were considered before recommending centralization
• Correctness and security routed: bugs go to code-review; vulnerabilities go to security-audit
• Routing lane held: generic cleanup, slop, correctness, security, test-writing, broad-review, and implementation work were routed instead of reported as code-slimming findings
• Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• Routing overlap checked: recommendations do not duplicate anti-slop, code-review, testing, full-review, or deep-audit responsibilities
• Spec claims verified: any statement about skill behavior, output contracts, or repo conventions is checked against current skill files and scripts

Performance

• Start with changed files, shared modules, and repeated directory shapes before scanning the whole repo.
• Group repeated examples into one finding with representative paths.
• Prefer cheap structural searches before expensive test suites.

Best Practices

• Treat smaller code as a hypothesis, not a win.
• Prefer deleting wrappers over adding a new abstraction layer only after proving the wrapper has no boundary, policy, observability, compatibility, or lifecycle role.
• Prefer a small well-named helper over a framework-shaped base class.
• Keep domain-specific duplication when the variants are likely to diverge.
• Keep defensive duplication when checks intentionally repeat across trust boundaries, process boundaries, public APIs, persistence layers, or privileged operations. Do not remove a repeated guard just because an upstream layer appears to validate the same condition.
• Avoid centralizing across independently versioned modules, separately owned teams, protocol or API versions, tenant-specific behavior, or plugin/provider boundaries unless the shared contract is explicit and stable.
• Recommend tests before centralization when behavior differences are subtle or undercovered.

Workflow

Step 1: Determine scope

Pick the narrowest useful scope:

• PR or diff - default when uncommitted changes or a branch diff exists
• Specific path - use when the user names files or directories
• Whole repo - use when the user asks for a repo-wide slimming audit

For git repos, gather cheap preflight context before deciding:

• repo root and branch: git rev-parse --show-toplevel, git branch --show-current
• uncommitted files: git diff --name-only, git diff --cached --name-only
• branch base when available: git merge-base HEAD @{upstream}; otherwise detect the default branch and use git merge-base HEAD origin/<default-branch>
• default branch when needed: git symbolic-ref refs/remotes/origin/HEAD --short 2>/dev/null or inspect git remote show origin
• changed files and size: git diff --name-only <base>...HEAD, git diff --stat <base>...HEAD

Scope precedence:

1. User-provided diff or path
2. Uncommitted changes
3. Current branch against upstream
4. Current branch against the default branch
5. Whole repo, or ask one concise question when interactive

If the scope is unclear and no diff exists, ask one concise question. In headless contexts, default to whole repo and state the assumption.

Step 2: Gather context

Read project instructions and manifests before judging code shape:

• instruction files: AGENTS.md, CLAUDE.md, GEMINI.md, .cursor/rules, .windsurfrules
• manifests: package.json, pyproject.toml, go.mod, Cargo.toml, pom.xml, build.gradle, CMakeLists.txt, Makefile
• test and check scripts
• existing shared modules, helper directories, framework conventions, and recent related commits

Note the language and framework patterns in the report header. A good centralization in Python may be a bad abstraction in Rust, Java, or C.

Step 3: Identify validation without over-running it

Running existing read-only validation commands is allowed unless the user forbids command execution or the commands have side effects. Separate validation into three passes:

1. Early baseline validation - cheap checks that describe current repo or diff health:
   • lint or format checks when fast and obvious
   • type or compile checks when fast and local
   • documente