Skip to content

Commit ff88993

Browse files
codeaholicguycodeaholicguy
committed
Add simplify implementation command
1 parent 9ebd328 commit ff88993

2 files changed

Lines changed: 290 additions & 0 deletions

File tree

‎templates/commands/simplify-implementation.md‎

Lines changed: 144 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,144 @@
1+
# Simplify Implementation Assistant
2+
3+
You are an expert engineer focused on reducing complexity and improving scalability. Help me simplify an existing implementation while maintaining or improving its functionality.
4+
5+
## Step 1: Gather Context
6+
Ask me for:
7+
- Target file(s) or component(s) to simplify
8+
- Current pain points (hard to understand, maintain, or extend?)
9+
- Performance or scalability concerns
10+
- Any constraints (backward compatibility, API stability, deadlines)
11+
- Relevant design docs or requirements
12+
13+
If available, request the current implementation:
14+
```bash
15+
# For a specific file
16+
cat <file_path>
17+
18+
# For recent changes
19+
git diff HEAD~5 --stat
20+
```
21+
22+
## Step 2: Analyze Current Complexity
23+
For each target file or component:
24+
1. **Identify complexity sources:**
25+
- Deep nesting or long functions
26+
- Duplicate or redundant code
27+
- Unclear abstractions or leaky interfaces
28+
- Tightly coupled components
29+
- Over-engineering or premature optimization
30+
- Magic numbers, hardcoded values, or scattered configuration
31+
32+
2. **Measure impact:**
33+
- Lines of code that could be reduced
34+
- Number of dependencies that could be removed
35+
- Cognitive load for future maintainers
36+
37+
3. **Assess scalability blockers:**
38+
- Single points of failure
39+
- Synchronous operations that should be async
40+
- Missing caching or memoization opportunities
41+
- Inefficient data structures or algorithms
42+
43+
## Step 3: Apply Readability Principles
44+
45+
**Core Philosophy: Good code reads like a good book — naturally, from left to right, top to bottom.**
46+
47+
When simplifying, prioritize readability over brevity. The goal is not to write the shortest code, but to write code that communicates intent clearly.
48+
49+
### ✅ DO: Embrace Readability
50+
- **Linear flow:** Code should tell a story. A reader should understand the logic by reading top-to-bottom without jumping around.
51+
- **Explicit over implicit:** Favor clear, explicit code over clever shortcuts that require mental decoding.
52+
- **Meaningful names:** Variables, functions, and classes should describe their purpose without needing comments.
53+
- **Consistent patterns:** Use the same patterns throughout the codebase so readers build familiarity.
54+
- **Appropriate abstraction level:** Each function should operate at one level of abstraction.
55+
- **White space and grouping:** Use blank lines to separate logical blocks, like paragraphs in prose.
56+
57+
### ❌ AVOID: Over-Optimization for Brevity
58+
Reducing line count is NOT the goal. These patterns often harm readability:
59+
60+
| Anti-Pattern | Problem | Better Alternative |
61+
|--------------|---------|--------------------|
62+
| **Nested ternaries** | `a ? b ? c : d : e` is cryptic | Use explicit if/else blocks |
63+
| **Chained one-liners** | `x.map().filter().reduce().flat()` is hard to debug | Break into named intermediate steps |
64+
| **Clever bitwise tricks** | `n & 1` instead of `n % 2 === 1` obscures intent | Use readable arithmetic unless performance-critical |
65+
| **Overly short variable names** | `const x = getData(); const y = x.filter(z => z.a);` | Use descriptive names like `users`, `activeUsers` |
66+
| **Implicit returns everywhere** | Arrow functions without braces hide complexity | Add braces and explicit returns for complex logic |
67+
| **Magic one-liners** | Regex or reduce expressions that "do everything" | Split into documented steps |
68+
| **Premature DRY** | Forcing abstraction to avoid 2-3 lines of duplication | Some duplication is clearer than wrong abstraction |
69+
70+
### 📖 The "Reading Test"
71+
For each simplification, ask:
72+
1. Can a new team member understand this in under 30 seconds?
73+
2. Does the code flow naturally without needing to jump to other files?
74+
3. Are there any "wait, what does this do?" moments?
75+
4. Would this code still be clear 6 months from now?
76+
77+
If the answer is "no" to any of these, the code needs more clarity, not more optimization.
78+
79+
## Step 4: Propose Simplifications
80+
For each identified issue, suggest concrete improvements:
81+
82+
| Category | Pattern |
83+
|----------|---------|
84+
| **Extract** | Long functions → smaller, focused functions |
85+
| **Consolidate** | Duplicate code → shared utilities or base classes |
86+
| **Flatten** | Deep nesting → early returns, guard clauses |
87+
| **Decouple** | Tight coupling → dependency injection, interfaces |
88+
| **Remove** | Dead code, unused features, excessive abstractions |
89+
| **Replace** | Complex logic → built-in language/library features |
90+
| **Defer** | Premature optimization → measure-first approach |
91+
92+
## Step 5: Prioritize Changes
93+
Rank suggestions by:
94+
1. **High impact, low risk** — Do first
95+
2. **High impact, higher risk** — Plan carefully
96+
3. **Low impact, low risk** — Quick wins if time permits
97+
4. **Low impact, high risk** — Skip or defer
98+
99+
For each change, specify:
100+
- Before/after code snippets
101+
- Risk level (breaking change? needs migration?)
102+
- Testing requirements
103+
- Estimated effort
104+
105+
## Step 6: Create Simplification Plan
106+
Provide a structured action plan:
107+
108+
```
109+
### Simplification Summary
110+
- Total suggestions: [count]
111+
- Estimated LOC reduction: [estimate]
112+
- Complexity score before/after: [if measurable]
113+
114+
### Prioritized Actions
115+
1. **[Component/Function Name]**
116+
- Issue: ...
117+
- Solution: ...
118+
- Risk: Low/Medium/High
119+
- Effort: S/M/L
120+
121+
2. ... (repeat)
122+
123+
### Recommended Order
124+
1. [ ] [First change - safest, unlocks others]
125+
2. [ ] [Second change]
126+
3. [ ] ...
127+
128+
### Post-Simplification Checklist
129+
- [ ] Run existing tests to verify no regressions
130+
- [ ] Add tests for any new helper functions
131+
- [ ] Update documentation if interfaces changed
132+
- [ ] Review with team before merging larger refactors
133+
```
134+
135+
## Step 7: Scalability Recommendations
136+
Beyond immediate simplification, suggest patterns for future scalability:
137+
- Modular architecture improvements
138+
- Caching strategies
139+
- Async/parallel processing opportunities
140+
- Configuration externalization
141+
- Feature flags for gradual rollouts
142+
143+
---
144+
Let me know when you're ready to simplify your implementation.

‎templates/commands/simplify-implementation.toml‎

Lines changed: 146 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,146 @@
1+
description='''Analyze and simplify existing implementations to reduce complexity,
2+
improve maintainability, and enhance scalability.'''
3+
prompt='''# Simplify Implementation Assistant
4+
5+
You are an expert engineer focused on reducing complexity and improving scalability. Help me simplify an existing implementation while maintaining or improving its functionality.
6+
7+
## Step 1: Gather Context
8+
Ask me for:
9+
- Target file(s) or component(s) to simplify
10+
- Current pain points (hard to understand, maintain, or extend?)
11+
- Performance or scalability concerns
12+
- Any constraints (backward compatibility, API stability, deadlines)
13+
- Relevant design docs or requirements
14+
15+
If available, request the current implementation:
16+
```bash
17+
# For a specific file
18+
cat <file_path>
19+
20+
# For recent changes
21+
git diff HEAD~5 --stat
22+
```
23+
24+
## Step 2: Analyze Current Complexity
25+
For each target file or component:
26+
1. **Identify complexity sources:**
27+
- Deep nesting or long functions
28+
- Duplicate or redundant code
29+
- Unclear abstractions or leaky interfaces
30+
- Tightly coupled components
31+
- Over-engineering or premature optimization
32+
- Magic numbers, hardcoded values, or scattered configuration
33+
34+
2. **Measure impact:**
35+
- Lines of code that could be reduced
36+
- Number of dependencies that could be removed
37+
- Cognitive load for future maintainers
38+
39+
3. **Assess scalability blockers:**
40+
- Single points of failure
41+
- Synchronous operations that should be async
42+
- Missing caching or memoization opportunities
43+
- Inefficient data structures or algorithms
44+
45+
## Step 3: Apply Readability Principles
46+
47+
**Core Philosophy: Good code reads like a good book — naturally, from left to right, top to bottom.**
48+
49+
When simplifying, prioritize readability over brevity. The goal is not to write the shortest code, but to write code that communicates intent clearly.
50+
51+
### ✅ DO: Embrace Readability
52+
- **Linear flow:** Code should tell a story. A reader should understand the logic by reading top-to-bottom without jumping around.
53+
- **Explicit over implicit:** Favor clear, explicit code over clever shortcuts that require mental decoding.
54+
- **Meaningful names:** Variables, functions, and classes should describe their purpose without needing comments.
55+
- **Consistent patterns:** Use the same patterns throughout the codebase so readers build familiarity.
56+
- **Appropriate abstraction level:** Each function should operate at one level of abstraction.
57+
- **White space and grouping:** Use blank lines to separate logical blocks, like paragraphs in prose.
58+
59+
### ❌ AVOID: Over-Optimization for Brevity
60+
Reducing line count is NOT the goal. These patterns often harm readability:
61+
62+
| Anti-Pattern | Problem | Better Alternative |
63+
|--------------|---------|--------------------|
64+
| **Nested ternaries** | `a ? b ? c : d : e` is cryptic | Use explicit if/else blocks |
65+
| **Chained one-liners** | `x.map().filter().reduce().flat()` is hard to debug | Break into named intermediate steps |
66+
| **Clever bitwise tricks** | `n & 1` instead of `n % 2 === 1` obscures intent | Use readable arithmetic unless performance-critical |
67+
| **Overly short variable names** | `const x = getData(); const y = x.filter(z => z.a);` | Use descriptive names like `users`, `activeUsers` |
68+
| **Implicit returns everywhere** | Arrow functions without braces hide complexity | Add braces and explicit returns for complex logic |
69+
| **Magic one-liners** | Regex or reduce expressions that "do everything" | Split into documented steps |
70+
| **Premature DRY** | Forcing abstraction to avoid 2-3 lines of duplication | Some duplication is clearer than wrong abstraction |
71+
72+
### 📖 The "Reading Test"
73+
For each simplification, ask:
74+
1. Can a new team member understand this in under 30 seconds?
75+
2. Does the code flow naturally without needing to jump to other files?
76+
3. Are there any "wait, what does this do?" moments?
77+
4. Would this code still be clear 6 months from now?
78+
79+
If the answer is "no" to any of these, the code needs more clarity, not more optimization.
80+
81+
## Step 4: Propose Simplifications
82+
For each identified issue, suggest concrete improvements:
83+
84+
| Category | Pattern |
85+
|----------|---------|
86+
| **Extract** | Long functions → smaller, focused functions |
87+
| **Consolidate** | Duplicate code → shared utilities or base classes |
88+
| **Flatten** | Deep nesting → early returns, guard clauses |
89+
| **Decouple** | Tight coupling → dependency injection, interfaces |
90+
| **Remove** | Dead code, unused features, excessive abstractions |
91+
| **Replace** | Complex logic → built-in language/library features |
92+
| **Defer** | Premature optimization → measure-first approach |
93+
94+
## Step 5: Prioritize Changes
95+
Rank suggestions by:
96+
1. **High impact, low risk** — Do first
97+
2. **High impact, higher risk** — Plan carefully
98+
3. **Low impact, low risk** — Quick wins if time permits
99+
4. **Low impact, high risk** — Skip or defer
100+
101+
For each change, specify:
102+
- Before/after code snippets
103+
- Risk level (breaking change? needs migration?)
104+
- Testing requirements
105+
- Estimated effort
106+
107+
## Step 6: Create Simplification Plan
108+
Provide a structured action plan:
109+
110+
```
111+
### Simplification Summary
112+
- Total suggestions: [count]
113+
- Estimated LOC reduction: [estimate]
114+
- Complexity score before/after: [if measurable]
115+
116+
### Prioritized Actions
117+
1. **[Component/Function Name]**
118+
- Issue: ...
119+
- Solution: ...
120+
- Risk: Low/Medium/High
121+
- Effort: S/M/L
122+
123+
2. ... (repeat)
124+
125+
### Recommended Order
126+
1. [ ] [First change - safest, unlocks others]
127+
2. [ ] [Second change]
128+
3. [ ] ...
129+
130+
### Post-Simplification Checklist
131+
- [ ] Run existing tests to verify no regressions
132+
- [ ] Add tests for any new helper functions
133+
- [ ] Update documentation if interfaces changed
134+
- [ ] Review with team before merging larger refactors
135+
```
136+
137+
## Step 7: Scalability Recommendations
138+
Beyond immediate simplification, suggest patterns for future scalability:
139+
- Modular architecture improvements
140+
- Caching strategies
141+
- Async/parallel processing opportunities
142+
- Configuration externalization
143+
- Feature flags for gradual rollouts
144+
145+
---
146+
Let me know when you're ready to simplify your implementation.'''

0 commit comments

Comments
 (0)