@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.
Files changed (33) hide show
  1. package/README.md +329 -0
  2. package/agents/architect.md +426 -0
  3. package/agents/code-reviewer.md +186 -0
  4. package/agents/code-writer.md +140 -0
  5. package/agents/documentation.md +164 -0
  6. package/agents/research.md +179 -0
  7. package/agents/security-expert.md +238 -0
  8. package/agents/test-runner.md +168 -0
  9. package/agents/waldo.md +457 -0
  10. package/bin/intuition.js +216 -0
  11. package/package.json +36 -0
  12. package/scripts/install-skills.js +127 -0
  13. package/scripts/uninstall-skills.js +78 -0
  14. package/skills/intuition-execute/SKILL.md +181 -0
  15. package/skills/intuition-execute/references/architect_core.md +419 -0
  16. package/skills/intuition-execute/references/sub_agents.md +285 -0
  17. package/skills/intuition-execute/references/templates/execution_report.md +323 -0
  18. package/skills/intuition-execute/references/templates/parallel_execution.md +371 -0
  19. package/skills/intuition-execute/references/templates/task_delegation.md +327 -0
  20. package/skills/intuition-initialize/SKILL.md +960 -0
  21. package/skills/intuition-initialize/references/bugs_template.md +41 -0
  22. package/skills/intuition-initialize/references/decisions_template.md +92 -0
  23. package/skills/intuition-initialize/references/issues_template.md +76 -0
  24. package/skills/intuition-initialize/references/key_facts_template.md +158 -0
  25. package/skills/intuition-initialize/references/project_plan_template.md +151 -0
  26. package/skills/intuition-initialize/references/state_template.json +26 -0
  27. package/skills/intuition-plan/SKILL.md +109 -0
  28. package/skills/intuition-plan/references/sub_agents.md +98 -0
  29. package/skills/intuition-plan/references/templates/confidence_scoring.md +199 -0
  30. package/skills/intuition-plan/references/templates/plan_format.md +110 -0
  31. package/skills/intuition-plan/references/templates/planning_process.md +219 -0
  32. package/skills/intuition-plan/references/waldo_core.md +446 -0
  33. 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.