fuck-over-engineering
Skill142 starsChanged 22 days agoMITView on GitHub
Use when the user asks what could be deleted or reduced to simplify a codebase, says "simplify", "over-engineered", or wants a repo-, folder-, or file-wide audit for over-engineering — hunts dead code, reinvented stdlib, needless dependencies, and single-implementation abstractions, reports ranked cuts, applies only the picks. Not a diff review and not a bug hunt
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- publish-pluginsSkill
- upgrade-playbooksSkill
- audit-agent-settingsSkill
- best-practicesSkill
- blindspotSkill
- commitSkill
- differenceSkill
- prSkill
- refactor-agents-mdSkill
- refactor-memorySkill
- refactor-skillSkill
- simple-englishSkill
- write-like-meSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 32
Use AskUserQuestion in Claude Code or request_user_input in Codex when available.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Fuck Over-Engineering
Audit the scope for over-engineering and report what to cut, ranked biggest cut first. The best outcome is a shorter codebase with the same behavior. The argument is the scope; without one, the whole tree. Read what the scope holds before judging it, and fan out subagents when it will not fit in context.
Tags
delete:dead code, unused flexibility, speculative feature. Nothing replaces it.reuse:hand-written code that a helper already in this codebase, or an installed dependency, already provides. Name the helper or function.stdlib:hand-rolled thing the language's standard library ships. Name the function.native:dependency or code doing what the platform already does. Name the feature.yagni:abstraction with one implementation, config nobody sets, layer with one caller.shrink:same logic, fewer lines. Show the shorter form.
Hunt
Dependencies the stdlib or platform already covers, single-implementation interfaces, factories with one product, wrappers that only delegate, files exporting one thing, dead flags and config, hand-rolled stdlib, near-duplicates of an existing helper, special-case branches bolted onto shared paths, feature logic living in shared modules.
Evidence
Every finding cites the evidence that makes it a cut: caller count, implementation count, or the stdlib or platform feature and the version that ships it. Count callers through dynamic dispatch, entry points, hooks, and tests, not grep alone. A published package's public export stays at zero in-repo callers. Verify stdlib: and native: claims against current docs (the find-docs skill when present) before asserting them.
A finding removes lines or concepts; moving them between files is a refactor, not a cut. Fewer, bigger cuts beat a long list: a shrink: that saves two lines earns a slot only when it also removes a concept.
Output
Use AskUserQuestion in Claude Code or request_user_input in Codex when available. Use plain text when neither tool is available.
One line per finding, numbered, ranked biggest cut first:
N. <tag> <what to cut>. <replacement>. <evidence>. [path:line]
delete: omits the replacement sentence. End with net: -<N> lines, -<M> deps possible. Nothing to cut: Lean already. Ship.
1. yagni: AbstractRepository with one implementation. Inline it. 1 subclass, 3 call sites typed to the base. [repo.py:88]2. reuse: hand-rolled slugify. python-slugify is installed, slugify(). 1 caller. [utils/text.py:10-31]3. delete: retry wrapper around an idempotent local call. 0 callers outside its own test. [src/net.py:52-71]
Then offer the findings in ranked batches, collect the user's picks, and apply them.
Boundaries
Over-engineering and complexity only: correctness bugs, security holes, and performance belong to a normal review pass. Trust-boundary validation, data-loss handling, security, and accessibility are never cuts. A single smoke test or assert-based self-check is the minimum, not bloat. Tests enter the report only as a side effect of a deleted target.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

