@cluesmith/codev 2.0.0-rc.3 → 2.0.0-rc.4

package/skeleton/protocols/spider/prompts/implement.md

@@ -0,0 +1,149 @@
+# IMPLEMENT Phase Prompt
+
+You are executing the **IMPLEMENT** phase of the SPIDER protocol.
+
+## Your Goal
+
+Write clean, well-structured code that implements the current plan phase.
+
+## Context
+
+- **Project ID**: {{project_id}}
+- **Project Title**: {{title}}
+- **Current State**: {{current_state}}
+- **Plan Phase**: {{plan_phase}} (if applicable)
+- **Spec File**: `codev/specs/{{project_id}}-{{title}}.md`
+- **Plan File**: `codev/plans/{{project_id}}-{{title}}.md`
+
+## Consultation Context
+
+**Implementation does NOT require consultation checkpoints** - that happens after Defend.
+
+However, you should be aware:
+- Spec and Plan have already been reviewed by GPT-5 Codex and Gemini Pro
+- After you complete Implement + Defend, your work will be reviewed
+- Implementation must strictly follow the approved spec and plan
+
+## Prerequisites
+
+Before implementing, verify:
+1. Previous phase (if any) is committed to git
+2. You've read the plan phase you're implementing
+3. You understand the success criteria for this phase
+4. Dependencies from earlier phases are available
+
+## Process
+
+### 1. Review the Plan Phase
+
+Read the current phase in the plan:
+- What is the objective?
+- What files need to be created/modified?
+- What are the success criteria?
+- What dependencies exist?
+
+### 2. Set Up
+
+- Verify you're on the correct branch
+- Check that previous phase is committed: `git log --oneline -5`
+- Ensure build passes before starting: `npm run build` (or equivalent)
+
+### 3. Implement
+
+Write the code following these principles:
+
+**Code Quality Standards**:
+- Self-documenting code (clear names, obvious structure)
+- No commented-out code
+- No debug prints in final code
+- Explicit error handling
+- Follow project style guide
+
+**Implementation Approach**:
+- Work on one file at a time
+- Make small, incremental changes
+- Test as you go (manual verification is fine here)
+- Document complex logic with comments
+
+### 4. Self-Review
+
+Before signaling completion:
+- Read through all changes
+- Check for obvious bugs
+- Verify code matches the spec requirements
+- Ensure no accidental debug code
+
+### 5. Build Verification
+
+Run build checks using **project-specific commands**:
+
+```bash
+# Check package.json scripts or Makefile for actual commands
+# Common patterns:
+npm run build      # Node.js/TypeScript projects
+npm run typecheck  # TypeScript type checking
+npm run lint       # Linting (ESLint, etc.)
+cargo build        # Rust projects
+go build ./...     # Go projects
+make build         # Projects using Makefiles
+```
+
+**Important**: Don't assume `npm run build` exists. Check `package.json` or equivalent first.
+
+Fix any errors before proceeding.
+
+## Output
+
+- Modified/created source files as specified in the plan phase
+- All build checks passing
+- Code ready for the Defend (testing) phase
+
+## Signals
+
+Emit appropriate signals based on your progress:
+
+- After implementation is complete and builds pass:
+  ```
+  <signal>PHASE_IMPLEMENTED</signal>
+  ```
+
+- If you encounter a blocker:
+  ```
+  <signal>BLOCKED:reason goes here</signal>
+  ```
+
+- If you need spec/plan clarification:
+  ```
+  <signal>NEEDS_CLARIFICATION:specific question</signal>
+  ```
+
+## Important Notes
+
+1. **Follow the plan** - Implement what's specified, not more
+2. **Don't over-engineer** - Simplest solution that works
+3. **Don't skip error handling** - But don't go overboard either
+4. **Keep changes focused** - Only touch files in this phase
+5. **Build must pass** - Don't proceed if build fails
+
+## What NOT to Do
+
+- Don't write tests yet (that's Defend phase)
+- Don't modify files outside this phase's scope
+- Don't add features not in the spec
+- Don't leave TODO comments for later (fix now or note as blocker)
+- Don't commit yet (that happens after Defend + Evaluate)
+- Don't use `git add .` or `git add -A` when you do commit (security risk)
+
+## Handling Problems
+
+**If the plan is unclear**:
+Signal `NEEDS_CLARIFICATION` with your specific question.
+
+**If you discover the spec is wrong**:
+Signal `BLOCKED` and explain the issue. The Architect may need to update the spec.
+
+**If a dependency is missing**:
+Signal `BLOCKED` with details about what's missing.
+
+**If build fails and you can't fix it**:
+Signal `BLOCKED` with the error message.

package/skeleton/protocols/spider/prompts/plan.md

@@ -0,0 +1,214 @@
+# PLAN Phase Prompt
+
+You are executing the **PLAN** phase of the SPIDER protocol.
+
+## Your Goal
+
+Transform the approved specification into an executable implementation plan with clear phases.
+
+## Context
+
+- **Project ID**: {{project_id}}
+- **Project Title**: {{title}}
+- **Current State**: {{current_state}}
+- **Spec File**: `codev/specs/{{project_id}}-{{title}}.md`
+- **Plan File**: `codev/plans/{{project_id}}-{{title}}.md`
+
+## CRITICAL: Multi-Agent Consultation is MANDATORY
+
+The SPIDER protocol **requires** consultation with GPT-5 Codex AND Gemini Pro at specific checkpoints. This is BLOCKING - you cannot proceed without completing consultations.
+
+## Prerequisites
+
+Before planning, verify:
+1. The specification exists and has been approved
+2. You've read and understood the entire spec
+3. Success criteria are clear and measurable
+
+## Process
+
+### 1. Analyze the Specification
+
+Read the spec thoroughly. Identify:
+- All functional requirements
+- Non-functional requirements
+- Dependencies and constraints
+- Success criteria to validate against
+
+### 2. Identify Implementation Phases
+
+Break the work into logical phases. Each phase should be:
+- **Self-contained** - A complete unit of functionality
+- **Independently testable** - Can be verified on its own
+- **Valuable** - Delivers observable progress
+- **Committable** - Can be a single atomic commit
+
+Good phase examples:
+- "Database Schema" - Creates all tables/migrations
+- "Core API Endpoints" - Implements main REST routes
+- "Authentication Flow" - Handles login/logout/session
+
+Bad phase examples:
+- "Setup" - Too vague
+- "Part 1" - Not descriptive
+- "Everything" - Not broken down
+
+### 3. Define Each Phase
+
+For each phase, document:
+- **Objective** - Single clear goal
+- **Files to modify/create** - Specific paths
+- **Dependencies** - Which phases must complete first
+- **Success criteria** - How to know it's done
+- **Test approach** - What tests will verify it
+
+### 4. Order Phases by Dependencies
+
+Arrange phases so dependencies are satisfied:
+```
+Phase 1: Database Schema (no dependencies)
+Phase 2: Data Models (depends on Phase 1)
+Phase 3: API Endpoints (depends on Phase 2)
+Phase 4: Frontend Integration (depends on Phase 3)
+```
+
+### 5. MANDATORY: First Consultation (After Draft)
+
+After completing the initial plan draft:
+
+```bash
+# Run consultations in parallel (REQUIRED)
+consult --model gemini plan {{project_id}} &
+consult --model codex plan {{project_id}} &
+wait
+```
+
+- Review ALL feedback from both models
+- Update the plan with incorporated feedback
+- Add a **Consultation Log** section documenting:
+  - Key feedback received
+  - Changes made in response
+  - Any feedback intentionally not incorporated (with reasoning)
+
+### 6. Human Review
+
+After consultation feedback is incorporated:
+- Present the plan for human review
+- Wait for approval or change requests
+- If changes requested, make them and proceed to Step 7
+
+### 7. MANDATORY: Second Consultation (After Human Feedback)
+
+After incorporating human feedback:
+
+```bash
+# Run consultations again (REQUIRED)
+consult --model gemini plan {{project_id}} &
+consult --model codex plan {{project_id}} &
+wait
+```
+
+- Update Consultation Log with new feedback
+- Incorporate changes
+- Prepare final plan for approval
+
+## Output
+
+Create the plan file at `codev/plans/{{project_id}}-{{title}}.md`.
+
+Use the plan template from `codev/protocols/spider/templates/plan.md` if available.
+
+### Plan Structure
+
+```markdown
+# Implementation Plan: {{title}}
+
+## Overview
+Brief summary of what will be implemented.
+
+## Phases
+
+### Phase 1: [Name]
+- **Objective**: [Single clear goal]
+- **Files**: [List of files to create/modify]
+- **Dependencies**: None
+- **Success Criteria**: [How to verify completion]
+- **Tests**: [What tests will be written]
+
+### Phase 2: [Name]
+- **Objective**: [Single clear goal]
+- **Files**: [List of files]
+- **Dependencies**: Phase 1
+- **Success Criteria**: [Verification method]
+- **Tests**: [Test approach]
+
+[Continue for all phases...]
+
+## Risk Assessment
+- [Risk 1]: [Mitigation]
+- [Risk 2]: [Mitigation]
+
+## Consultation Log
+
+### First Consultation (After Draft)
+- **Gemini Feedback**: [Summary]
+- **Codex Feedback**: [Summary]
+- **Changes Made**: [List]
+- **Not Incorporated**: [List with reasons]
+
+### Second Consultation (After Human Feedback)
+- **Gemini Feedback**: [Summary]
+- **Codex Feedback**: [Summary]
+- **Changes Made**: [List]
+```
+
+## Signals
+
+Emit appropriate signals based on your progress:
+
+- After completing the plan draft:
+  ```
+  <signal>PLAN_DRAFTED</signal>
+  ```
+
+- After incorporating consultation feedback:
+  ```
+  <signal>CONSULTATION_INCORPORATED</signal>
+  ```
+
+- After final plan is ready for human approval:
+  ```
+  <signal>PLAN_READY_FOR_APPROVAL</signal>
+  ```
+
+## Commit Cadence
+
+Make commits at these milestones:
+1. `[Spec {{project_id}}] Initial implementation plan`
+2. `[Spec {{project_id}}] Plan with multi-agent review`
+3. `[Spec {{project_id}}] Plan with user feedback`
+4. `[Spec {{project_id}}] Final approved plan`
+
+**CRITICAL**: Never use `git add .` or `git add -A`. Always stage specific files:
+```bash
+git add codev/plans/{{project_id}}-{{title}}.md
+```
+
+## Important Notes
+
+1. **Consultation is MANDATORY** - Cannot skip GPT-5 + Gemini reviews
+2. **No time estimates** - Don't include hours/days/weeks
+3. **Be specific about files** - Exact paths, not "the config file"
+4. **Keep phases small** - 1-3 files per phase is ideal
+5. **Document dependencies clearly** - Prevents blocked work
+6. **Document consultations** - Maintain the Consultation Log section
+
+## What NOT to Do
+
+- Don't skip consultations (they are BLOCKING)
+- Don't write code (that's for Implement phase)
+- Don't estimate time (meaningless in AI development)
+- Don't create phases that can't be independently tested
+- Don't skip dependency analysis
+- Don't make phases too large (if >5 files, split it)
+- Don't use `git add .` or `git add -A` (security risk)

package/skeleton/protocols/spider/prompts/review.md

@@ -0,0 +1,217 @@
+# REVIEW Phase Prompt
+
+You are executing the **REVIEW** phase of the SPIDER protocol.
+
+## Your Goal
+
+Perform a comprehensive review, document lessons learned, run final consultation, and prepare for PR submission.
+
+## CRITICAL: Final Consultation Before PR
+
+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.
+
+## Context
+
+- **Project ID**: {{project_id}}
+- **Project Title**: {{title}}
+- **Current State**: {{current_state}}
+- **Spec File**: `codev/specs/{{project_id}}-{{title}}.md`
+- **Plan File**: `codev/plans/{{project_id}}-{{title}}.md`
+- **Review File**: `codev/reviews/{{project_id}}-{{title}}.md`
+
+## Prerequisites
+
+Before review, verify:
+1. All implementation phases are committed
+2. All tests are passing
+3. Build is passing
+4. Spec compliance verified for all phases
+
+Verify commits: `git log --oneline | grep "[Spec {{project_id}}]"`
+
+## Process
+
+### 1. Comprehensive Review
+
+Review the entire implementation:
+
+**Code Quality**:
+- Is the code readable and maintainable?
+- Are there any code smells?
+- Is error handling consistent?
+- Are there any security concerns?
+
+**Architecture**:
+- Does the implementation fit well with existing code?
+- Are there any architectural concerns?
+- Is the design scalable if needed?
+
+**Documentation**:
+- Is code adequately commented where needed?
+- Are public APIs documented?
+- Is README updated if needed?
+
+### 2. Spec Comparison
+
+Compare final implementation to original specification:
+
+- What was delivered vs what was specified?
+- Any deviations? Document why.
+- All success criteria met?
+
+### 3. Create Review Document
+
+Create `codev/reviews/{{project_id}}-{{title}}.md`:
+
+```markdown
+# Review: {{title}}
+
+## Summary
+Brief description of what was implemented.
+
+## Spec Compliance
+- [x] Requirement 1: Implemented as specified
+- [x] Requirement 2: Implemented with deviation (see below)
+- [x] Requirement 3: Implemented as specified
+
+## Deviations from Plan
+- **Phase X**: [What changed and why]
+
+## Lessons Learned
+
+### What Went Well
+- [Positive observation 1]
+- [Positive observation 2]
+
+### Challenges Encountered
+- [Challenge 1]: [How it was resolved]
+- [Challenge 2]: [How it was resolved]
+
+### What Would Be Done Differently
+- [Insight 1]
+- [Insight 2]
+
+### Methodology Improvements
+- [Suggested improvement to SPIDER protocol]
+- [Suggested improvement to tooling]
+
+## Technical Debt
+- [Any shortcuts taken that should be addressed later]
+
+## Follow-up Items
+- [Any items identified for future work]
+```
+
+### 4. Update Documentation
+
+If needed, update:
+- README.md (new features, changed behavior)
+- API documentation
+- Architecture documentation (`codev/resources/arch.md`)
+
+### 5. Final Verification
+
+Before PR:
+- [ ] All tests pass (use project-specific test command)
+- [ ] Build passes (use project-specific build command)
+- [ ] Lint passes (if configured)
+- [ ] No uncommitted changes: `git status`
+- [ ] Review document complete
+
+### 6. MANDATORY: Final Consultation (PR-Ready Review)
+
+**Before creating the PR, run final consultation:**
+
+```bash
+# Run consultations in parallel (REQUIRED)
+consult --model gemini --type pr-ready spec {{project_id}} &
+consult --model codex --type pr-ready spec {{project_id}} &
+wait
+```
+
+- Review ALL feedback from both models
+- Address any final issues identified
+- This is the last chance to catch problems before PR
+
+### 7. Create Pull Request
+
+Prepare PR with:
+
+**Title**: `[Spec {{project_id}}] {{title}}`
+
+**Body**:
+```markdown
+## Summary
+[Brief description of the implementation]
+
+## Changes
+- [Change 1]
+- [Change 2]
+
+## Testing
+- All unit tests passing
+- Integration tests added for [X]
+- Manual testing completed for [Y]
+
+## Spec
+Link: codev/specs/{{project_id}}-{{title}}.md
+
+## Review
+Link: codev/reviews/{{project_id}}-{{title}}.md
+```
+
+## Output
+
+- Review document at `codev/reviews/{{project_id}}-{{title}}.md`
+- Updated documentation (if needed)
+- Pull request ready for submission
+
+## Signals
+
+Emit appropriate signals based on your progress:
+
+- After review document is complete:
+  ```
+  <signal>REVIEW_COMPLETE</signal>
+  ```
+
+- After PR is created:
+  ```
+  <signal>PR_CREATED</signal>
+  ```
+
+- When ready for Architect review:
+  ```
+  <signal>PR_READY</signal>
+  ```
+
+## Important Notes
+
+1. **Final consultation is MANDATORY** - Cannot skip GPT-5 + Gemini reviews before PR
+2. **Be honest in lessons learned** - Future you will thank present you
+3. **Document deviations** - They're not failures, they're learnings
+4. **Update methodology** - If you found a better way, document it
+5. **Don't skip the checklist** - It catches last-minute issues
+6. **Clean PR description** - Makes review easier
+
+## What NOT to Do
+
+- Don't skip final consultation (it's BLOCKING)
+- Don't skip lessons learned ("nothing to report")
+- Don't merge your own PR (Architect handles integration)
+- Don't leave uncommitted changes
+- Don't forget to update documentation
+- Don't rush this phase - it's valuable for learning
+- Don't use `git add .` or `git add -A` (security risk)
+
+## Review Prompts for Reflection
+
+Ask yourself:
+- What surprised me during implementation?
+- Where did I spend the most time? Was it avoidable?
+- What would have helped me go faster?
+- Did the spec adequately describe what was needed?
+- Did the plan phases make sense in hindsight?
+- What tests caught issues? What tests were unnecessary?
+
+Capture these reflections in the lessons learned section.