super-opencode 1.1.0 → 1.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.opencode/agents/architect.md +84 -84
- package/.opencode/agents/backend.md +124 -124
- package/.opencode/agents/frontend.md +137 -137
- package/.opencode/agents/optimizer.md +51 -51
- package/.opencode/agents/pm-agent.md +105 -105
- package/.opencode/agents/quality.md +107 -107
- package/.opencode/agents/researcher.md +105 -105
- package/.opencode/agents/reviewer.md +80 -80
- package/.opencode/agents/security.md +107 -107
- package/.opencode/agents/writer.md +136 -136
- package/.opencode/commands/soc-analyze.md +136 -137
- package/.opencode/commands/soc-brainstorm.md +109 -110
- package/.opencode/commands/soc-cleanup.md +107 -107
- package/.opencode/commands/soc-design.md +0 -1
- package/.opencode/commands/soc-explain.md +113 -113
- package/.opencode/commands/soc-git.md +104 -104
- package/.opencode/commands/soc-help.md +94 -94
- package/.opencode/commands/soc-implement.md +112 -112
- package/.opencode/commands/soc-improve.md +105 -105
- package/.opencode/commands/soc-pm.md +99 -99
- package/.opencode/commands/soc-research.md +105 -105
- package/.opencode/commands/soc-review.md +102 -102
- package/.opencode/commands/soc-test.md +109 -109
- package/.opencode/commands/soc-workflow.md +97 -97
- package/.opencode/settings.json +3 -3
- package/.opencode/skills/confidence-check/SKILL.md +97 -97
- package/.opencode/skills/debug-protocol/SKILL.md +83 -83
- package/.opencode/skills/reflexion/SKILL.md +108 -108
- package/.opencode/skills/security-audit/SKILL.md +90 -90
- package/.opencode/skills/self-check/SKILL.md +95 -95
- package/.opencode/skills/simplification/SKILL.md +92 -92
- package/AGENTS.md +175 -175
- package/LICENSE +21 -21
- package/dist/cli.js +2 -2
- package/package.json +45 -45
|
@@ -1,95 +1,95 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: self-check
|
|
3
|
-
description: Post-implementation validation to enforce the Definition of Done (DoD) and prevent hallucinations.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Self-Check Skill
|
|
7
|
-
|
|
8
|
-
## Purpose
|
|
9
|
-
To validate work **after** implementation but **before** handoff.
|
|
10
|
-
This is the "Check" in PDCA. It prevents the "It works on my machine" (or "It works in my context window") syndrome.
|
|
11
|
-
|
|
12
|
-
**ROI Metric**: Catching a syntax error here costs 50 tokens. Catching it in a PR review costs 5,000 tokens + human time.
|
|
13
|
-
|
|
14
|
-
## When to Use
|
|
15
|
-
- **Trigger**: Immediately after `execution` mode finishes writing code.
|
|
16
|
-
- **Trigger**: Before the `backend` agent hands off to `frontend`.
|
|
17
|
-
- **Trigger**: Before any `git commit`.
|
|
18
|
-
|
|
19
|
-
## The "Proof of Work" Protocol
|
|
20
|
-
|
|
21
|
-
### 1. The Build Check (Syntax)
|
|
22
|
-
**Rule**: *Code that doesn't build doesn't exist.*
|
|
23
|
-
- Did you run the build/transpile command? (`npm run build`, `go build`, etc.)
|
|
24
|
-
- **Evidence**: Paste the exit code and the last 3 lines of output.
|
|
25
|
-
|
|
26
|
-
### 2. The Logic Check (Behavior)
|
|
27
|
-
**Rule**: *Claims require proof.*
|
|
28
|
-
- **Forbidden Phrase**: "I ran the tests and they passed." (This is often a hallucination).
|
|
29
|
-
- **Required Action**: Run the test command via `run_command` and capture the actual output.
|
|
30
|
-
- **Evidence**: Paste the `Total: X Passed, 0 Failed` line.
|
|
31
|
-
|
|
32
|
-
### 3. The Contract Check (Requirements)
|
|
33
|
-
**Rule**: *Did you solve the user's problem?*
|
|
34
|
-
- Map every constraint from the original prompt to a specific line of code or test case.
|
|
35
|
-
|
|
36
|
-
### 4. The Hygiene Check (Cleanup)
|
|
37
|
-
**Rule**: *Leave no trace.*
|
|
38
|
-
- Scan for: `console.log("here")`, `debugger`, commented out code blocks, or `TODO` comments added by you.
|
|
39
|
-
- **Action**: Remove them.
|
|
40
|
-
|
|
41
|
-
## Execution Template
|
|
42
|
-
|
|
43
|
-
*Copy this into the context window to validate your work.*
|
|
44
|
-
|
|
45
|
-
```markdown
|
|
46
|
-
## ✅ Self-Check Validation
|
|
47
|
-
|
|
48
|
-
### 1. Build Verification
|
|
49
|
-
- **Command**: `npm run build`
|
|
50
|
-
- **Output**:
|
|
51
|
-
```text
|
|
52
|
-
> build
|
|
53
|
-
> tsc
|
|
54
|
-
✨ Done in 2.45s.
|
|
55
|
-
```
|
|
56
|
-
- **Status**: [ PASS / FAIL ]
|
|
57
|
-
|
|
58
|
-
### 2. Test Verification
|
|
59
|
-
- **Command**: `npm test -- user.service.test.ts`
|
|
60
|
-
- **Output**:
|
|
61
|
-
```text
|
|
62
|
-
PASS src/services/user.service.test.ts
|
|
63
|
-
Tests: 3 passed, 3 total
|
|
64
|
-
```
|
|
65
|
-
- **Status**: [ PASS / FAIL ] -> *If FAIL, trigger `reflexion` skill.*
|
|
66
|
-
|
|
67
|
-
### 3. Requirements Mapping
|
|
68
|
-
| Requirement | Implemented? | Evidence (File/Line) |
|
|
69
|
-
| :--- | :--- | :--- |
|
|
70
|
-
| "Users must have a role" | ✅ | `UserSchema.ts:12` (Zod enum) |
|
|
71
|
-
| "Passwords must be hashed" | ✅ | `AuthService.ts:45` (bcrypt call) |
|
|
72
|
-
|
|
73
|
-
### 4. Code Hygiene
|
|
74
|
-
- [ ] Removed debug `console.log`s?
|
|
75
|
-
- [ ] Removed temporary comments?
|
|
76
|
-
- [ ] Ran Linter? (`npm run lint`)
|
|
77
|
-
|
|
78
|
-
### 🏁 Final Verdict: [ READY TO SHIP / NEEDS FIXING ]
|
|
79
|
-
|
|
80
|
-
## Red Flags (Hallucination Detection)
|
|
81
|
-
|
|
82
|
-
If you see these patterns in your own reasoning, **STOP**:
|
|
83
|
-
|
|
84
|
-
| Red Flag | Why It's Bad | Correction |
|
|
85
|
-
| :--- | :--- | :--- |
|
|
86
|
-
| *"The code looks correct."* | Visual inspection is insufficient. | Run the code. |
|
|
87
|
-
| *"I updated the tests."* | Did you *run* them? | Run the tests. |
|
|
88
|
-
| *"This should fix the error."* | Hope is not a strategy. | Verify the fix. |
|
|
89
|
-
| *"I'll assume the DB is running."* | Assumption is the mother of all failures. | Check connection. |
|
|
90
|
-
|
|
91
|
-
## Integration with Agents
|
|
92
|
-
|
|
93
|
-
- **`execution` mode**: Must run `self-check` before declaring `Status: COMPLETE`.
|
|
94
|
-
- **`pm-agent`**: Rejects any task update that does not include a `self-check` artifact.
|
|
95
|
-
- **`reflexion` skill**: If `self-check` results in **FAIL**, the agent must immediately enter `reflexion` mode to analyze the root cause before retrying.
|
|
1
|
+
---
|
|
2
|
+
name: self-check
|
|
3
|
+
description: Post-implementation validation to enforce the Definition of Done (DoD) and prevent hallucinations.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Self-Check Skill
|
|
7
|
+
|
|
8
|
+
## Purpose
|
|
9
|
+
To validate work **after** implementation but **before** handoff.
|
|
10
|
+
This is the "Check" in PDCA. It prevents the "It works on my machine" (or "It works in my context window") syndrome.
|
|
11
|
+
|
|
12
|
+
**ROI Metric**: Catching a syntax error here costs 50 tokens. Catching it in a PR review costs 5,000 tokens + human time.
|
|
13
|
+
|
|
14
|
+
## When to Use
|
|
15
|
+
- **Trigger**: Immediately after `execution` mode finishes writing code.
|
|
16
|
+
- **Trigger**: Before the `backend` agent hands off to `frontend`.
|
|
17
|
+
- **Trigger**: Before any `git commit`.
|
|
18
|
+
|
|
19
|
+
## The "Proof of Work" Protocol
|
|
20
|
+
|
|
21
|
+
### 1. The Build Check (Syntax)
|
|
22
|
+
**Rule**: *Code that doesn't build doesn't exist.*
|
|
23
|
+
- Did you run the build/transpile command? (`npm run build`, `go build`, etc.)
|
|
24
|
+
- **Evidence**: Paste the exit code and the last 3 lines of output.
|
|
25
|
+
|
|
26
|
+
### 2. The Logic Check (Behavior)
|
|
27
|
+
**Rule**: *Claims require proof.*
|
|
28
|
+
- **Forbidden Phrase**: "I ran the tests and they passed." (This is often a hallucination).
|
|
29
|
+
- **Required Action**: Run the test command via `run_command` and capture the actual output.
|
|
30
|
+
- **Evidence**: Paste the `Total: X Passed, 0 Failed` line.
|
|
31
|
+
|
|
32
|
+
### 3. The Contract Check (Requirements)
|
|
33
|
+
**Rule**: *Did you solve the user's problem?*
|
|
34
|
+
- Map every constraint from the original prompt to a specific line of code or test case.
|
|
35
|
+
|
|
36
|
+
### 4. The Hygiene Check (Cleanup)
|
|
37
|
+
**Rule**: *Leave no trace.*
|
|
38
|
+
- Scan for: `console.log("here")`, `debugger`, commented out code blocks, or `TODO` comments added by you.
|
|
39
|
+
- **Action**: Remove them.
|
|
40
|
+
|
|
41
|
+
## Execution Template
|
|
42
|
+
|
|
43
|
+
*Copy this into the context window to validate your work.*
|
|
44
|
+
|
|
45
|
+
```markdown
|
|
46
|
+
## ✅ Self-Check Validation
|
|
47
|
+
|
|
48
|
+
### 1. Build Verification
|
|
49
|
+
- **Command**: `npm run build`
|
|
50
|
+
- **Output**:
|
|
51
|
+
```text
|
|
52
|
+
> build
|
|
53
|
+
> tsc
|
|
54
|
+
✨ Done in 2.45s.
|
|
55
|
+
```
|
|
56
|
+
- **Status**: [ PASS / FAIL ]
|
|
57
|
+
|
|
58
|
+
### 2. Test Verification
|
|
59
|
+
- **Command**: `npm test -- user.service.test.ts`
|
|
60
|
+
- **Output**:
|
|
61
|
+
```text
|
|
62
|
+
PASS src/services/user.service.test.ts
|
|
63
|
+
Tests: 3 passed, 3 total
|
|
64
|
+
```
|
|
65
|
+
- **Status**: [ PASS / FAIL ] -> *If FAIL, trigger `reflexion` skill.*
|
|
66
|
+
|
|
67
|
+
### 3. Requirements Mapping
|
|
68
|
+
| Requirement | Implemented? | Evidence (File/Line) |
|
|
69
|
+
| :--- | :--- | :--- |
|
|
70
|
+
| "Users must have a role" | ✅ | `UserSchema.ts:12` (Zod enum) |
|
|
71
|
+
| "Passwords must be hashed" | ✅ | `AuthService.ts:45` (bcrypt call) |
|
|
72
|
+
|
|
73
|
+
### 4. Code Hygiene
|
|
74
|
+
- [ ] Removed debug `console.log`s?
|
|
75
|
+
- [ ] Removed temporary comments?
|
|
76
|
+
- [ ] Ran Linter? (`npm run lint`)
|
|
77
|
+
|
|
78
|
+
### 🏁 Final Verdict: [ READY TO SHIP / NEEDS FIXING ]
|
|
79
|
+
|
|
80
|
+
## Red Flags (Hallucination Detection)
|
|
81
|
+
|
|
82
|
+
If you see these patterns in your own reasoning, **STOP**:
|
|
83
|
+
|
|
84
|
+
| Red Flag | Why It's Bad | Correction |
|
|
85
|
+
| :--- | :--- | :--- |
|
|
86
|
+
| *"The code looks correct."* | Visual inspection is insufficient. | Run the code. |
|
|
87
|
+
| *"I updated the tests."* | Did you *run* them? | Run the tests. |
|
|
88
|
+
| *"This should fix the error."* | Hope is not a strategy. | Verify the fix. |
|
|
89
|
+
| *"I'll assume the DB is running."* | Assumption is the mother of all failures. | Check connection. |
|
|
90
|
+
|
|
91
|
+
## Integration with Agents
|
|
92
|
+
|
|
93
|
+
- **`execution` mode**: Must run `self-check` before declaring `Status: COMPLETE`.
|
|
94
|
+
- **`pm-agent`**: Rejects any task update that does not include a `self-check` artifact.
|
|
95
|
+
- **`reflexion` skill**: If `self-check` results in **FAIL**, the agent must immediately enter `reflexion` mode to analyze the root cause before retrying.
|
|
@@ -1,92 +1,92 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: simplification
|
|
3
|
-
description: Complexity reduction and architectural streamlining for Frontend, Backend, and Quality agents.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Simplification Skill (Occam's Razor)
|
|
7
|
-
|
|
8
|
-
## Purpose
|
|
9
|
-
"Simplicity is the ultimate sophistication." This skill provides a rigorous protocol for identifying and eliminating over-engineering, code bloat, and technical debt across the entire stack.
|
|
10
|
-
|
|
11
|
-
## Overview
|
|
12
|
-
The Simplification Skill is a cross-functional protocol used to flatten logic, reduce state, and ensure every line of code justifies its existence. It leverages specialized agents and MCP tools to validate architectural simplicity and performance.
|
|
13
|
-
|
|
14
|
-
## Prerequisites
|
|
15
|
-
- **Agents**: [Backend](file:///.opencode/agents/backend.md), [Frontend](file:///.opencode/agents/frontend.md), [Quality](file:///.opencode/agents/quality.md).
|
|
16
|
-
- **MCP Tools**:
|
|
17
|
-
- `context7`: To research lightweight alternatives and library standards.
|
|
18
|
-
- `sequential-thinking`: To audit complex logic flows for potential flattening.
|
|
19
|
-
- `sqlite`: To verify if database schemas or queries can be compressed.
|
|
20
|
-
- `playwright`/`chrome-devtools`: To identify UI "jank" or DOM complexity.
|
|
21
|
-
|
|
22
|
-
## Agent-Specific Simplification Protocols
|
|
23
|
-
|
|
24
|
-
### [Senior Backend Engineer](file:///.opencode/agents/backend.md)
|
|
25
|
-
- **State Reduction**: Derive values instead of storing them. If `is_active` can be derived from `status === 'active'`, delete the redundant field.
|
|
26
|
-
- **Query Optimization**: Use `sqlite` to check for N+1 issues. Replace nested loops with single optimized queries or batching.
|
|
27
|
-
- **Error Flattening**: Centralize error handling middleware. Remove repetitive `try/catch` blocks from business logic to expose the "Happy Path".
|
|
28
|
-
|
|
29
|
-
### [Senior Frontend Engineer](file:///.opencode/agents/frontend.md)
|
|
30
|
-
- **DOM Streamlining**: Replace "Div Soup" with semantic HTML elements.
|
|
31
|
-
- **Hook Optimization**: Audit `useEffect` usage. If it's used to sync state, replace it with derived constants or `useMemo`.
|
|
32
|
-
- **Styling Discipline**: Replace custom inline styles with standard Tailwind utility classes or `cva` variants.
|
|
33
|
-
|
|
34
|
-
### [QA Automation Engineer](file:///.opencode/agents/quality.md)
|
|
35
|
-
- **Test Pruning**: Remove redundant unit tests if the logic is covered by a high-confidence integration test.
|
|
36
|
-
- **Selector Simplification**: Replace fragile XPaths or class-based selectors with accessible `getByRole` or `getByLabel` locators.
|
|
37
|
-
|
|
38
|
-
## The Procedural Workflow
|
|
39
|
-
|
|
40
|
-
### 1. The Deletion Test
|
|
41
|
-
- **Action**: Use `grep_search` to find references to the target code. If references < 1, **DELETE**.
|
|
42
|
-
- **Rule**: Dead code is the best code.
|
|
43
|
-
|
|
44
|
-
### 2. The Library Leverage (via `context7`)
|
|
45
|
-
- **Action**: Use `context7` to check if a complex custom utility (e.g., date formatting, deep cloning) can be replaced by a native function or a lightweight standard library (Lodash/Zustand).
|
|
46
|
-
|
|
47
|
-
### 3. Flat Logic Audit (via `sequential-thinking`)
|
|
48
|
-
- **Action**: Step through the logic. If nesting > 3 levels or cyclomatic complexity is high, apply guard clauses.
|
|
49
|
-
- **Target Pattern**:
|
|
50
|
-
```diff
|
|
51
|
-
- if (user) {
|
|
52
|
-
- if (user.active) {
|
|
53
|
-
- return doThing();
|
|
54
|
-
- }
|
|
55
|
-
- }
|
|
56
|
-
+ if (!user?.active) return;
|
|
57
|
-
+ return doThing();
|
|
58
|
-
```
|
|
59
|
-
|
|
60
|
-
## Complexity Metrics to Watch
|
|
61
|
-
- **Nesting Level**: Maximum 3 levels of indentation.
|
|
62
|
-
- **Function Size**: Maximum 30 lines.
|
|
63
|
-
- **Cognitive Weight**: If a function requires `sequential-thinking` just to "read" it, it's too complex.
|
|
64
|
-
|
|
65
|
-
## Output Format
|
|
66
|
-
|
|
67
|
-
```markdown
|
|
68
|
-
## Simplification Review: [Target File/Function]
|
|
69
|
-
|
|
70
|
-
### 1. Opportunities Identified
|
|
71
|
-
| Area | Description | Tool Used | Impact |
|
|
72
|
-
|------|-------------|-----------|--------|
|
|
73
|
-
| Logic | Flatten nested `if` statements | `sequential-thinking` | High |
|
|
74
|
-
| State | Remove redundant `isLoading` boolean | - | Medium |
|
|
75
|
-
| Lib | Replace custom deep clone with `structuredClone` | `context7` | Low |
|
|
76
|
-
|
|
77
|
-
### 2. Implementation: Before vs After
|
|
78
|
-
**Before**:
|
|
79
|
-
```javascript
|
|
80
|
-
// Complex, nested, or redundant code
|
|
81
|
-
```
|
|
82
|
-
|
|
83
|
-
**After**:
|
|
84
|
-
```javascript
|
|
85
|
-
// Streamlined, readable, and efficient code
|
|
86
|
-
```
|
|
87
|
-
|
|
88
|
-
### 3. Impact Assessment
|
|
89
|
-
- Lines Removed: [Count]
|
|
90
|
-
- Performance Gain: [e.g., Reduced O(N²) to O(N)]
|
|
91
|
-
- Maintenance Status: Optimized
|
|
92
|
-
```
|
|
1
|
+
---
|
|
2
|
+
name: simplification
|
|
3
|
+
description: Complexity reduction and architectural streamlining for Frontend, Backend, and Quality agents.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Simplification Skill (Occam's Razor)
|
|
7
|
+
|
|
8
|
+
## Purpose
|
|
9
|
+
"Simplicity is the ultimate sophistication." This skill provides a rigorous protocol for identifying and eliminating over-engineering, code bloat, and technical debt across the entire stack.
|
|
10
|
+
|
|
11
|
+
## Overview
|
|
12
|
+
The Simplification Skill is a cross-functional protocol used to flatten logic, reduce state, and ensure every line of code justifies its existence. It leverages specialized agents and MCP tools to validate architectural simplicity and performance.
|
|
13
|
+
|
|
14
|
+
## Prerequisites
|
|
15
|
+
- **Agents**: [Backend](file:///.opencode/agents/backend.md), [Frontend](file:///.opencode/agents/frontend.md), [Quality](file:///.opencode/agents/quality.md).
|
|
16
|
+
- **MCP Tools**:
|
|
17
|
+
- `context7`: To research lightweight alternatives and library standards.
|
|
18
|
+
- `sequential-thinking`: To audit complex logic flows for potential flattening.
|
|
19
|
+
- `sqlite`: To verify if database schemas or queries can be compressed.
|
|
20
|
+
- `playwright`/`chrome-devtools`: To identify UI "jank" or DOM complexity.
|
|
21
|
+
|
|
22
|
+
## Agent-Specific Simplification Protocols
|
|
23
|
+
|
|
24
|
+
### [Senior Backend Engineer](file:///.opencode/agents/backend.md)
|
|
25
|
+
- **State Reduction**: Derive values instead of storing them. If `is_active` can be derived from `status === 'active'`, delete the redundant field.
|
|
26
|
+
- **Query Optimization**: Use `sqlite` to check for N+1 issues. Replace nested loops with single optimized queries or batching.
|
|
27
|
+
- **Error Flattening**: Centralize error handling middleware. Remove repetitive `try/catch` blocks from business logic to expose the "Happy Path".
|
|
28
|
+
|
|
29
|
+
### [Senior Frontend Engineer](file:///.opencode/agents/frontend.md)
|
|
30
|
+
- **DOM Streamlining**: Replace "Div Soup" with semantic HTML elements.
|
|
31
|
+
- **Hook Optimization**: Audit `useEffect` usage. If it's used to sync state, replace it with derived constants or `useMemo`.
|
|
32
|
+
- **Styling Discipline**: Replace custom inline styles with standard Tailwind utility classes or `cva` variants.
|
|
33
|
+
|
|
34
|
+
### [QA Automation Engineer](file:///.opencode/agents/quality.md)
|
|
35
|
+
- **Test Pruning**: Remove redundant unit tests if the logic is covered by a high-confidence integration test.
|
|
36
|
+
- **Selector Simplification**: Replace fragile XPaths or class-based selectors with accessible `getByRole` or `getByLabel` locators.
|
|
37
|
+
|
|
38
|
+
## The Procedural Workflow
|
|
39
|
+
|
|
40
|
+
### 1. The Deletion Test
|
|
41
|
+
- **Action**: Use `grep_search` to find references to the target code. If references < 1, **DELETE**.
|
|
42
|
+
- **Rule**: Dead code is the best code.
|
|
43
|
+
|
|
44
|
+
### 2. The Library Leverage (via `context7`)
|
|
45
|
+
- **Action**: Use `context7` to check if a complex custom utility (e.g., date formatting, deep cloning) can be replaced by a native function or a lightweight standard library (Lodash/Zustand).
|
|
46
|
+
|
|
47
|
+
### 3. Flat Logic Audit (via `sequential-thinking`)
|
|
48
|
+
- **Action**: Step through the logic. If nesting > 3 levels or cyclomatic complexity is high, apply guard clauses.
|
|
49
|
+
- **Target Pattern**:
|
|
50
|
+
```diff
|
|
51
|
+
- if (user) {
|
|
52
|
+
- if (user.active) {
|
|
53
|
+
- return doThing();
|
|
54
|
+
- }
|
|
55
|
+
- }
|
|
56
|
+
+ if (!user?.active) return;
|
|
57
|
+
+ return doThing();
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
## Complexity Metrics to Watch
|
|
61
|
+
- **Nesting Level**: Maximum 3 levels of indentation.
|
|
62
|
+
- **Function Size**: Maximum 30 lines.
|
|
63
|
+
- **Cognitive Weight**: If a function requires `sequential-thinking` just to "read" it, it's too complex.
|
|
64
|
+
|
|
65
|
+
## Output Format
|
|
66
|
+
|
|
67
|
+
```markdown
|
|
68
|
+
## Simplification Review: [Target File/Function]
|
|
69
|
+
|
|
70
|
+
### 1. Opportunities Identified
|
|
71
|
+
| Area | Description | Tool Used | Impact |
|
|
72
|
+
|------|-------------|-----------|--------|
|
|
73
|
+
| Logic | Flatten nested `if` statements | `sequential-thinking` | High |
|
|
74
|
+
| State | Remove redundant `isLoading` boolean | - | Medium |
|
|
75
|
+
| Lib | Replace custom deep clone with `structuredClone` | `context7` | Low |
|
|
76
|
+
|
|
77
|
+
### 2. Implementation: Before vs After
|
|
78
|
+
**Before**:
|
|
79
|
+
```javascript
|
|
80
|
+
// Complex, nested, or redundant code
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
**After**:
|
|
84
|
+
```javascript
|
|
85
|
+
// Streamlined, readable, and efficient code
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
### 3. Impact Assessment
|
|
89
|
+
- Lines Removed: [Count]
|
|
90
|
+
- Performance Gain: [e.g., Reduced O(N²) to O(N)]
|
|
91
|
+
- Maintenance Status: Optimized
|
|
92
|
+
```
|