@cluesmith/codev 2.0.0-rc.2 → 2.0.0-rc.4
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/dist/agent-farm/commands/kickoff.d.ts.map +1 -1
- package/dist/agent-farm/commands/kickoff.js +86 -24
- package/dist/agent-farm/commands/kickoff.js.map +1 -1
- package/dist/commands/porch/index.d.ts +1 -1
- package/dist/commands/porch/index.d.ts.map +1 -1
- package/dist/commands/porch/index.js +194 -18
- package/dist/commands/porch/index.js.map +1 -1
- package/dist/commands/porch/state.d.ts.map +1 -1
- package/dist/commands/porch/state.js +14 -0
- package/dist/commands/porch/state.js.map +1 -1
- package/package.json +1 -1
- package/skeleton/protocols/spider/prompts/defend.md +215 -0
- package/skeleton/protocols/spider/prompts/evaluate.md +241 -0
- package/skeleton/protocols/spider/prompts/implement.md +149 -0
- package/skeleton/protocols/spider/prompts/plan.md +214 -0
- package/skeleton/protocols/spider/prompts/review.md +217 -0
- package/skeleton/protocols/spider/prompts/specify.md +167 -0
- package/skeleton/protocols/spider/protocol.json +6 -0
|
@@ -0,0 +1,217 @@
|
|
|
1
|
+
# REVIEW Phase Prompt
|
|
2
|
+
|
|
3
|
+
You are executing the **REVIEW** phase of the SPIDER protocol.
|
|
4
|
+
|
|
5
|
+
## Your Goal
|
|
6
|
+
|
|
7
|
+
Perform a comprehensive review, document lessons learned, run final consultation, and prepare for PR submission.
|
|
8
|
+
|
|
9
|
+
## CRITICAL: Final Consultation Before PR
|
|
10
|
+
|
|
11
|
+
The SPIDER protocol **requires** a final consultation with GPT-5 Codex AND Gemini Pro before submitting the PR. This ensures the complete implementation is reviewed.
|
|
12
|
+
|
|
13
|
+
## Context
|
|
14
|
+
|
|
15
|
+
- **Project ID**: {{project_id}}
|
|
16
|
+
- **Project Title**: {{title}}
|
|
17
|
+
- **Current State**: {{current_state}}
|
|
18
|
+
- **Spec File**: `codev/specs/{{project_id}}-{{title}}.md`
|
|
19
|
+
- **Plan File**: `codev/plans/{{project_id}}-{{title}}.md`
|
|
20
|
+
- **Review File**: `codev/reviews/{{project_id}}-{{title}}.md`
|
|
21
|
+
|
|
22
|
+
## Prerequisites
|
|
23
|
+
|
|
24
|
+
Before review, verify:
|
|
25
|
+
1. All implementation phases are committed
|
|
26
|
+
2. All tests are passing
|
|
27
|
+
3. Build is passing
|
|
28
|
+
4. Spec compliance verified for all phases
|
|
29
|
+
|
|
30
|
+
Verify commits: `git log --oneline | grep "[Spec {{project_id}}]"`
|
|
31
|
+
|
|
32
|
+
## Process
|
|
33
|
+
|
|
34
|
+
### 1. Comprehensive Review
|
|
35
|
+
|
|
36
|
+
Review the entire implementation:
|
|
37
|
+
|
|
38
|
+
**Code Quality**:
|
|
39
|
+
- Is the code readable and maintainable?
|
|
40
|
+
- Are there any code smells?
|
|
41
|
+
- Is error handling consistent?
|
|
42
|
+
- Are there any security concerns?
|
|
43
|
+
|
|
44
|
+
**Architecture**:
|
|
45
|
+
- Does the implementation fit well with existing code?
|
|
46
|
+
- Are there any architectural concerns?
|
|
47
|
+
- Is the design scalable if needed?
|
|
48
|
+
|
|
49
|
+
**Documentation**:
|
|
50
|
+
- Is code adequately commented where needed?
|
|
51
|
+
- Are public APIs documented?
|
|
52
|
+
- Is README updated if needed?
|
|
53
|
+
|
|
54
|
+
### 2. Spec Comparison
|
|
55
|
+
|
|
56
|
+
Compare final implementation to original specification:
|
|
57
|
+
|
|
58
|
+
- What was delivered vs what was specified?
|
|
59
|
+
- Any deviations? Document why.
|
|
60
|
+
- All success criteria met?
|
|
61
|
+
|
|
62
|
+
### 3. Create Review Document
|
|
63
|
+
|
|
64
|
+
Create `codev/reviews/{{project_id}}-{{title}}.md`:
|
|
65
|
+
|
|
66
|
+
```markdown
|
|
67
|
+
# Review: {{title}}
|
|
68
|
+
|
|
69
|
+
## Summary
|
|
70
|
+
Brief description of what was implemented.
|
|
71
|
+
|
|
72
|
+
## Spec Compliance
|
|
73
|
+
- [x] Requirement 1: Implemented as specified
|
|
74
|
+
- [x] Requirement 2: Implemented with deviation (see below)
|
|
75
|
+
- [x] Requirement 3: Implemented as specified
|
|
76
|
+
|
|
77
|
+
## Deviations from Plan
|
|
78
|
+
- **Phase X**: [What changed and why]
|
|
79
|
+
|
|
80
|
+
## Lessons Learned
|
|
81
|
+
|
|
82
|
+
### What Went Well
|
|
83
|
+
- [Positive observation 1]
|
|
84
|
+
- [Positive observation 2]
|
|
85
|
+
|
|
86
|
+
### Challenges Encountered
|
|
87
|
+
- [Challenge 1]: [How it was resolved]
|
|
88
|
+
- [Challenge 2]: [How it was resolved]
|
|
89
|
+
|
|
90
|
+
### What Would Be Done Differently
|
|
91
|
+
- [Insight 1]
|
|
92
|
+
- [Insight 2]
|
|
93
|
+
|
|
94
|
+
### Methodology Improvements
|
|
95
|
+
- [Suggested improvement to SPIDER protocol]
|
|
96
|
+
- [Suggested improvement to tooling]
|
|
97
|
+
|
|
98
|
+
## Technical Debt
|
|
99
|
+
- [Any shortcuts taken that should be addressed later]
|
|
100
|
+
|
|
101
|
+
## Follow-up Items
|
|
102
|
+
- [Any items identified for future work]
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
### 4. Update Documentation
|
|
106
|
+
|
|
107
|
+
If needed, update:
|
|
108
|
+
- README.md (new features, changed behavior)
|
|
109
|
+
- API documentation
|
|
110
|
+
- Architecture documentation (`codev/resources/arch.md`)
|
|
111
|
+
|
|
112
|
+
### 5. Final Verification
|
|
113
|
+
|
|
114
|
+
Before PR:
|
|
115
|
+
- [ ] All tests pass (use project-specific test command)
|
|
116
|
+
- [ ] Build passes (use project-specific build command)
|
|
117
|
+
- [ ] Lint passes (if configured)
|
|
118
|
+
- [ ] No uncommitted changes: `git status`
|
|
119
|
+
- [ ] Review document complete
|
|
120
|
+
|
|
121
|
+
### 6. MANDATORY: Final Consultation (PR-Ready Review)
|
|
122
|
+
|
|
123
|
+
**Before creating the PR, run final consultation:**
|
|
124
|
+
|
|
125
|
+
```bash
|
|
126
|
+
# Run consultations in parallel (REQUIRED)
|
|
127
|
+
consult --model gemini --type pr-ready spec {{project_id}} &
|
|
128
|
+
consult --model codex --type pr-ready spec {{project_id}} &
|
|
129
|
+
wait
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
- Review ALL feedback from both models
|
|
133
|
+
- Address any final issues identified
|
|
134
|
+
- This is the last chance to catch problems before PR
|
|
135
|
+
|
|
136
|
+
### 7. Create Pull Request
|
|
137
|
+
|
|
138
|
+
Prepare PR with:
|
|
139
|
+
|
|
140
|
+
**Title**: `[Spec {{project_id}}] {{title}}`
|
|
141
|
+
|
|
142
|
+
**Body**:
|
|
143
|
+
```markdown
|
|
144
|
+
## Summary
|
|
145
|
+
[Brief description of the implementation]
|
|
146
|
+
|
|
147
|
+
## Changes
|
|
148
|
+
- [Change 1]
|
|
149
|
+
- [Change 2]
|
|
150
|
+
|
|
151
|
+
## Testing
|
|
152
|
+
- All unit tests passing
|
|
153
|
+
- Integration tests added for [X]
|
|
154
|
+
- Manual testing completed for [Y]
|
|
155
|
+
|
|
156
|
+
## Spec
|
|
157
|
+
Link: codev/specs/{{project_id}}-{{title}}.md
|
|
158
|
+
|
|
159
|
+
## Review
|
|
160
|
+
Link: codev/reviews/{{project_id}}-{{title}}.md
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
## Output
|
|
164
|
+
|
|
165
|
+
- Review document at `codev/reviews/{{project_id}}-{{title}}.md`
|
|
166
|
+
- Updated documentation (if needed)
|
|
167
|
+
- Pull request ready for submission
|
|
168
|
+
|
|
169
|
+
## Signals
|
|
170
|
+
|
|
171
|
+
Emit appropriate signals based on your progress:
|
|
172
|
+
|
|
173
|
+
- After review document is complete:
|
|
174
|
+
```
|
|
175
|
+
<signal>REVIEW_COMPLETE</signal>
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
- After PR is created:
|
|
179
|
+
```
|
|
180
|
+
<signal>PR_CREATED</signal>
|
|
181
|
+
```
|
|
182
|
+
|
|
183
|
+
- When ready for Architect review:
|
|
184
|
+
```
|
|
185
|
+
<signal>PR_READY</signal>
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
## Important Notes
|
|
189
|
+
|
|
190
|
+
1. **Final consultation is MANDATORY** - Cannot skip GPT-5 + Gemini reviews before PR
|
|
191
|
+
2. **Be honest in lessons learned** - Future you will thank present you
|
|
192
|
+
3. **Document deviations** - They're not failures, they're learnings
|
|
193
|
+
4. **Update methodology** - If you found a better way, document it
|
|
194
|
+
5. **Don't skip the checklist** - It catches last-minute issues
|
|
195
|
+
6. **Clean PR description** - Makes review easier
|
|
196
|
+
|
|
197
|
+
## What NOT to Do
|
|
198
|
+
|
|
199
|
+
- Don't skip final consultation (it's BLOCKING)
|
|
200
|
+
- Don't skip lessons learned ("nothing to report")
|
|
201
|
+
- Don't merge your own PR (Architect handles integration)
|
|
202
|
+
- Don't leave uncommitted changes
|
|
203
|
+
- Don't forget to update documentation
|
|
204
|
+
- Don't rush this phase - it's valuable for learning
|
|
205
|
+
- Don't use `git add .` or `git add -A` (security risk)
|
|
206
|
+
|
|
207
|
+
## Review Prompts for Reflection
|
|
208
|
+
|
|
209
|
+
Ask yourself:
|
|
210
|
+
- What surprised me during implementation?
|
|
211
|
+
- Where did I spend the most time? Was it avoidable?
|
|
212
|
+
- What would have helped me go faster?
|
|
213
|
+
- Did the spec adequately describe what was needed?
|
|
214
|
+
- Did the plan phases make sense in hindsight?
|
|
215
|
+
- What tests caught issues? What tests were unnecessary?
|
|
216
|
+
|
|
217
|
+
Capture these reflections in the lessons learned section.
|
|
@@ -0,0 +1,167 @@
|
|
|
1
|
+
# SPECIFY Phase Prompt
|
|
2
|
+
|
|
3
|
+
You are executing the **SPECIFY** phase of the SPIDER protocol.
|
|
4
|
+
|
|
5
|
+
## Your Goal
|
|
6
|
+
|
|
7
|
+
Create a comprehensive specification document that thoroughly explores the problem space and proposed solution.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
|
|
11
|
+
- **Project ID**: {{project_id}}
|
|
12
|
+
- **Project Title**: {{title}}
|
|
13
|
+
- **Current State**: {{current_state}}
|
|
14
|
+
- **Spec File**: `codev/specs/{{project_id}}-{{title}}.md`
|
|
15
|
+
|
|
16
|
+
## CRITICAL: Multi-Agent Consultation is MANDATORY
|
|
17
|
+
|
|
18
|
+
The SPIDER protocol **requires** consultation with GPT-5 Codex AND Gemini Pro at specific checkpoints. This is BLOCKING - you cannot proceed without completing consultations.
|
|
19
|
+
|
|
20
|
+
## Process
|
|
21
|
+
|
|
22
|
+
### 1. Clarifying Questions (ALWAYS START HERE)
|
|
23
|
+
|
|
24
|
+
Before writing anything, ask clarifying questions to understand:
|
|
25
|
+
- What problem is being solved?
|
|
26
|
+
- Who are the stakeholders?
|
|
27
|
+
- What are the constraints?
|
|
28
|
+
- What's in scope vs out of scope?
|
|
29
|
+
- What does success look like?
|
|
30
|
+
|
|
31
|
+
If this is your first iteration, ask these questions now and wait for answers.
|
|
32
|
+
|
|
33
|
+
**On subsequent iterations**: If questions were already answered, acknowledge the answers and proceed to the next step.
|
|
34
|
+
|
|
35
|
+
### 2. Problem Analysis
|
|
36
|
+
|
|
37
|
+
Once you have answers, document:
|
|
38
|
+
- The problem being solved (clearly articulated)
|
|
39
|
+
- Current state vs desired state
|
|
40
|
+
- Stakeholders and their needs
|
|
41
|
+
- Assumptions and constraints
|
|
42
|
+
|
|
43
|
+
### 3. Solution Exploration
|
|
44
|
+
|
|
45
|
+
Generate multiple solution approaches. For each:
|
|
46
|
+
- Technical design overview
|
|
47
|
+
- Trade-offs (pros/cons)
|
|
48
|
+
- Complexity assessment
|
|
49
|
+
- Risk assessment
|
|
50
|
+
|
|
51
|
+
### 4. Open Questions
|
|
52
|
+
|
|
53
|
+
List uncertainties categorized as:
|
|
54
|
+
- **Critical** - blocks progress
|
|
55
|
+
- **Important** - affects design
|
|
56
|
+
- **Nice-to-know** - optimization
|
|
57
|
+
|
|
58
|
+
### 5. Success Criteria
|
|
59
|
+
|
|
60
|
+
Define measurable acceptance criteria:
|
|
61
|
+
- Functional requirements (MUST, SHOULD, COULD)
|
|
62
|
+
- Non-functional requirements (performance, security)
|
|
63
|
+
- Test scenarios
|
|
64
|
+
|
|
65
|
+
### 6. MANDATORY: First Consultation (After Draft)
|
|
66
|
+
|
|
67
|
+
After completing the initial spec draft:
|
|
68
|
+
|
|
69
|
+
```bash
|
|
70
|
+
# Run consultations in parallel (REQUIRED)
|
|
71
|
+
consult --model gemini spec {{project_id}} &
|
|
72
|
+
consult --model codex spec {{project_id}} &
|
|
73
|
+
wait
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
- Review ALL feedback from both models
|
|
77
|
+
- Update the spec with incorporated feedback
|
|
78
|
+
- Add a **Consultation Log** section documenting:
|
|
79
|
+
- Key feedback received
|
|
80
|
+
- Changes made in response
|
|
81
|
+
- Any feedback intentionally not incorporated (with reasoning)
|
|
82
|
+
|
|
83
|
+
### 7. Human Review
|
|
84
|
+
|
|
85
|
+
After consultation feedback is incorporated:
|
|
86
|
+
- Present the spec for human review
|
|
87
|
+
- Wait for approval or change requests
|
|
88
|
+
- If changes requested, make them and proceed to Step 8
|
|
89
|
+
|
|
90
|
+
### 8. MANDATORY: Second Consultation (After Human Feedback)
|
|
91
|
+
|
|
92
|
+
After incorporating human feedback:
|
|
93
|
+
|
|
94
|
+
```bash
|
|
95
|
+
# Run consultations again (REQUIRED)
|
|
96
|
+
consult --model gemini spec {{project_id}} &
|
|
97
|
+
consult --model codex spec {{project_id}} &
|
|
98
|
+
wait
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
- Update Consultation Log with new feedback
|
|
102
|
+
- Incorporate changes
|
|
103
|
+
- Prepare final spec for approval
|
|
104
|
+
|
|
105
|
+
## Output
|
|
106
|
+
|
|
107
|
+
Create or update the specification file at `codev/specs/{{project_id}}-{{title}}.md`.
|
|
108
|
+
|
|
109
|
+
**IMPORTANT**: Keep spec/plan/review filenames in sync:
|
|
110
|
+
- Spec: `codev/specs/{{project_id}}-{{title}}.md`
|
|
111
|
+
- Plan: `codev/plans/{{project_id}}-{{title}}.md`
|
|
112
|
+
- Review: `codev/reviews/{{project_id}}-{{title}}.md`
|
|
113
|
+
|
|
114
|
+
Include a **Consultation Log** section in the spec documenting all consultation feedback.
|
|
115
|
+
|
|
116
|
+
## Signals
|
|
117
|
+
|
|
118
|
+
Emit appropriate signals based on your progress:
|
|
119
|
+
|
|
120
|
+
- When waiting for clarifying question answers:
|
|
121
|
+
```
|
|
122
|
+
<signal>AWAITING_INPUT</signal>
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
- After completing the initial spec draft:
|
|
126
|
+
```
|
|
127
|
+
<signal>SPEC_DRAFTED</signal>
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
- After incorporating consultation feedback:
|
|
131
|
+
```
|
|
132
|
+
<signal>CONSULTATION_INCORPORATED</signal>
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
- After final spec is ready for human approval:
|
|
136
|
+
```
|
|
137
|
+
<signal>SPEC_READY_FOR_APPROVAL</signal>
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
## Commit Cadence
|
|
141
|
+
|
|
142
|
+
Make commits at these milestones:
|
|
143
|
+
1. `[Spec {{project_id}}] Initial specification draft`
|
|
144
|
+
2. `[Spec {{project_id}}] Specification with multi-agent review`
|
|
145
|
+
3. `[Spec {{project_id}}] Specification with user feedback`
|
|
146
|
+
4. `[Spec {{project_id}}] Final approved specification`
|
|
147
|
+
|
|
148
|
+
**CRITICAL**: Never use `git add .` or `git add -A`. Always stage specific files:
|
|
149
|
+
```bash
|
|
150
|
+
git add codev/specs/{{project_id}}-{{title}}.md
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
## Important Notes
|
|
154
|
+
|
|
155
|
+
1. **Consultation is MANDATORY** - Cannot skip GPT-5 + Gemini reviews
|
|
156
|
+
2. **Be thorough** - A good spec prevents implementation problems
|
|
157
|
+
3. **Be specific** - Vague specs lead to wrong implementations
|
|
158
|
+
4. **Include examples** - Concrete examples clarify intent
|
|
159
|
+
5. **Document consultations** - Maintain the Consultation Log section
|
|
160
|
+
|
|
161
|
+
## What NOT to Do
|
|
162
|
+
|
|
163
|
+
- Don't skip consultations (they are BLOCKING)
|
|
164
|
+
- Don't include implementation details (that's for the Plan phase)
|
|
165
|
+
- Don't estimate time (AI makes time estimates meaningless)
|
|
166
|
+
- Don't start coding (you're in Specify, not Implement)
|
|
167
|
+
- Don't use `git add .` or `git add -A` (security risk)
|
|
@@ -9,6 +9,7 @@
|
|
|
9
9
|
"name": "Specify",
|
|
10
10
|
"description": "Collaborative design exploration and specification",
|
|
11
11
|
"type": "once",
|
|
12
|
+
"prompt": "specify.md",
|
|
12
13
|
"steps": [
|
|
13
14
|
"clarifying_questions",
|
|
14
15
|
"problem_analysis",
|
|
@@ -40,6 +41,7 @@
|
|
|
40
41
|
"name": "Plan",
|
|
41
42
|
"description": "Implementation planning with phased breakdown",
|
|
42
43
|
"type": "once",
|
|
44
|
+
"prompt": "plan.md",
|
|
43
45
|
"steps": [
|
|
44
46
|
"analyze_spec",
|
|
45
47
|
"identify_phases",
|
|
@@ -68,6 +70,7 @@
|
|
|
68
70
|
"name": "Implement",
|
|
69
71
|
"description": "Code implementation following the plan",
|
|
70
72
|
"type": "per_plan_phase",
|
|
73
|
+
"prompt": "implement.md",
|
|
71
74
|
"steps": [
|
|
72
75
|
"read_phase",
|
|
73
76
|
"implement_code",
|
|
@@ -96,6 +99,7 @@
|
|
|
96
99
|
"name": "Defend",
|
|
97
100
|
"description": "Testing and verification",
|
|
98
101
|
"type": "per_plan_phase",
|
|
102
|
+
"prompt": "defend.md",
|
|
99
103
|
"steps": [
|
|
100
104
|
"write_tests",
|
|
101
105
|
"run_tests",
|
|
@@ -131,6 +135,7 @@
|
|
|
131
135
|
"name": "Evaluate",
|
|
132
136
|
"description": "Verify implementation against spec",
|
|
133
137
|
"type": "per_plan_phase",
|
|
138
|
+
"prompt": "evaluate.md",
|
|
134
139
|
"steps": [
|
|
135
140
|
"check_spec_compliance",
|
|
136
141
|
"check_success_criteria",
|
|
@@ -152,6 +157,7 @@
|
|
|
152
157
|
"name": "Review",
|
|
153
158
|
"description": "Final review and lessons learned",
|
|
154
159
|
"type": "once",
|
|
160
|
+
"prompt": "review.md",
|
|
155
161
|
"steps": [
|
|
156
162
|
"create_review_document",
|
|
157
163
|
"document_lessons",
|