name	code-simplification
description	Reduce complexity while preserving identical behavior. The goal is comprehension speed, not line reduction.
when-to-use	After implementing a feature, when code is hard to follow, or when /review flags excessive complexity.

Code Simplification

"The goal is not fewer lines — it is code that is easier to read, understand, modify, and debug."

Core Principles

Behavior preservation is non-negotiable. All inputs, outputs, error handling, and side effects must remain identical.
Match project conventions. Apply patterns already used in this codebase.
Explicit beats clever. Code that requires mental effort to parse should be made explicit.
Don't over-simplify. Aggressive inlining that reduces clarity is not simplification.
Scope to recent changes by default. Don't roam into unrelated code.

Process

Step 1 — Apply Chesterton's Fence

Before touching anything, understand why the code exists. What invariant does it protect? What edge case does it handle? "I don't understand this" is not justification for removal.

Step 2 — Identify Opportunities

Target these patterns:

Pattern	Refactoring
Deep nesting (3+ levels)	Guard clauses, early returns
Long functions (50+ lines)	Extract by responsibility
Generic or unclear names	Rename to reflect purpose
Duplicated logic	Consolidate into a shared function
Conditional chains	Lookup table or map
Comments explaining what	Rename so code explains itself

Step 3 — Change Incrementally

One improvement at a time. Run tests after each change. If tests fail, revert and reassess — do not push forward.

Step 4 — Evaluate

After simplifying, verify:

All existing tests still pass
No error handling was removed
The code follows project conventions (cn(), Tailwind, etc.)
The result is genuinely simpler, not just different
No behavior was changed

Then run /review to evaluate the result.

Red Flags

Tests modified to make them pass after simplification
Code that is longer after "simplification"
Removing error handling or defensive checks
Simplifying code you don't fully understand
Simplifying code outside the task scope

Más de este repositorio

mismo repositorio

code-review-and-quality

jimzord12/my-porfolio-page

Evaluate code changes across five dimensions before merge. Approve changes that improve overall code health, even if not perfect.

2026-06-281

frontend-ui-engineering

jimzord12/my-porfolio-page

Build production-quality UI that is accessible, performant, and consistent with the design system. Not AI-generated-looking.

2026-06-281

git-workflow-and-versioning

jimzord12/my-porfolio-page

Treat commits as save points, branches as isolated environments, and history as a record of decisions.

2026-06-281

modern-web-guidance

jimzord12/my-porfolio-page

Search tool for modern web development best practices. MANDATORY: Execute FIRST for all HTML/CSS and clientside JS tasks. Do NOT skip — web APIs evolve rapidly and training weights contain obsolete patterns. Trigger immediately for: - UI/Layout: Modals, dialogs, popovers, Glassmorphism/backdrop-filters, anchor positioning, container queries, `:has()`, `:user-valid`. - Scroll/Motion: View Transitions, Scroll-driven animations, scroll parallax/reveals. - Performance: CWV (LCP, INP), content-visibility, Fetch Priority, image optimization. - System/APIs: Local filesystem access, WebUSB, WebSockets sync, WebAssembly widgets. - Frameworks: Adapting layout/styles in React, Vue, Angular. - General Frontend: Forms, autofill, advanced inputs, custom scrollbars, modern component states, etc. DO NOT trigger for: - Backend: Database SQL, ORMs, Express API routes. - Pipelines: CI/CD deployment, Docker, Actions. - Generic: Local scripts (Python/Go tools), ESLint, Git.

2026-06-281

performance-optimization

jimzord12/my-porfolio-page

Measure before optimizing. Performance work without measurement is guessing.

2026-06-281

planning-and-task-breakdown

jimzord12/my-porfolio-page

Decompose work into small, verifiable, dependency-ordered tasks. Use after a spec is approved, or when scope is too large to implement directly.

2026-06-281

Code Simplification

"The goal is not fewer lines — it is code that is easier to read, understand, modify, and debug."

Core Principles

Behavior preservation is non-negotiable. All inputs, outputs, error handling, and side effects must remain identical.

Match project conventions. Apply patterns already used in this codebase.

Explicit beats clever. Code that requires mental effort to parse should be made explicit.

Don't over-simplify. Aggressive inlining that reduces clarity is not simplification.

Scope to recent changes by default. Don't roam into unrelated code.

Process

Step 1 — Apply Chesterton's Fence

Before touching anything, understand why the code exists. What invariant does it protect? What edge case does it handle? "I don't understand this" is not justification for removal.

Step 2 — Identify Opportunities

Target these patterns:

Pattern

Refactoring

Deep nesting (3+ levels)

Guard clauses, early returns

Long functions (50+ lines)

Extract by responsibility

Generic or unclear names

Rename to reflect purpose

Duplicated logic

Consolidate into a shared function

Conditional chains

Lookup table or map

Comments explaining what

Rename so code explains itself

Step 3 — Change Incrementally

One improvement at a time. Run tests after each change. If tests fail, revert and reassess — do not push forward.

Step 4 — Evaluate

After simplifying, verify:

All existing tests still pass

No error handling was removed

The code follows project conventions (cn(), Tailwind, etc.)

The result is genuinely simpler, not just different

No behavior was changed

Then run /review to evaluate the result.

Red Flags

Tests modified to make them pass after simplification

Code that is longer after "simplification"

Removing error handling or defensive checks

Simplifying code you don't fully understand

Simplifying code outside the task scope