@cluesmith/codev 2.0.0-rc.1 → 2.0.0-rc.10

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.

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

@@ -0,0 +1,174 @@
+# SPECIFY Phase Prompt
+
+You are executing the **SPECIFY** phase of the SPIDER protocol.
+
+## Your Goal
+
+Create a comprehensive specification document that thoroughly explores the problem space and proposed solution.
+
+## Context
+
+- **Project ID**: {{project_id}}
+- **Project Title**: {{title}}
+- **Current State**: {{current_state}}
+- **Spec File**: `codev/specs/{{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.
+
+## Process
+
+### 1. Clarifying Questions (ALWAYS START HERE)
+
+Before writing anything, ask clarifying questions to understand:
+- What problem is being solved?
+- Who are the stakeholders?
+- What are the constraints?
+- What's in scope vs out of scope?
+- What does success look like?
+
+If this is your first iteration, ask these questions now and wait for answers.
+
+**On subsequent iterations**: If questions were already answered, acknowledge the answers and proceed to the next step.
+
+### 2. Problem Analysis
+
+Once you have answers, document:
+- The problem being solved (clearly articulated)
+- Current state vs desired state
+- Stakeholders and their needs
+- Assumptions and constraints
+
+### 3. Solution Exploration
+
+Generate multiple solution approaches. For each:
+- Technical design overview
+- Trade-offs (pros/cons)
+- Complexity assessment
+- Risk assessment
+
+### 4. Open Questions
+
+List uncertainties categorized as:
+- **Critical** - blocks progress
+- **Important** - affects design
+- **Nice-to-know** - optimization
+
+### 5. Success Criteria
+
+Define measurable acceptance criteria:
+- Functional requirements (MUST, SHOULD, COULD)
+- Non-functional requirements (performance, security)
+- Test scenarios
+
+### 6. MANDATORY: First Consultation (After Draft)
+
+After completing the initial spec draft:
+
+```bash
+# Run consultations in parallel (REQUIRED)
+consult --model gemini spec {{project_id}} &
+consult --model codex spec {{project_id}} &
+wait
+```
+
+- Review ALL feedback from both models
+- Update the spec with incorporated feedback
+- Add a **Consultation Log** section documenting:
+  - Key feedback received
+  - Changes made in response
+  - Any feedback intentionally not incorporated (with reasoning)
+
+### 7. Human Review
+
+After consultation feedback is incorporated:
+- Present the spec for human review
+- Wait for approval or change requests
+- If changes requested, make them and proceed to Step 8
+
+### 8. MANDATORY: Second Consultation (After Human Feedback)
+
+After incorporating human feedback:
+
+```bash
+# Run consultations again (REQUIRED)
+consult --model gemini spec {{project_id}} &
+consult --model codex spec {{project_id}} &
+wait
+```
+
+- Update Consultation Log with new feedback
+- Incorporate changes
+- Prepare final spec for approval
+
+## Output
+
+Create or update the specification file at `codev/specs/{{project_id}}-{{title}}.md`.
+
+**IMPORTANT**: Keep spec/plan/review filenames in sync:
+- Spec: `codev/specs/{{project_id}}-{{title}}.md`
+- Plan: `codev/plans/{{project_id}}-{{title}}.md`
+- Review: `codev/reviews/{{project_id}}-{{title}}.md`
+
+Include a **Consultation Log** section in the spec documenting all consultation feedback.
+
+## Signals
+
+Emit appropriate signals based on your progress:
+
+- When waiting for clarifying question answers, **include your questions in the signal**:
+  ```
+  <signal type=AWAITING_INPUT>
+  Please answer these questions:
+  1. What should the primary use case be - internal tooling or customer-facing?
+  2. What are the key constraints we should consider?
+  3. Who are the main stakeholders?
+  </signal>
+  ```
+
+  The content inside the signal tag is displayed prominently to the user.
+
+- After completing the initial spec draft:
+  ```
+  <signal>SPEC_DRAFTED</signal>
+  ```
+
+- After incorporating consultation feedback:
+  ```
+  <signal>CONSULTATION_INCORPORATED</signal>
+  ```
+
+- After final spec is ready for human approval:
+  ```
+  <signal>SPEC_READY_FOR_APPROVAL</signal>
+  ```
+
+## Commit Cadence
+
+Make commits at these milestones:
+1. `[Spec {{project_id}}] Initial specification draft`
+2. `[Spec {{project_id}}] Specification with multi-agent review`
+3. `[Spec {{project_id}}] Specification with user feedback`
+4. `[Spec {{project_id}}] Final approved specification`
+
+**CRITICAL**: Never use `git add .` or `git add -A`. Always stage specific files:
+```bash
+git add codev/specs/{{project_id}}-{{title}}.md
+```
+
+## Important Notes
+
+1. **Consultation is MANDATORY** - Cannot skip GPT-5 + Gemini reviews
+2. **Be thorough** - A good spec prevents implementation problems
+3. **Be specific** - Vague specs lead to wrong implementations
+4. **Include examples** - Concrete examples clarify intent
+5. **Document consultations** - Maintain the Consultation Log section
+
+## What NOT to Do
+
+- Don't skip consultations (they are BLOCKING)
+- Don't include implementation details (that's for the Plan phase)
+- Don't estimate time (AI makes time estimates meaningless)
+- Don't start coding (you're in Specify, not Implement)
+- Don't use `git add .` or `git add -A` (security risk)