@tgoodington/intuition 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/README.md +329 -0
- package/agents/architect.md +426 -0
- package/agents/code-reviewer.md +186 -0
- package/agents/code-writer.md +140 -0
- package/agents/documentation.md +164 -0
- package/agents/research.md +179 -0
- package/agents/security-expert.md +238 -0
- package/agents/test-runner.md +168 -0
- package/agents/waldo.md +457 -0
- package/bin/intuition.js +216 -0
- package/package.json +36 -0
- package/scripts/install-skills.js +127 -0
- package/scripts/uninstall-skills.js +78 -0
- package/skills/intuition-execute/SKILL.md +181 -0
- package/skills/intuition-execute/references/architect_core.md +419 -0
- package/skills/intuition-execute/references/sub_agents.md +285 -0
- package/skills/intuition-execute/references/templates/execution_report.md +323 -0
- package/skills/intuition-execute/references/templates/parallel_execution.md +371 -0
- package/skills/intuition-execute/references/templates/task_delegation.md +327 -0
- package/skills/intuition-initialize/SKILL.md +960 -0
- package/skills/intuition-initialize/references/bugs_template.md +41 -0
- package/skills/intuition-initialize/references/decisions_template.md +92 -0
- package/skills/intuition-initialize/references/issues_template.md +76 -0
- package/skills/intuition-initialize/references/key_facts_template.md +158 -0
- package/skills/intuition-initialize/references/project_plan_template.md +151 -0
- package/skills/intuition-initialize/references/state_template.json +26 -0
- package/skills/intuition-plan/SKILL.md +109 -0
- package/skills/intuition-plan/references/sub_agents.md +98 -0
- package/skills/intuition-plan/references/templates/confidence_scoring.md +199 -0
- package/skills/intuition-plan/references/templates/plan_format.md +110 -0
- package/skills/intuition-plan/references/templates/planning_process.md +219 -0
- package/skills/intuition-plan/references/waldo_core.md +446 -0
- package/skills/intuition-start/SKILL.md +159 -0
|
@@ -0,0 +1,327 @@
|
|
|
1
|
+
# Task Delegation Format
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
When delegating work to sub-agents, use this format to ensure complete context and clear expectations.
|
|
6
|
+
|
|
7
|
+
## Complete Task Delegation Format
|
|
8
|
+
|
|
9
|
+
```markdown
|
|
10
|
+
## Task Assignment
|
|
11
|
+
|
|
12
|
+
**Agent:** [agent-name]
|
|
13
|
+
**Priority:** High/Medium/Low
|
|
14
|
+
|
|
15
|
+
**Objective:**
|
|
16
|
+
[Clear description of what to accomplish]
|
|
17
|
+
|
|
18
|
+
**Context:**
|
|
19
|
+
[Relevant information from the plan]
|
|
20
|
+
|
|
21
|
+
**Acceptance Criteria:**
|
|
22
|
+
- [ ] Criterion 1
|
|
23
|
+
- [ ] Criterion 2
|
|
24
|
+
|
|
25
|
+
**Files:** [Specific files to work with, if known]
|
|
26
|
+
|
|
27
|
+
**Constraints:**
|
|
28
|
+
- [Any limitations or requirements]
|
|
29
|
+
|
|
30
|
+
**On Failure:**
|
|
31
|
+
- Retry: [yes/no, conditions]
|
|
32
|
+
- Fallback: [alternative approach]
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
## Section Guidelines
|
|
36
|
+
|
|
37
|
+
### Agent
|
|
38
|
+
- Name of the sub-agent receiving the task
|
|
39
|
+
- Options: Code Writer, Test Runner, Documentation, Research, Code Reviewer, Security Expert
|
|
40
|
+
|
|
41
|
+
### Priority
|
|
42
|
+
- **High**: Critical path, blocks other work, must complete before proceeding
|
|
43
|
+
- **Medium**: Important but some flexibility on timing
|
|
44
|
+
- **Low**: Nice to have, can defer if needed
|
|
45
|
+
|
|
46
|
+
### Objective
|
|
47
|
+
- **What:** Clear description of what to accomplish
|
|
48
|
+
- **Why:** Why this task matters to the overall plan
|
|
49
|
+
- **Success:** What does success look like?
|
|
50
|
+
|
|
51
|
+
**Example:**
|
|
52
|
+
```
|
|
53
|
+
Implement user authentication module
|
|
54
|
+
|
|
55
|
+
This module is the foundation for access control. Users must be able to:
|
|
56
|
+
1. Register with email and password
|
|
57
|
+
2. Log in with credentials
|
|
58
|
+
3. Receive JWT token for authenticated requests
|
|
59
|
+
4. Access protected resources with token
|
|
60
|
+
|
|
61
|
+
Success = Users can complete registration/login flow and access protected endpoints
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
### Context
|
|
65
|
+
- **From the Plan:** Relevant background information
|
|
66
|
+
- **Dependencies:** What other work relates to this?
|
|
67
|
+
- **Constraints:** What limitations apply?
|
|
68
|
+
- **Background:** What should the agent know about this feature?
|
|
69
|
+
|
|
70
|
+
**Example:**
|
|
71
|
+
```
|
|
72
|
+
This authentication module supports the user management system. We're using:
|
|
73
|
+
- Node.js/Express for the backend
|
|
74
|
+
- PostgreSQL for user storage
|
|
75
|
+
- JWT for session management
|
|
76
|
+
|
|
77
|
+
The user registration API endpoint should be at POST /api/auth/register
|
|
78
|
+
Login endpoint at POST /api/auth/login
|
|
79
|
+
|
|
80
|
+
This task is Task 1 in the plan; other tasks depend on completion.
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
### Acceptance Criteria
|
|
84
|
+
- Specific, measurable outcomes
|
|
85
|
+
- Each criterion should be verifiable
|
|
86
|
+
- Include both functional and quality criteria
|
|
87
|
+
- Use checkbox format for tracking
|
|
88
|
+
|
|
89
|
+
**Example:**
|
|
90
|
+
```
|
|
91
|
+
- [ ] User model created with email and password fields
|
|
92
|
+
- [ ] Email validation implemented
|
|
93
|
+
- [ ] Password hashed using bcrypt
|
|
94
|
+
- [ ] Login endpoint accepts email/password, returns JWT
|
|
95
|
+
- [ ] Registration endpoint creates new user and returns JWT
|
|
96
|
+
- [ ] Invalid credentials rejected with appropriate error
|
|
97
|
+
- [ ] Code follows project style guide
|
|
98
|
+
- [ ] Unit tests written and passing
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
### Files
|
|
102
|
+
- Specific files to create or modify
|
|
103
|
+
- Include relative paths from project root
|
|
104
|
+
- Be explicit about new files vs. modifications
|
|
105
|
+
|
|
106
|
+
**Example:**
|
|
107
|
+
```
|
|
108
|
+
Files to create:
|
|
109
|
+
- src/auth/auth.service.ts (new)
|
|
110
|
+
- src/auth/auth.controller.ts (new)
|
|
111
|
+
- src/auth/jwt.strategy.ts (new)
|
|
112
|
+
- src/auth/auth.module.ts (new)
|
|
113
|
+
|
|
114
|
+
Files to modify:
|
|
115
|
+
- src/app.module.ts (import AuthModule)
|
|
116
|
+
- src/main.ts (if middleware configuration needed)
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
### Constraints
|
|
120
|
+
- **Limitations:** What can't be done?
|
|
121
|
+
- **Requirements:** Must-follow rules?
|
|
122
|
+
- **Standards:** Code style, patterns to follow?
|
|
123
|
+
- **Integrations:** What systems must this work with?
|
|
124
|
+
|
|
125
|
+
**Example:**
|
|
126
|
+
```
|
|
127
|
+
- Must use bcrypt for password hashing (security requirement)
|
|
128
|
+
- Must follow existing project code style and conventions
|
|
129
|
+
- Must use TypeScript, no JavaScript
|
|
130
|
+
- Must be compatible with existing Express middleware
|
|
131
|
+
- Password must be at least 8 characters
|
|
132
|
+
- Must support both email/password and OAuth in future
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
### On Failure
|
|
136
|
+
|
|
137
|
+
#### Retry Strategy
|
|
138
|
+
- **Yes**: Retry with what conditions/changes?
|
|
139
|
+
- **No**: Don't retry, escalate immediately
|
|
140
|
+
|
|
141
|
+
**When to retry:**
|
|
142
|
+
- Transient failures (network issues, temporary service outage)
|
|
143
|
+
- Ambiguous requirements (request clarification and retry)
|
|
144
|
+
- Minor issues (syntax errors, easy fixes)
|
|
145
|
+
|
|
146
|
+
**When not to retry:**
|
|
147
|
+
- Architectural issues (design doesn't fit)
|
|
148
|
+
- Scope creep (task has become unclear)
|
|
149
|
+
- Security concerns (something feels unsafe)
|
|
150
|
+
|
|
151
|
+
**Example:**
|
|
152
|
+
```
|
|
153
|
+
- Retry: Yes, if tests fail due to environment issues. Provide more detailed instructions and retry.
|
|
154
|
+
- Retry: No, if architecture doesn't support the approach. Escalate for design review.
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
#### Fallback Options
|
|
158
|
+
- **Decompose:** Break task into smaller pieces
|
|
159
|
+
- **Research:** Gather more information first
|
|
160
|
+
- **Escalate:** Ask Architect for guidance
|
|
161
|
+
- **Alternative Approach:** Different way to accomplish goal
|
|
162
|
+
|
|
163
|
+
**Example:**
|
|
164
|
+
```
|
|
165
|
+
Fallback strategy:
|
|
166
|
+
1. If JWT approach has issues: Use session-based authentication instead
|
|
167
|
+
2. If performance is inadequate: Optimize queries and caching
|
|
168
|
+
3. If complexity exceeds expectations: Break into smaller tasks
|
|
169
|
+
```
|
|
170
|
+
|
|
171
|
+
## Delegation Examples
|
|
172
|
+
|
|
173
|
+
### Example 1: Code Writer - Feature Implementation
|
|
174
|
+
|
|
175
|
+
```markdown
|
|
176
|
+
## Task Assignment
|
|
177
|
+
|
|
178
|
+
**Agent:** Code Writer
|
|
179
|
+
**Priority:** High
|
|
180
|
+
|
|
181
|
+
**Objective:**
|
|
182
|
+
Implement the authentication module providing user registration and login functionality.
|
|
183
|
+
This is the foundation for user access control and enables all subsequent user-related features.
|
|
184
|
+
|
|
185
|
+
**Context:**
|
|
186
|
+
Plan: User Authentication System
|
|
187
|
+
Task: Create authentication service with JWT support
|
|
188
|
+
|
|
189
|
+
Current project uses:
|
|
190
|
+
- Node.js/Express
|
|
191
|
+
- PostgreSQL
|
|
192
|
+
- TypeScript
|
|
193
|
+
- JWT for sessions
|
|
194
|
+
|
|
195
|
+
**Acceptance Criteria:**
|
|
196
|
+
- [ ] User model with email and password fields
|
|
197
|
+
- [ ] Email validation (valid format, not already registered)
|
|
198
|
+
- [ ] Password hashing with bcrypt (salt rounds: 10)
|
|
199
|
+
- [ ] POST /api/auth/register - creates user, returns JWT
|
|
200
|
+
- [ ] POST /api/auth/login - validates credentials, returns JWT
|
|
201
|
+
- [ ] Invalid credentials return 401 with descriptive message
|
|
202
|
+
- [ ] Password constraints enforced (min 8 chars, complexity rules)
|
|
203
|
+
- [ ] Unit tests covering happy path and error cases
|
|
204
|
+
- [ ] Code follows project TypeScript conventions
|
|
205
|
+
- [ ] Error handling is comprehensive
|
|
206
|
+
|
|
207
|
+
**Files:**
|
|
208
|
+
Create:
|
|
209
|
+
- src/auth/auth.service.ts
|
|
210
|
+
- src/auth/auth.controller.ts
|
|
211
|
+
- src/auth/jwt.strategy.ts
|
|
212
|
+
- src/auth/auth.module.ts
|
|
213
|
+
- src/auth/__tests__/auth.service.spec.ts
|
|
214
|
+
|
|
215
|
+
Modify:
|
|
216
|
+
- src/app.module.ts (import AuthModule)
|
|
217
|
+
|
|
218
|
+
**Constraints:**
|
|
219
|
+
- Must use bcrypt for password hashing
|
|
220
|
+
- Must follow NestJS patterns (already in project)
|
|
221
|
+
- Must be compatible with PostgreSQL
|
|
222
|
+
- Must work with existing Express middleware
|
|
223
|
+
|
|
224
|
+
**On Failure:**
|
|
225
|
+
- Retry: Yes, if tests fail due to database setup. Provide database initialization details and retry.
|
|
226
|
+
- Retry: No, if architecture conflicts with project design. Escalate to Architect.
|
|
227
|
+
- Fallback: If complexity exceeds timeline, use simpler session-based auth instead
|
|
228
|
+
```
|
|
229
|
+
|
|
230
|
+
### Example 2: Test Runner - Verification
|
|
231
|
+
|
|
232
|
+
```markdown
|
|
233
|
+
## Task Assignment
|
|
234
|
+
|
|
235
|
+
**Agent:** Test Runner
|
|
236
|
+
**Priority:** High
|
|
237
|
+
|
|
238
|
+
**Objective:**
|
|
239
|
+
Run complete test suite to verify authentication implementation and ensure no regressions.
|
|
240
|
+
All tests must pass before code review.
|
|
241
|
+
|
|
242
|
+
**Context:**
|
|
243
|
+
Authentication module has been implemented in latest commit.
|
|
244
|
+
Need to verify all unit tests pass and integration tests work.
|
|
245
|
+
|
|
246
|
+
**Acceptance Criteria:**
|
|
247
|
+
- [ ] All unit tests pass (auth.service.spec.ts)
|
|
248
|
+
- [ ] All integration tests pass (auth.controller.spec.ts)
|
|
249
|
+
- [ ] Test coverage reported
|
|
250
|
+
- [ ] No failing tests in full project test suite (regression check)
|
|
251
|
+
- [ ] Performance acceptable (tests complete in <30 seconds)
|
|
252
|
+
|
|
253
|
+
**Files:**
|
|
254
|
+
Test files:
|
|
255
|
+
- src/auth/__tests__/auth.service.spec.ts
|
|
256
|
+
- src/auth/__tests__/auth.controller.spec.ts
|
|
257
|
+
- Full suite: npm test
|
|
258
|
+
|
|
259
|
+
**Constraints:**
|
|
260
|
+
- Must use existing test framework (Jest)
|
|
261
|
+
- Database must be seeded for integration tests
|
|
262
|
+
- Use test database, not production
|
|
263
|
+
|
|
264
|
+
**On Failure:**
|
|
265
|
+
- Retry: Yes, with additional debugging output if tests fail intermittently
|
|
266
|
+
- Fallback: If environment issue, run tests individually to identify failure
|
|
267
|
+
```
|
|
268
|
+
|
|
269
|
+
### Example 3: Security Expert - Vulnerability Scan
|
|
270
|
+
|
|
271
|
+
```markdown
|
|
272
|
+
## Task Assignment
|
|
273
|
+
|
|
274
|
+
**Agent:** Security Expert
|
|
275
|
+
**Priority:** High
|
|
276
|
+
|
|
277
|
+
**Objective:**
|
|
278
|
+
Scan authentication module for security vulnerabilities and best practice violations.
|
|
279
|
+
MANDATORY before any code is merged. Must identify and report any issues.
|
|
280
|
+
|
|
281
|
+
**Context:**
|
|
282
|
+
Authentication module implementation complete at /src/auth/
|
|
283
|
+
Must verify no security vulnerabilities before accepting code.
|
|
284
|
+
|
|
285
|
+
**Acceptance Criteria:**
|
|
286
|
+
- [ ] No hardcoded secrets or credentials in code
|
|
287
|
+
- [ ] No sensitive data (passwords, tokens) in logs
|
|
288
|
+
- [ ] Password hashing uses secure algorithm (bcrypt verified)
|
|
289
|
+
- [ ] JWT implementation follows security best practices
|
|
290
|
+
- [ ] Input validation prevents injection attacks
|
|
291
|
+
- [ ] No exposure of internal system information in errors
|
|
292
|
+
- [ ] Database queries use parameterized statements
|
|
293
|
+
- [ ] Security headers properly configured
|
|
294
|
+
- [ ] Rate limiting suitable for auth endpoints
|
|
295
|
+
- [ ] Full report provided with findings and recommendations
|
|
296
|
+
|
|
297
|
+
**Files:**
|
|
298
|
+
Scan:
|
|
299
|
+
- src/auth/ (entire authentication module)
|
|
300
|
+
- src/config/ (configuration files)
|
|
301
|
+
- .env (environment configuration - verify no hardcoded secrets)
|
|
302
|
+
|
|
303
|
+
**Constraints:**
|
|
304
|
+
- Must follow OWASP security guidelines
|
|
305
|
+
- Must check for common auth vulnerabilities (brute force, timing attacks, etc.)
|
|
306
|
+
- Must verify JWT secret is sufficiently random
|
|
307
|
+
|
|
308
|
+
**On Failure:**
|
|
309
|
+
- Retry: Yes, after addressing identified issues. Re-run scan to verify fixes.
|
|
310
|
+
- Escalate: If critical vulnerabilities found, escalate to Architect before proceeding
|
|
311
|
+
```
|
|
312
|
+
|
|
313
|
+
## Key Principles for Effective Delegation
|
|
314
|
+
|
|
315
|
+
1. **Be Specific**: Avoid vague objectives. State exactly what should be done.
|
|
316
|
+
|
|
317
|
+
2. **Provide Context**: Agent needs to understand why this task matters.
|
|
318
|
+
|
|
319
|
+
3. **Clear Success Criteria**: Agent knows exactly when task is complete.
|
|
320
|
+
|
|
321
|
+
4. **Realistic Constraints**: State limitations so agent can plan accordingly.
|
|
322
|
+
|
|
323
|
+
5. **Failure Handling**: Agent knows what to do if problems arise.
|
|
324
|
+
|
|
325
|
+
6. **File Specificity**: Exact paths prevent confusion and errors.
|
|
326
|
+
|
|
327
|
+
7. **One Task at a Time**: Each delegation has clear, singular focus.
|