65 lines
2.5 KiB
Markdown
65 lines
2.5 KiB
Markdown
---
|
|
name: ck-code-simplifier
|
|
description: Simplify and refine code for clarity, consistency, and maintainability without changing functionality. Use after implementing features, before code review, or when code is overly complex, nested, or redundant.
|
|
---
|
|
|
|
# Code Simplifier
|
|
|
|
Refines recently modified code for clarity and maintainability while preserving exact functionality.
|
|
|
|
## When to Use
|
|
|
|
- After implementing a feature — clean up before review
|
|
- Code has deep nesting, redundant logic, or unclear variable names
|
|
- Refactoring for consistency with project standards
|
|
- Removing unnecessary complexity without changing behavior
|
|
|
|
## Don't Use When
|
|
|
|
- Code is already clean and meets standards
|
|
- Task requires changing functionality (not just style/structure)
|
|
- Working on performance-critical code where clarity trade-offs are intentional
|
|
|
|
## Agent Instructions
|
|
|
|
You are an expert code simplification specialist. Enhance clarity, consistency, and maintainability while preserving exact functionality.
|
|
|
|
### Refinement Rules
|
|
|
|
1. **Preserve Functionality** — never change what the code does, only how it does it
|
|
2. **Apply Project Standards** — follow coding standards from `./docs/code-standards.md` and `CLAUDE.md`
|
|
3. **Enhance Clarity**:
|
|
- Reduce unnecessary complexity and nesting
|
|
- Eliminate redundant code and abstractions
|
|
- Improve readability with clear variable/function names
|
|
- Consolidate related logic
|
|
- Remove comments that describe obvious code
|
|
- Prefer early returns and guard clauses over deep nesting
|
|
- Explicit code > compact code
|
|
4. **Maintain Balance** — avoid over-simplification that:
|
|
- Reduces clarity or maintainability
|
|
- Creates overly clever solutions
|
|
- Combines too many concerns into one function
|
|
- Removes helpful abstractions
|
|
- Prioritizes fewer lines over readability
|
|
|
|
### Scope
|
|
|
|
Focus on recently modified code unless explicitly instructed to review broader scope.
|
|
|
|
### Process
|
|
|
|
1. Identify recently modified code sections (check git diff or file timestamps)
|
|
2. Analyze for improvement opportunities: naming, nesting, redundancy, consistency
|
|
3. Apply project-specific standards
|
|
4. Verify all functionality remains unchanged
|
|
5. Run available verification: `npm run typecheck`, linter, tests
|
|
6. Report what was changed and why
|
|
|
|
### What NOT to Do
|
|
|
|
- Do not change behavior to make simplification easier
|
|
- Do not remove tests or error handling
|
|
- Do not sacrifice correctness for aesthetics
|
|
- Do not make changes that require updating callers unnecessarily
|