@soleri/forge 5.4.0 → 5.6.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/dist/scaffolder.js +98 -6
- package/dist/scaffolder.js.map +1 -1
- package/dist/skills/brain-debrief.md +186 -0
- package/dist/skills/brainstorming.md +170 -0
- package/dist/skills/code-patrol.md +176 -0
- package/dist/skills/context-resume.md +143 -0
- package/dist/skills/executing-plans.md +201 -0
- package/dist/skills/fix-and-learn.md +164 -0
- package/dist/skills/health-check.md +225 -0
- package/dist/skills/knowledge-harvest.md +178 -0
- package/dist/skills/onboard-me.md +197 -0
- package/dist/skills/retrospective.md +189 -0
- package/dist/skills/second-opinion.md +142 -0
- package/dist/skills/skills/brain-debrief.md +214 -0
- package/dist/skills/skills/brainstorming.md +180 -0
- package/dist/skills/skills/code-patrol.md +178 -0
- package/dist/skills/skills/context-resume.md +146 -0
- package/dist/skills/skills/executing-plans.md +216 -0
- package/dist/skills/skills/fix-and-learn.md +167 -0
- package/dist/skills/skills/health-check.md +231 -0
- package/dist/skills/skills/knowledge-harvest.md +185 -0
- package/dist/skills/skills/onboard-me.md +198 -0
- package/dist/skills/skills/retrospective.md +205 -0
- package/dist/skills/skills/second-opinion.md +149 -0
- package/dist/skills/skills/systematic-debugging.md +241 -0
- package/dist/skills/skills/test-driven-development.md +281 -0
- package/dist/skills/skills/vault-capture.md +170 -0
- package/dist/skills/skills/vault-navigator.md +140 -0
- package/dist/skills/skills/verification-before-completion.md +182 -0
- package/dist/skills/skills/writing-plans.md +215 -0
- package/dist/skills/systematic-debugging.md +230 -0
- package/dist/skills/test-driven-development.md +266 -0
- package/dist/skills/vault-capture.md +154 -0
- package/dist/skills/vault-navigator.md +129 -0
- package/dist/skills/verification-before-completion.md +170 -0
- package/dist/skills/writing-plans.md +207 -0
- package/dist/templates/entry-point.js +8 -0
- package/dist/templates/entry-point.js.map +1 -1
- package/dist/templates/readme.js +38 -0
- package/dist/templates/readme.js.map +1 -1
- package/dist/templates/setup-script.js +26 -0
- package/dist/templates/setup-script.js.map +1 -1
- package/dist/templates/skills.d.ts +16 -0
- package/dist/templates/skills.js +73 -0
- package/dist/templates/skills.js.map +1 -0
- package/dist/templates/test-facades.js +35 -6
- package/dist/templates/test-facades.js.map +1 -1
- package/package.json +2 -2
- package/src/__tests__/scaffolder.test.ts +115 -2
- package/src/scaffolder.ts +100 -6
- package/src/skills/brain-debrief.md +214 -0
- package/src/skills/brainstorming.md +180 -0
- package/src/skills/code-patrol.md +178 -0
- package/src/skills/context-resume.md +146 -0
- package/src/skills/executing-plans.md +216 -0
- package/src/skills/fix-and-learn.md +167 -0
- package/src/skills/health-check.md +231 -0
- package/src/skills/knowledge-harvest.md +185 -0
- package/src/skills/onboard-me.md +198 -0
- package/src/skills/retrospective.md +205 -0
- package/src/skills/second-opinion.md +149 -0
- package/src/skills/systematic-debugging.md +241 -0
- package/src/skills/test-driven-development.md +281 -0
- package/src/skills/vault-capture.md +170 -0
- package/src/skills/vault-navigator.md +140 -0
- package/src/skills/verification-before-completion.md +182 -0
- package/src/skills/writing-plans.md +215 -0
- package/src/templates/entry-point.ts +8 -0
- package/src/templates/readme.ts +38 -0
- package/src/templates/setup-script.ts +26 -0
- package/src/templates/skills.ts +82 -0
- package/src/templates/test-facades.ts +35 -6
|
@@ -0,0 +1,176 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: code-patrol
|
|
3
|
+
description: Use when the user asks "review this code", "check this against patterns", "code patrol", "does this follow our rules", "validate against vault", "check for anti-patterns", or wants code reviewed not against generic lint rules but against the project's own captured patterns, anti-patterns, and conventions.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Code Patrol — Review Code Against Your Own Knowledge
|
|
7
|
+
|
|
8
|
+
Review code against the vault's patterns, anti-patterns, and project conventions — not generic lint rules, but YOUR team's captured knowledge applied to new code. Catches violations that no linter knows about.
|
|
9
|
+
|
|
10
|
+
## When to Use
|
|
11
|
+
|
|
12
|
+
- Before committing or creating a PR
|
|
13
|
+
- "Does this follow our patterns?"
|
|
14
|
+
- "Check this code against our rules"
|
|
15
|
+
- Code review with institutional knowledge
|
|
16
|
+
- After writing implementation code
|
|
17
|
+
|
|
18
|
+
## The Magic: Project-Specific Code Intelligence
|
|
19
|
+
|
|
20
|
+
### Step 1: Understand the Code's Domain
|
|
21
|
+
|
|
22
|
+
Classify what domain this code belongs to:
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
YOUR_AGENT_core op:route_intent
|
|
26
|
+
params: { prompt: "Code review: <brief description of the code>" }
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
Determine which vault domains are relevant:
|
|
30
|
+
|
|
31
|
+
```
|
|
32
|
+
YOUR_AGENT_core op:vault_domains
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
### Step 2: Load Relevant Patterns
|
|
36
|
+
|
|
37
|
+
Search for patterns in the code's domain:
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
YOUR_AGENT_core op:search_intelligent
|
|
41
|
+
params: { query: "<what this code does>" }
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Search specifically for anti-patterns to check against:
|
|
45
|
+
|
|
46
|
+
```
|
|
47
|
+
YOUR_AGENT_core op:search
|
|
48
|
+
params: { type: "anti-pattern" }
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
Search for critical rules that must not be violated:
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
YOUR_AGENT_core op:search
|
|
55
|
+
params: { severity: "critical" }
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
Load project-specific rules:
|
|
59
|
+
|
|
60
|
+
```
|
|
61
|
+
YOUR_AGENT_core op:project_list_rules
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
```
|
|
65
|
+
YOUR_AGENT_core op:get_behavior_rules
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
Get proven approaches from the brain:
|
|
69
|
+
|
|
70
|
+
```
|
|
71
|
+
YOUR_AGENT_core op:brain_strengths
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
### Step 3: Review the Code
|
|
75
|
+
|
|
76
|
+
With vault patterns loaded, review the code checking for:
|
|
77
|
+
|
|
78
|
+
| Check | Source | Severity |
|
|
79
|
+
|-------|--------|----------|
|
|
80
|
+
| Violates a critical rule | `search (severity: critical)` | Must fix |
|
|
81
|
+
| Matches a known anti-pattern | `search (type: anti-pattern)` | Must fix |
|
|
82
|
+
| Doesn't follow a proven pattern | `brain_strengths` | Should fix |
|
|
83
|
+
| Breaks project conventions | `project_list_rules` | Should fix |
|
|
84
|
+
| Misses an opportunity to use a pattern | `search_intelligent` | Could improve |
|
|
85
|
+
|
|
86
|
+
### Step 4: Present the Review
|
|
87
|
+
|
|
88
|
+
```
|
|
89
|
+
## Code Patrol Report
|
|
90
|
+
|
|
91
|
+
### Must Fix (Critical)
|
|
92
|
+
- **[Rule name]**: [What's wrong and why]
|
|
93
|
+
Vault ref: [entry title] (severity: critical)
|
|
94
|
+
Fix: [How to fix it]
|
|
95
|
+
|
|
96
|
+
### Should Fix (Warning)
|
|
97
|
+
- **[Anti-pattern name]**: [What's wrong]
|
|
98
|
+
Vault ref: [entry title] (type: anti-pattern)
|
|
99
|
+
Better approach: [The pattern to follow]
|
|
100
|
+
|
|
101
|
+
### Could Improve (Suggestion)
|
|
102
|
+
- **[Pattern opportunity]**: [The code works but could benefit from...]
|
|
103
|
+
Vault ref: [entry title] (type: pattern)
|
|
104
|
+
|
|
105
|
+
### Looks Good
|
|
106
|
+
- [What the code does well — patterns it follows correctly]
|
|
107
|
+
|
|
108
|
+
### Summary
|
|
109
|
+
X critical issues, Y warnings, Z suggestions
|
|
110
|
+
Patterns followed: [list]
|
|
111
|
+
Patterns missed: [list]
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
### Step 5: Learn From the Review
|
|
115
|
+
|
|
116
|
+
If the review reveals a new pattern or anti-pattern not in the vault, capture it:
|
|
117
|
+
|
|
118
|
+
```
|
|
119
|
+
YOUR_AGENT_core op:capture_quick
|
|
120
|
+
params: {
|
|
121
|
+
title: "<new pattern or anti-pattern discovered>",
|
|
122
|
+
description: "<what it is, when it applies>"
|
|
123
|
+
}
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
If the review reveals a knowledge gap, note it:
|
|
127
|
+
|
|
128
|
+
```
|
|
129
|
+
YOUR_AGENT_core op:capture_knowledge
|
|
130
|
+
params: {
|
|
131
|
+
title: "<missing convention>",
|
|
132
|
+
description: "<this should be documented as a project rule>",
|
|
133
|
+
type: "principle",
|
|
134
|
+
category: "<domain>",
|
|
135
|
+
tags: ["convention", "code-review"]
|
|
136
|
+
}
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
### Step 6: Verify After Fixes
|
|
140
|
+
|
|
141
|
+
After the user applies fixes, re-run the patrol to confirm clean:
|
|
142
|
+
|
|
143
|
+
```
|
|
144
|
+
YOUR_AGENT_core op:search_intelligent
|
|
145
|
+
params: { query: "<re-check the specific violations>" }
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
Check system health:
|
|
149
|
+
```
|
|
150
|
+
YOUR_AGENT_core op:admin_health
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
## The Magic
|
|
154
|
+
|
|
155
|
+
This feels like magic because:
|
|
156
|
+
1. It's not ESLint — it catches things like "we decided not to use inheritance here" or "this API pattern caused production issues last month"
|
|
157
|
+
2. The rules come from YOUR team's experience, not a generic config file
|
|
158
|
+
3. It gets smarter over time — every captured pattern becomes a new check
|
|
159
|
+
4. It catches institutional knowledge violations that no static analyzer can
|
|
160
|
+
|
|
161
|
+
A linter checks syntax. Code patrol checks wisdom.
|
|
162
|
+
|
|
163
|
+
## Agent Tools Reference
|
|
164
|
+
|
|
165
|
+
| Op | When to Use |
|
|
166
|
+
|----|-------------|
|
|
167
|
+
| `route_intent` | Classify the code's domain |
|
|
168
|
+
| `vault_domains` | See which domains are relevant |
|
|
169
|
+
| `search_intelligent` | Find relevant patterns for this code |
|
|
170
|
+
| `search` | Find anti-patterns and critical rules |
|
|
171
|
+
| `project_list_rules` | Project-specific conventions |
|
|
172
|
+
| `get_behavior_rules` | Behavioral rules |
|
|
173
|
+
| `brain_strengths` | Proven patterns to check against |
|
|
174
|
+
| `capture_quick` | Capture new patterns discovered during review |
|
|
175
|
+
| `capture_knowledge` | Capture new conventions |
|
|
176
|
+
| `admin_health` | Post-review health check |
|
|
@@ -0,0 +1,143 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: context-resume
|
|
3
|
+
description: Use when starting a new session, returning to work, or when the user asks "what was I working on", "where did I leave off", "catch me up", "morning standup", "resume", "what's the status". Reconstructs full working context from memory, plans, and sessions.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Context Resume — Pick Up Where You Left Off
|
|
7
|
+
|
|
8
|
+
Reconstruct your full working context in seconds. Chains memory, plans, sessions, and brain to rebuild exactly where you left off — even across session boundaries and context compactions.
|
|
9
|
+
|
|
10
|
+
## When to Use
|
|
11
|
+
|
|
12
|
+
- Starting a new Claude Code session
|
|
13
|
+
- Returning after a break
|
|
14
|
+
- "What was I working on?"
|
|
15
|
+
- "Morning standup"
|
|
16
|
+
- After context compaction (session_capture fires automatically, this reads it back)
|
|
17
|
+
|
|
18
|
+
## The Magic: Full Context Reconstruction
|
|
19
|
+
|
|
20
|
+
### Step 1: Load Active Plans
|
|
21
|
+
|
|
22
|
+
Check for plans in progress — these are your active work streams:
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
YOUR_AGENT_core op:plan_stats
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
For each active plan, load its details and task status:
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
YOUR_AGENT_core op:get_plan
|
|
32
|
+
YOUR_AGENT_core op:plan_list_tasks
|
|
33
|
+
params: { planId: "<id>" }
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
Present:
|
|
37
|
+
- Plan objective and current status
|
|
38
|
+
- Which tasks are completed, in progress, or pending
|
|
39
|
+
- What's next to do
|
|
40
|
+
|
|
41
|
+
### Step 2: Search Recent Memory
|
|
42
|
+
|
|
43
|
+
Load the latest session summaries — these capture what happened before:
|
|
44
|
+
|
|
45
|
+
```
|
|
46
|
+
YOUR_AGENT_core op:memory_search
|
|
47
|
+
params: { query: "session summary" }
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
```
|
|
51
|
+
YOUR_AGENT_core op:memory_list
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
Also check recent vault captures — what knowledge was added recently?
|
|
55
|
+
|
|
56
|
+
```
|
|
57
|
+
YOUR_AGENT_core op:vault_recent
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
### Step 3: Check Active Loops
|
|
61
|
+
|
|
62
|
+
See if there's a validation loop in progress:
|
|
63
|
+
|
|
64
|
+
```
|
|
65
|
+
YOUR_AGENT_core op:loop_is_active
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
If active:
|
|
69
|
+
```
|
|
70
|
+
YOUR_AGENT_core op:loop_status
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
This tells you if an iterative workflow (TDD, debugging, migration) was mid-flight.
|
|
74
|
+
|
|
75
|
+
### Step 4: Brain Snapshot
|
|
76
|
+
|
|
77
|
+
Get the latest brain insights relevant to current work:
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
YOUR_AGENT_core op:brain_strengths
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
### Step 5: System Health
|
|
84
|
+
|
|
85
|
+
Quick health check to make sure everything is working:
|
|
86
|
+
|
|
87
|
+
```
|
|
88
|
+
YOUR_AGENT_core op:admin_health
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
## Presenting the Resume
|
|
92
|
+
|
|
93
|
+
Format as a concise standup:
|
|
94
|
+
|
|
95
|
+
```
|
|
96
|
+
## Where You Left Off
|
|
97
|
+
|
|
98
|
+
**Active Plans:**
|
|
99
|
+
- [Plan name] — X/Y tasks complete, next: [task description]
|
|
100
|
+
|
|
101
|
+
**Last Session:**
|
|
102
|
+
- [Summary from memory — what was done, key decisions]
|
|
103
|
+
|
|
104
|
+
**Recent Captures:**
|
|
105
|
+
- [New patterns/anti-patterns added to vault]
|
|
106
|
+
|
|
107
|
+
**Active Loops:**
|
|
108
|
+
- [Any in-progress validation loops]
|
|
109
|
+
|
|
110
|
+
**Brain Says:**
|
|
111
|
+
- [Top relevant patterns for current work]
|
|
112
|
+
|
|
113
|
+
**Health:** [OK / Issues found]
|
|
114
|
+
|
|
115
|
+
## Recommended Next Step
|
|
116
|
+
[Based on active plans and last session context]
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
## The Magic
|
|
120
|
+
|
|
121
|
+
This feels like magic because the user just says "catch me up" and the agent:
|
|
122
|
+
1. Knows what plans are active and where they stand
|
|
123
|
+
2. Remembers what happened last session (even across context compactions)
|
|
124
|
+
3. Shows what knowledge was recently captured
|
|
125
|
+
4. Detects in-flight loops
|
|
126
|
+
5. Recommends what to work on next
|
|
127
|
+
|
|
128
|
+
No other tool does this — the agent has genuine persistent memory.
|
|
129
|
+
|
|
130
|
+
## Agent Tools Reference
|
|
131
|
+
|
|
132
|
+
| Op | When to Use |
|
|
133
|
+
|----|-------------|
|
|
134
|
+
| `plan_stats` | Find active plans |
|
|
135
|
+
| `get_plan` | Load plan details |
|
|
136
|
+
| `plan_list_tasks` | See task status within plan |
|
|
137
|
+
| `memory_search` | Find session summaries |
|
|
138
|
+
| `memory_list` | Browse recent memories |
|
|
139
|
+
| `vault_recent` | Recently captured knowledge |
|
|
140
|
+
| `loop_is_active` | Check for in-flight loops |
|
|
141
|
+
| `loop_status` | Get loop details |
|
|
142
|
+
| `brain_strengths` | Relevant proven patterns |
|
|
143
|
+
| `admin_health` | System health check |
|
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: executing-plans
|
|
3
|
+
description: Use when you have a written implementation plan to execute in a separate session with review checkpoints
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- Adapted from superpowers (MIT License) -->
|
|
7
|
+
|
|
8
|
+
# Executing Plans
|
|
9
|
+
|
|
10
|
+
## Overview
|
|
11
|
+
|
|
12
|
+
Load plan, review critically, execute tasks in batches, report for review between batches.
|
|
13
|
+
|
|
14
|
+
**Core principle:** Batch execution with checkpoints for architect review.
|
|
15
|
+
|
|
16
|
+
**Announce at start:** "I'm using the executing-plans skill to implement this plan."
|
|
17
|
+
|
|
18
|
+
## The Process
|
|
19
|
+
|
|
20
|
+
### Step 1: Load and Review Plan
|
|
21
|
+
|
|
22
|
+
First, load the tracked plan from the agent:
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
YOUR_AGENT_core op:get_plan
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
List all tasks to understand scope:
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
YOUR_AGENT_core op:plan_list_tasks
|
|
32
|
+
params: { planId: "<id>" }
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Check plan stats for an overview:
|
|
36
|
+
|
|
37
|
+
```
|
|
38
|
+
YOUR_AGENT_core op:plan_stats
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
If no tracked plan exists, read the plan file from `docs/plans/`.
|
|
42
|
+
|
|
43
|
+
Review critically — identify any questions or concerns about the plan.
|
|
44
|
+
- If concerns: Raise them with your human partner before starting
|
|
45
|
+
- If no concerns: Create TodoWrite and proceed
|
|
46
|
+
|
|
47
|
+
### Step 2: Start Execution Loop
|
|
48
|
+
|
|
49
|
+
For iterative tasks, start a validation loop:
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
YOUR_AGENT_core op:loop_start
|
|
53
|
+
params: { prompt: "<plan objective>", mode: "custom" }
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
The loop tracks iterations and validates progress automatically.
|
|
57
|
+
|
|
58
|
+
### Step 3: Execute Batch
|
|
59
|
+
**Default: First 3 tasks**
|
|
60
|
+
|
|
61
|
+
For each task:
|
|
62
|
+
1. Mark as in_progress:
|
|
63
|
+
```
|
|
64
|
+
YOUR_AGENT_core op:update_task
|
|
65
|
+
params: { planId: "<id>", taskIndex: <n>, status: "in_progress" }
|
|
66
|
+
```
|
|
67
|
+
2. Follow each step exactly (plan has bite-sized steps)
|
|
68
|
+
3. Run verifications as specified
|
|
69
|
+
4. Mark as completed:
|
|
70
|
+
```
|
|
71
|
+
YOUR_AGENT_core op:update_task
|
|
72
|
+
params: { planId: "<id>", taskIndex: <n>, status: "completed" }
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
After each task, iterate the loop:
|
|
76
|
+
|
|
77
|
+
```
|
|
78
|
+
YOUR_AGENT_core op:loop_iterate
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
### Step 4: Report
|
|
82
|
+
When batch complete:
|
|
83
|
+
- Show what was implemented
|
|
84
|
+
- Show verification output
|
|
85
|
+
- Check loop status:
|
|
86
|
+
```
|
|
87
|
+
YOUR_AGENT_core op:loop_status
|
|
88
|
+
```
|
|
89
|
+
- Say: "Ready for feedback."
|
|
90
|
+
|
|
91
|
+
### Step 5: Continue
|
|
92
|
+
Based on feedback:
|
|
93
|
+
- Apply changes if needed
|
|
94
|
+
- Execute next batch
|
|
95
|
+
- Repeat until complete
|
|
96
|
+
|
|
97
|
+
### Step 6: Complete Development
|
|
98
|
+
|
|
99
|
+
After all tasks complete and verified:
|
|
100
|
+
|
|
101
|
+
1. Run final verification (use verification-before-completion skill)
|
|
102
|
+
|
|
103
|
+
2. Complete the validation loop:
|
|
104
|
+
```
|
|
105
|
+
YOUR_AGENT_core op:loop_complete
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
3. Reconcile plan — compare what was planned vs what actually happened:
|
|
109
|
+
```
|
|
110
|
+
YOUR_AGENT_core op:plan_reconcile
|
|
111
|
+
params: {
|
|
112
|
+
planId: "<id>",
|
|
113
|
+
actualSteps: "<description of what was actually done>",
|
|
114
|
+
driftNotes: "<what differed from the plan>"
|
|
115
|
+
}
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
4. Complete plan lifecycle — extract knowledge and archive:
|
|
119
|
+
```
|
|
120
|
+
YOUR_AGENT_core op:plan_complete_lifecycle
|
|
121
|
+
params: { planId: "<id>" }
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
5. Archive the plan for historical reference:
|
|
125
|
+
```
|
|
126
|
+
YOUR_AGENT_core op:plan_archive
|
|
127
|
+
params: { planId: "<id>" }
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
6. Capture a session summary:
|
|
131
|
+
```
|
|
132
|
+
YOUR_AGENT_core op:session_capture
|
|
133
|
+
params: { summary: "<what was built, key decisions, files modified>" }
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
## Capture Learnings During Execution
|
|
137
|
+
|
|
138
|
+
If you discover something worth remembering during execution (a gotcha, a better approach, an anti-pattern):
|
|
139
|
+
|
|
140
|
+
```
|
|
141
|
+
YOUR_AGENT_core op:capture_quick
|
|
142
|
+
params: {
|
|
143
|
+
title: "<what you learned>",
|
|
144
|
+
description: "<context, why it matters, when it applies>"
|
|
145
|
+
}
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
Don't wait until the end — capture insights as they happen.
|
|
149
|
+
|
|
150
|
+
## When to Stop and Ask for Help
|
|
151
|
+
|
|
152
|
+
**STOP executing immediately when:**
|
|
153
|
+
- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
|
|
154
|
+
- Plan has critical gaps preventing starting
|
|
155
|
+
- You don't understand an instruction
|
|
156
|
+
- Verification fails repeatedly
|
|
157
|
+
|
|
158
|
+
**Ask for clarification rather than guessing.**
|
|
159
|
+
|
|
160
|
+
## When to Revisit Earlier Steps
|
|
161
|
+
|
|
162
|
+
**Return to Review (Step 1) when:**
|
|
163
|
+
- Partner updates the plan based on your feedback
|
|
164
|
+
- Fundamental approach needs rethinking
|
|
165
|
+
|
|
166
|
+
**Don't force through blockers** - stop and ask.
|
|
167
|
+
|
|
168
|
+
## Remember
|
|
169
|
+
- Review plan critically first
|
|
170
|
+
- Follow plan steps exactly
|
|
171
|
+
- Don't skip verifications
|
|
172
|
+
- Between batches: just report and wait
|
|
173
|
+
- Stop when blocked, don't guess
|
|
174
|
+
- Capture learnings as you go, not just at the end
|
|
175
|
+
- Always reconcile the plan after execution — drift data makes future plans better
|
|
176
|
+
- Never start implementation on main/master branch without explicit user consent
|
|
177
|
+
|
|
178
|
+
## Agent Tools Reference
|
|
179
|
+
|
|
180
|
+
| Op | When to Use |
|
|
181
|
+
|----|-------------|
|
|
182
|
+
| `get_plan` | Load tracked plan |
|
|
183
|
+
| `plan_list_tasks` | List all tasks in the plan |
|
|
184
|
+
| `plan_stats` | Plan overview and metrics |
|
|
185
|
+
| `update_task` | Mark tasks in_progress / completed |
|
|
186
|
+
| `loop_start` | Begin validation loop for iterative execution |
|
|
187
|
+
| `loop_iterate` | Track each iteration |
|
|
188
|
+
| `loop_status` | Check loop progress |
|
|
189
|
+
| `loop_complete` | Finish validation loop |
|
|
190
|
+
| `plan_reconcile` | Compare planned vs actual (post-execution) |
|
|
191
|
+
| `plan_complete_lifecycle` | Extract knowledge from execution |
|
|
192
|
+
| `plan_archive` | Archive plan for history |
|
|
193
|
+
| `session_capture` | Save session context |
|
|
194
|
+
| `capture_quick` | Capture mid-execution learnings |
|
|
195
|
+
|
|
196
|
+
## Integration
|
|
197
|
+
|
|
198
|
+
**Required workflow skills:**
|
|
199
|
+
- writing-plans — Creates the plan this skill executes
|
|
200
|
+
- verification-before-completion — Verify work before claiming completion
|
|
201
|
+
- test-driven-development — Follow TDD for each implementation step
|
|
@@ -0,0 +1,164 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: fix-and-learn
|
|
3
|
+
description: Use AFTER systematic-debugging completes to execute the fix and capture the learning in the vault. Invoke this skill when moving from diagnosis to repair for bugs, broken behavior, errors, regressions, or unexpected results. Chains with systematic-debugging — debugging finds root cause, this skill fixes and captures the anti-pattern.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Fix & Learn — Debug, Repair, Capture
|
|
7
|
+
|
|
8
|
+
Fix bugs through a structured recovery workflow, then capture the root cause as a reusable anti-pattern. The learning step is what makes fixes compound across sessions.
|
|
9
|
+
|
|
10
|
+
## When to Use
|
|
11
|
+
|
|
12
|
+
Any time something is broken, behaving unexpectedly, or producing errors. This includes runtime bugs, visual regressions, type errors, and "it used to work" situations.
|
|
13
|
+
|
|
14
|
+
## The Search Order — MANDATORY
|
|
15
|
+
|
|
16
|
+
**Never jump to writing code.** Always follow this lookup order:
|
|
17
|
+
|
|
18
|
+
1. **Vault first** — has this been solved before?
|
|
19
|
+
2. **Web search** — is there a known solution or pattern?
|
|
20
|
+
3. **Plan the fix** — design the approach before touching code
|
|
21
|
+
4. **Implement** — only after steps 1-3
|
|
22
|
+
|
|
23
|
+
Skipping to implementation is the #1 cause of wasted time and recurring bugs.
|
|
24
|
+
|
|
25
|
+
## Orchestration Sequence
|
|
26
|
+
|
|
27
|
+
### Step 1: Classify and Route
|
|
28
|
+
|
|
29
|
+
Classify the intent to confirm this is a FIX and get routing context:
|
|
30
|
+
|
|
31
|
+
```
|
|
32
|
+
YOUR_AGENT_core op:route_intent
|
|
33
|
+
params: { prompt: "<user's bug description>" }
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
### Step 2: Check Vault First
|
|
37
|
+
|
|
38
|
+
Search for this bug or similar issues:
|
|
39
|
+
|
|
40
|
+
```
|
|
41
|
+
YOUR_AGENT_core op:search_intelligent
|
|
42
|
+
params: { query: "<error message or bug description>" }
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
Check memory for patterns across sessions:
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
YOUR_AGENT_core op:memory_search
|
|
49
|
+
params: { query: "<bug description>" }
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
Check memory topics — are bugs clustering in a specific area?
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
YOUR_AGENT_core op:memory_topics
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
Check memory stats to understand the debugging landscape:
|
|
59
|
+
|
|
60
|
+
```
|
|
61
|
+
YOUR_AGENT_core op:memory_stats
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
If vault returns a match with high confidence — **use it**. Don't re-investigate what's already been solved.
|
|
65
|
+
|
|
66
|
+
### Step 3: Search the Web
|
|
67
|
+
|
|
68
|
+
If the vault has no answer, search for existing solutions before investigating from scratch:
|
|
69
|
+
- Known issues in the library/framework
|
|
70
|
+
- Stack Overflow answers for the exact error
|
|
71
|
+
- GitHub issues on relevant repos
|
|
72
|
+
- Official documentation for the API or feature involved
|
|
73
|
+
|
|
74
|
+
A 30-second web search can save hours of investigation.
|
|
75
|
+
|
|
76
|
+
### Step 4: Start Fix Loop
|
|
77
|
+
|
|
78
|
+
For complex bugs requiring multiple iterations, start a validation loop:
|
|
79
|
+
|
|
80
|
+
```
|
|
81
|
+
YOUR_AGENT_core op:loop_start
|
|
82
|
+
params: { prompt: "Fix: <bug description>", mode: "custom" }
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
### Step 5: Diagnose and Fix
|
|
86
|
+
|
|
87
|
+
Only if Steps 2-3 didn't produce a solution, apply the systematic debugging approach (use systematic-debugging skill):
|
|
88
|
+
1. Reproduce the issue
|
|
89
|
+
2. Isolate the root cause
|
|
90
|
+
3. **Plan the fix before writing code** — even a one-line mental plan
|
|
91
|
+
4. Implement the fix
|
|
92
|
+
5. Verify the fix resolves the issue without regressions
|
|
93
|
+
|
|
94
|
+
Track each iteration:
|
|
95
|
+
|
|
96
|
+
```
|
|
97
|
+
YOUR_AGENT_core op:loop_iterate
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
### Step 6: Validate the Fix
|
|
101
|
+
|
|
102
|
+
Run the project's test suite to ensure the fix didn't introduce regressions. Use the verification-before-completion skill to confirm all checks pass.
|
|
103
|
+
|
|
104
|
+
Complete the loop when validated:
|
|
105
|
+
|
|
106
|
+
```
|
|
107
|
+
YOUR_AGENT_core op:loop_complete
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
### Step 7: Capture the Learning
|
|
111
|
+
|
|
112
|
+
This step is critical — it's what makes the agent smarter over time.
|
|
113
|
+
|
|
114
|
+
```
|
|
115
|
+
YOUR_AGENT_core op:capture_knowledge
|
|
116
|
+
params: {
|
|
117
|
+
title: "<bug title>",
|
|
118
|
+
description: "<root cause, solution, what made it hard to find>",
|
|
119
|
+
type: "anti-pattern",
|
|
120
|
+
category: "<domain>",
|
|
121
|
+
tags: ["<error-type>", "<component>"]
|
|
122
|
+
}
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
For quick captures:
|
|
126
|
+
```
|
|
127
|
+
YOUR_AGENT_core op:capture_quick
|
|
128
|
+
params: { title: "<bug>", description: "<root cause and fix>" }
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
### Step 8: Post-Capture Quality
|
|
132
|
+
|
|
133
|
+
Run duplicate detection to ensure we didn't create redundant entries:
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
YOUR_AGENT_core op:curator_detect_duplicates
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
### Step 9: Verify Health
|
|
140
|
+
|
|
141
|
+
```
|
|
142
|
+
YOUR_AGENT_core op:admin_health
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
## Exit Criteria
|
|
146
|
+
|
|
147
|
+
Fix is complete when: the bug is resolved, tests pass (Step 6), and the root cause is captured in vault (Step 7). A fix without a capture is an incomplete fix.
|
|
148
|
+
|
|
149
|
+
## Agent Tools Reference
|
|
150
|
+
|
|
151
|
+
| Op | When to Use |
|
|
152
|
+
|----|-------------|
|
|
153
|
+
| `route_intent` | Classify as FIX intent |
|
|
154
|
+
| `search_intelligent` | Check vault for known bugs |
|
|
155
|
+
| `memory_search` | Search across session memories |
|
|
156
|
+
| `memory_topics` | See if bugs cluster in an area |
|
|
157
|
+
| `memory_stats` | Understand debugging landscape |
|
|
158
|
+
| `loop_start` | Begin iterative fix cycle |
|
|
159
|
+
| `loop_iterate` | Track each fix attempt |
|
|
160
|
+
| `loop_complete` | Finish fix cycle |
|
|
161
|
+
| `capture_knowledge` | Full anti-pattern capture |
|
|
162
|
+
| `capture_quick` | Fast capture |
|
|
163
|
+
| `curator_detect_duplicates` | Prevent redundant entries |
|
|
164
|
+
| `admin_health` | Verify system health |
|