@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.
@@ -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",