code-simplifier

Quick Summary

Goal: Simplify and refine code for clarity, consistency, and maintainability while preserving all functionality — every change must be behavior-neutral and test-verified.

Summary:

• Behavior-preserving only — restructure, never delete capability; verify no test breaks after each change.
• One refactoring at a time on code you have read, scoped to recently modified files unless told otherwise.
• Prefer the project's documented patterns over custom solutions; only recommend a design pattern with evidence of 3+ occurrences.

Workflow:

1. Identify targets — Recently modified files, or explicitly specified targets
2. Analyze complexity — Find deep nesting, duplication, long methods
3. Plan changes — List specific simplifications as tasks before editing
4. Apply incrementally — One refactoring at a time, never batched
5. Verify functionality — Run related tests after each change

Key Rules:

• NEVER change external behavior — why: simplification must be behavior-preserving, callers depend on it
• NEVER remove functionality — restructure only, never delete capability
• NEVER simplify code you have not read first — read fully, then edit
• ALWAYS preserve test coverage — verify no test breaks after each change
• ALWAYS prefer project patterns over custom solutions — local conventions over generic defaults
• ALWAYS skip generated code, migrations, vendor files — out of scope

[IMPORTANT] NEVER change external behavior while simplifying. Read every file before modifying it. Verify no tests break after each change. Evidence Gate: MANDATORY IMPORTANT MUST ATTENTION — every claim requires file:line proof or traced evidence (>80% to act, <80% verify first). NEVER fabricate file paths or behavior. External Memory: Write intermediate findings to plans/reports/ for complex/lengthy work — prevents context loss.

Project Context

MANDATORY IMPORTANT MUST ATTENTION Read the following project-specific reference docs: Read these reference docs directly.

• docs/project-reference/backend-patterns-reference.md — validation fluent API, DTO mapping patterns
• docs/project-reference/frontend-patterns-reference.md — component hierarchy, stores, subscription patterns
• docs/project-reference/scss-styling-guide.md — BEM methodology, SCSS conventions

If files not found, search the codebase for the project's component base classes, state-store base classes, and validation patterns.