@tech-leads-club/agent-skills 0.1.0-beta.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/CHANGELOG.md +112 -0
- package/index.js +22 -0
- package/index.js.map +7 -0
- package/package.json +40 -0
- package/skills/cursor-skill-creator/SKILL.md +379 -0
- package/skills/cursor-subagent-creator/SKILL.md +683 -0
- package/skills/skill-creator/SKILL.md +173 -0
- package/skills/spec-driven-dev/SKILL.md +43 -0
- package/skills/spec-driven-dev/references/design.md +140 -0
- package/skills/spec-driven-dev/references/implement.md +66 -0
- package/skills/spec-driven-dev/references/specify.md +116 -0
- package/skills/spec-driven-dev/references/tasks.md +221 -0
- package/skills/spec-driven-dev/references/validate.md +126 -0
- package/skills/subagent-creator/SKILL.md +283 -0
|
@@ -0,0 +1,221 @@
|
|
|
1
|
+
# Phase 3: Tasks
|
|
2
|
+
|
|
3
|
+
**Goal**: Break into GRANULAR, ATOMIC tasks. Clear dependencies. Right tools. Parallel execution plan.
|
|
4
|
+
|
|
5
|
+
## Why Granular Tasks?
|
|
6
|
+
|
|
7
|
+
| Vague Task (BAD) | Granular Tasks (GOOD) |
|
|
8
|
+
|------------------|----------------------|
|
|
9
|
+
| "Create form" | T1: Create email input component |
|
|
10
|
+
| | T2: Add email validation function |
|
|
11
|
+
| | T3: Create submit button |
|
|
12
|
+
| | T4: Add form state management |
|
|
13
|
+
| | T5: Connect form to API |
|
|
14
|
+
| "Implement auth" | T1: Create login form |
|
|
15
|
+
| | T2: Create register form |
|
|
16
|
+
| | T3: Add token storage utility |
|
|
17
|
+
| | T4: Create auth API service |
|
|
18
|
+
| | T5: Add route protection |
|
|
19
|
+
|
|
20
|
+
**Benefits of granular:**
|
|
21
|
+
- **Agents don't err** - Single focus, no ambiguity
|
|
22
|
+
- **Easy to test** - Each task = one verifiable outcome
|
|
23
|
+
- **Parallelizable** - Independent tasks run simultaneously
|
|
24
|
+
- **Errors isolated** - One failure doesn't block everything
|
|
25
|
+
|
|
26
|
+
**Rule**: One task = ONE of these:
|
|
27
|
+
- One component
|
|
28
|
+
- One function
|
|
29
|
+
- One API endpoint
|
|
30
|
+
- One file change
|
|
31
|
+
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
## Process
|
|
35
|
+
|
|
36
|
+
### 1. Review Design
|
|
37
|
+
Read `.specs/[feature]/design.md` before creating tasks.
|
|
38
|
+
|
|
39
|
+
### 2. Break Into Atomic Tasks
|
|
40
|
+
|
|
41
|
+
**Task = ONE deliverable**. Examples:
|
|
42
|
+
- ✅ "Create UserService interface" (one file, one concept)
|
|
43
|
+
- ❌ "Implement user management" (too vague, multiple files)
|
|
44
|
+
|
|
45
|
+
### 3. Define Dependencies
|
|
46
|
+
|
|
47
|
+
What MUST be done before this task can start?
|
|
48
|
+
|
|
49
|
+
### 4. Create Execution Plan
|
|
50
|
+
|
|
51
|
+
Group tasks into phases. Identify what can run in parallel.
|
|
52
|
+
|
|
53
|
+
### 5. ASK About MCPs and Skills
|
|
54
|
+
|
|
55
|
+
**CRITICAL**: Before execution, ask the user:
|
|
56
|
+
|
|
57
|
+
> "For each task, which tools should I use?"
|
|
58
|
+
>
|
|
59
|
+
> **Available MCPs**: [list from project or user]
|
|
60
|
+
> **Available Skills**: [list from project or user]
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
## Template: `.specs/[feature]/tasks.md`
|
|
65
|
+
|
|
66
|
+
```markdown
|
|
67
|
+
# [Feature] Tasks
|
|
68
|
+
|
|
69
|
+
**Design**: `.specs/[feature]/design.md`
|
|
70
|
+
**Status**: Draft | Approved | In Progress | Done
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
## Execution Plan
|
|
75
|
+
|
|
76
|
+
### Phase 1: Foundation (Sequential)
|
|
77
|
+
Tasks that must be done first, in order.
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
T1 → T2 → T3
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
### Phase 2: Core Implementation (Parallel OK)
|
|
84
|
+
After foundation, these can run in parallel.
|
|
85
|
+
|
|
86
|
+
```
|
|
87
|
+
┌→ T4 ─┐
|
|
88
|
+
T3 ──┼→ T5 ─┼──→ T8
|
|
89
|
+
└→ T6 ─┘
|
|
90
|
+
T7 ──────→
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
### Phase 3: Integration (Sequential)
|
|
94
|
+
Bringing it all together.
|
|
95
|
+
|
|
96
|
+
```
|
|
97
|
+
T8 → T9
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## Task Breakdown
|
|
103
|
+
|
|
104
|
+
### T1: [Create X Interface]
|
|
105
|
+
|
|
106
|
+
**What**: [One sentence: exact deliverable]
|
|
107
|
+
**Where**: `src/path/to/file.ts`
|
|
108
|
+
**Depends on**: None
|
|
109
|
+
**Reuses**: `src/existing/BaseInterface.ts`
|
|
110
|
+
|
|
111
|
+
**Tools**:
|
|
112
|
+
- MCP: `filesystem` (or NONE)
|
|
113
|
+
- Skill: NONE
|
|
114
|
+
|
|
115
|
+
**Done when**:
|
|
116
|
+
- [ ] Interface defined with all methods from design
|
|
117
|
+
- [ ] Types exported correctly
|
|
118
|
+
- [ ] No TypeScript errors
|
|
119
|
+
|
|
120
|
+
---
|
|
121
|
+
|
|
122
|
+
### T2: [Implement Y Service] [P]
|
|
123
|
+
|
|
124
|
+
**What**: [Exact deliverable]
|
|
125
|
+
**Where**: `src/services/YService.ts`
|
|
126
|
+
**Depends on**: T1
|
|
127
|
+
**Reuses**: `src/services/BaseService.ts` patterns
|
|
128
|
+
|
|
129
|
+
**Tools**:
|
|
130
|
+
- MCP: `filesystem`, `context7`
|
|
131
|
+
- Skill: NONE
|
|
132
|
+
|
|
133
|
+
**Done when**:
|
|
134
|
+
- [ ] Implements interface from T1
|
|
135
|
+
- [ ] Handles error cases from design
|
|
136
|
+
- [ ] Unit test passes
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
### T3: [Create Z Component] [P]
|
|
141
|
+
|
|
142
|
+
**What**: [Exact deliverable]
|
|
143
|
+
**Where**: `src/components/ZComponent.tsx`
|
|
144
|
+
**Depends on**: T1
|
|
145
|
+
**Reuses**: `src/components/BaseComponent.tsx`
|
|
146
|
+
|
|
147
|
+
**Tools**:
|
|
148
|
+
- MCP: `filesystem`
|
|
149
|
+
- Skill: NONE
|
|
150
|
+
|
|
151
|
+
**Done when**:
|
|
152
|
+
- [ ] Component renders correctly
|
|
153
|
+
- [ ] Handles props from interface
|
|
154
|
+
- [ ] Follows existing component patterns
|
|
155
|
+
|
|
156
|
+
---
|
|
157
|
+
|
|
158
|
+
### T4: [Add A Feature to Y]
|
|
159
|
+
|
|
160
|
+
**What**: [Exact deliverable]
|
|
161
|
+
**Where**: `src/services/YService.ts` (modify)
|
|
162
|
+
**Depends on**: T2, T3
|
|
163
|
+
**Reuses**: Existing service patterns
|
|
164
|
+
|
|
165
|
+
**Tools**:
|
|
166
|
+
- MCP: `filesystem`, `github`
|
|
167
|
+
- Skill: `api-design`
|
|
168
|
+
|
|
169
|
+
**Done when**:
|
|
170
|
+
- [ ] Feature works per acceptance criteria
|
|
171
|
+
- [ ] Integration test passes
|
|
172
|
+
|
|
173
|
+
---
|
|
174
|
+
|
|
175
|
+
## Parallel Execution Map
|
|
176
|
+
|
|
177
|
+
Visual representation of what can run simultaneously:
|
|
178
|
+
|
|
179
|
+
```
|
|
180
|
+
Phase 1 (Sequential):
|
|
181
|
+
T1 ──→ T2 ──→ T3
|
|
182
|
+
|
|
183
|
+
Phase 2 (Parallel):
|
|
184
|
+
T3 complete, then:
|
|
185
|
+
├── T4 [P]
|
|
186
|
+
├── T5 [P] } Can run simultaneously
|
|
187
|
+
└── T6 [P]
|
|
188
|
+
|
|
189
|
+
Phase 3 (Sequential):
|
|
190
|
+
T4, T5, T6 complete, then:
|
|
191
|
+
T7 ──→ T8
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
---
|
|
195
|
+
|
|
196
|
+
## Task Granularity Check
|
|
197
|
+
|
|
198
|
+
Before approving tasks, verify they are granular enough:
|
|
199
|
+
|
|
200
|
+
| Task | Scope | Status |
|
|
201
|
+
|------|-------|--------|
|
|
202
|
+
| T1: Create email input | 1 component | ✅ Granular |
|
|
203
|
+
| T2: Add validation function | 1 function | ✅ Granular |
|
|
204
|
+
| T3: Create form with all fields | 5+ components | ❌ Split it! |
|
|
205
|
+
| T4: Connect to API | 1 function | ✅ Granular |
|
|
206
|
+
|
|
207
|
+
**Granularity check**:
|
|
208
|
+
- ✅ 1 component / 1 function / 1 endpoint = Good
|
|
209
|
+
- ⚠️ 2-3 related things in same file = OK if cohesive
|
|
210
|
+
- ❌ Multiple components or files = MUST split
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
## Tips
|
|
216
|
+
|
|
217
|
+
- **[P] = Parallel OK** - Mark tasks that can run simultaneously
|
|
218
|
+
- **Reuses = Token saver** - Always reference existing code
|
|
219
|
+
- **Tools per task** - MCPs and Skills prevent wrong approaches
|
|
220
|
+
- **Dependencies are gates** - Clear what blocks what
|
|
221
|
+
- **Done when = Testable** - If you can't verify it, rewrite it
|
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
# Phase 4b: Validate
|
|
2
|
+
|
|
3
|
+
**Goal**: Verify implementation meets spec requirements.
|
|
4
|
+
|
|
5
|
+
## When to Validate
|
|
6
|
+
|
|
7
|
+
- After completing a user story (all tasks for P1, P2, etc.)
|
|
8
|
+
- After completing all tasks
|
|
9
|
+
- When user requests validation
|
|
10
|
+
|
|
11
|
+
## Process
|
|
12
|
+
|
|
13
|
+
### 1. Check Completed Tasks
|
|
14
|
+
|
|
15
|
+
Go through tasks.md:
|
|
16
|
+
- [ ] All tasks marked done?
|
|
17
|
+
- [ ] Any blocked or partial?
|
|
18
|
+
|
|
19
|
+
### 2. Verify Acceptance Criteria
|
|
20
|
+
|
|
21
|
+
For each user story in spec.md:
|
|
22
|
+
|
|
23
|
+
```markdown
|
|
24
|
+
### P1: [Story Title]
|
|
25
|
+
|
|
26
|
+
**Acceptance Criteria**:
|
|
27
|
+
1. WHEN [X] THEN [Y] → [PASS/FAIL]
|
|
28
|
+
2. WHEN [X] THEN [Y] → [PASS/FAIL]
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
### 3. Check Edge Cases
|
|
32
|
+
|
|
33
|
+
From spec.md edge cases:
|
|
34
|
+
- [ ] [Edge case 1] handled correctly
|
|
35
|
+
- [ ] [Edge case 2] handled correctly
|
|
36
|
+
|
|
37
|
+
### 4. Run Tests (if applicable)
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
npm test # or project test command
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
### 5. Report
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## Validation Report Template
|
|
48
|
+
|
|
49
|
+
```markdown
|
|
50
|
+
# [Feature] Validation
|
|
51
|
+
|
|
52
|
+
**Date**: [YYYY-MM-DD]
|
|
53
|
+
**Spec**: `.specs/[feature]/spec.md`
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## Task Completion
|
|
58
|
+
|
|
59
|
+
| Task | Status | Notes |
|
|
60
|
+
|------|--------|-------|
|
|
61
|
+
| T1 | ✅ Done | - |
|
|
62
|
+
| T2 | ✅ Done | - |
|
|
63
|
+
| T3 | ⚠️ Partial | [Issue] |
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
## User Story Validation
|
|
68
|
+
|
|
69
|
+
### P1: [Story Title] ⭐ MVP
|
|
70
|
+
|
|
71
|
+
| Criterion | Result |
|
|
72
|
+
|-----------|--------|
|
|
73
|
+
| WHEN X THEN Y | ✅ PASS |
|
|
74
|
+
| WHEN A THEN B | ✅ PASS |
|
|
75
|
+
|
|
76
|
+
**Status**: ✅ P1 Complete
|
|
77
|
+
|
|
78
|
+
### P2: [Story Title]
|
|
79
|
+
|
|
80
|
+
| Criterion | Result |
|
|
81
|
+
|-----------|--------|
|
|
82
|
+
| WHEN X THEN Y | ❌ FAIL - [reason] |
|
|
83
|
+
|
|
84
|
+
**Status**: ⚠️ P2 Issues
|
|
85
|
+
|
|
86
|
+
---
|
|
87
|
+
|
|
88
|
+
## Edge Cases
|
|
89
|
+
|
|
90
|
+
- [x] Edge case 1: Handled correctly
|
|
91
|
+
- [ ] Edge case 2: NOT handled - needs fix
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
## Tests
|
|
96
|
+
|
|
97
|
+
- **Ran**: `npm test`
|
|
98
|
+
- **Result**: 15 passed, 2 failed
|
|
99
|
+
- **Failures**: [list]
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## Summary
|
|
104
|
+
|
|
105
|
+
**Overall**: ✅ Ready | ⚠️ Issues | ❌ Not Ready
|
|
106
|
+
|
|
107
|
+
**What works**:
|
|
108
|
+
- [List]
|
|
109
|
+
|
|
110
|
+
**Issues found**:
|
|
111
|
+
- [Issue 1]: [How to fix]
|
|
112
|
+
- [Issue 2]: [How to fix]
|
|
113
|
+
|
|
114
|
+
**Recommended next steps**:
|
|
115
|
+
1. [Action]
|
|
116
|
+
2. [Action]
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## Tips
|
|
122
|
+
|
|
123
|
+
- **P1 first** - MVP must work before P2/P3
|
|
124
|
+
- **WHEN/THEN = Test** - Each criterion is a test case
|
|
125
|
+
- **Be specific** - "Doesn't work" isn't helpful
|
|
126
|
+
- **Recommend fixes** - Don't just report problems
|
|
@@ -0,0 +1,283 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: subagent-creator
|
|
3
|
+
description: Guide for creating AI subagents with isolated context for complex multi-step workflows. Use when users want to create a subagent, specialized agent, verifier, debugger, or orchestrator that requires isolated context and deep specialization. Works with any agent that supports subagent delegation. Triggers on "create subagent", "new agent", "specialized assistant", "create verifier".
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Subagent Creator
|
|
7
|
+
|
|
8
|
+
This skill provides guidance for creating effective, agent-agnostic subagents.
|
|
9
|
+
|
|
10
|
+
## What are Subagents?
|
|
11
|
+
|
|
12
|
+
Subagents are specialized assistants that an AI agent can delegate tasks to. Characteristics:
|
|
13
|
+
|
|
14
|
+
- **Isolated context**: Each subagent has its own context window
|
|
15
|
+
- **Parallel execution**: Multiple subagents can run simultaneously
|
|
16
|
+
- **Specialization**: Configured with specific prompts and expertise
|
|
17
|
+
- **Reusable**: Defined once, used in multiple contexts
|
|
18
|
+
|
|
19
|
+
### When to Use Subagents vs Skills
|
|
20
|
+
|
|
21
|
+
```
|
|
22
|
+
Is the task complex with multiple steps?
|
|
23
|
+
├─ YES → Does it require isolated context?
|
|
24
|
+
│ ├─ YES → Use SUBAGENT
|
|
25
|
+
│ └─ NO → Use SKILL
|
|
26
|
+
│
|
|
27
|
+
└─ NO → Use SKILL
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
**Use Subagents for:**
|
|
31
|
+
- Complex workflows requiring isolated context
|
|
32
|
+
- Long-running tasks that benefit from specialization
|
|
33
|
+
- Verification and auditing (independent perspective)
|
|
34
|
+
- Parallel workstreams
|
|
35
|
+
|
|
36
|
+
**Use Skills for:**
|
|
37
|
+
- Quick, one-off actions
|
|
38
|
+
- Domain knowledge without context isolation
|
|
39
|
+
- Reusable procedures that don't need isolation
|
|
40
|
+
|
|
41
|
+
## Subagent Structure
|
|
42
|
+
|
|
43
|
+
A subagent is typically a markdown file with frontmatter metadata:
|
|
44
|
+
|
|
45
|
+
```markdown
|
|
46
|
+
---
|
|
47
|
+
name: agent-name
|
|
48
|
+
description: Description of when to use this subagent.
|
|
49
|
+
model: inherit # or fast, or specific model ID
|
|
50
|
+
readonly: false # true to restrict write permissions
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
You are an [expert in X].
|
|
54
|
+
|
|
55
|
+
When invoked:
|
|
56
|
+
1. [Step 1]
|
|
57
|
+
2. [Step 2]
|
|
58
|
+
3. [Step 3]
|
|
59
|
+
|
|
60
|
+
[Detailed instructions about expected behavior]
|
|
61
|
+
|
|
62
|
+
Report [type of expected result]:
|
|
63
|
+
- [Output format]
|
|
64
|
+
- [Metrics or specific information]
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
## Subagent Creation Process
|
|
68
|
+
|
|
69
|
+
### 1. Define the Purpose
|
|
70
|
+
|
|
71
|
+
- What specific responsibility does the subagent have?
|
|
72
|
+
- Why does it need isolated context?
|
|
73
|
+
- Does it involve multiple complex steps?
|
|
74
|
+
- Does it require deep specialization?
|
|
75
|
+
|
|
76
|
+
### 2. Configure the Metadata
|
|
77
|
+
|
|
78
|
+
#### name (required)
|
|
79
|
+
Unique identifier. Use kebab-case.
|
|
80
|
+
|
|
81
|
+
```yaml
|
|
82
|
+
name: security-auditor
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
#### description (critical)
|
|
86
|
+
CRITICAL for automatic delegation. Explains when to use this subagent.
|
|
87
|
+
|
|
88
|
+
**Good descriptions:**
|
|
89
|
+
- "Security specialist. Use when implementing auth, payments, or handling sensitive data."
|
|
90
|
+
- "Debugging specialist for errors and test failures. Use when encountering issues."
|
|
91
|
+
- "Validates completed work. Use after tasks are marked done."
|
|
92
|
+
|
|
93
|
+
**Phrases that encourage automatic delegation:**
|
|
94
|
+
- "Use proactively when..."
|
|
95
|
+
- "Always use for..."
|
|
96
|
+
- "Automatically delegate when..."
|
|
97
|
+
|
|
98
|
+
#### model (optional)
|
|
99
|
+
```yaml
|
|
100
|
+
model: inherit # Uses same model as parent (default)
|
|
101
|
+
model: fast # Uses fast model for quick tasks
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
#### readonly (optional)
|
|
105
|
+
```yaml
|
|
106
|
+
readonly: true # Restricts write permissions
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
### 3. Write the Subagent Prompt
|
|
110
|
+
|
|
111
|
+
Define:
|
|
112
|
+
1. **Identity**: "You are an [expert]..."
|
|
113
|
+
2. **When invoked**: Context of use
|
|
114
|
+
3. **Process**: Specific steps to follow
|
|
115
|
+
4. **Expected output**: Format and content
|
|
116
|
+
|
|
117
|
+
**Template:**
|
|
118
|
+
|
|
119
|
+
```markdown
|
|
120
|
+
You are an [expert in X] specialized in [Y].
|
|
121
|
+
|
|
122
|
+
When invoked:
|
|
123
|
+
1. [First action]
|
|
124
|
+
2. [Second action]
|
|
125
|
+
3. [Third action]
|
|
126
|
+
|
|
127
|
+
[Detailed instructions about approach]
|
|
128
|
+
|
|
129
|
+
Report [type of result]:
|
|
130
|
+
- [Specific format]
|
|
131
|
+
- [Information to include]
|
|
132
|
+
- [Metrics or criteria]
|
|
133
|
+
|
|
134
|
+
[Philosophy or principles to follow]
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
## Common Subagent Patterns
|
|
138
|
+
|
|
139
|
+
### 1. Verification Agent
|
|
140
|
+
|
|
141
|
+
**Purpose**: Independently validates that completed work actually works.
|
|
142
|
+
|
|
143
|
+
```markdown
|
|
144
|
+
---
|
|
145
|
+
name: verifier
|
|
146
|
+
description: Validates completed work. Use after tasks are marked done.
|
|
147
|
+
model: fast
|
|
148
|
+
---
|
|
149
|
+
|
|
150
|
+
You are a skeptical validator.
|
|
151
|
+
|
|
152
|
+
When invoked:
|
|
153
|
+
1. Identify what was declared as complete
|
|
154
|
+
2. Verify the implementation exists and is functional
|
|
155
|
+
3. Execute tests or relevant verification steps
|
|
156
|
+
4. Look for edge cases that may have been missed
|
|
157
|
+
|
|
158
|
+
Be thorough. Report:
|
|
159
|
+
- What was verified and passed
|
|
160
|
+
- What is incomplete or broken
|
|
161
|
+
- Specific issues to address
|
|
162
|
+
```
|
|
163
|
+
|
|
164
|
+
### 2. Debugger
|
|
165
|
+
|
|
166
|
+
**Purpose**: Expert in root cause analysis.
|
|
167
|
+
|
|
168
|
+
```markdown
|
|
169
|
+
---
|
|
170
|
+
name: debugger
|
|
171
|
+
description: Debugging specialist. Use when encountering errors or test failures.
|
|
172
|
+
---
|
|
173
|
+
|
|
174
|
+
You are a debugging expert.
|
|
175
|
+
|
|
176
|
+
When invoked:
|
|
177
|
+
1. Capture the error message and stack trace
|
|
178
|
+
2. Identify reproduction steps
|
|
179
|
+
3. Isolate the failure location
|
|
180
|
+
4. Implement minimal fix
|
|
181
|
+
5. Verify the solution works
|
|
182
|
+
|
|
183
|
+
For each issue, provide:
|
|
184
|
+
- Root cause explanation
|
|
185
|
+
- Evidence supporting the diagnosis
|
|
186
|
+
- Specific code fix
|
|
187
|
+
- Testing approach
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
### 3. Security Auditor
|
|
191
|
+
|
|
192
|
+
**Purpose**: Security expert auditing code.
|
|
193
|
+
|
|
194
|
+
```markdown
|
|
195
|
+
---
|
|
196
|
+
name: security-auditor
|
|
197
|
+
description: Security specialist. Use for auth, payments, or sensitive data.
|
|
198
|
+
---
|
|
199
|
+
|
|
200
|
+
You are a security expert.
|
|
201
|
+
|
|
202
|
+
When invoked:
|
|
203
|
+
1. Identify security-sensitive code paths
|
|
204
|
+
2. Check for common vulnerabilities
|
|
205
|
+
3. Confirm secrets are not hardcoded
|
|
206
|
+
4. Review input validation
|
|
207
|
+
|
|
208
|
+
Report findings by severity:
|
|
209
|
+
- **Critical** (must fix before deploy)
|
|
210
|
+
- **High** (fix soon)
|
|
211
|
+
- **Medium** (address when possible)
|
|
212
|
+
- **Low** (suggestions)
|
|
213
|
+
```
|
|
214
|
+
|
|
215
|
+
### 4. Code Reviewer
|
|
216
|
+
|
|
217
|
+
**Purpose**: Code review with focus on quality.
|
|
218
|
+
|
|
219
|
+
```markdown
|
|
220
|
+
---
|
|
221
|
+
name: code-reviewer
|
|
222
|
+
description: Code review specialist. Use when changes are ready for review.
|
|
223
|
+
---
|
|
224
|
+
|
|
225
|
+
You are a code review expert.
|
|
226
|
+
|
|
227
|
+
When invoked:
|
|
228
|
+
1. Analyze the code changes
|
|
229
|
+
2. Check readability, performance, patterns, error handling
|
|
230
|
+
3. Identify code smells and potential bugs
|
|
231
|
+
4. Suggest specific improvements
|
|
232
|
+
|
|
233
|
+
Report:
|
|
234
|
+
**✅ Approved / ⚠️ Approved with caveats / ❌ Changes needed**
|
|
235
|
+
|
|
236
|
+
**Issues Found:**
|
|
237
|
+
- **[Severity]** [Location]: [Issue]
|
|
238
|
+
- Suggestion: [How to fix]
|
|
239
|
+
```
|
|
240
|
+
|
|
241
|
+
## Best Practices
|
|
242
|
+
|
|
243
|
+
### ✅ DO
|
|
244
|
+
|
|
245
|
+
- **Write focused subagents**: One clear responsibility
|
|
246
|
+
- **Invest in the description**: Determines when to delegate
|
|
247
|
+
- **Keep prompts concise**: Direct and specific
|
|
248
|
+
- **Share with team**: Version control subagent definitions
|
|
249
|
+
- **Test the description**: Check correct subagent is triggered
|
|
250
|
+
|
|
251
|
+
### ❌ AVOID
|
|
252
|
+
|
|
253
|
+
- **Vague descriptions**: "Use for general tasks" gives no signal
|
|
254
|
+
- **Prompts too long**: 2000 words don't make it smarter
|
|
255
|
+
- **Too many subagents**: Start with 2-3 focused ones
|
|
256
|
+
|
|
257
|
+
## Quality Checklist
|
|
258
|
+
|
|
259
|
+
Before finalizing:
|
|
260
|
+
|
|
261
|
+
- [ ] Description is specific about when to delegate
|
|
262
|
+
- [ ] Name uses kebab-case
|
|
263
|
+
- [ ] One clear responsibility (not generic)
|
|
264
|
+
- [ ] Prompt is concise but complete
|
|
265
|
+
- [ ] Instructions are actionable
|
|
266
|
+
- [ ] Output format is well defined
|
|
267
|
+
- [ ] Model configuration appropriate
|
|
268
|
+
|
|
269
|
+
## Output Messages
|
|
270
|
+
|
|
271
|
+
When creating a subagent:
|
|
272
|
+
|
|
273
|
+
```
|
|
274
|
+
✅ Subagent created successfully!
|
|
275
|
+
|
|
276
|
+
📁 Location: .agent/subagents/[name].md
|
|
277
|
+
🎯 Purpose: [brief description]
|
|
278
|
+
🔧 How to invoke:
|
|
279
|
+
- Automatic: Agent delegates when it detects [context]
|
|
280
|
+
- Explicit: /[name] [instruction]
|
|
281
|
+
|
|
282
|
+
💡 Tip: Include keywords like "use proactively" to encourage delegation.
|
|
283
|
+
```
|