claudify-agent 0.0.0-stage → 1.0.0
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/.claude/QUICK-REFERENCE.md +213 -0
- package/.claude/cost-dashboard.md +162 -0
- package/.claude/docs/COST-OPTIMIZATION.md +403 -0
- package/.claude/docs/MCP-INTEGRATION-GUIDE.md +348 -0
- package/.claude/docs/PLAN-MODE-OPTIMIZATION.md +836 -0
- package/.claude/hooks/auto-learning-review.ts +195 -0
- package/.claude/hooks/auto-lint-fix.ts +104 -0
- package/.claude/hooks/auto-security-review.ts +354 -0
- package/.claude/hooks/auto-validate.ts +348 -0
- package/.claude/hooks/plan-quality-tracker.ts +719 -0
- package/.claude/rules/anti-patterns.md +22 -0
- package/.claude/rules/context-tier-1.md +41 -0
- package/.claude/rules/context-tier-2.md +285 -0
- package/.claude/rules/general.md +25 -0
- package/.claude/rules/mcp-auto-use.md +46 -0
- package/.claude/rules/parallel-exploration-auto.md +31 -0
- package/.claude/rules/plan-mode-execution.md +289 -0
- package/.claude/rules/plan-mode-research.md +34 -0
- package/.claude/rules/plan-mode-structure.md +166 -0
- package/.claude/rules/plan-mode-validation.md +130 -0
- package/.claude/rules/security-critical.md +19 -0
- package/.claude/rules/tool-auto-selection.md +45 -0
- package/.claude/rules/tool-strategy.md +22 -0
- package/.claude/scripts/auto-validate.js +69 -0
- package/.claude/scripts/security-scan.js +45 -0
- package/.claude/security-dashboard.md +142 -0
- package/.claude/skills/backend-concurrency/SKILL.md +203 -0
- package/.claude/skills/debug-optimizer/SKILL.md +399 -0
- package/.claude/skills/debug-optimizer.md +12 -0
- package/.claude/skills/golang-guide/SKILL.md +177 -0
- package/.claude/skills/learning-loop/SKILL.md +308 -0
- package/.claude/skills/mcp-mastery/SKILL.md +214 -0
- package/.claude/skills/nestjs-guide/SKILL.md +197 -0
- package/.claude/skills/nextjs-guide/SKILL.md +687 -0
- package/.claude/skills/nextjs.md +13 -0
- package/.claude/skills/parallel-exploration/SKILL.md +193 -0
- package/.claude/skills/plan-mode-mastery/SKILL.md +263 -0
- package/.claude/skills/python-guide/SKILL.md +822 -0
- package/.claude/skills/react-guide/SKILL.md +762 -0
- package/.claude/skills/react.md +12 -0
- package/.claude/skills/security.md +18 -0
- package/.claude/skills/solidity-guide/SKILL.md +32 -0
- package/.claude/skills/tool-selection/SKILL.md +428 -0
- package/.claude/skills/vite-guide/SKILL.md +445 -0
- package/CLAUDE.md +49 -0
- package/README.md +65 -2
- package/bin/cli.js +50 -0
- package/package.json +44 -4
|
@@ -0,0 +1,289 @@
|
|
|
1
|
+
# Plan Mode Execution Monitoring
|
|
2
|
+
|
|
3
|
+
## Automatic Progress Tracking
|
|
4
|
+
|
|
5
|
+
### TodoWrite Creation
|
|
6
|
+
When plan approved:
|
|
7
|
+
1. Convert steps to todos automatically
|
|
8
|
+
2. First step: in_progress
|
|
9
|
+
3. Update after EACH completion
|
|
10
|
+
4. Only ONE in_progress at a time
|
|
11
|
+
|
|
12
|
+
### Checkpoint Strategy
|
|
13
|
+
Create checkpoint before:
|
|
14
|
+
- Large refactors (>5 files)
|
|
15
|
+
- Database changes
|
|
16
|
+
- API contract changes
|
|
17
|
+
- Breaking changes
|
|
18
|
+
- Irreversible operations
|
|
19
|
+
|
|
20
|
+
### Iteration Loops
|
|
21
|
+
If tests fail:
|
|
22
|
+
1. Use /grind automatically
|
|
23
|
+
2. Max 5 iterations
|
|
24
|
+
3. Update scratchpad
|
|
25
|
+
4. Report if BLOCKED
|
|
26
|
+
|
|
27
|
+
### Adaptive Re-planning
|
|
28
|
+
If deviation >30%:
|
|
29
|
+
1. Pause execution
|
|
30
|
+
2. Create updated plan
|
|
31
|
+
3. Present delta
|
|
32
|
+
4. Get approval
|
|
33
|
+
|
|
34
|
+
### Quality Gates
|
|
35
|
+
After EACH step:
|
|
36
|
+
- ReadLints on modified files
|
|
37
|
+
- Fix introduced lints immediately
|
|
38
|
+
- Run relevant tests
|
|
39
|
+
- Update todos
|
|
40
|
+
|
|
41
|
+
## Progress Tracking Template
|
|
42
|
+
|
|
43
|
+
```markdown
|
|
44
|
+
## Current Progress
|
|
45
|
+
Step 3/7: Creating API endpoints (in_progress)
|
|
46
|
+
|
|
47
|
+
## Completed Steps
|
|
48
|
+
✅ Step 1: Research patterns (2 min)
|
|
49
|
+
✅ Step 2: Create project structure (5 min)
|
|
50
|
+
|
|
51
|
+
## Remaining Steps
|
|
52
|
+
⏳ Step 3: Create API endpoints (in_progress)
|
|
53
|
+
⏹ Step 4: Build UI components
|
|
54
|
+
⏹ Step 5: Integration
|
|
55
|
+
⏹ Step 6: Testing
|
|
56
|
+
⏹ Step 7: Documentation
|
|
57
|
+
|
|
58
|
+
## Quality Status
|
|
59
|
+
- Lints: ✅ Clear
|
|
60
|
+
- Tests: ✅ Passing
|
|
61
|
+
- Checkpoints: 1 created (before Step 3)
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
## Checkpoint Guidelines
|
|
65
|
+
|
|
66
|
+
### When to Create Checkpoints
|
|
67
|
+
|
|
68
|
+
**ALWAYS create checkpoint before:**
|
|
69
|
+
1. Database schema migrations
|
|
70
|
+
2. API contract changes
|
|
71
|
+
3. Authentication/authorization changes
|
|
72
|
+
4. Payment processing changes
|
|
73
|
+
5. Data migration
|
|
74
|
+
6. Breaking changes
|
|
75
|
+
7. Removing existing functionality
|
|
76
|
+
|
|
77
|
+
**OPTIONAL checkpoints:**
|
|
78
|
+
1. After completing major phases
|
|
79
|
+
2. Before experimental changes
|
|
80
|
+
3. When trying multiple approaches
|
|
81
|
+
|
|
82
|
+
### Checkpoint Naming Convention
|
|
83
|
+
|
|
84
|
+
```
|
|
85
|
+
checkpoint-[plan-name]-step-[N]-[description]
|
|
86
|
+
|
|
87
|
+
Examples:
|
|
88
|
+
- checkpoint-auth-migration-step-3-before-db-change
|
|
89
|
+
- checkpoint-dashboard-feature-step-2-before-api
|
|
90
|
+
- checkpoint-checkout-refactor-step-5-before-breaking-change
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
### Rollback Triggers
|
|
94
|
+
|
|
95
|
+
**Automatic rollback if:**
|
|
96
|
+
1. Tests fail after 5 /grind iterations
|
|
97
|
+
2. Critical linter errors introduced
|
|
98
|
+
3. User requests rollback
|
|
99
|
+
4. Agent detects critical error
|
|
100
|
+
5. Data corruption detected
|
|
101
|
+
|
|
102
|
+
## Iteration Loop (/grind)
|
|
103
|
+
|
|
104
|
+
### When to Use
|
|
105
|
+
- Tests failing
|
|
106
|
+
- Linter errors persist
|
|
107
|
+
- Matching design mockups
|
|
108
|
+
- Fixing edge cases
|
|
109
|
+
|
|
110
|
+
### Process
|
|
111
|
+
1. Run tests → identify failures
|
|
112
|
+
2. Fix code → run tests again
|
|
113
|
+
3. Repeat until pass or max 5 iterations
|
|
114
|
+
4. Update scratchpad: `.cursor/scratchpad.md`
|
|
115
|
+
5. Report BLOCKED if stuck
|
|
116
|
+
|
|
117
|
+
### Scratchpad Format
|
|
118
|
+
|
|
119
|
+
```markdown
|
|
120
|
+
## Task: Make all tests pass
|
|
121
|
+
|
|
122
|
+
### Iteration 1
|
|
123
|
+
- ❌ 3 tests failing
|
|
124
|
+
- Fixed authentication logic
|
|
125
|
+
|
|
126
|
+
### Iteration 2
|
|
127
|
+
- ❌ 1 test failing
|
|
128
|
+
- Fixed edge case in validation
|
|
129
|
+
|
|
130
|
+
### Iteration 3
|
|
131
|
+
- ✅ All tests passing
|
|
132
|
+
- DONE
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
## Adaptive Re-planning
|
|
136
|
+
|
|
137
|
+
### When to Re-plan
|
|
138
|
+
|
|
139
|
+
**Re-plan required if:**
|
|
140
|
+
1. >30% of plan steps changed
|
|
141
|
+
2. New blockers discovered
|
|
142
|
+
3. Time estimate off by >50%
|
|
143
|
+
4. User changes requirements
|
|
144
|
+
5. Critical dependency missing
|
|
145
|
+
|
|
146
|
+
### Re-plan Process
|
|
147
|
+
|
|
148
|
+
1. **Pause execution**
|
|
149
|
+
- Stop current step
|
|
150
|
+
- Create checkpoint if needed
|
|
151
|
+
|
|
152
|
+
2. **Assess deviation**
|
|
153
|
+
- What changed?
|
|
154
|
+
- Why did it change?
|
|
155
|
+
- Impact on remaining steps?
|
|
156
|
+
|
|
157
|
+
3. **Create updated plan**
|
|
158
|
+
- Show delta from original
|
|
159
|
+
- Explain why changes needed
|
|
160
|
+
- Provide new time estimate
|
|
161
|
+
|
|
162
|
+
4. **Get approval**
|
|
163
|
+
- Present to user
|
|
164
|
+
- Explain trade-offs
|
|
165
|
+
- Wait for approval to continue
|
|
166
|
+
|
|
167
|
+
### Re-plan Template
|
|
168
|
+
|
|
169
|
+
```markdown
|
|
170
|
+
## Plan Update Required
|
|
171
|
+
|
|
172
|
+
### What Changed
|
|
173
|
+
- Original: [what we planned]
|
|
174
|
+
- Reality: [what we discovered]
|
|
175
|
+
- Impact: [how it affects the plan]
|
|
176
|
+
|
|
177
|
+
### Proposed Changes
|
|
178
|
+
1. Add step: [new step]
|
|
179
|
+
2. Remove step: [unnecessary step]
|
|
180
|
+
3. Modify step: [changed step]
|
|
181
|
+
4. New time estimate: [X minutes]
|
|
182
|
+
|
|
183
|
+
### Reason for Changes
|
|
184
|
+
[Brief explanation]
|
|
185
|
+
|
|
186
|
+
### Approval Required
|
|
187
|
+
Shall I proceed with this updated plan?
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
## Examples
|
|
191
|
+
|
|
192
|
+
### Example 1: Normal Execution
|
|
193
|
+
|
|
194
|
+
Plan: "Add login button" (5 steps)
|
|
195
|
+
|
|
196
|
+
Execution:
|
|
197
|
+
```
|
|
198
|
+
✅ Step 1: Research patterns
|
|
199
|
+
- Tool: SemanticSearch
|
|
200
|
+
- ReadLints: Clear
|
|
201
|
+
- TodoWrite: Updated
|
|
202
|
+
|
|
203
|
+
✅ Step 2: Add button to Header
|
|
204
|
+
- Tool: StrReplace
|
|
205
|
+
- ReadLints: Clear
|
|
206
|
+
- TodoWrite: Updated
|
|
207
|
+
|
|
208
|
+
✅ Step 3: Style button
|
|
209
|
+
- Tool: Write
|
|
210
|
+
- ReadLints: Clear
|
|
211
|
+
- TodoWrite: Updated
|
|
212
|
+
|
|
213
|
+
✅ Step 4: Add click handler
|
|
214
|
+
- Tool: StrReplace
|
|
215
|
+
- Tests: Pass
|
|
216
|
+
- TodoWrite: Updated
|
|
217
|
+
|
|
218
|
+
✅ Step 5: Final validation
|
|
219
|
+
- Tool: ReadLints
|
|
220
|
+
- Tool: Shell (tests)
|
|
221
|
+
- All clear → COMPLETE
|
|
222
|
+
```
|
|
223
|
+
|
|
224
|
+
### Example 2: Tests Failing
|
|
225
|
+
|
|
226
|
+
Plan: "Add authentication" (Step 4: Testing)
|
|
227
|
+
|
|
228
|
+
Execution:
|
|
229
|
+
```
|
|
230
|
+
❌ Tests failing: 2 failures
|
|
231
|
+
|
|
232
|
+
→ Automatic /grind loop:
|
|
233
|
+
|
|
234
|
+
Iteration 1:
|
|
235
|
+
- Fix: Token validation logic
|
|
236
|
+
- Result: 1 test still failing
|
|
237
|
+
|
|
238
|
+
Iteration 2:
|
|
239
|
+
- Fix: Edge case for expired tokens
|
|
240
|
+
- Result: All tests passing ✅
|
|
241
|
+
|
|
242
|
+
→ Continue to next step
|
|
243
|
+
```
|
|
244
|
+
|
|
245
|
+
### Example 3: Checkpoint & Rollback
|
|
246
|
+
|
|
247
|
+
Plan: "Migrate auth from JWT to sessions"
|
|
248
|
+
|
|
249
|
+
Execution:
|
|
250
|
+
```
|
|
251
|
+
✅ Step 1: Research session patterns
|
|
252
|
+
✅ Step 2: Add session dependencies
|
|
253
|
+
|
|
254
|
+
📸 CHECKPOINT created: Before DB changes
|
|
255
|
+
|
|
256
|
+
❌ Step 3: Database migration
|
|
257
|
+
- Error: Breaking change detected
|
|
258
|
+
- Tests failing
|
|
259
|
+
|
|
260
|
+
→ Automatic rollback to checkpoint
|
|
261
|
+
→ User notified
|
|
262
|
+
→ Alternative approach suggested
|
|
263
|
+
```
|
|
264
|
+
|
|
265
|
+
### Example 4: Adaptive Re-planning
|
|
266
|
+
|
|
267
|
+
Plan: "Add dashboard" (original: 5 steps)
|
|
268
|
+
|
|
269
|
+
Discovery during execution:
|
|
270
|
+
```
|
|
271
|
+
⚠️ Discovered: Existing dashboard component
|
|
272
|
+
⚠️ Impact: 3 steps unnecessary
|
|
273
|
+
⚠️ New approach: Modify existing instead
|
|
274
|
+
|
|
275
|
+
## Plan Update Required
|
|
276
|
+
|
|
277
|
+
### What Changed
|
|
278
|
+
- Original: Create new dashboard from scratch
|
|
279
|
+
- Reality: Existing dashboard can be extended
|
|
280
|
+
- Impact: 60% reduction in work
|
|
281
|
+
|
|
282
|
+
### Proposed Changes
|
|
283
|
+
1. Remove: Create new page file
|
|
284
|
+
2. Remove: Create new layout
|
|
285
|
+
3. Modify: Extend existing dashboard
|
|
286
|
+
4. New time estimate: 20 minutes (was 45)
|
|
287
|
+
|
|
288
|
+
Shall I proceed with updated plan?
|
|
289
|
+
```
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Plan Mode Pre-Plan Research
|
|
2
|
+
|
|
3
|
+
## Automatic Research Steps (Before ANY Plan)
|
|
4
|
+
|
|
5
|
+
1. **SemanticSearch** (30s)
|
|
6
|
+
- Query: "How is [similar feature] implemented?"
|
|
7
|
+
- Target: Most relevant directory
|
|
8
|
+
|
|
9
|
+
2. **Task Subagents** (60s, parallel)
|
|
10
|
+
- Launch 2-4 explore subagents
|
|
11
|
+
- Use model="fast", run_in_background=true
|
|
12
|
+
|
|
13
|
+
3. **ReadLints** (15s)
|
|
14
|
+
- Check target files for existing issues
|
|
15
|
+
|
|
16
|
+
4. **AskQuestion** (if ambiguous)
|
|
17
|
+
- Batch ALL questions in ONE call
|
|
18
|
+
|
|
19
|
+
## Output
|
|
20
|
+
- Summary of findings
|
|
21
|
+
- Reference files for patterns
|
|
22
|
+
- Clarified requirements (if asked)
|
|
23
|
+
|
|
24
|
+
## Examples
|
|
25
|
+
|
|
26
|
+
**Feature**: "Add user dashboard" → Research page/component patterns
|
|
27
|
+
**Bug**: "Fix auth bug" → Research auth implementation
|
|
28
|
+
**Refactor**: "Refactor checkout" → Research checkout code
|
|
29
|
+
|
|
30
|
+
## Rules
|
|
31
|
+
- Never plan without research (2-3 min max)
|
|
32
|
+
- Use parallel subagents for complex tasks
|
|
33
|
+
- Batch questions with AskQuestion
|
|
34
|
+
- Follow patterns found in codebase
|
|
@@ -0,0 +1,166 @@
|
|
|
1
|
+
# Plan Mode Plan Structure
|
|
2
|
+
|
|
3
|
+
## Required Plan Sections
|
|
4
|
+
|
|
5
|
+
Every plan MUST include:
|
|
6
|
+
|
|
7
|
+
1. **Summary** (1-2 sentences)
|
|
8
|
+
- What will be done
|
|
9
|
+
- Why it's needed
|
|
10
|
+
|
|
11
|
+
2. **Files to Create/Modify**
|
|
12
|
+
- Path and purpose
|
|
13
|
+
- Reference pattern: "Follow @[file]"
|
|
14
|
+
- Tools: "Use [tool] for [operation]"
|
|
15
|
+
|
|
16
|
+
3. **Implementation Steps**
|
|
17
|
+
- Sequential ordering
|
|
18
|
+
- Tool for each step
|
|
19
|
+
- Success metric: "Tests pass", "Lints clear"
|
|
20
|
+
|
|
21
|
+
4. **Tool Strategy**
|
|
22
|
+
- Exploration tools
|
|
23
|
+
- Implementation tools
|
|
24
|
+
- Validation tools
|
|
25
|
+
- Question strategy
|
|
26
|
+
|
|
27
|
+
5. **Testing Strategy**
|
|
28
|
+
- Test types
|
|
29
|
+
- Test files to create/modify
|
|
30
|
+
- Commands to run
|
|
31
|
+
|
|
32
|
+
6. **Risk Mitigation**
|
|
33
|
+
- High-risk steps flagged
|
|
34
|
+
- Fallback strategies
|
|
35
|
+
- Checkpoint locations
|
|
36
|
+
|
|
37
|
+
7. **Estimated Time**
|
|
38
|
+
- Based on complexity
|
|
39
|
+
- Includes buffer (20%)
|
|
40
|
+
|
|
41
|
+
## Plan Quality Gates
|
|
42
|
+
|
|
43
|
+
- [ ] All steps verifiable
|
|
44
|
+
- [ ] Tools specified
|
|
45
|
+
- [ ] Patterns referenced
|
|
46
|
+
- [ ] Risks identified
|
|
47
|
+
- [ ] Tests included
|
|
48
|
+
|
|
49
|
+
## Enhanced Plan Structure Template
|
|
50
|
+
|
|
51
|
+
```markdown
|
|
52
|
+
## Files to Create/Modify
|
|
53
|
+
- `path/to/file.ts` - Purpose
|
|
54
|
+
- Pattern: Follow @[reference file]
|
|
55
|
+
- Tools: Use StrReplace for edits, Shell for testing
|
|
56
|
+
|
|
57
|
+
## Implementation Steps
|
|
58
|
+
1. [Step]
|
|
59
|
+
- Tool: SemanticSearch to find [X]
|
|
60
|
+
- Tool: Task subagent to explore [Y]
|
|
61
|
+
- Tool: ReadLints to verify [Z]
|
|
62
|
+
- Success: [Verifiable metric]
|
|
63
|
+
|
|
64
|
+
## Tool Strategy
|
|
65
|
+
- Exploration: SemanticSearch + Task (explore)
|
|
66
|
+
- Implementation: Read/Write/StrReplace
|
|
67
|
+
- Validation: ReadLints + Shell (tests)
|
|
68
|
+
- Questions: AskQuestion for [specific decisions]
|
|
69
|
+
|
|
70
|
+
## Risk Mitigation
|
|
71
|
+
- If [X] fails → Fallback: [Y]
|
|
72
|
+
- If tests fail → Use /grind loop (max 5 iterations)
|
|
73
|
+
- If stuck → AskQuestion with options
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
## Examples
|
|
77
|
+
|
|
78
|
+
### Example 1: Simple Feature
|
|
79
|
+
User: "Add login button"
|
|
80
|
+
|
|
81
|
+
Plan structure:
|
|
82
|
+
```markdown
|
|
83
|
+
## Summary
|
|
84
|
+
Add login button to header navigation following existing button patterns.
|
|
85
|
+
|
|
86
|
+
## Files to Modify
|
|
87
|
+
- `components/Header.tsx` - Add login button to nav
|
|
88
|
+
- Pattern: Follow @components/Button.tsx
|
|
89
|
+
- Tools: StrReplace for edit, ReadLints for validation
|
|
90
|
+
|
|
91
|
+
## Implementation Steps
|
|
92
|
+
1. Find existing button patterns
|
|
93
|
+
- Tool: SemanticSearch: "How are buttons styled?"
|
|
94
|
+
- Success: Pattern identified
|
|
95
|
+
|
|
96
|
+
2. Add login button to Header
|
|
97
|
+
- Tool: StrReplace
|
|
98
|
+
- Success: Button renders correctly
|
|
99
|
+
|
|
100
|
+
3. Verify no linting errors
|
|
101
|
+
- Tool: ReadLints
|
|
102
|
+
- Success: Zero new lints
|
|
103
|
+
|
|
104
|
+
## Tool Strategy
|
|
105
|
+
- Exploration: SemanticSearch for button patterns
|
|
106
|
+
- Implementation: StrReplace
|
|
107
|
+
- Validation: ReadLints
|
|
108
|
+
|
|
109
|
+
## Estimated Time: 10 minutes
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
### Example 2: Complex Feature
|
|
113
|
+
User: "Add user dashboard"
|
|
114
|
+
|
|
115
|
+
Plan structure:
|
|
116
|
+
```markdown
|
|
117
|
+
## Summary
|
|
118
|
+
Create user dashboard with stats, activity feed, and settings panel.
|
|
119
|
+
|
|
120
|
+
## Files to Create
|
|
121
|
+
- `app/dashboard/page.tsx` - Main dashboard page
|
|
122
|
+
- Pattern: Follow @app/profile/page.tsx
|
|
123
|
+
- Tools: Write for new file
|
|
124
|
+
- `components/dashboard/StatsCard.tsx` - Stats component
|
|
125
|
+
- Pattern: Follow @components/Card.tsx
|
|
126
|
+
- Tools: Write for new file
|
|
127
|
+
- `app/api/dashboard/stats/route.ts` - Stats API
|
|
128
|
+
- Pattern: Follow @app/api/users/route.ts
|
|
129
|
+
- Tools: Write for new file
|
|
130
|
+
|
|
131
|
+
## Implementation Steps
|
|
132
|
+
1. Research existing patterns (3 min)
|
|
133
|
+
- Tool: Task (explore): "Find page patterns"
|
|
134
|
+
- Tool: Task (explore): "Find component patterns"
|
|
135
|
+
- Success: Patterns identified
|
|
136
|
+
|
|
137
|
+
2. Create API endpoint (5 min)
|
|
138
|
+
- Tool: Write
|
|
139
|
+
- Success: Endpoint created, tests pass
|
|
140
|
+
|
|
141
|
+
3. Build dashboard page (10 min)
|
|
142
|
+
- Tool: Write
|
|
143
|
+
- Success: Page renders
|
|
144
|
+
|
|
145
|
+
4. Create UI components (15 min)
|
|
146
|
+
- Tool: Write for each component
|
|
147
|
+
- Success: Components render
|
|
148
|
+
|
|
149
|
+
5. Integration testing (5 min)
|
|
150
|
+
- Tool: Shell: npm run test
|
|
151
|
+
- Tool: ReadLints
|
|
152
|
+
- Success: All tests pass, zero lints
|
|
153
|
+
|
|
154
|
+
## Tool Strategy
|
|
155
|
+
- Exploration: Task (explore) x2 in parallel
|
|
156
|
+
- Implementation: Write, StrReplace
|
|
157
|
+
- Validation: Shell (tests), ReadLints
|
|
158
|
+
- Questions: AskQuestion for dashboard widget priorities
|
|
159
|
+
|
|
160
|
+
## Risk Mitigation
|
|
161
|
+
- If API fails → Fallback: Mock data initially
|
|
162
|
+
- If tests fail → Use /grind loop (max 5 iterations)
|
|
163
|
+
- Checkpoint before: Integration step
|
|
164
|
+
|
|
165
|
+
## Estimated Time: 45 minutes
|
|
166
|
+
```
|
|
@@ -0,0 +1,130 @@
|
|
|
1
|
+
# Plan Mode Plan Validation
|
|
2
|
+
|
|
3
|
+
## Automatic Validation Steps
|
|
4
|
+
|
|
5
|
+
Before presenting plan to user:
|
|
6
|
+
|
|
7
|
+
1. **Feasibility Check**
|
|
8
|
+
- Task subagent: "Validate this plan"
|
|
9
|
+
- Check file accessibility
|
|
10
|
+
- Verify tool availability
|
|
11
|
+
- Estimate time accuracy
|
|
12
|
+
|
|
13
|
+
2. **Dependency Analysis**
|
|
14
|
+
- Step ordering correct
|
|
15
|
+
- No missing prerequisites
|
|
16
|
+
- Parallel opportunities identified
|
|
17
|
+
|
|
18
|
+
3. **Risk Assessment**
|
|
19
|
+
- High-risk steps flagged
|
|
20
|
+
- Fallback strategies defined
|
|
21
|
+
- Checkpoint locations set
|
|
22
|
+
|
|
23
|
+
4. **Tool Availability**
|
|
24
|
+
- MCP servers running
|
|
25
|
+
- Permissions verified
|
|
26
|
+
- Alternative tools identified
|
|
27
|
+
|
|
28
|
+
## Validation Output
|
|
29
|
+
|
|
30
|
+
If PASS: Present plan to user
|
|
31
|
+
If FAIL:
|
|
32
|
+
- List specific issues
|
|
33
|
+
- Suggest fixes
|
|
34
|
+
- Auto-correct if possible
|
|
35
|
+
- Re-validate
|
|
36
|
+
|
|
37
|
+
## Validation Checklist
|
|
38
|
+
|
|
39
|
+
### Feasibility Check
|
|
40
|
+
- [ ] All required files accessible
|
|
41
|
+
- [ ] No circular dependencies
|
|
42
|
+
- [ ] Estimated time realistic (based on complexity)
|
|
43
|
+
- [ ] Tools available for all steps
|
|
44
|
+
|
|
45
|
+
### Dependency Analysis
|
|
46
|
+
- [ ] Step ordering correct
|
|
47
|
+
- [ ] No missing prerequisites
|
|
48
|
+
- [ ] Parallel opportunities identified
|
|
49
|
+
|
|
50
|
+
### Risk Assessment
|
|
51
|
+
- [ ] High-risk steps flagged
|
|
52
|
+
- [ ] Fallback strategies defined
|
|
53
|
+
- [ ] Rollback plan (Checkpoints) identified
|
|
54
|
+
|
|
55
|
+
### Tool Availability
|
|
56
|
+
- [ ] Required MCP servers running
|
|
57
|
+
- [ ] Permissions verified
|
|
58
|
+
- [ ] Alternative tools identified
|
|
59
|
+
|
|
60
|
+
## Validation Subagent Pattern
|
|
61
|
+
|
|
62
|
+
```
|
|
63
|
+
Task:
|
|
64
|
+
description="Validate implementation plan"
|
|
65
|
+
prompt="Review this plan for feasibility:
|
|
66
|
+
|
|
67
|
+
## Plan to Validate
|
|
68
|
+
[Plan content]
|
|
69
|
+
|
|
70
|
+
## Validation Checklist
|
|
71
|
+
1. Check if all referenced files exist
|
|
72
|
+
2. Verify tool availability
|
|
73
|
+
3. Estimate actual time based on complexity
|
|
74
|
+
4. Identify potential blockers
|
|
75
|
+
5. Suggest improvements
|
|
76
|
+
|
|
77
|
+
## Output Format
|
|
78
|
+
Pass/Fail: [Your verdict]
|
|
79
|
+
Issues: [List specific problems]
|
|
80
|
+
Suggestions: [Concrete improvements]
|
|
81
|
+
Confidence: [High/Medium/Low]"
|
|
82
|
+
subagent_type="generalPurpose"
|
|
83
|
+
readonly=true
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
## Examples
|
|
87
|
+
|
|
88
|
+
### Example 1: Simple Plan Validation
|
|
89
|
+
|
|
90
|
+
Plan: "Add login button to header"
|
|
91
|
+
|
|
92
|
+
Validation checks:
|
|
93
|
+
- ✅ File exists: components/Header.tsx
|
|
94
|
+
- ✅ Tool available: StrReplace
|
|
95
|
+
- ✅ Time realistic: 10 minutes
|
|
96
|
+
- ✅ No dependencies
|
|
97
|
+
- ✅ Low risk
|
|
98
|
+
|
|
99
|
+
Result: PASS → Present to user
|
|
100
|
+
|
|
101
|
+
### Example 2: Complex Plan Validation
|
|
102
|
+
|
|
103
|
+
Plan: "Migrate authentication from JWT to sessions"
|
|
104
|
+
|
|
105
|
+
Validation checks:
|
|
106
|
+
- ✅ Files accessible: src/auth/, app/api/auth/
|
|
107
|
+
- ⚠️ Risk: Breaking change (checkpoint needed)
|
|
108
|
+
- ⚠️ Time: 2 hours might be optimistic → suggest 3 hours
|
|
109
|
+
- ✅ Tools available: Read, Write, Shell, ReadLints
|
|
110
|
+
- ✅ Fallback: Keep JWT code until tests pass
|
|
111
|
+
|
|
112
|
+
Result: PASS with warnings → Present with caveats
|
|
113
|
+
|
|
114
|
+
### Example 3: Failed Validation
|
|
115
|
+
|
|
116
|
+
Plan: "Rewrite entire backend in Rust"
|
|
117
|
+
|
|
118
|
+
Validation checks:
|
|
119
|
+
- ❌ Time unrealistic: 1 week → needs 2-3 months
|
|
120
|
+
- ❌ Risk: Critical system rewrite
|
|
121
|
+
- ❌ Missing: Testing strategy
|
|
122
|
+
- ❌ Missing: Rollback plan
|
|
123
|
+
- ❌ Dependencies: Team training needed
|
|
124
|
+
|
|
125
|
+
Result: FAIL → Suggest phased approach:
|
|
126
|
+
1. Start with non-critical service
|
|
127
|
+
2. Add testing strategy
|
|
128
|
+
3. Create rollback plan
|
|
129
|
+
4. Revise time estimate
|
|
130
|
+
5. Re-validate
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# Security-Critical Operations
|
|
2
|
+
|
|
3
|
+
## Triggers
|
|
4
|
+
Keywords: "auth", "security", "password", "token", "encrypt", "API key", "secret", "credential"
|
|
5
|
+
|
|
6
|
+
## Critical Rules
|
|
7
|
+
- Never hardcode credentials - use environment variables
|
|
8
|
+
- Always validate and sanitize user input
|
|
9
|
+
- Use parameterized queries (no SQL injection)
|
|
10
|
+
- Hash passwords with bcrypt/argon2
|
|
11
|
+
- Use strong crypto (SHA-256+, AES-256)
|
|
12
|
+
|
|
13
|
+
## Security Checklist
|
|
14
|
+
See `.cursor/security-report.md` for OWASP Top 10 checklist
|
|
15
|
+
|
|
16
|
+
## Examples
|
|
17
|
+
- Auth pattern: `@src/auth/validateToken.ts`
|
|
18
|
+
- Password hashing: `@src/lib/password.ts`
|
|
19
|
+
- Input validation: `@src/validators/userSchema.ts`
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Tool Auto-Selection
|
|
2
|
+
|
|
3
|
+
## Tool Cost Hierarchy (Start Cheap, Escalate)
|
|
4
|
+
|
|
5
|
+
**Tier 1 (Cheapest)**: Read, Glob, Grep, Shell
|
|
6
|
+
**Tier 2 (Moderate)**: SemanticSearch, StrReplace, Write
|
|
7
|
+
**Tier 3 (Higher)**: Task, ReadLints
|
|
8
|
+
**Tier 4 (Most Expensive)**: Parallel subagents, Browser MCP
|
|
9
|
+
|
|
10
|
+
## Automatic Triggers
|
|
11
|
+
|
|
12
|
+
### After Code Changes
|
|
13
|
+
- After StrReplace/Write → ReadLints (automatic)
|
|
14
|
+
- After substantive changes → Shell (tests)
|
|
15
|
+
|
|
16
|
+
### For Exploration
|
|
17
|
+
- Know path? → Read
|
|
18
|
+
- Pattern? → Glob + Read
|
|
19
|
+
- Exact text? → Grep
|
|
20
|
+
- Concept? → SemanticSearch
|
|
21
|
+
- Broad? → Task (explore)
|
|
22
|
+
|
|
23
|
+
### For Implementation
|
|
24
|
+
- New file? → Write
|
|
25
|
+
- <50 lines? → StrReplace
|
|
26
|
+
- >50 lines? → Write (entire file)
|
|
27
|
+
|
|
28
|
+
### For Complex Tasks
|
|
29
|
+
- >10 steps or >5 files → Launch 3-4 parallel subagents
|
|
30
|
+
|
|
31
|
+
## Rules
|
|
32
|
+
|
|
33
|
+
1. Always start with Tier 1, escalate only if needed
|
|
34
|
+
2. Never skip tiers unless justified
|
|
35
|
+
3. Run ReadLints after EVERY code change
|
|
36
|
+
4. Use parallel subagents for broad exploration (>3 files)
|
|
37
|
+
|
|
38
|
+
## Decision Trees
|
|
39
|
+
See `.cursor/skills/tool-selection/SKILL.md` for complete decision trees and patterns.
|
|
40
|
+
|
|
41
|
+
## Anti-Patterns to Avoid
|
|
42
|
+
- ❌ Tool hoarding (using 5 tools when 1 works)
|
|
43
|
+
- ❌ Using expensive tools for simple tasks
|
|
44
|
+
- ❌ Skipping validation after edits
|
|
45
|
+
- ❌ No checkpoints for risky changes
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
# Tool Selection Strategy
|
|
2
|
+
|
|
3
|
+
## Cost Hierarchy (Start Cheap)
|
|
4
|
+
Tier 1: Read, Glob, Grep (fastest)
|
|
5
|
+
Tier 2: SemanticSearch, StrReplace, Write
|
|
6
|
+
Tier 3: Task, Shell, ReadLints
|
|
7
|
+
Tier 4: Parallel subagents, Browser MCP
|
|
8
|
+
|
|
9
|
+
## Automatic Triggers
|
|
10
|
+
- After edits → ReadLints automatically
|
|
11
|
+
- After substantive changes → Shell (tests)
|
|
12
|
+
- Ambiguous requirements → AskQuestion (batch)
|
|
13
|
+
- Complex exploration → Task (parallel subagents)
|
|
14
|
+
|
|
15
|
+
## MCP Servers
|
|
16
|
+
- cursor-ide-browser: UI changes, visual verification
|
|
17
|
+
- user-github: PR/issue operations
|
|
18
|
+
- user-ESLint: Code quality checks
|
|
19
|
+
- user-context7: Library documentation
|
|
20
|
+
|
|
21
|
+
## Pattern
|
|
22
|
+
Follow tool selection examples in @.cursor/skills/tool-selection/SKILL.md
|