code-simplifier

Code Simplifier

Post-session cleanup pass. Reviews what changed, understands how it fits the existing codebase, and makes targeted improvements — modernizing syntax, removing unnecessary complexity, consolidating duplicated logic, catching efficiency issues. Prioritizes codebase cohesion over local perfection.

Core philosophy

Every change must earn its keep. A simplification that doesn't meaningfully improve clarity, correctness, or cohesion is noise. Don't refactor for refactoring's sake. Don't create new files, abstractions, or utilities unless they solve a demonstrated problem. If the existing code works and is readable, leave it alone. The goal is a cohesive codebase, not a pristine one.

Procedure

Phase 1: Identify changes

Run git status to see the shape of the working tree, then git diff HEAD for all uncommitted changes (staged and unstaged). Untracked files never appear in the diff — read new files directly. If the tree is clean, review the most recently modified files from the current session.

Phase 2: Understand the surrounding codebase

Don't review changes in isolation. Before any modifications:

1. Read the full files containing changes — not just the diff hunks. Understand imports, surrounding logic, module structure.
2. Identify the project language(s) and select the relevant transformation rules. Discard inapplicable rules.
3. Survey adjacent code — shared utilities, sibling modules, common patterns. You need to know what already exists before deciding something is missing. For mcp-ts-core projects, check src/utils/ for project utilities, src/errors/ for error handling, and node_modules/@cyanheads/mcp-ts-core/ for framework exports.

Phase 3: Review

Evaluate the changes across these dimensions. Not every dimension applies to every diff — skip what's irrelevant.

Codebase cohesion

• Reuse — Search for existing utilities, helpers, and patterns that could replace newly-written code. For mcp-ts-core projects, prefer import from '@cyanheads/mcp-ts-core/utils' over hand-rolled equivalents — pagination helpers, schema builders, retry primitives, and OTel attribute constants are framework-provided.
• Consolidation — Flag copy-paste-with-variation: near-duplicate code blocks that should be unified. Only unify if the shared abstraction is genuinely simpler than the duplicated code.
• Consistency — Check that new code follows the same patterns as the rest of the codebase: naming conventions, error handling style, import patterns, type annotation style. Normalize toward the better variant when the project is inconsistent.
• Stringly-typed code — Flag raw strings where constants, string-union types, branded types, or framework attribute constants already exist. For mcp-ts-core projects, the ATTR_* constants in @cyanheads/mcp-ts-core/utils should replace raw OTel attribute keys.