superpowers-opencode-fork-dev-test 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/.opencode/plugins/superpowers.js +95 -0
- package/LICENSE +21 -0
- package/README.md +159 -0
- package/package.json +45 -0
- package/skills/brainstorming/SKILL.md +54 -0
- package/skills/dispatching-parallel-agents/SKILL.md +180 -0
- package/skills/executing-plans/SKILL.md +76 -0
- package/skills/finishing-a-development-branch/SKILL.md +200 -0
- package/skills/receiving-code-review/SKILL.md +213 -0
- package/skills/requesting-code-review/SKILL.md +105 -0
- package/skills/requesting-code-review/code-reviewer.md +146 -0
- package/skills/subagent-driven-development/SKILL.md +240 -0
- package/skills/subagent-driven-development/code-quality-reviewer-prompt.md +20 -0
- package/skills/subagent-driven-development/implementer-prompt.md +78 -0
- package/skills/subagent-driven-development/spec-reviewer-prompt.md +61 -0
- package/skills/systematic-debugging/CREATION-LOG.md +119 -0
- package/skills/systematic-debugging/SKILL.md +296 -0
- package/skills/systematic-debugging/condition-based-waiting-example.ts +158 -0
- package/skills/systematic-debugging/condition-based-waiting.md +115 -0
- package/skills/systematic-debugging/defense-in-depth.md +122 -0
- package/skills/systematic-debugging/find-polluter.sh +63 -0
- package/skills/systematic-debugging/root-cause-tracing.md +169 -0
- package/skills/systematic-debugging/test-academic.md +14 -0
- package/skills/systematic-debugging/test-pressure-1.md +58 -0
- package/skills/systematic-debugging/test-pressure-2.md +68 -0
- package/skills/systematic-debugging/test-pressure-3.md +69 -0
- package/skills/test-driven-development/SKILL.md +371 -0
- package/skills/test-driven-development/testing-anti-patterns.md +299 -0
- package/skills/using-git-worktrees/SKILL.md +217 -0
- package/skills/using-superpowers/SKILL.md +87 -0
- package/skills/verification-before-completion/SKILL.md +139 -0
- package/skills/writing-plans/SKILL.md +116 -0
- package/skills/writing-skills/SKILL.md +655 -0
- package/skills/writing-skills/anthropic-best-practices.md +1150 -0
- package/skills/writing-skills/examples/CLAUDE_MD_TESTING.md +189 -0
- package/skills/writing-skills/graphviz-conventions.dot +172 -0
- package/skills/writing-skills/persuasion-principles.md +187 -0
- package/skills/writing-skills/render-graphs.js +168 -0
- package/skills/writing-skills/testing-skills-with-subagents.md +384 -0
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Superpowers plugin for OpenCode.ai
|
|
3
|
+
*
|
|
4
|
+
* Injects superpowers bootstrap context via system prompt transform.
|
|
5
|
+
* Skills are discovered via OpenCode's native skill tool from symlinked directory.
|
|
6
|
+
*/
|
|
7
|
+
|
|
8
|
+
import path from 'path';
|
|
9
|
+
import fs from 'fs';
|
|
10
|
+
import os from 'os';
|
|
11
|
+
import { fileURLToPath } from 'url';
|
|
12
|
+
|
|
13
|
+
const __dirname = path.dirname(fileURLToPath(import.meta.url));
|
|
14
|
+
|
|
15
|
+
// Simple frontmatter extraction (avoid dependency on skills-core for bootstrap)
|
|
16
|
+
const extractAndStripFrontmatter = (content) => {
|
|
17
|
+
const match = content.match(/^---\n([\s\S]*?)\n---\n([\s\S]*)$/);
|
|
18
|
+
if (!match) return { frontmatter: {}, content };
|
|
19
|
+
|
|
20
|
+
const frontmatterStr = match[1];
|
|
21
|
+
const body = match[2];
|
|
22
|
+
const frontmatter = {};
|
|
23
|
+
|
|
24
|
+
for (const line of frontmatterStr.split('\n')) {
|
|
25
|
+
const colonIdx = line.indexOf(':');
|
|
26
|
+
if (colonIdx > 0) {
|
|
27
|
+
const key = line.slice(0, colonIdx).trim();
|
|
28
|
+
const value = line.slice(colonIdx + 1).trim().replace(/^["']|["']$/g, '');
|
|
29
|
+
frontmatter[key] = value;
|
|
30
|
+
}
|
|
31
|
+
}
|
|
32
|
+
|
|
33
|
+
return { frontmatter, content: body };
|
|
34
|
+
};
|
|
35
|
+
|
|
36
|
+
// Normalize a path: trim whitespace, expand ~, resolve to absolute
|
|
37
|
+
const normalizePath = (p, homeDir) => {
|
|
38
|
+
if (!p || typeof p !== 'string') return null;
|
|
39
|
+
let normalized = p.trim();
|
|
40
|
+
if (!normalized) return null;
|
|
41
|
+
if (normalized.startsWith('~/')) {
|
|
42
|
+
normalized = path.join(homeDir, normalized.slice(2));
|
|
43
|
+
} else if (normalized === '~') {
|
|
44
|
+
normalized = homeDir;
|
|
45
|
+
}
|
|
46
|
+
return path.resolve(normalized);
|
|
47
|
+
};
|
|
48
|
+
|
|
49
|
+
export const SuperpowersPlugin = async ({ client, directory }) => {
|
|
50
|
+
const homeDir = os.homedir();
|
|
51
|
+
const superpowersSkillsDir = path.resolve(__dirname, '../../skills');
|
|
52
|
+
const envConfigDir = normalizePath(process.env.OPENCODE_CONFIG_DIR, homeDir);
|
|
53
|
+
const configDir = envConfigDir || path.join(homeDir, '.config/opencode');
|
|
54
|
+
|
|
55
|
+
// Helper to generate bootstrap content
|
|
56
|
+
const getBootstrapContent = () => {
|
|
57
|
+
// Try to load using-superpowers skill
|
|
58
|
+
const skillPath = path.join(superpowersSkillsDir, 'using-superpowers', 'SKILL.md');
|
|
59
|
+
if (!fs.existsSync(skillPath)) return null;
|
|
60
|
+
|
|
61
|
+
const fullContent = fs.readFileSync(skillPath, 'utf8');
|
|
62
|
+
const { content } = extractAndStripFrontmatter(fullContent);
|
|
63
|
+
|
|
64
|
+
const toolMapping = `**Tool Mapping for OpenCode:**
|
|
65
|
+
When skills reference tools you don't have, substitute OpenCode equivalents:
|
|
66
|
+
- \`TodoWrite\` → \`update_plan\`
|
|
67
|
+
- \`Task\` tool with subagents → Use OpenCode's subagent system (@mention)
|
|
68
|
+
- \`Skill\` tool → OpenCode's native \`skill\` tool
|
|
69
|
+
- \`Read\`, \`Write\`, \`Edit\`, \`Bash\` → Your native tools
|
|
70
|
+
|
|
71
|
+
**Skills location:**
|
|
72
|
+
Superpowers skills are in \`${configDir}/skills/superpowers/\`
|
|
73
|
+
Use OpenCode's native \`skill\` tool to list and load skills.`;
|
|
74
|
+
|
|
75
|
+
return `<EXTREMELY_IMPORTANT>
|
|
76
|
+
You have superpowers.
|
|
77
|
+
|
|
78
|
+
**IMPORTANT: The using-superpowers skill content is included below. It is ALREADY LOADED - you are currently following it. Do NOT use the skill tool to load "using-superpowers" again - that would be redundant.**
|
|
79
|
+
|
|
80
|
+
${content}
|
|
81
|
+
|
|
82
|
+
${toolMapping}
|
|
83
|
+
</EXTREMELY_IMPORTANT>`;
|
|
84
|
+
};
|
|
85
|
+
|
|
86
|
+
return {
|
|
87
|
+
// Use system prompt transform to inject bootstrap (fixes #226 agent reset bug)
|
|
88
|
+
'experimental.chat.system.transform': async (_input, output) => {
|
|
89
|
+
const bootstrap = getBootstrapContent();
|
|
90
|
+
if (bootstrap) {
|
|
91
|
+
(output.system ||= []).push(bootstrap);
|
|
92
|
+
}
|
|
93
|
+
}
|
|
94
|
+
};
|
|
95
|
+
};
|
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2025 Jesse Vincent
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,159 @@
|
|
|
1
|
+
# Superpowers
|
|
2
|
+
|
|
3
|
+
Superpowers is a complete software development workflow for your coding agents, built on top of a set of composable "skills" and some initial instructions that make sure your agent uses them.
|
|
4
|
+
|
|
5
|
+
## How it works
|
|
6
|
+
|
|
7
|
+
It starts from the moment you fire up your coding agent. As soon as it sees that you're building something, it *doesn't* just jump into trying to write code. Instead, it steps back and asks you what you're really trying to do.
|
|
8
|
+
|
|
9
|
+
Once it's teased a spec out of the conversation, it shows it to you in chunks short enough to actually read and digest.
|
|
10
|
+
|
|
11
|
+
After you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow. It emphasizes true red/green TDD, YAGNI (You Aren't Gonna Need It), and DRY.
|
|
12
|
+
|
|
13
|
+
Next up, once you say "go", it launches a *subagent-driven-development* process, having agents work through each engineering task, inspecting and reviewing their work, and continuing forward. It's not uncommon for Claude to be able to work autonomously for a couple hours at a time without deviating from the plan you put together.
|
|
14
|
+
|
|
15
|
+
There's a bunch more to it, but that's the core of the system. And because the skills trigger automatically, you don't need to do anything special. Your coding agent just has Superpowers.
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
## Sponsorship
|
|
19
|
+
|
|
20
|
+
If Superpowers has helped you do stuff that makes money and you are so inclined, I'd greatly appreciate it if you'd consider [sponsoring my opensource work](https://github.com/sponsors/obra).
|
|
21
|
+
|
|
22
|
+
Thanks!
|
|
23
|
+
|
|
24
|
+
- Jesse
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
## Installation
|
|
28
|
+
|
|
29
|
+
**Note:** Installation differs by platform. Claude Code has a built-in plugin system. Codex and OpenCode require manual setup.
|
|
30
|
+
|
|
31
|
+
### Claude Code (via Plugin Marketplace)
|
|
32
|
+
|
|
33
|
+
In Claude Code, register the marketplace first:
|
|
34
|
+
|
|
35
|
+
```bash
|
|
36
|
+
/plugin marketplace add obra/superpowers-marketplace
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
Then install the plugin from this marketplace:
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
/plugin install superpowers@superpowers-marketplace
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
### Verify Installation
|
|
46
|
+
|
|
47
|
+
Check that commands appear:
|
|
48
|
+
|
|
49
|
+
```bash
|
|
50
|
+
/help
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
# Should see:
|
|
55
|
+
# /superpowers:brainstorm - Interactive design refinement
|
|
56
|
+
# /superpowers:write-plan - Create implementation plan
|
|
57
|
+
# /superpowers:execute-plan - Execute plan in batches
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
### Codex
|
|
61
|
+
|
|
62
|
+
Tell Codex:
|
|
63
|
+
|
|
64
|
+
```
|
|
65
|
+
Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
**Detailed docs:** [docs/README.codex.md](docs/README.codex.md)
|
|
69
|
+
|
|
70
|
+
### OpenCode
|
|
71
|
+
|
|
72
|
+
Tell OpenCode:
|
|
73
|
+
|
|
74
|
+
```
|
|
75
|
+
Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
**Detailed docs:** [docs/README.opencode.md](docs/README.opencode.md)
|
|
79
|
+
|
|
80
|
+
## The Basic Workflow
|
|
81
|
+
|
|
82
|
+
1. **brainstorming** - Activates before writing code. Refines rough ideas through questions, explores alternatives, presents design in sections for validation. Saves design document.
|
|
83
|
+
|
|
84
|
+
2. **using-git-worktrees** - Activates after design approval. Creates isolated workspace on new branch, runs project setup, verifies clean test baseline.
|
|
85
|
+
|
|
86
|
+
3. **writing-plans** - Activates with approved design. Breaks work into bite-sized tasks (2-5 minutes each). Every task has exact file paths, complete code, verification steps.
|
|
87
|
+
|
|
88
|
+
4. **subagent-driven-development** or **executing-plans** - Activates with plan. Dispatches fresh subagent per task with two-stage review (spec compliance, then code quality), or executes in batches with human checkpoints.
|
|
89
|
+
|
|
90
|
+
5. **test-driven-development** - Activates during implementation. Enforces RED-GREEN-REFACTOR: write failing test, watch it fail, write minimal code, watch it pass, commit. Deletes code written before tests.
|
|
91
|
+
|
|
92
|
+
6. **requesting-code-review** - Activates between tasks. Reviews against plan, reports issues by severity. Critical issues block progress.
|
|
93
|
+
|
|
94
|
+
7. **finishing-a-development-branch** - Activates when tasks complete. Verifies tests, presents options (merge/PR/keep/discard), cleans up worktree.
|
|
95
|
+
|
|
96
|
+
**The agent checks for relevant skills before any task.** Mandatory workflows, not suggestions.
|
|
97
|
+
|
|
98
|
+
## What's Inside
|
|
99
|
+
|
|
100
|
+
### Skills Library
|
|
101
|
+
|
|
102
|
+
**Testing**
|
|
103
|
+
- **test-driven-development** - RED-GREEN-REFACTOR cycle (includes testing anti-patterns reference)
|
|
104
|
+
|
|
105
|
+
**Debugging**
|
|
106
|
+
- **systematic-debugging** - 4-phase root cause process (includes root-cause-tracing, defense-in-depth, condition-based-waiting techniques)
|
|
107
|
+
- **verification-before-completion** - Ensure it's actually fixed
|
|
108
|
+
|
|
109
|
+
**Collaboration**
|
|
110
|
+
- **brainstorming** - Socratic design refinement
|
|
111
|
+
- **writing-plans** - Detailed implementation plans
|
|
112
|
+
- **executing-plans** - Batch execution with checkpoints
|
|
113
|
+
- **dispatching-parallel-agents** - Concurrent subagent workflows
|
|
114
|
+
- **requesting-code-review** - Pre-review checklist
|
|
115
|
+
- **receiving-code-review** - Responding to feedback
|
|
116
|
+
- **using-git-worktrees** - Parallel development branches
|
|
117
|
+
- **finishing-a-development-branch** - Merge/PR decision workflow
|
|
118
|
+
- **subagent-driven-development** - Fast iteration with two-stage review (spec compliance, then code quality)
|
|
119
|
+
|
|
120
|
+
**Meta**
|
|
121
|
+
- **writing-skills** - Create new skills following best practices (includes testing methodology)
|
|
122
|
+
- **using-superpowers** - Introduction to the skills system
|
|
123
|
+
|
|
124
|
+
## Philosophy
|
|
125
|
+
|
|
126
|
+
- **Test-Driven Development** - Write tests first, always
|
|
127
|
+
- **Systematic over ad-hoc** - Process over guessing
|
|
128
|
+
- **Complexity reduction** - Simplicity as primary goal
|
|
129
|
+
- **Evidence over claims** - Verify before declaring success
|
|
130
|
+
|
|
131
|
+
Read more: [Superpowers for Claude Code](https://blog.fsck.com/2025/10/09/superpowers/)
|
|
132
|
+
|
|
133
|
+
## Contributing
|
|
134
|
+
|
|
135
|
+
Skills live directly in this repository. To contribute:
|
|
136
|
+
|
|
137
|
+
1. Fork the repository
|
|
138
|
+
2. Create a branch for your skill
|
|
139
|
+
3. Follow the `writing-skills` skill for creating and testing new skills
|
|
140
|
+
4. Submit a PR
|
|
141
|
+
|
|
142
|
+
See `skills/writing-skills/SKILL.md` for the complete guide.
|
|
143
|
+
|
|
144
|
+
## Updating
|
|
145
|
+
|
|
146
|
+
Skills update automatically when you update the plugin:
|
|
147
|
+
|
|
148
|
+
```bash
|
|
149
|
+
/plugin update superpowers
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
## License
|
|
153
|
+
|
|
154
|
+
MIT License - see LICENSE file for details
|
|
155
|
+
|
|
156
|
+
## Support
|
|
157
|
+
|
|
158
|
+
- **Issues**: https://github.com/obra/superpowers/issues
|
|
159
|
+
- **Marketplace**: https://github.com/obra/superpowers-marketplace
|
package/package.json
ADDED
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "superpowers-opencode-fork-dev-test",
|
|
3
|
+
"version": "1.0.0",
|
|
4
|
+
"description": "Superpowers plugin for OpenCode.ai - Complete software development workflow with composable skills",
|
|
5
|
+
"type": "module",
|
|
6
|
+
"main": ".opencode/plugins/superpowers.js",
|
|
7
|
+
"exports": {
|
|
8
|
+
".": {
|
|
9
|
+
"types": "./.opencode/plugins/superpowers.js",
|
|
10
|
+
"default": "./.opencode/plugins/superpowers.js"
|
|
11
|
+
}
|
|
12
|
+
},
|
|
13
|
+
"files": [
|
|
14
|
+
".opencode/plugins/superpowers.js",
|
|
15
|
+
"skills/"
|
|
16
|
+
],
|
|
17
|
+
"scripts": {
|
|
18
|
+
"test": "echo \"Error: no test specified\" && exit 1"
|
|
19
|
+
},
|
|
20
|
+
"keywords": [
|
|
21
|
+
"opencode",
|
|
22
|
+
"opencode-plugin",
|
|
23
|
+
"superpowers",
|
|
24
|
+
"skills",
|
|
25
|
+
"tdd",
|
|
26
|
+
"development",
|
|
27
|
+
"workflow"
|
|
28
|
+
],
|
|
29
|
+
"author": "obra",
|
|
30
|
+
"license": "MIT",
|
|
31
|
+
"repository": {
|
|
32
|
+
"type": "git",
|
|
33
|
+
"url": "git+https://github.com/obra/superpowers.git"
|
|
34
|
+
},
|
|
35
|
+
"bugs": {
|
|
36
|
+
"url": "https://github.com/obra/superpowers/issues"
|
|
37
|
+
},
|
|
38
|
+
"homepage": "https://github.com/obra/superpowers#readme",
|
|
39
|
+
"dependencies": {
|
|
40
|
+
"@opencode-ai/plugin": "^1.1.34"
|
|
41
|
+
},
|
|
42
|
+
"peerDependencies": {
|
|
43
|
+
"@opencode-ai/plugin": "^1.1.0"
|
|
44
|
+
}
|
|
45
|
+
}
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: brainstorming
|
|
3
|
+
description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Brainstorming Ideas Into Designs
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
|
|
11
|
+
|
|
12
|
+
Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
|
|
13
|
+
|
|
14
|
+
## The Process
|
|
15
|
+
|
|
16
|
+
**Understanding the idea:**
|
|
17
|
+
- Check out the current project state first (files, docs, recent commits)
|
|
18
|
+
- Ask questions one at a time to refine the idea
|
|
19
|
+
- Prefer multiple choice questions when possible, but open-ended is fine too
|
|
20
|
+
- Only one question per message - if a topic needs more exploration, break it into multiple questions
|
|
21
|
+
- Focus on understanding: purpose, constraints, success criteria
|
|
22
|
+
|
|
23
|
+
**Exploring approaches:**
|
|
24
|
+
- Propose 2-3 different approaches with trade-offs
|
|
25
|
+
- Present options conversationally with your recommendation and reasoning
|
|
26
|
+
- Lead with your recommended option and explain why
|
|
27
|
+
|
|
28
|
+
**Presenting the design:**
|
|
29
|
+
- Once you believe you understand what you're building, present the design
|
|
30
|
+
- Break it into sections of 200-300 words
|
|
31
|
+
- Ask after each section whether it looks right so far
|
|
32
|
+
- Cover: architecture, components, data flow, error handling, testing
|
|
33
|
+
- Be ready to go back and clarify if something doesn't make sense
|
|
34
|
+
|
|
35
|
+
## After the Design
|
|
36
|
+
|
|
37
|
+
**Documentation:**
|
|
38
|
+
- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
|
|
39
|
+
- Use elements-of-style:writing-clearly-and-concisely skill if available
|
|
40
|
+
- Commit the design document to git
|
|
41
|
+
|
|
42
|
+
**Implementation (if continuing):**
|
|
43
|
+
- Ask: "Ready to set up for implementation?"
|
|
44
|
+
- Use superpowers:using-git-worktrees to create isolated workspace
|
|
45
|
+
- Use superpowers:writing-plans to create detailed implementation plan
|
|
46
|
+
|
|
47
|
+
## Key Principles
|
|
48
|
+
|
|
49
|
+
- **One question at a time** - Don't overwhelm with multiple questions
|
|
50
|
+
- **Multiple choice preferred** - Easier to answer than open-ended when possible
|
|
51
|
+
- **YAGNI ruthlessly** - Remove unnecessary features from all designs
|
|
52
|
+
- **Explore alternatives** - Always propose 2-3 approaches before settling
|
|
53
|
+
- **Incremental validation** - Present design in sections, validate each
|
|
54
|
+
- **Be flexible** - Go back and clarify when something doesn't make sense
|
|
@@ -0,0 +1,180 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dispatching-parallel-agents
|
|
3
|
+
description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Dispatching Parallel Agents
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
|
|
11
|
+
|
|
12
|
+
**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.
|
|
13
|
+
|
|
14
|
+
## When to Use
|
|
15
|
+
|
|
16
|
+
```dot
|
|
17
|
+
digraph when_to_use {
|
|
18
|
+
"Multiple failures?" [shape=diamond];
|
|
19
|
+
"Are they independent?" [shape=diamond];
|
|
20
|
+
"Single agent investigates all" [shape=box];
|
|
21
|
+
"One agent per problem domain" [shape=box];
|
|
22
|
+
"Can they work in parallel?" [shape=diamond];
|
|
23
|
+
"Sequential agents" [shape=box];
|
|
24
|
+
"Parallel dispatch" [shape=box];
|
|
25
|
+
|
|
26
|
+
"Multiple failures?" -> "Are they independent?" [label="yes"];
|
|
27
|
+
"Are they independent?" -> "Single agent investigates all" [label="no - related"];
|
|
28
|
+
"Are they independent?" -> "Can they work in parallel?" [label="yes"];
|
|
29
|
+
"Can they work in parallel?" -> "Parallel dispatch" [label="yes"];
|
|
30
|
+
"Can they work in parallel?" -> "Sequential agents" [label="no - shared state"];
|
|
31
|
+
}
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
**Use when:**
|
|
35
|
+
- 3+ test files failing with different root causes
|
|
36
|
+
- Multiple subsystems broken independently
|
|
37
|
+
- Each problem can be understood without context from others
|
|
38
|
+
- No shared state between investigations
|
|
39
|
+
|
|
40
|
+
**Don't use when:**
|
|
41
|
+
- Failures are related (fix one might fix others)
|
|
42
|
+
- Need to understand full system state
|
|
43
|
+
- Agents would interfere with each other
|
|
44
|
+
|
|
45
|
+
## The Pattern
|
|
46
|
+
|
|
47
|
+
### 1. Identify Independent Domains
|
|
48
|
+
|
|
49
|
+
Group failures by what's broken:
|
|
50
|
+
- File A tests: Tool approval flow
|
|
51
|
+
- File B tests: Batch completion behavior
|
|
52
|
+
- File C tests: Abort functionality
|
|
53
|
+
|
|
54
|
+
Each domain is independent - fixing tool approval doesn't affect abort tests.
|
|
55
|
+
|
|
56
|
+
### 2. Create Focused Agent Tasks
|
|
57
|
+
|
|
58
|
+
Each agent gets:
|
|
59
|
+
- **Specific scope:** One test file or subsystem
|
|
60
|
+
- **Clear goal:** Make these tests pass
|
|
61
|
+
- **Constraints:** Don't change other code
|
|
62
|
+
- **Expected output:** Summary of what you found and fixed
|
|
63
|
+
|
|
64
|
+
### 3. Dispatch in Parallel
|
|
65
|
+
|
|
66
|
+
```typescript
|
|
67
|
+
// In Claude Code / AI environment
|
|
68
|
+
Task("Fix agent-tool-abort.test.ts failures")
|
|
69
|
+
Task("Fix batch-completion-behavior.test.ts failures")
|
|
70
|
+
Task("Fix tool-approval-race-conditions.test.ts failures")
|
|
71
|
+
// All three run concurrently
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
### 4. Review and Integrate
|
|
75
|
+
|
|
76
|
+
When agents return:
|
|
77
|
+
- Read each summary
|
|
78
|
+
- Verify fixes don't conflict
|
|
79
|
+
- Run full test suite
|
|
80
|
+
- Integrate all changes
|
|
81
|
+
|
|
82
|
+
## Agent Prompt Structure
|
|
83
|
+
|
|
84
|
+
Good agent prompts are:
|
|
85
|
+
1. **Focused** - One clear problem domain
|
|
86
|
+
2. **Self-contained** - All context needed to understand the problem
|
|
87
|
+
3. **Specific about output** - What should the agent return?
|
|
88
|
+
|
|
89
|
+
```markdown
|
|
90
|
+
Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
|
|
91
|
+
|
|
92
|
+
1. "should abort tool with partial output capture" - expects 'interrupted at' in message
|
|
93
|
+
2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
|
|
94
|
+
3. "should properly track pendingToolCount" - expects 3 results but gets 0
|
|
95
|
+
|
|
96
|
+
These are timing/race condition issues. Your task:
|
|
97
|
+
|
|
98
|
+
1. Read the test file and understand what each test verifies
|
|
99
|
+
2. Identify root cause - timing issues or actual bugs?
|
|
100
|
+
3. Fix by:
|
|
101
|
+
- Replacing arbitrary timeouts with event-based waiting
|
|
102
|
+
- Fixing bugs in abort implementation if found
|
|
103
|
+
- Adjusting test expectations if testing changed behavior
|
|
104
|
+
|
|
105
|
+
Do NOT just increase timeouts - find the real issue.
|
|
106
|
+
|
|
107
|
+
Return: Summary of what you found and what you fixed.
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
## Common Mistakes
|
|
111
|
+
|
|
112
|
+
**❌ Too broad:** "Fix all the tests" - agent gets lost
|
|
113
|
+
**✅ Specific:** "Fix agent-tool-abort.test.ts" - focused scope
|
|
114
|
+
|
|
115
|
+
**❌ No context:** "Fix the race condition" - agent doesn't know where
|
|
116
|
+
**✅ Context:** Paste the error messages and test names
|
|
117
|
+
|
|
118
|
+
**❌ No constraints:** Agent might refactor everything
|
|
119
|
+
**✅ Constraints:** "Do NOT change production code" or "Fix tests only"
|
|
120
|
+
|
|
121
|
+
**❌ Vague output:** "Fix it" - you don't know what changed
|
|
122
|
+
**✅ Specific:** "Return summary of root cause and changes"
|
|
123
|
+
|
|
124
|
+
## When NOT to Use
|
|
125
|
+
|
|
126
|
+
**Related failures:** Fixing one might fix others - investigate together first
|
|
127
|
+
**Need full context:** Understanding requires seeing entire system
|
|
128
|
+
**Exploratory debugging:** You don't know what's broken yet
|
|
129
|
+
**Shared state:** Agents would interfere (editing same files, using same resources)
|
|
130
|
+
|
|
131
|
+
## Real Example from Session
|
|
132
|
+
|
|
133
|
+
**Scenario:** 6 test failures across 3 files after major refactoring
|
|
134
|
+
|
|
135
|
+
**Failures:**
|
|
136
|
+
- agent-tool-abort.test.ts: 3 failures (timing issues)
|
|
137
|
+
- batch-completion-behavior.test.ts: 2 failures (tools not executing)
|
|
138
|
+
- tool-approval-race-conditions.test.ts: 1 failure (execution count = 0)
|
|
139
|
+
|
|
140
|
+
**Decision:** Independent domains - abort logic separate from batch completion separate from race conditions
|
|
141
|
+
|
|
142
|
+
**Dispatch:**
|
|
143
|
+
```
|
|
144
|
+
Agent 1 → Fix agent-tool-abort.test.ts
|
|
145
|
+
Agent 2 → Fix batch-completion-behavior.test.ts
|
|
146
|
+
Agent 3 → Fix tool-approval-race-conditions.test.ts
|
|
147
|
+
```
|
|
148
|
+
|
|
149
|
+
**Results:**
|
|
150
|
+
- Agent 1: Replaced timeouts with event-based waiting
|
|
151
|
+
- Agent 2: Fixed event structure bug (threadId in wrong place)
|
|
152
|
+
- Agent 3: Added wait for async tool execution to complete
|
|
153
|
+
|
|
154
|
+
**Integration:** All fixes independent, no conflicts, full suite green
|
|
155
|
+
|
|
156
|
+
**Time saved:** 3 problems solved in parallel vs sequentially
|
|
157
|
+
|
|
158
|
+
## Key Benefits
|
|
159
|
+
|
|
160
|
+
1. **Parallelization** - Multiple investigations happen simultaneously
|
|
161
|
+
2. **Focus** - Each agent has narrow scope, less context to track
|
|
162
|
+
3. **Independence** - Agents don't interfere with each other
|
|
163
|
+
4. **Speed** - 3 problems solved in time of 1
|
|
164
|
+
|
|
165
|
+
## Verification
|
|
166
|
+
|
|
167
|
+
After agents return:
|
|
168
|
+
1. **Review each summary** - Understand what changed
|
|
169
|
+
2. **Check for conflicts** - Did agents edit same code?
|
|
170
|
+
3. **Run full suite** - Verify all fixes work together
|
|
171
|
+
4. **Spot check** - Agents can make systematic errors
|
|
172
|
+
|
|
173
|
+
## Real-World Impact
|
|
174
|
+
|
|
175
|
+
From debugging session (2025-10-03):
|
|
176
|
+
- 6 failures across 3 files
|
|
177
|
+
- 3 agents dispatched in parallel
|
|
178
|
+
- All investigations completed concurrently
|
|
179
|
+
- All fixes integrated successfully
|
|
180
|
+
- Zero conflicts between agent changes
|
|
@@ -0,0 +1,76 @@
|
|
|
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
|
+
# Executing Plans
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
Load plan, review critically, execute tasks in batches, report for review between batches.
|
|
11
|
+
|
|
12
|
+
**Core principle:** Batch execution with checkpoints for architect review.
|
|
13
|
+
|
|
14
|
+
**Announce at start:** "I'm using the executing-plans skill to implement this plan."
|
|
15
|
+
|
|
16
|
+
## The Process
|
|
17
|
+
|
|
18
|
+
### Step 1: Load and Review Plan
|
|
19
|
+
1. Read plan file
|
|
20
|
+
2. Review critically - identify any questions or concerns about the plan
|
|
21
|
+
3. If concerns: Raise them with your human partner before starting
|
|
22
|
+
4. If no concerns: Create TodoWrite and proceed
|
|
23
|
+
|
|
24
|
+
### Step 2: Execute Batch
|
|
25
|
+
**Default: First 3 tasks**
|
|
26
|
+
|
|
27
|
+
For each task:
|
|
28
|
+
1. Mark as in_progress
|
|
29
|
+
2. Follow each step exactly (plan has bite-sized steps)
|
|
30
|
+
3. Run verifications as specified
|
|
31
|
+
4. Mark as completed
|
|
32
|
+
|
|
33
|
+
### Step 3: Report
|
|
34
|
+
When batch complete:
|
|
35
|
+
- Show what was implemented
|
|
36
|
+
- Show verification output
|
|
37
|
+
- Say: "Ready for feedback."
|
|
38
|
+
|
|
39
|
+
### Step 4: Continue
|
|
40
|
+
Based on feedback:
|
|
41
|
+
- Apply changes if needed
|
|
42
|
+
- Execute next batch
|
|
43
|
+
- Repeat until complete
|
|
44
|
+
|
|
45
|
+
### Step 5: Complete Development
|
|
46
|
+
|
|
47
|
+
After all tasks complete and verified:
|
|
48
|
+
- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
|
|
49
|
+
- **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch
|
|
50
|
+
- Follow that skill to verify tests, present options, execute choice
|
|
51
|
+
|
|
52
|
+
## When to Stop and Ask for Help
|
|
53
|
+
|
|
54
|
+
**STOP executing immediately when:**
|
|
55
|
+
- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
|
|
56
|
+
- Plan has critical gaps preventing starting
|
|
57
|
+
- You don't understand an instruction
|
|
58
|
+
- Verification fails repeatedly
|
|
59
|
+
|
|
60
|
+
**Ask for clarification rather than guessing.**
|
|
61
|
+
|
|
62
|
+
## When to Revisit Earlier Steps
|
|
63
|
+
|
|
64
|
+
**Return to Review (Step 1) when:**
|
|
65
|
+
- Partner updates the plan based on your feedback
|
|
66
|
+
- Fundamental approach needs rethinking
|
|
67
|
+
|
|
68
|
+
**Don't force through blockers** - stop and ask.
|
|
69
|
+
|
|
70
|
+
## Remember
|
|
71
|
+
- Review plan critically first
|
|
72
|
+
- Follow plan steps exactly
|
|
73
|
+
- Don't skip verifications
|
|
74
|
+
- Reference skills when plan says to
|
|
75
|
+
- Between batches: just report and wait
|
|
76
|
+
- Stop when blocked, don't guess
|