103 lines
3.0 KiB
Markdown
103 lines
3.0 KiB
Markdown
---
|
|
name: simplify-code
|
|
description: Systematic code simplification using proven refactoring patterns. Apply incrementally with tests at each step.
|
|
---
|
|
|
|
# Simplify Code
|
|
|
|
Lean-mode simplification contract optimized for low token usage.
|
|
Detailed pattern catalog and examples are in [APPENDIX.md](./APPENDIX.md).
|
|
|
|
## Execution Workflow
|
|
|
|
### 1. Setup
|
|
- Detect build and test commands from project files.
|
|
- If missing, ask user once and store commands.
|
|
- Build candidate file list from git-visible files only:
|
|
- prefer `git ls-files` for tracked + unignored files
|
|
- include untracked-but-unignored files when relevant (`git ls-files --others --exclude-standard`)
|
|
- NEVER simplify files ignored by `.gitignore` (or `.git/info/exclude` / global gitignore)
|
|
- if workspace is not a git repo, ask user for include paths before modifying files
|
|
|
|
### 2. Baseline Validation
|
|
- Run build; if failing, STOP.
|
|
- Run tests; if failing, STOP.
|
|
|
|
### 3. Prepare Tooling
|
|
- Detect and run formatter/linter appropriate for the language.
|
|
- Keep edits style-compliant before simplification passes.
|
|
|
|
### 4. Simplification Passes
|
|
- Prioritize largest or most complex files first (within the git-visible candidate list).
|
|
- Apply one refactoring pattern at a time.
|
|
- Keep behavior unchanged.
|
|
|
|
### 5. Verify
|
|
- Re-run build and tests after each pass or grouped pass.
|
|
- If failures appear, go to failure handling.
|
|
|
|
### 6. Failure Handling
|
|
- Generate `simplification-report.md` with:
|
|
- files touched
|
|
- patterns applied
|
|
- failures and diagnostics
|
|
- rollback guidance
|
|
|
|
## Detection Triggers
|
|
|
|
Target code that shows one or more of:
|
|
- long methods / large classes
|
|
- nested or complex conditionals
|
|
- duplicate logic
|
|
- magic numbers
|
|
- ambiguous naming
|
|
- long parameter lists
|
|
- dead code / commented code
|
|
- impure stateful helpers
|
|
|
|
## Core Patterns
|
|
|
|
Apply these patterns first:
|
|
1. Extract Method
|
|
2. Guard Clauses
|
|
3. Decompose Conditional
|
|
4. Replace Magic Number with Constant
|
|
5. Rename for clarity
|
|
6. Remove dead/commented code
|
|
7. Introduce parameter object when argument lists are large
|
|
|
|
Prefer pure functions and immutability where idiomatic for the language.
|
|
|
|
## Constraints
|
|
|
|
- Avoid large-bang refactors.
|
|
- Keep each change small and reversible.
|
|
- Do not change public behavior unless explicitly requested.
|
|
- Do not introduce speculative abstractions.
|
|
- Do not read, modify, or propose edits for files ignored by git ignore rules.
|
|
|
|
## Metrics (Targets)
|
|
|
|
- Cyclomatic complexity `< 10`
|
|
- Method length `< 30` lines
|
|
- Nesting depth `< 4`
|
|
- Parameter count `< 4`
|
|
- Class length `< 300` lines
|
|
|
|
## Language Notes
|
|
|
|
- Use ecosystem formatters/linters (Prettier/ESLint, Black/isort, gofmt, etc.).
|
|
- Follow project-native naming conventions.
|
|
- Prefer readability over cleverness.
|
|
|
|
## Quick Mapping
|
|
|
|
- Long method → Extract Method
|
|
- Nested conditionals → Guard Clauses + Decompose Conditional
|
|
- Duplicate code → Extract shared helper
|
|
- Magic numbers → Named constants
|
|
- Dead code → Remove
|
|
|
|
## Reference
|
|
|
|
For expanded examples and anti-pattern details, see [APPENDIX.md](./APPENDIX.md). |