القائمة
Remove accidental complexity without changing behavior — apply Chesterton's Fence
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
استنادا إلى تصنيف SOC المهني
| name | code-simplification |
| description | Remove accidental complexity without changing behavior — apply Chesterton's Fence |
| difficulty | senior |
| domains | ["general"] |
Every line of code is a liability. Complexity that serves no purpose makes systems harder to understand, harder to test, and harder to change. This skill removes accidental complexity while preserving intentional complexity and essential behavior.
/simplify workflowBefore removing any code that seems unnecessary: understand why it was written. If you don't know why a fence exists, don't remove it. Find out first.
Only remove accidental complexity. Essential complexity cannot be removed — only managed.
Dead code: Code that is never executed. Remove it (git remembers it).
Premature abstraction: Abstractions that are more complex than the thing they abstract. Inline them.
Unnecessary indirection: Function A calls function B which calls function C and each is 5 lines. Collapse them.
Redundant comments: Comments that say what the code already says. Delete them. Keep comments that explain WHY.
Magic numbers: Replace if (retries > 3) with if (retries > MAX_RETRIES).
Over-engineered error handling: 10 levels of nested try/catch for a case that can't happen. Simplify.
Duplicate logic: The same logic in 3 places. Extract to one place.
One simplification at a time. Run tests after each step.
The test suite must pass. If there are no tests, write tests for the behavior you're simplifying before you simplify it.
Have someone unfamiliar with this code read it. Is it easier to understand than before?
"Removing this might break something I don't know about" This is Chesterton's Fence. Understand it first. Then remove it.
"The abstraction makes it more extensible" If you are not extending it now, the abstraction is premature. Three identical lines are better than a wrong abstraction.