@soleri/forge 5.14.2 → 5.14.3
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/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/deliver-and-ship.md +123 -0
- package/dist/skills/skills/env-setup.md +151 -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/templates/skills.js +1 -0
- package/dist/templates/skills.js.map +1 -1
- package/package.json +1 -1
- package/src/__tests__/scaffolder.test.ts +3 -1
- package/src/skills/deliver-and-ship.md +123 -0
- package/src/skills/env-setup.md +151 -0
- package/src/templates/skills.ts +1 -0
|
@@ -0,0 +1,140 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: vault-navigator
|
|
3
|
+
description: Use when the user asks "what does vault say", "search knowledge", "find pattern", "have we seen this before", "best practice for", "check vault", "vault search", "any patterns for", or wants to query the knowledge base for existing solutions or guidance.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Vault Navigator — Knowledge Oracle
|
|
7
|
+
|
|
8
|
+
Navigate the vault intelligently. The vault has multiple search strategies — this skill picks the right one based on what the user needs.
|
|
9
|
+
|
|
10
|
+
## When to Use
|
|
11
|
+
|
|
12
|
+
Any time the user wants to find existing knowledge before building something new. Also when asking about best practices, previous solutions, or patterns.
|
|
13
|
+
|
|
14
|
+
## Search Strategy Decision Tree
|
|
15
|
+
|
|
16
|
+
### For "Have we seen this before?" / "Best practice for X"
|
|
17
|
+
|
|
18
|
+
Start with `YOUR_AGENT_core op:search_intelligent` — this is semantic search, the broadest and smartest query. Pass the user's question as the query.
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
YOUR_AGENT_core op:search_intelligent
|
|
22
|
+
params: { query: "<user's question>" }
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
If results are weak (low scores or few matches), fall back to `YOUR_AGENT_core op:search` with explicit filters (type, category, tags, severity). This is structured search — narrower but more precise.
|
|
26
|
+
|
|
27
|
+
### For "Show me everything about X" (Exploration)
|
|
28
|
+
|
|
29
|
+
Use tag-based and domain-based browsing for broader exploration:
|
|
30
|
+
|
|
31
|
+
```
|
|
32
|
+
YOUR_AGENT_core op:vault_tags
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Lists all tags in the vault — helps discover what topics are covered.
|
|
36
|
+
|
|
37
|
+
```
|
|
38
|
+
YOUR_AGENT_core op:vault_domains
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
Lists all domains — shows the knowledge landscape at a glance.
|
|
42
|
+
|
|
43
|
+
```
|
|
44
|
+
YOUR_AGENT_core op:vault_recent
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
Shows recently added or modified entries — what's fresh in the vault.
|
|
48
|
+
|
|
49
|
+
### For "What's stale?" / "What needs updating?"
|
|
50
|
+
|
|
51
|
+
Run an age report to find outdated knowledge:
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
YOUR_AGENT_core op:vault_age_report
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
Present entries that haven't been updated recently — these are candidates for review, refresh, or removal.
|
|
58
|
+
|
|
59
|
+
### For "What do other projects do?"
|
|
60
|
+
|
|
61
|
+
Call `YOUR_AGENT_core op:memory_cross_project_search` with `crossProject: true`. This searches across all linked projects, not just the current one.
|
|
62
|
+
|
|
63
|
+
```
|
|
64
|
+
YOUR_AGENT_core op:memory_cross_project_search
|
|
65
|
+
params: { query: "<topic>", crossProject: true }
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
Check what projects are linked:
|
|
69
|
+
|
|
70
|
+
```
|
|
71
|
+
YOUR_AGENT_core op:project_linked_projects
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
### For "Has brain learned anything about X?"
|
|
75
|
+
|
|
76
|
+
Call `YOUR_AGENT_core op:brain_strengths` to see which patterns have proven strength. Then call `YOUR_AGENT_core op:brain_global_patterns` with a domain or tag filter to find cross-project patterns.
|
|
77
|
+
|
|
78
|
+
```
|
|
79
|
+
YOUR_AGENT_core op:brain_strengths
|
|
80
|
+
YOUR_AGENT_core op:brain_global_patterns
|
|
81
|
+
params: { domain: "<domain>" }
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
### For "What do I know about X?" (broad exploration)
|
|
85
|
+
|
|
86
|
+
Chain multiple strategies for comprehensive results:
|
|
87
|
+
|
|
88
|
+
1. `search_intelligent` → semantic vault search
|
|
89
|
+
2. `vault_tags` / `vault_domains` → browse knowledge landscape
|
|
90
|
+
3. `memory_cross_project_search` → cross-project patterns
|
|
91
|
+
4. `brain_strengths` → proven patterns
|
|
92
|
+
|
|
93
|
+
Present all findings with source labels so the user knows where each insight came from.
|
|
94
|
+
|
|
95
|
+
## Presenting Results
|
|
96
|
+
|
|
97
|
+
Always include:
|
|
98
|
+
|
|
99
|
+
- **Source**: Which search found it (vault, memory, brain, tags, domains)
|
|
100
|
+
- **Confidence**: Score or strength rating
|
|
101
|
+
- **Relevance**: Why this result matches the query
|
|
102
|
+
- **Actionable next step**: How to apply this knowledge
|
|
103
|
+
|
|
104
|
+
## Fallback: Web Search
|
|
105
|
+
|
|
106
|
+
If all vault strategies return no results, search the web for the user's question before saying "nothing found." The web may have:
|
|
107
|
+
|
|
108
|
+
- Documentation, articles, or guides on the topic
|
|
109
|
+
- Community patterns and best practices
|
|
110
|
+
- Library-specific solutions
|
|
111
|
+
|
|
112
|
+
If web search finds something useful, offer to capture it to the vault:
|
|
113
|
+
|
|
114
|
+
```
|
|
115
|
+
YOUR_AGENT_core op:capture_quick
|
|
116
|
+
params: {
|
|
117
|
+
title: "<what was found>",
|
|
118
|
+
description: "<summary from web search, source URL>"
|
|
119
|
+
}
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
## Exit Criteria
|
|
123
|
+
|
|
124
|
+
Search is complete when at least one search strategy has been tried and results presented. If no results found across all strategies (vault + web), say so explicitly — that's valuable information too (it means this is genuinely new territory worth exploring and capturing).
|
|
125
|
+
|
|
126
|
+
## Agent Tools Reference
|
|
127
|
+
|
|
128
|
+
| Op | When to Use |
|
|
129
|
+
| ----------------------------- | ----------------------------------------------------- |
|
|
130
|
+
| `search_intelligent` | Default semantic search — broadest and smartest |
|
|
131
|
+
| `search` | Structured search with filters (type, tags, category) |
|
|
132
|
+
| `vault_tags` | Browse all tags — discover knowledge landscape |
|
|
133
|
+
| `vault_domains` | Browse all domains — see what areas are covered |
|
|
134
|
+
| `vault_recent` | Recently modified entries — what's fresh |
|
|
135
|
+
| `vault_age_report` | Find stale entries needing refresh |
|
|
136
|
+
| `memory_cross_project_search` | Search across linked projects |
|
|
137
|
+
| `project_linked_projects` | See what projects are connected |
|
|
138
|
+
| `brain_strengths` | Proven patterns ranked by success |
|
|
139
|
+
| `brain_global_patterns` | Cross-project patterns from global pool |
|
|
140
|
+
| `capture_quick` | Capture web findings to vault for next time |
|
|
@@ -0,0 +1,182 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: verification-before-completion
|
|
3
|
+
description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- Adapted from superpowers (MIT License) -->
|
|
7
|
+
|
|
8
|
+
# Verification Before Completion
|
|
9
|
+
|
|
10
|
+
## Overview
|
|
11
|
+
|
|
12
|
+
Claiming work is complete without verification is dishonesty, not efficiency.
|
|
13
|
+
|
|
14
|
+
**Core principle:** Evidence before claims, always.
|
|
15
|
+
|
|
16
|
+
**Violating the letter of this rule is violating the spirit of this rule.**
|
|
17
|
+
|
|
18
|
+
## The Iron Law
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
If you haven't run the verification command in this message, you cannot claim it passes.
|
|
25
|
+
|
|
26
|
+
## The Gate Function
|
|
27
|
+
|
|
28
|
+
```
|
|
29
|
+
BEFORE claiming any status or expressing satisfaction:
|
|
30
|
+
|
|
31
|
+
1. IDENTIFY: What command proves this claim?
|
|
32
|
+
2. RUN: Execute the FULL command (fresh, complete)
|
|
33
|
+
3. READ: Full output, check exit code, count failures
|
|
34
|
+
4. VERIFY: Does output confirm the claim?
|
|
35
|
+
- If NO: State actual status with evidence
|
|
36
|
+
- If YES: State claim WITH evidence
|
|
37
|
+
5. AGENT CHECK: Run system diagnostics
|
|
38
|
+
6. ONLY THEN: Make the claim
|
|
39
|
+
|
|
40
|
+
Skip any step = lying, not verifying
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
## Agent System Checks
|
|
44
|
+
|
|
45
|
+
After passing all verification commands, run system diagnostics:
|
|
46
|
+
|
|
47
|
+
### Health Check
|
|
48
|
+
|
|
49
|
+
```
|
|
50
|
+
YOUR_AGENT_core op:admin_health
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
Catches issues tests might miss — vault corruption, stale caches, configuration drift.
|
|
54
|
+
|
|
55
|
+
### Full Diagnostic
|
|
56
|
+
|
|
57
|
+
```
|
|
58
|
+
YOUR_AGENT_core op:admin_diagnostic
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
Comprehensive system check — module status, database integrity, cache health, configuration validity.
|
|
62
|
+
|
|
63
|
+
### Vault Analytics
|
|
64
|
+
|
|
65
|
+
```
|
|
66
|
+
YOUR_AGENT_core op:admin_vault_analytics
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
Verify knowledge quality metrics — are capture rates healthy? Any degradation?
|
|
70
|
+
|
|
71
|
+
If any check reports problems, address them before claiming completion.
|
|
72
|
+
|
|
73
|
+
## Common Failures
|
|
74
|
+
|
|
75
|
+
| Claim | Requires | Not Sufficient |
|
|
76
|
+
| --------------------- | ------------------------------- | ------------------------------ |
|
|
77
|
+
| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
|
|
78
|
+
| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
|
|
79
|
+
| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
|
|
80
|
+
| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
|
|
81
|
+
| Regression test works | Red-green cycle verified | Test passes once |
|
|
82
|
+
| Agent completed | VCS diff shows changes | Agent reports "success" |
|
|
83
|
+
| Requirements met | Line-by-line checklist | Tests passing |
|
|
84
|
+
| Agent healthy | `admin_diagnostic` clean | "No errors in logs" |
|
|
85
|
+
|
|
86
|
+
## Red Flags - STOP
|
|
87
|
+
|
|
88
|
+
- Using "should", "probably", "seems to"
|
|
89
|
+
- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
|
|
90
|
+
- About to commit/push/PR without verification
|
|
91
|
+
- Trusting agent success reports
|
|
92
|
+
- Relying on partial verification
|
|
93
|
+
- Thinking "just this once"
|
|
94
|
+
- Tired and wanting work over
|
|
95
|
+
- ANY wording implying success without having run verification
|
|
96
|
+
|
|
97
|
+
## Rationalization Prevention
|
|
98
|
+
|
|
99
|
+
| Excuse | Reality |
|
|
100
|
+
| --------------------------------------- | ---------------------- |
|
|
101
|
+
| "Should work now" | RUN the verification |
|
|
102
|
+
| "I'm confident" | Confidence ≠ evidence |
|
|
103
|
+
| "Just this once" | No exceptions |
|
|
104
|
+
| "Linter passed" | Linter ≠ compiler |
|
|
105
|
+
| "Agent said success" | Verify independently |
|
|
106
|
+
| "I'm tired" | Exhaustion ≠ excuse |
|
|
107
|
+
| "Partial check is enough" | Partial proves nothing |
|
|
108
|
+
| "Different words so rule doesn't apply" | Spirit over letter |
|
|
109
|
+
|
|
110
|
+
## Key Patterns
|
|
111
|
+
|
|
112
|
+
**Tests:**
|
|
113
|
+
|
|
114
|
+
```
|
|
115
|
+
[Run test command] [See: 34/34 pass] "All tests pass"
|
|
116
|
+
NOT: "Should pass now" / "Looks correct"
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
**Regression tests (TDD Red-Green):**
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
Write -> Run (pass) -> Revert fix -> Run (MUST FAIL) -> Restore -> Run (pass)
|
|
123
|
+
NOT: "I've written a regression test" (without red-green verification)
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
**Build:**
|
|
127
|
+
|
|
128
|
+
```
|
|
129
|
+
[Run build] [See: exit 0] "Build passes"
|
|
130
|
+
NOT: "Linter passed" (linter doesn't check compilation)
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
**Requirements:**
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
Re-read plan -> Create checklist -> Verify each -> Report gaps or completion
|
|
137
|
+
NOT: "Tests pass, phase complete"
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
**Agent delegation:**
|
|
141
|
+
|
|
142
|
+
```
|
|
143
|
+
Agent reports success -> Check VCS diff -> Verify changes -> Report actual state
|
|
144
|
+
NOT: Trust agent report
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
## After Verification — Capture Session
|
|
148
|
+
|
|
149
|
+
Once work is verified complete, capture a session summary so context persists:
|
|
150
|
+
|
|
151
|
+
```
|
|
152
|
+
YOUR_AGENT_core op:session_capture
|
|
153
|
+
params: {
|
|
154
|
+
summary: "<what was accomplished, files modified, key decisions>"
|
|
155
|
+
}
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
This ensures the next session has context about what was verified and completed.
|
|
159
|
+
|
|
160
|
+
## When To Apply
|
|
161
|
+
|
|
162
|
+
**ALWAYS before:**
|
|
163
|
+
|
|
164
|
+
- ANY variation of success/completion claims
|
|
165
|
+
- ANY expression of satisfaction
|
|
166
|
+
- ANY positive statement about work state
|
|
167
|
+
- Committing, PR creation, task completion
|
|
168
|
+
- Moving to next task
|
|
169
|
+
- Delegating to agents
|
|
170
|
+
|
|
171
|
+
## The Bottom Line
|
|
172
|
+
|
|
173
|
+
Run the command. Read the output. THEN claim the result. This is non-negotiable.
|
|
174
|
+
|
|
175
|
+
## Agent Tools Reference
|
|
176
|
+
|
|
177
|
+
| Op | When to Use |
|
|
178
|
+
| ----------------------- | ----------------------------------- |
|
|
179
|
+
| `admin_health` | Quick system health check |
|
|
180
|
+
| `admin_diagnostic` | Comprehensive system diagnostic |
|
|
181
|
+
| `admin_vault_analytics` | Knowledge quality metrics |
|
|
182
|
+
| `session_capture` | Persist verified completion context |
|
|
@@ -0,0 +1,215 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: writing-plans
|
|
3
|
+
description: Use when you have a spec or requirements for a multi-step task, before touching code
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- Adapted from superpowers (MIT License) -->
|
|
7
|
+
|
|
8
|
+
# Writing Plans
|
|
9
|
+
|
|
10
|
+
## Overview
|
|
11
|
+
|
|
12
|
+
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
|
|
13
|
+
|
|
14
|
+
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
|
|
15
|
+
|
|
16
|
+
**Announce at start:** "I'm using the writing-plans skill to create the implementation plan."
|
|
17
|
+
|
|
18
|
+
**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
|
|
19
|
+
|
|
20
|
+
## Before Writing — Search First, Plan Second
|
|
21
|
+
|
|
22
|
+
**Never write a plan from scratch.** Always search for existing knowledge first.
|
|
23
|
+
|
|
24
|
+
### 1. Vault First
|
|
25
|
+
|
|
26
|
+
Check the vault for relevant implementation patterns:
|
|
27
|
+
|
|
28
|
+
```
|
|
29
|
+
YOUR_AGENT_core op:search_intelligent
|
|
30
|
+
params: { query: "<feature being planned>" }
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Look for:
|
|
34
|
+
|
|
35
|
+
- **Implementation patterns** — proven approaches for similar features
|
|
36
|
+
- **Anti-patterns** — approaches that failed and should be avoided
|
|
37
|
+
- **Testing patterns** — how similar features were tested
|
|
38
|
+
|
|
39
|
+
Also check brain strengths for what's worked:
|
|
40
|
+
|
|
41
|
+
```
|
|
42
|
+
YOUR_AGENT_core op:brain_strengths
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
Browse related knowledge domains for additional context:
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
YOUR_AGENT_core op:vault_domains
|
|
49
|
+
YOUR_AGENT_core op:vault_tags
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
### 2. Web Search Second
|
|
53
|
+
|
|
54
|
+
If the vault doesn't have implementation guidance, search the web:
|
|
55
|
+
|
|
56
|
+
- **Libraries and tools** — is there a package that does this already?
|
|
57
|
+
- **Reference implementations** — how did other projects solve this?
|
|
58
|
+
- **API documentation** — official docs for libraries you'll use
|
|
59
|
+
- **Known issues** — pitfalls others ran into
|
|
60
|
+
|
|
61
|
+
### 3. Then Write the Plan
|
|
62
|
+
|
|
63
|
+
Incorporate vault insights and web findings into the plan. Reference specific vault entries and documentation links when they inform a step. A plan informed by existing knowledge is dramatically better than one written from first principles.
|
|
64
|
+
|
|
65
|
+
## Create a Tracked Plan
|
|
66
|
+
|
|
67
|
+
Use the agent's planning system to create a tracked, resumable plan:
|
|
68
|
+
|
|
69
|
+
```
|
|
70
|
+
YOUR_AGENT_core op:create_plan
|
|
71
|
+
params: {
|
|
72
|
+
objective: "<one-sentence goal>",
|
|
73
|
+
scope: { included: [...], excluded: [...] },
|
|
74
|
+
steps: [
|
|
75
|
+
{ title: "Step 1 title", description: "details" },
|
|
76
|
+
...
|
|
77
|
+
]
|
|
78
|
+
}
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
This makes the plan persistent across sessions — if context compacts or sessions change, the plan survives.
|
|
82
|
+
|
|
83
|
+
## Grade the Plan
|
|
84
|
+
|
|
85
|
+
After drafting, grade the plan for quality before presenting to the user:
|
|
86
|
+
|
|
87
|
+
```
|
|
88
|
+
YOUR_AGENT_core op:plan_grade
|
|
89
|
+
params: { planId: "<id from create_plan>" }
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
If the grade is below target, auto-improve:
|
|
93
|
+
|
|
94
|
+
```
|
|
95
|
+
YOUR_AGENT_core op:plan_auto_improve
|
|
96
|
+
params: { planId: "<id>" }
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
This iterates on the plan — filling gaps, adding missing test steps, clarifying ambiguous instructions. Repeat until the grade meets the target:
|
|
100
|
+
|
|
101
|
+
```
|
|
102
|
+
YOUR_AGENT_core op:plan_meets_grade
|
|
103
|
+
params: { planId: "<id>", targetGrade: "A" }
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
### Iterate on Drafts
|
|
107
|
+
|
|
108
|
+
For complex plans, iterate before finalizing:
|
|
109
|
+
|
|
110
|
+
```
|
|
111
|
+
YOUR_AGENT_core op:plan_iterate
|
|
112
|
+
params: { planId: "<id>", feedback: "<what needs improvement>" }
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
This creates a new version of the plan incorporating the feedback, preserving version history.
|
|
116
|
+
|
|
117
|
+
## Split into Tasks
|
|
118
|
+
|
|
119
|
+
Once the plan is approved, split it into trackable tasks:
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
YOUR_AGENT_core op:plan_split
|
|
123
|
+
params: { planId: "<id>" }
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
This generates individual tasks from the plan steps, ready for execution tracking.
|
|
127
|
+
|
|
128
|
+
## Bite-Sized Task Granularity
|
|
129
|
+
|
|
130
|
+
**Each step is one action (2-5 minutes):**
|
|
131
|
+
|
|
132
|
+
- "Write the failing test" - step
|
|
133
|
+
- "Run it to make sure it fails" - step
|
|
134
|
+
- "Implement the minimal code to make the test pass" - step
|
|
135
|
+
- "Run the tests and make sure they pass" - step
|
|
136
|
+
- "Commit" - step
|
|
137
|
+
|
|
138
|
+
## Plan Document Header
|
|
139
|
+
|
|
140
|
+
**Every plan MUST start with this header:**
|
|
141
|
+
|
|
142
|
+
```markdown
|
|
143
|
+
# [Feature Name] Implementation Plan
|
|
144
|
+
|
|
145
|
+
> **For Claude:** REQUIRED SUB-SKILL: Use executing-plans to implement this plan task-by-task.
|
|
146
|
+
|
|
147
|
+
**Goal:** [One sentence describing what this builds]
|
|
148
|
+
|
|
149
|
+
**Architecture:** [2-3 sentences about approach]
|
|
150
|
+
|
|
151
|
+
**Tech Stack:** [Key technologies/libraries]
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
## Task Structure
|
|
157
|
+
|
|
158
|
+
Each task uses this format:
|
|
159
|
+
|
|
160
|
+
- Files: Create / Modify / Test paths
|
|
161
|
+
- Step 1: Write the failing test (with code)
|
|
162
|
+
- Step 2: Run test to verify it fails (with expected output)
|
|
163
|
+
- Step 3: Write minimal implementation (with code)
|
|
164
|
+
- Step 4: Run test to verify it passes (with expected output)
|
|
165
|
+
- Step 5: Commit (with exact git commands)
|
|
166
|
+
|
|
167
|
+
## Remember
|
|
168
|
+
|
|
169
|
+
- Exact file paths always
|
|
170
|
+
- Complete code in plan (not "add validation")
|
|
171
|
+
- Exact commands with expected output
|
|
172
|
+
- DRY, YAGNI, TDD, frequent commits
|
|
173
|
+
|
|
174
|
+
## After Plan Approval
|
|
175
|
+
|
|
176
|
+
Once the user approves the plan, register it for tracking:
|
|
177
|
+
|
|
178
|
+
```
|
|
179
|
+
YOUR_AGENT_core op:approve_plan
|
|
180
|
+
params: { planId: "<id from create_plan>" }
|
|
181
|
+
```
|
|
182
|
+
|
|
183
|
+
Check plan stats for an overview:
|
|
184
|
+
|
|
185
|
+
```
|
|
186
|
+
YOUR_AGENT_core op:plan_stats
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
## Execution Handoff
|
|
190
|
+
|
|
191
|
+
After saving the plan, offer execution choice:
|
|
192
|
+
|
|
193
|
+
"Plan complete and saved to `docs/plans/<filename>.md`. Two execution options:
|
|
194
|
+
|
|
195
|
+
**1. Subagent-Driven (this session)** - I dispatch fresh subagent per task, review between tasks, fast iteration
|
|
196
|
+
|
|
197
|
+
**2. Parallel Session (separate)** - Open new session with executing-plans, batch execution with checkpoints
|
|
198
|
+
|
|
199
|
+
Which approach?"
|
|
200
|
+
|
|
201
|
+
## Agent Tools Reference
|
|
202
|
+
|
|
203
|
+
| Op | When to Use |
|
|
204
|
+
| ------------------------------ | -------------------------------------- |
|
|
205
|
+
| `search_intelligent` | Find relevant patterns before planning |
|
|
206
|
+
| `brain_strengths` | Check proven approaches |
|
|
207
|
+
| `vault_domains` / `vault_tags` | Browse knowledge landscape |
|
|
208
|
+
| `create_plan` | Create tracked, persistent plan |
|
|
209
|
+
| `plan_grade` | Grade plan quality |
|
|
210
|
+
| `plan_auto_improve` | Auto-fix plan weaknesses |
|
|
211
|
+
| `plan_meets_grade` | Verify grade target reached |
|
|
212
|
+
| `plan_iterate` | Iterate on draft with feedback |
|
|
213
|
+
| `plan_split` | Split plan into trackable tasks |
|
|
214
|
+
| `approve_plan` | Lock in approved plan |
|
|
215
|
+
| `plan_stats` | Overview of plan metrics |
|
package/dist/templates/skills.js
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"skills.js","sourceRoot":"","sources":["../../src/templates/skills.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,WAAW,EAAE,MAAM,SAAS,CAAC;AACpD,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAC1C,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AAGzC,MAAM,SAAS,GAAG,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;AAC1D,MAAM,UAAU,GAAG,IAAI,CAAC,SAAS,EAAE,IAAI,EAAE,QAAQ,CAAC,CAAC;AAEnD,wFAAwF;AACxF,MAAM,qBAAqB,GAAG,IAAI,GAAG,CAAC;IACpC,eAAe;IACf,eAAe;IACf,aAAa;IACb,gBAAgB;IAChB,iBAAiB;IACjB,eAAe;IACf,cAAc;IACd,mBAAmB;IACnB,YAAY;IACZ,eAAe;IACf,gBAAgB;IAChB,sBAAsB;IACtB,yBAAyB;IACzB,eAAe;IACf,iBAAiB;IACjB,gCAAgC;IAChC,eAAe;CAChB,CAAC,CAAC;AAEH;;;;;;;;GAQG;AACH,MAAM,UAAU,cAAc,CAAC,MAAmB;IAChD,MAAM,KAAK,GAA4B,EAAE,CAAC;IAC1C,IAAI,UAAoB,CAAC;IAEzB,IAAI,CAAC;QACH,UAAU,GAAG,WAAW,CAAC,UAAU,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC,CAAC;IACxE,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,KAAK,CAAC;IACf,CAAC;IAED,2DAA2D;IAC3D,gEAAgE;IAChE,MAAM,aAAa,GAAG,MAAM,CAAC,MAAM,CAAC,CAAC,CAAC,IAAI,GAAG,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,uCAAuC;IAE5G,KAAK,MAAM,IAAI,IAAI,UAAU,EAAE,CAAC;QAC9B,MAAM,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,KAAK,EAAE,EAAE,CAAC,CAAC;QAE1C,IAAI,aAAa,IAAI,CAAC,aAAa,CAAC,GAAG,CAAC,SAAS,CAAC,EAAE,CAAC;YACnD,SAAS;QACX,CAAC;QAED,IAAI,OAAO,GAAG,YAAY,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,EAAE,OAAO,CAAC,CAAC;QAE5D,IAAI,qBAAqB,CAAC,GAAG,CAAC,SAAS,CAAC,EAAE,CAAC;YACzC,OAAO,GAAG,OAAO,CAAC,OAAO,CAAC,kBAAkB,EAAE,GAAG,MAAM,CAAC,EAAE,OAAO,CAAC,CAAC;QACrE,CAAC;QAED,KAAK,CAAC,IAAI,CAAC,CAAC,UAAU,SAAS,WAAW,EAAE,OAAO,CAAC,CAAC,CAAC;IACxD,CAAC;IAED,OAAO,KAAK,CAAC;AACf,CAAC"}
|
|
1
|
+
{"version":3,"file":"skills.js","sourceRoot":"","sources":["../../src/templates/skills.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,WAAW,EAAE,MAAM,SAAS,CAAC;AACpD,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAC1C,OAAO,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AAGzC,MAAM,SAAS,GAAG,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;AAC1D,MAAM,UAAU,GAAG,IAAI,CAAC,SAAS,EAAE,IAAI,EAAE,QAAQ,CAAC,CAAC;AAEnD,wFAAwF;AACxF,MAAM,qBAAqB,GAAG,IAAI,GAAG,CAAC;IACpC,eAAe;IACf,eAAe;IACf,aAAa;IACb,gBAAgB;IAChB,kBAAkB;IAClB,iBAAiB;IACjB,eAAe;IACf,cAAc;IACd,mBAAmB;IACnB,YAAY;IACZ,eAAe;IACf,gBAAgB;IAChB,sBAAsB;IACtB,yBAAyB;IACzB,eAAe;IACf,iBAAiB;IACjB,gCAAgC;IAChC,eAAe;CAChB,CAAC,CAAC;AAEH;;;;;;;;GAQG;AACH,MAAM,UAAU,cAAc,CAAC,MAAmB;IAChD,MAAM,KAAK,GAA4B,EAAE,CAAC;IAC1C,IAAI,UAAoB,CAAC;IAEzB,IAAI,CAAC;QACH,UAAU,GAAG,WAAW,CAAC,UAAU,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC,CAAC;IACxE,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,KAAK,CAAC;IACf,CAAC;IAED,2DAA2D;IAC3D,gEAAgE;IAChE,MAAM,aAAa,GAAG,MAAM,CAAC,MAAM,CAAC,CAAC,CAAC,IAAI,GAAG,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,uCAAuC;IAE5G,KAAK,MAAM,IAAI,IAAI,UAAU,EAAE,CAAC;QAC9B,MAAM,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,KAAK,EAAE,EAAE,CAAC,CAAC;QAE1C,IAAI,aAAa,IAAI,CAAC,aAAa,CAAC,GAAG,CAAC,SAAS,CAAC,EAAE,CAAC;YACnD,SAAS;QACX,CAAC;QAED,IAAI,OAAO,GAAG,YAAY,CAAC,IAAI,CAAC,UAAU,EAAE,IAAI,CAAC,EAAE,OAAO,CAAC,CAAC;QAE5D,IAAI,qBAAqB,CAAC,GAAG,CAAC,SAAS,CAAC,EAAE,CAAC;YACzC,OAAO,GAAG,OAAO,CAAC,OAAO,CAAC,kBAAkB,EAAE,GAAG,MAAM,CAAC,EAAE,OAAO,CAAC,CAAC;QACrE,CAAC;QAED,KAAK,CAAC,IAAI,CAAC,CAAC,UAAU,SAAS,WAAW,EAAE,OAAO,CAAC,CAAC,CAAC;IACxD,CAAC;IAED,OAAO,KAAK,CAAC;AACf,CAAC"}
|
package/package.json
CHANGED
|
@@ -262,7 +262,7 @@ describe('Scaffolder', () => {
|
|
|
262
262
|
.filter((e) => e.isDirectory())
|
|
263
263
|
.map((e) => e.name);
|
|
264
264
|
|
|
265
|
-
expect(skillDirs).toHaveLength(
|
|
265
|
+
expect(skillDirs).toHaveLength(19);
|
|
266
266
|
|
|
267
267
|
// Verify each skill dir has a SKILL.md
|
|
268
268
|
for (const dir of skillDirs) {
|
|
@@ -280,6 +280,8 @@ describe('Scaffolder', () => {
|
|
|
280
280
|
'brainstorming',
|
|
281
281
|
'code-patrol',
|
|
282
282
|
'context-resume',
|
|
283
|
+
'deliver-and-ship',
|
|
284
|
+
'env-setup',
|
|
283
285
|
'executing-plans',
|
|
284
286
|
'fix-and-learn',
|
|
285
287
|
'health-check',
|