SuperAPI AI Directory

same-results-less-code

General & other

View repository

Updated 10-16 09:51

About this skill

Community Refactoring Best Practices: Same Results, Less Code

Code-review and refactoring guide focused on the parts of code volume that come from judgment and modelling gaps — wrong abstraction choices, hidden semantic duplication, defensive habits, premature generality. This skill deliberately skips what linters and tools like knip, eslint, ruff, tsc --noUnusedLocals, or formatters already catch. It is the second pass: after the mechanical cleanup, what remains?

Core Principles

  1. Preserve behaviour. Every transformation must produce identical observable behaviour — same outputs, same errors, same side effects, same API surface.
  2. Earlier mistakes cascade. A wrong frame multiplies into wrong shapes, which multiply into duplicate logic. Optimise from the top of the lifecycle.
  3. Explain why, not just what. Each rule explains the cost of the anti-pattern so judgment can transfer to novel cases.
  4. Quantify where possible. Prefer "eliminates N lines / prevents X bug class" over "cleaner."
  5. Don't over-refactor. Rule of three: extract abstractions when duplication has actually appeared three times, not in anticipation.

When to Apply

Use this skill when:

  • Reviewing a PR for "could this be simpler?" (the question linters can't answer)
  • Refactoring code that has grown in volume without growing in capability
  • Auditing a module that "feels heavy" — many flags, many layers, many checks
  • Onboarding to an unfamiliar codebase and trying to spot the parts that are accidental volume vs essential complexity
  • Designing a new module and wanting to avoid the common over-abstraction traps
  • Working alongside knip / eslint / ruff and wanting the layer of judgment those tools can't supply

Don't use this skill for:

  • Mechanical cleanup that a linter or formatter already does (unused imports, dead exports, style) — use knip, eslint, ruff, or prettier/black instead.
  • Algorithmic complexity / performance tuning — use complexity-optimizer for that.
  • General cleanup of recently modified code regardless of mental-model gaps — use code-simplifier.

Rule Categories by Priority

# Category Prefix Impact Rules Gist
1 Reinvention reinvent- CRITICAL 5 You wrote what the platform/stdlib already provides
2 Wrong Frame frame- CRITICAL 5 Wrong abstraction shape — class where a function fits, manager nouns, OO over data
3 Hidden Duplication dup- HIGH 5 Semantic copies hiding behind syntactic differences
4 Derived State Stored derive- HIGH 5 Storing what should be computed
5 Procedural Rebuilds proc- MEDIUM-HIGH 5 Imperative reimplementation of declarative concepts
6 Speculative Generality spec- MEDIUM 5 Generality built for a second user who never arrived
7 Defensive Excess defense- MEDIUM 4 Checks for states the type/flow already rules out
8 Type System Underuse types- LOW-MEDIUM 6 Runtime guards that should be types

Quick Reference

1. Reinvention (CRITICAL)

2. Wrong Frame (CRITICAL)

3. Hidden Duplication (HIGH)

4. Derived State Stored (HIGH)

5. Procedural Rebuilds (MEDIUM-HIGH)

6. Speculative Generality (MEDIUM)

7. Defensive Excess (MEDIUM)

8. Type System Underuse (LOW-MEDIUM)

How to Apply (Workflow)

When asked to review or refactor code with this skill:

  1. Run the mechanical pass first. knip/eslint/ruff/tsc --noUnusedLocals will catch dead code, unused imports, style. Don't duplicate that work here.
  2. Read the file or PR for intent. Ask: what is this code trying to do? The judgment skill is recognising when the implementation overshoots the intent.
  3. Walk the categories in priority order.
  4. Propose minimal-diff transformations. Each rule shows incorrect → correct as a tight diff; preserve that property in suggestions.
  5. Verify behaviour. Outputs, errors, and side effects must be identical. Tests must still pass.
  6. Don't bundle unrelated changes. Each transformation should map to one category. Mixing them makes the change hard to review.

When NOT to Apply

  • Code is younger than the rule of three (one or two duplicates) — extracting is premature.
  • The pattern is genuinely a known exception (see each rule's "When NOT to use this pattern" section).
  • The refactor would be a large, risky rewrite without a clear test safety net — propose, don't execute.
  • Performance-critical hot paths where the "simpler" form has measurable cost — measure first.

Reference Files

File Description
references/_sections.md Category definitions and ordering
assets/templates/_template.md Template for new rules
metadata.json Version and reference information

Related Skills

  • code-simplifier — Mechanical simplification (naming, dead code, nesting). Complementary first pass.
  • complexity-optimizer — Algorithmic/performance complexity. Different axis.
  • refactor — General-purpose refactoring workflow.
  • clean-code — Broader clean-code principles. This skill is the narrower, judgment-focused subset.