opencode-agile-agent 1.0.1 → 1.0.2
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/README.md +61 -71
- package/bin/cli.js +344 -434
- package/bin/sync-templates.js +45 -0
- package/bin/validate-templates.js +44 -6
- package/package.json +2 -1
- package/templates/.opencode/ARCHITECTURE.md +82 -368
- package/templates/.opencode/README.md +110 -391
- package/templates/.opencode/agents/api-designer.md +45 -312
- package/templates/.opencode/agents/backend-specialist.md +46 -214
- package/templates/.opencode/agents/code-archaeologist.md +45 -260
- package/templates/.opencode/agents/context-gatherer.md +51 -0
- package/templates/.opencode/agents/database-architect.md +45 -212
- package/templates/.opencode/agents/debugger.md +45 -302
- package/templates/.opencode/agents/developer.md +45 -523
- package/templates/.opencode/agents/devops-engineer.md +45 -253
- package/templates/.opencode/agents/documentation-writer.md +45 -247
- package/templates/.opencode/agents/explorer-agent.md +49 -233
- package/templates/.opencode/agents/feature-lead.md +62 -302
- package/templates/.opencode/agents/frontend-specialist.md +46 -186
- package/templates/.opencode/agents/game-developer.md +45 -391
- package/templates/.opencode/agents/mobile-developer.md +45 -264
- package/templates/.opencode/agents/orchestrator.md +48 -463
- package/templates/.opencode/agents/penetration-tester.md +44 -254
- package/templates/.opencode/agents/performance-optimizer.md +45 -292
- package/templates/.opencode/agents/pr-reviewer.md +45 -468
- package/templates/.opencode/agents/product-manager.md +46 -225
- package/templates/.opencode/agents/project-planner.md +45 -248
- package/templates/.opencode/agents/qa-automation-engineer.md +45 -275
- package/templates/.opencode/agents/security-auditor.md +44 -258
- package/templates/.opencode/agents/seo-specialist.md +45 -266
- package/templates/.opencode/agents/system-analyst.md +48 -428
- package/templates/.opencode/agents/test-engineer.md +45 -229
- package/templates/.opencode/archive/README.md +24 -0
- package/templates/.opencode/commands/brainstorm.md +10 -0
- package/templates/.opencode/commands/create.md +11 -0
- package/templates/.opencode/commands/debug.md +10 -0
- package/templates/.opencode/commands/plan.md +9 -0
- package/templates/.opencode/commands/review.md +11 -0
- package/templates/.opencode/commands/status.md +9 -0
- package/templates/.opencode/commands/test.md +10 -0
- package/templates/.opencode/skills/api-patterns/SKILL.md +25 -149
- package/templates/.opencode/skills/brainstorming/SKILL.md +26 -242
- package/templates/.opencode/skills/clean-code/SKILL.md +27 -339
- package/templates/.opencode/skills/code-philosophy/SKILL.md +27 -499
- package/templates/.opencode/skills/context-archive/SKILL.md +47 -0
- package/templates/.opencode/skills/context-gathering/SKILL.md +51 -0
- package/templates/.opencode/skills/frontend-design/SKILL.md +26 -224
- package/templates/.opencode/skills/intelligent-routing/SKILL.md +25 -182
- package/templates/.opencode/skills/parallel-agents/SKILL.md +25 -261
- package/templates/.opencode/skills/plan-writing/SKILL.md +28 -238
- package/templates/.opencode/skills/redteam-validation/SKILL.md +33 -0
- package/templates/.opencode/skills/security-gate/SKILL.md +33 -0
- package/templates/.opencode/skills/systematic-debugging/SKILL.md +25 -197
- package/templates/.opencode/skills/testing-patterns/SKILL.md +25 -238
- package/templates/AGENTS.template.md +300 -426
- package/templates/.opencode/agents/product-owner.md +0 -264
- package/templates/.opencode/workflows/brainstorm.md +0 -110
- package/templates/.opencode/workflows/create.md +0 -108
- package/templates/.opencode/workflows/debug.md +0 -128
- package/templates/.opencode/workflows/deploy.md +0 -160
- package/templates/.opencode/workflows/enhance.md +0 -253
- package/templates/.opencode/workflows/orchestrate.md +0 -130
- package/templates/.opencode/workflows/plan.md +0 -163
- package/templates/.opencode/workflows/review.md +0 -135
- package/templates/.opencode/workflows/status.md +0 -102
- package/templates/.opencode/workflows/test.md +0 -146
|
@@ -1,160 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Deploy application to production or staging. Use when ready to release.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# /deploy Workflow
|
|
6
|
-
|
|
7
|
-
Deploy applications to production, staging, or other environments.
|
|
8
|
-
|
|
9
|
-
## When to Use
|
|
10
|
-
|
|
11
|
-
- Ready to release to production
|
|
12
|
-
- Deploying to staging for testing
|
|
13
|
-
- Rolling out a new version
|
|
14
|
-
- Setting up CI/CD
|
|
15
|
-
|
|
16
|
-
## Workflow Steps
|
|
17
|
-
|
|
18
|
-
### Step 1: Pre-Deployment Check
|
|
19
|
-
|
|
20
|
-
```
|
|
21
|
-
Verify readiness:
|
|
22
|
-
- [ ] All tests pass
|
|
23
|
-
- [ ] Code reviewed and approved
|
|
24
|
-
- [ ] Changelog updated
|
|
25
|
-
- [ ] Environment variables configured
|
|
26
|
-
- [ ] Database migrations ready (if needed)
|
|
27
|
-
```
|
|
28
|
-
|
|
29
|
-
### Step 2: Build
|
|
30
|
-
|
|
31
|
-
```
|
|
32
|
-
Prepare the build:
|
|
33
|
-
1. Install dependencies
|
|
34
|
-
2. Run build command
|
|
35
|
-
3. Verify build output
|
|
36
|
-
4. Check bundle size
|
|
37
|
-
```
|
|
38
|
-
|
|
39
|
-
### Step 3: Deploy
|
|
40
|
-
|
|
41
|
-
```
|
|
42
|
-
Execute deployment:
|
|
43
|
-
1. Choose deployment target
|
|
44
|
-
2. Deploy to environment
|
|
45
|
-
3. Monitor deployment progress
|
|
46
|
-
4. Verify deployment success
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
### Step 4: Post-Deployment Verification
|
|
50
|
-
|
|
51
|
-
```
|
|
52
|
-
Verify the deployment:
|
|
53
|
-
1. Health check endpoints
|
|
54
|
-
2. Smoke tests
|
|
55
|
-
3. Key user flows
|
|
56
|
-
4. Error monitoring
|
|
57
|
-
```
|
|
58
|
-
|
|
59
|
-
### Step 5: Monitor
|
|
60
|
-
|
|
61
|
-
```
|
|
62
|
-
Watch for issues:
|
|
63
|
-
- Error rates
|
|
64
|
-
- Response times
|
|
65
|
-
- Resource usage
|
|
66
|
-
- User feedback
|
|
67
|
-
```
|
|
68
|
-
|
|
69
|
-
## Deployment Targets
|
|
70
|
-
|
|
71
|
-
### Vercel
|
|
72
|
-
|
|
73
|
-
```bash
|
|
74
|
-
# Install CLI
|
|
75
|
-
npm i -g vercel
|
|
76
|
-
|
|
77
|
-
# Deploy
|
|
78
|
-
vercel --prod
|
|
79
|
-
```
|
|
80
|
-
|
|
81
|
-
### Docker
|
|
82
|
-
|
|
83
|
-
```bash
|
|
84
|
-
# Build image
|
|
85
|
-
docker build -t app:latest .
|
|
86
|
-
|
|
87
|
-
# Run container
|
|
88
|
-
docker run -p 3000:3000 app:latest
|
|
89
|
-
```
|
|
90
|
-
|
|
91
|
-
### Kubernetes
|
|
92
|
-
|
|
93
|
-
```bash
|
|
94
|
-
# Apply manifests
|
|
95
|
-
kubectl apply -f k8s/
|
|
96
|
-
|
|
97
|
-
# Verify deployment
|
|
98
|
-
kubectl get pods
|
|
99
|
-
```
|
|
100
|
-
|
|
101
|
-
### AWS
|
|
102
|
-
|
|
103
|
-
```bash
|
|
104
|
-
# Deploy to ECS
|
|
105
|
-
aws ecs update-service --cluster prod --service app --force-new-deployment
|
|
106
|
-
|
|
107
|
-
# Or use SAM/CDK
|
|
108
|
-
sam deploy --guided
|
|
109
|
-
```
|
|
110
|
-
|
|
111
|
-
## Rollback Plan
|
|
112
|
-
|
|
113
|
-
```
|
|
114
|
-
If deployment fails:
|
|
115
|
-
1. Identify the issue
|
|
116
|
-
2. Rollback to previous version
|
|
117
|
-
3. Investigate in development
|
|
118
|
-
4. Fix and redeploy
|
|
119
|
-
|
|
120
|
-
Rollback commands:
|
|
121
|
-
- Vercel: vercel rollback
|
|
122
|
-
- Docker: docker tag app:previous app:latest
|
|
123
|
-
- K8s: kubectl rollout undo deployment/app
|
|
124
|
-
```
|
|
125
|
-
|
|
126
|
-
## Example
|
|
127
|
-
|
|
128
|
-
```
|
|
129
|
-
User: /deploy to production
|
|
130
|
-
|
|
131
|
-
Agent: I'll help you deploy to production.
|
|
132
|
-
|
|
133
|
-
**Pre-Deployment Check:**
|
|
134
|
-
- [x] All tests pass
|
|
135
|
-
- [x] Code reviewed
|
|
136
|
-
- [x] Changelog updated
|
|
137
|
-
- [x] Environment configured
|
|
138
|
-
|
|
139
|
-
**Build:**
|
|
140
|
-
- Installing dependencies...
|
|
141
|
-
- Building application...
|
|
142
|
-
- Bundle size: 245KB (within budget)
|
|
143
|
-
|
|
144
|
-
**Deploy:**
|
|
145
|
-
- Target: Vercel
|
|
146
|
-
- Environment: production
|
|
147
|
-
- Deploying...
|
|
148
|
-
|
|
149
|
-
**Verification:**
|
|
150
|
-
- Health check: ✅
|
|
151
|
-
- Smoke tests: ✅
|
|
152
|
-
- Key flows: ✅
|
|
153
|
-
|
|
154
|
-
**Deployed Successfully!**
|
|
155
|
-
URL: https://app.example.com
|
|
156
|
-
```
|
|
157
|
-
|
|
158
|
-
---
|
|
159
|
-
|
|
160
|
-
**Deploy with confidence, rollback with ease.**
|
|
@@ -1,253 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Improve existing code for better quality, performance, or maintainability.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# /enhance Workflow
|
|
6
|
-
|
|
7
|
-
Improve existing code without changing its behavior.
|
|
8
|
-
|
|
9
|
-
## When to Use
|
|
10
|
-
|
|
11
|
-
- Code works but could be better
|
|
12
|
-
- Refactoring for maintainability
|
|
13
|
-
- Performance optimization
|
|
14
|
-
- Adding error handling
|
|
15
|
-
- Improving code quality
|
|
16
|
-
|
|
17
|
-
## Workflow Steps
|
|
18
|
-
|
|
19
|
-
### Step 1: Analyze Current State
|
|
20
|
-
|
|
21
|
-
```
|
|
22
|
-
Understand what exists:
|
|
23
|
-
- What does this code do?
|
|
24
|
-
- What are the pain points?
|
|
25
|
-
- What improvements are needed?
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
### Step 2: Identify Improvements
|
|
29
|
-
|
|
30
|
-
```
|
|
31
|
-
Common improvements:
|
|
32
|
-
- Extract duplicated code
|
|
33
|
-
- Improve naming
|
|
34
|
-
- Add error handling
|
|
35
|
-
- Optimize performance
|
|
36
|
-
- Increase test coverage
|
|
37
|
-
- Improve type safety
|
|
38
|
-
```
|
|
39
|
-
|
|
40
|
-
### Step 3: Prioritize
|
|
41
|
-
|
|
42
|
-
```
|
|
43
|
-
Impact vs. Effort:
|
|
44
|
-
- High impact, low effort → Do first
|
|
45
|
-
- High impact, high effort → Plan carefully
|
|
46
|
-
- Low impact, low effort → Do if time permits
|
|
47
|
-
- Low impact, high effort → Skip
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
### Step 4: Implement
|
|
51
|
-
|
|
52
|
-
```
|
|
53
|
-
Small, incremental changes:
|
|
54
|
-
1. Make one improvement
|
|
55
|
-
2. Test thoroughly
|
|
56
|
-
3. Commit
|
|
57
|
-
4. Repeat
|
|
58
|
-
```
|
|
59
|
-
|
|
60
|
-
### Step 5: Verify
|
|
61
|
-
|
|
62
|
-
```
|
|
63
|
-
Ensure behavior unchanged:
|
|
64
|
-
- All existing tests pass
|
|
65
|
-
- New tests added for edge cases
|
|
66
|
-
- Manual testing complete
|
|
67
|
-
```
|
|
68
|
-
|
|
69
|
-
## Enhancement Categories
|
|
70
|
-
|
|
71
|
-
### Code Quality
|
|
72
|
-
|
|
73
|
-
```typescript
|
|
74
|
-
// Before
|
|
75
|
-
function calc(a, b, c) {
|
|
76
|
-
if (a > 0) {
|
|
77
|
-
if (b > 0) {
|
|
78
|
-
return a + b + c;
|
|
79
|
-
}
|
|
80
|
-
}
|
|
81
|
-
return 0;
|
|
82
|
-
}
|
|
83
|
-
|
|
84
|
-
// After
|
|
85
|
-
function calculateSum(base: number, addition: number, extra: number): number {
|
|
86
|
-
if (base <= 0 || addition <= 0) {
|
|
87
|
-
return 0;
|
|
88
|
-
}
|
|
89
|
-
return base + addition + extra;
|
|
90
|
-
}
|
|
91
|
-
```
|
|
92
|
-
|
|
93
|
-
### Error Handling
|
|
94
|
-
|
|
95
|
-
```typescript
|
|
96
|
-
// Before
|
|
97
|
-
async function getUser(id) {
|
|
98
|
-
const response = await fetch(`/api/users/${id}`);
|
|
99
|
-
return response.json();
|
|
100
|
-
}
|
|
101
|
-
|
|
102
|
-
// After
|
|
103
|
-
async function getUser(id: string): Promise<User> {
|
|
104
|
-
validateUserId(id);
|
|
105
|
-
|
|
106
|
-
const response = await fetch(`/api/users/${id}`);
|
|
107
|
-
|
|
108
|
-
if (!response.ok) {
|
|
109
|
-
if (response.status === 404) {
|
|
110
|
-
throw new UserNotFoundError(id);
|
|
111
|
-
}
|
|
112
|
-
throw new ApiError(`Failed to fetch user: ${response.status}`);
|
|
113
|
-
}
|
|
114
|
-
|
|
115
|
-
return response.json();
|
|
116
|
-
}
|
|
117
|
-
```
|
|
118
|
-
|
|
119
|
-
### Performance
|
|
120
|
-
|
|
121
|
-
```typescript
|
|
122
|
-
// Before
|
|
123
|
-
function findUser(users: User[], name: string): User | undefined {
|
|
124
|
-
return users.find(user => user.name === name);
|
|
125
|
-
}
|
|
126
|
-
const user = findUser(allUsers, 'John'); // O(n) per call
|
|
127
|
-
|
|
128
|
-
// After
|
|
129
|
-
class UserLookup {
|
|
130
|
-
private byName: Map<string, User>;
|
|
131
|
-
|
|
132
|
-
constructor(users: User[]) {
|
|
133
|
-
this.byName = new Map(users.map(u => [u.name, u]));
|
|
134
|
-
}
|
|
135
|
-
|
|
136
|
-
findByName(name: string): User | undefined {
|
|
137
|
-
return this.byName.get(name); // O(1)
|
|
138
|
-
}
|
|
139
|
-
}
|
|
140
|
-
```
|
|
141
|
-
|
|
142
|
-
### Type Safety
|
|
143
|
-
|
|
144
|
-
```typescript
|
|
145
|
-
// Before
|
|
146
|
-
function process(data) {
|
|
147
|
-
return data.items.map(i => i.value);
|
|
148
|
-
}
|
|
149
|
-
|
|
150
|
-
// After
|
|
151
|
-
interface Data {
|
|
152
|
-
items: Array<{ value: number }>;
|
|
153
|
-
}
|
|
154
|
-
|
|
155
|
-
function process(data: Data): number[] {
|
|
156
|
-
return data.items.map(i => i.value);
|
|
157
|
-
}
|
|
158
|
-
```
|
|
159
|
-
|
|
160
|
-
## Example
|
|
161
|
-
|
|
162
|
-
```
|
|
163
|
-
User: /enhance login function for better error handling
|
|
164
|
-
|
|
165
|
-
Agent: I'll enhance the login function.
|
|
166
|
-
|
|
167
|
-
**Current State:**
|
|
168
|
-
```typescript
|
|
169
|
-
async function login(email, password) {
|
|
170
|
-
const response = await fetch('/api/login', {
|
|
171
|
-
method: 'POST',
|
|
172
|
-
body: JSON.stringify({ email, password })
|
|
173
|
-
});
|
|
174
|
-
return response.json();
|
|
175
|
-
}
|
|
176
|
-
```
|
|
177
|
-
|
|
178
|
-
**Issues:**
|
|
179
|
-
1. No input validation
|
|
180
|
-
2. No error handling
|
|
181
|
-
3. No type safety
|
|
182
|
-
4. No loading state
|
|
183
|
-
5. Hardcoded URL
|
|
184
|
-
|
|
185
|
-
**Improvements:**
|
|
186
|
-
1. Add input validation
|
|
187
|
-
2. Add error handling
|
|
188
|
-
3. Add type safety
|
|
189
|
-
4. Add loading state
|
|
190
|
-
5. Extract URL to config
|
|
191
|
-
|
|
192
|
-
**Enhanced Version:**
|
|
193
|
-
```typescript
|
|
194
|
-
interface LoginCredentials {
|
|
195
|
-
email: string;
|
|
196
|
-
password: string;
|
|
197
|
-
}
|
|
198
|
-
|
|
199
|
-
interface LoginResult {
|
|
200
|
-
success: boolean;
|
|
201
|
-
user?: User;
|
|
202
|
-
error?: string;
|
|
203
|
-
}
|
|
204
|
-
|
|
205
|
-
async function login(
|
|
206
|
-
credentials: LoginCredentials
|
|
207
|
-
): Promise<LoginResult> {
|
|
208
|
-
// Validation
|
|
209
|
-
if (!isValidEmail(credentials.email)) {
|
|
210
|
-
return { success: false, error: 'Invalid email' };
|
|
211
|
-
}
|
|
212
|
-
|
|
213
|
-
if (credentials.password.length < 8) {
|
|
214
|
-
return { success: false, error: 'Password too short' };
|
|
215
|
-
}
|
|
216
|
-
|
|
217
|
-
try {
|
|
218
|
-
const response = await fetch(API_CONFIG.loginUrl, {
|
|
219
|
-
method: 'POST',
|
|
220
|
-
headers: { 'Content-Type': 'application/json' },
|
|
221
|
-
body: JSON.stringify(credentials)
|
|
222
|
-
});
|
|
223
|
-
|
|
224
|
-
if (!response.ok) {
|
|
225
|
-
return {
|
|
226
|
-
success: false,
|
|
227
|
-
error: mapError(response.status)
|
|
228
|
-
};
|
|
229
|
-
}
|
|
230
|
-
|
|
231
|
-
const user = await response.json();
|
|
232
|
-
return { success: true, user };
|
|
233
|
-
|
|
234
|
-
} catch (error) {
|
|
235
|
-
return {
|
|
236
|
-
success: false,
|
|
237
|
-
error: 'Network error'
|
|
238
|
-
};
|
|
239
|
-
}
|
|
240
|
-
}
|
|
241
|
-
```
|
|
242
|
-
|
|
243
|
-
Enhanced with:
|
|
244
|
-
- Input validation
|
|
245
|
-
- Error handling
|
|
246
|
-
- Type safety
|
|
247
|
-
- Configuration
|
|
248
|
-
- Proper error messages
|
|
249
|
-
```
|
|
250
|
-
|
|
251
|
-
---
|
|
252
|
-
|
|
253
|
-
**Enhance incrementally, verify constantly.**
|
|
@@ -1,130 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Multi-agent coordination for complex tasks. Use when a task requires multiple specialists.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# /orchestrate Workflow
|
|
6
|
-
|
|
7
|
-
Coordinate multiple agents for complex, multi-domain tasks.
|
|
8
|
-
|
|
9
|
-
## When to Use
|
|
10
|
-
|
|
11
|
-
- Tasks requiring multiple perspectives
|
|
12
|
-
- Full-stack features
|
|
13
|
-
- Comprehensive reviews
|
|
14
|
-
- Complex implementations
|
|
15
|
-
|
|
16
|
-
## Minimum Agent Requirement
|
|
17
|
-
|
|
18
|
-
> **Orchestration requires at least 2 different agents.**
|
|
19
|
-
|
|
20
|
-
## Workflow Steps
|
|
21
|
-
|
|
22
|
-
### Step 1: Task Analysis
|
|
23
|
-
|
|
24
|
-
```
|
|
25
|
-
Analyze the task:
|
|
26
|
-
1. What domains are involved?
|
|
27
|
-
2. What skills are needed?
|
|
28
|
-
3. What are the dependencies?
|
|
29
|
-
4. What's the complexity level?
|
|
30
|
-
```
|
|
31
|
-
|
|
32
|
-
### Step 2: Agent Selection
|
|
33
|
-
|
|
34
|
-
```
|
|
35
|
-
Select appropriate agents:
|
|
36
|
-
- Security → security-auditor
|
|
37
|
-
- Frontend → frontend-specialist
|
|
38
|
-
- Backend → backend-specialist
|
|
39
|
-
- Database → database-architect
|
|
40
|
-
- Testing → test-engineer
|
|
41
|
-
- DevOps → devops-engineer
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
### Step 3: Plan Execution
|
|
45
|
-
|
|
46
|
-
```
|
|
47
|
-
Order agents by dependencies:
|
|
48
|
-
1. Foundation agents (database, security)
|
|
49
|
-
2. Core agents (backend, frontend)
|
|
50
|
-
3. Polish agents (testing, performance)
|
|
51
|
-
```
|
|
52
|
-
|
|
53
|
-
### Step 4: Execute
|
|
54
|
-
|
|
55
|
-
```
|
|
56
|
-
Invoke agents with context:
|
|
57
|
-
1. Pass full context to each agent
|
|
58
|
-
2. Collect findings from each
|
|
59
|
-
3. Handle any conflicts
|
|
60
|
-
4. Ensure boundaries respected
|
|
61
|
-
```
|
|
62
|
-
|
|
63
|
-
### Step 5: Synthesize
|
|
64
|
-
|
|
65
|
-
```
|
|
66
|
-
Combine results:
|
|
67
|
-
1. Merge findings
|
|
68
|
-
2. Resolve conflicts
|
|
69
|
-
3. Create unified report
|
|
70
|
-
4. Provide recommendations
|
|
71
|
-
```
|
|
72
|
-
|
|
73
|
-
## Example
|
|
74
|
-
|
|
75
|
-
```
|
|
76
|
-
User: /orchestrate build secure user management
|
|
77
|
-
|
|
78
|
-
Agent: I'll coordinate multiple agents for this task.
|
|
79
|
-
|
|
80
|
-
**Task Analysis:**
|
|
81
|
-
- Domains: Auth, Frontend, Backend, Database, Security
|
|
82
|
-
- Complexity: High
|
|
83
|
-
- Dependencies: DB → API → UI
|
|
84
|
-
|
|
85
|
-
**Agents Selected:**
|
|
86
|
-
1. database-architect (schema)
|
|
87
|
-
2. backend-specialist (API)
|
|
88
|
-
3. frontend-specialist (UI)
|
|
89
|
-
4. security-auditor (review)
|
|
90
|
-
5. test-engineer (tests)
|
|
91
|
-
|
|
92
|
-
**Execution:**
|
|
93
|
-
|
|
94
|
-
[database-architect]
|
|
95
|
-
- Created user schema
|
|
96
|
-
- Added indexes
|
|
97
|
-
- Migration ready
|
|
98
|
-
|
|
99
|
-
[backend-specialist]
|
|
100
|
-
- Created auth endpoints
|
|
101
|
-
- Implemented JWT
|
|
102
|
-
- Added validation
|
|
103
|
-
|
|
104
|
-
[frontend-specialist]
|
|
105
|
-
- Created login/register forms
|
|
106
|
-
- Implemented auth state
|
|
107
|
-
- Added route guards
|
|
108
|
-
|
|
109
|
-
[security-auditor]
|
|
110
|
-
- Reviewed auth implementation
|
|
111
|
-
- Identified 2 issues
|
|
112
|
-
- Provided fixes
|
|
113
|
-
|
|
114
|
-
[test-engineer]
|
|
115
|
-
- Added unit tests
|
|
116
|
-
- Added integration tests
|
|
117
|
-
- Coverage: 85%
|
|
118
|
-
|
|
119
|
-
**Synthesis Report:**
|
|
120
|
-
- Files created: 12
|
|
121
|
-
- Files modified: 5
|
|
122
|
-
- Issues found: 2 (fixed)
|
|
123
|
-
- Tests added: 24
|
|
124
|
-
|
|
125
|
-
**Ready for review!**
|
|
126
|
-
```
|
|
127
|
-
|
|
128
|
-
---
|
|
129
|
-
|
|
130
|
-
**Orchestration multiplies capability through coordination.**
|
|
@@ -1,163 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Create structured task breakdowns and plans. Use when starting complex work.
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# /plan Workflow
|
|
6
|
-
|
|
7
|
-
Create detailed plans and task breakdowns for complex work.
|
|
8
|
-
|
|
9
|
-
## When to Use
|
|
10
|
-
|
|
11
|
-
- Starting a new feature
|
|
12
|
-
- Breaking down complex tasks
|
|
13
|
-
- Creating project roadmaps
|
|
14
|
-
- Need clear direction before coding
|
|
15
|
-
|
|
16
|
-
## Workflow Steps
|
|
17
|
-
|
|
18
|
-
### Step 1: Understand the Goal
|
|
19
|
-
|
|
20
|
-
```
|
|
21
|
-
Clarify the objective:
|
|
22
|
-
1. What are we building?
|
|
23
|
-
2. Why does it matter?
|
|
24
|
-
3. What are the constraints?
|
|
25
|
-
4. What does success look like?
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
### Step 2: Gather Requirements
|
|
29
|
-
|
|
30
|
-
```
|
|
31
|
-
Document requirements:
|
|
32
|
-
- Functional requirements
|
|
33
|
-
- Non-functional requirements
|
|
34
|
-
- Constraints
|
|
35
|
-
- Assumptions
|
|
36
|
-
```
|
|
37
|
-
|
|
38
|
-
### Step 3: Break Down Tasks
|
|
39
|
-
|
|
40
|
-
```
|
|
41
|
-
Decompose into atomic tasks:
|
|
42
|
-
1. Each task should be completable in < 1 day
|
|
43
|
-
2. Tasks should have clear deliverables
|
|
44
|
-
3. Dependencies should be identified
|
|
45
|
-
4. Effort estimates should be included
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
### Step 4: Sequence Tasks
|
|
49
|
-
|
|
50
|
-
```
|
|
51
|
-
Order by dependencies:
|
|
52
|
-
- What must be done first?
|
|
53
|
-
- What can be done in parallel?
|
|
54
|
-
- What's the critical path?
|
|
55
|
-
```
|
|
56
|
-
|
|
57
|
-
### Step 5: Define Success Criteria
|
|
58
|
-
|
|
59
|
-
```
|
|
60
|
-
How will we know we're done?
|
|
61
|
-
- Measurable outcomes
|
|
62
|
-
- Acceptance criteria
|
|
63
|
-
- Quality gates
|
|
64
|
-
```
|
|
65
|
-
|
|
66
|
-
### Step 6: Document the Plan
|
|
67
|
-
|
|
68
|
-
```
|
|
69
|
-
Create plan document:
|
|
70
|
-
- Overview
|
|
71
|
-
- Requirements
|
|
72
|
-
- Tasks
|
|
73
|
-
- Dependencies
|
|
74
|
-
- Timeline
|
|
75
|
-
- Success criteria
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
## Plan Template
|
|
79
|
-
|
|
80
|
-
```markdown
|
|
81
|
-
# PLAN: [Feature Name]
|
|
82
|
-
|
|
83
|
-
## Overview
|
|
84
|
-
Brief description.
|
|
85
|
-
|
|
86
|
-
## Requirements
|
|
87
|
-
### Functional
|
|
88
|
-
- [ ] Requirement 1
|
|
89
|
-
- [ ] Requirement 2
|
|
90
|
-
|
|
91
|
-
### Non-Functional
|
|
92
|
-
- Performance: [target]
|
|
93
|
-
- Security: [requirements]
|
|
94
|
-
|
|
95
|
-
## Tasks
|
|
96
|
-
### Phase 1: [Name]
|
|
97
|
-
| Task | Size | Dependencies |
|
|
98
|
-
|------|------|--------------|
|
|
99
|
-
| 1.1 [Task] | S | None |
|
|
100
|
-
| 1.2 [Task] | M | 1.1 |
|
|
101
|
-
|
|
102
|
-
### Phase 2: [Name]
|
|
103
|
-
| Task | Size | Dependencies |
|
|
104
|
-
|------|------|--------------|
|
|
105
|
-
| 2.1 [Task] | S | 1.2 |
|
|
106
|
-
|
|
107
|
-
## Success Criteria
|
|
108
|
-
- [ ] Criterion 1
|
|
109
|
-
- [ ] Criterion 2
|
|
110
|
-
|
|
111
|
-
## Risks
|
|
112
|
-
| Risk | Mitigation |
|
|
113
|
-
|------|------------|
|
|
114
|
-
| [Risk] | [Action] |
|
|
115
|
-
```
|
|
116
|
-
|
|
117
|
-
## Example
|
|
118
|
-
|
|
119
|
-
```
|
|
120
|
-
User: /plan shopping cart feature
|
|
121
|
-
|
|
122
|
-
Agent: I'll create a plan for the shopping cart feature.
|
|
123
|
-
|
|
124
|
-
**Goal Clarification:**
|
|
125
|
-
- Add shopping cart to e-commerce site
|
|
126
|
-
- Users can add/remove items
|
|
127
|
-
- Persist across sessions
|
|
128
|
-
- Calculate totals with tax
|
|
129
|
-
|
|
130
|
-
**Requirements:**
|
|
131
|
-
- Add to cart from product page
|
|
132
|
-
- View cart with quantities
|
|
133
|
-
- Update quantities
|
|
134
|
-
- Remove items
|
|
135
|
-
- Calculate subtotal, tax, total
|
|
136
|
-
- Persist for logged-in users
|
|
137
|
-
|
|
138
|
-
**Tasks:**
|
|
139
|
-
| Task | Size | Dependencies |
|
|
140
|
-
|------|------|--------------|
|
|
141
|
-
| 1.1 Create CartItem type | XS | None |
|
|
142
|
-
| 1.2 Create CartStore | S | 1.1 |
|
|
143
|
-
| 1.3 Create AddToCart button | S | 1.2 |
|
|
144
|
-
| 1.4 Create CartPage | M | 1.2 |
|
|
145
|
-
| 1.5 Create CartItem component | S | 1.1 |
|
|
146
|
-
| 1.6 Implement quantity update | S | 1.4 |
|
|
147
|
-
| 1.7 Implement remove item | S | 1.4 |
|
|
148
|
-
| 1.8 Implement totals calculation | S | 1.1 |
|
|
149
|
-
| 1.9 Add persistence | M | 1.2 |
|
|
150
|
-
| 1.10 Add tests | M | All |
|
|
151
|
-
|
|
152
|
-
**Success Criteria:**
|
|
153
|
-
- [ ] Users can add/remove items
|
|
154
|
-
- [ ] Cart persists across sessions
|
|
155
|
-
- [ ] Totals calculate correctly
|
|
156
|
-
- [ ] All tests pass
|
|
157
|
-
|
|
158
|
-
**Plan saved to: context/shopping-cart/PLAN.md**
|
|
159
|
-
```
|
|
160
|
-
|
|
161
|
-
---
|
|
162
|
-
|
|
163
|
-
**Good plans make execution straightforward.**
|