@devobsessed/code-captain 0.2.0 → 0.2.2

package/copilot/prompts/create-spec.prompt.md

@@ -1,21 +1,16 @@
 ---
-agent: Code Captain
+agent: agent
+description: "Generate feature specifications using a contract-first approach"
 ---
 
-# Create Spec Command
+# You are executing the Create Spec command.
 
-## Overview
+You MUST follow these instructions exactly. Do NOT describe this process — execute it.
 
-Generate comprehensive feature specifications using a contract-first approach that ensures complete alignment between developer and AI before creating any supporting files. This command eliminates presumptuous file creation by establishing a clear "contract" through structured clarification rounds.
-
-## Command Process
+Your mission: Turn the user's rough feature idea into a clear work specification using a contract-first approach. Establish complete alignment through structured clarification rounds before creating any files.
 
 ### Phase 1: Contract Establishment (No File Creation)
 
-**Mission Statement:**
-
-> Your goal is to turn my rough feature idea into a very clear work specification. You will deliver the complete spec package only after we both agree on the requirements contract. **Important: Challenge ideas that don't make technical or business sense - it's better to surface concerns early than build the wrong thing.**
-
 #### Step 1.1: Initial Context Scan
 
 - Scan existing `.code-captain/specs/` for related specifications
@@ -105,11 +100,11 @@ When confident, present a contract proposal with any concerns surfaced:
 - In Scope: [2-3 key features]
 - Out of Scope: [2-3 things we won't build]
 
-**⚠️ Technical Concerns (if any):**
+**Technical Concerns (if any):**
 - [Specific concern about feasibility, performance, or architecture]
 - [Suggested alternative or mitigation approach]
 
-**💡 Recommendations:**
+**Recommendations:**
 - [Suggestions for improving the approach based on codebase analysis]
 - [Ways to reduce risk or complexity]
 
@@ -161,8 +156,8 @@ This returns the current date in `YYYY-MM-DD` format for folder naming:
 # [Feature Name] Specification
 
 > Created: [DATE from Step 2.1 determination process]
-> Status: Planning  
-> Contract Locked: ✅
+> Status: Planning
+> Contract Locked: Yes
 
 ## Contract Summary
 
@@ -220,7 +215,7 @@ This returns the current date in `YYYY-MM-DD` format for folder naming:
 ## User Story
 
 **As a** [user type from clarification]
-**I want to** [action from contract]  
+**I want to** [action from contract]
 **So that** [value from contract must-include]
 
 ## Acceptance Criteria
@@ -264,32 +259,7 @@ This returns the current date in `YYYY-MM-DD` format for folder naming:
 
 #### Step 2.5: Create User Stories Folder Structure
 
-**user-stories/ folder** - Organized individual story files with focused task groups:
-
-**Structure Philosophy:**
-
-- Each user story gets its own file for better organization
-- Implementation tasks are kept small and focused (max 5-7 per story)
-- Complex stories are broken into multiple smaller stories
-- README.md provides overview and progress tracking
-- Acceptance criteria become verification checkpoints
-- Each story follows TDD: test → implement → verify acceptance criteria
-
-**Benefits of Folder Structure:**
-
-- **Manageability**: Each file stays focused and readable
-- **Navigation**: Easy to find and work on specific stories
-- **Parallel Work**: Multiple developers can work on different stories
-- **Version Control**: Smaller, focused diffs when stories change
-- **Progress Tracking**: Clear visibility of completion status
-- **Traceability**: Every technical task traces to user value
-
-**File Organization:**
-
-- **README.md**: Overview, progress summary, dependencies
-- **story-N-{name}.md**: Individual stories with focused tasks (5-7 tasks max)
-- **Story Naming**: Clear, descriptive names for easy identification
-- **Task Numbering**: N.1, N.2, N.3... within each story file
+Each user story gets its own file for better organization. Keep implementation tasks small and focused (max 5-7 per story). Complex stories should be broken into multiple smaller stories. Each story follows TDD: test, implement, verify acceptance criteria.
 
 **Task Breakdown Strategy:**
 
@@ -304,23 +274,22 @@ This returns the current date in `YYYY-MM-DD` format for folder naming:
 Present complete package with file references:
 
 ```
-✅ Specification package created successfully!
-
-📁 .code-captain/specs/[DATE]-feature-name/
-├── 📋 spec.md - Main specification document
-├── 📝 spec-lite.md - AI context summary
-├── 👥 user-stories/ - Individual user story files
-│   ├── 📊 README.md - Overview and progress tracking
-│   ├── 📝 story-1-{name}.md - Focused story with 5-7 tasks
-│   ├── 📝 story-2-{name}.md - Manageable task groups
-│   └── 📝 story-N-{name}.md - Easy navigation and parallel work
-└── 📂 sub-specs/
-    ├── 🔧 technical-spec.md - Technical requirements
+Specification package created successfully!
+
+.code-captain/specs/[DATE]-feature-name/
+├── spec.md - Main specification document
+├── spec-lite.md - AI context summary
+├── user-stories/ - Individual user story files
+│   ├── README.md - Overview and progress tracking
+│   ├── story-1-{name}.md - Focused story with 5-7 tasks
+│   ├── story-2-{name}.md - Manageable task groups
+│   └── story-N-{name}.md - Easy navigation and parallel work
+└── sub-specs/
+    ├── technical-spec.md - Technical requirements
     [Additional specs as created]
 
 **Stories Created:** [N] user stories with focused task groups (max 5-7 tasks each)
 **Total Tasks:** [X] implementation tasks across all stories
-**Organization:** Each story is self-contained for better workflow management
 
 Please take a moment to review the specification documents. The spec captures everything we discussed, including:
 - [Brief summary of key features/requirements]
@@ -333,12 +302,6 @@ Please read through the files and let me know:
 - Are the user stories appropriately sized (5-7 tasks each)?
 - Should any stories be split further or combined?
 
-The user-stories folder structure allows you to:
-- Work on one story at a time for focused development
-- Track progress easily with the README overview
-- Assign different stories to different team members
-- Keep task lists manageable and actionable
-
 Once you're satisfied with the specification, I can help you start implementation with the first story, or we can make any needed adjustments.
 ```
 
@@ -358,34 +321,7 @@ Once you're satisfied with the specification, I can help you start implementatio
 - User stories organized in individual files for better management
 - Technical sub-specs created only when relevant
 
-## Key Improvements Over Original
-
-### 1. Contract-First Approach
-
-- **No presumptuous file creation** - Nothing gets built until contract is locked
-- **Structured clarification** - One question at a time, building understanding
-- **Echo check validation** - Clear contract summary before proceeding
-
-### 2. Codebase-Aware Questioning
-
-- **Context scanning between questions** - Each answer triggers fresh codebase analysis
-- **Integration-focused queries** - Questions shaped by what exists in the codebase
-- **Architecture consistency** - Recommendations align with existing patterns
-
-### 3. User Control & Transparency
-
-- **Clear decision points** - User explicitly approves before file creation
-- **Risk assessment option** - Can explore implementation risks before committing
-- **Blueprint preview** - Can see planned structure before creation
-- **Edit capability** - Can modify contract before locking
-
-### 4. Efficient Clarification Process
-
-- **Gap enumeration** - Systematically identifies all unknowns
-- **95% confidence threshold** - Stops asking when ready to deliver
-- **Token efficiency** - Focused questions, no verbose explanations during clarification
-
-## Example Usage Flow
+## Example of expected interaction
 
 ```
 Developer: /create-spec "real-time multiplayer chat with blockchain integration"
@@ -414,34 +350,11 @@ Agent: [Continues with more informed questions about the hybrid architecture...]
 
 **Deliverable:** Hybrid real-time chat with immediate message delivery and background blockchain verification for anti-spam
 
-**Must Include:** Sub-second message delivery while maintaining blockchain verification for spam prevention
-
-**Hardest Constraint:** Balancing real-time UX with blockchain settlement delays and gas cost management
-
-**⚠️ Technical Concerns:**
-- Gas costs could make casual chat expensive ($1-5 per message during network congestion)
-- Background settlement failures need graceful handling and user notification
-- Wallet integration adds authentication complexity to existing simple auth system
-
-**💡 Recommendations:**
-- Consider Layer 2 solution (Polygon) to reduce gas costs to $0.01-0.10 per message
-- Implement message batching to settle multiple messages in single transaction
-- Add fallback mode for when blockchain settlement fails
-
-**Success Criteria:** Messages appear instantly, spam is prevented via crypto payments, blockchain verification happens within 5 minutes
-
-**Scope Boundaries:**
-- In Scope: Real-time chat, wallet integration, background blockchain settlement
-- Out of Scope: Advanced chat features (file sharing, voice), custom token creation
-
----
-Options: [yes/edit/risks/blueprint]
+...
 
 Developer: yes
 
-Agent: ✅ Contract locked! Creating specification package...
+Agent: Contract locked! Creating specification package...
 
 [Creates files that account for the technical concerns and hybrid architecture discussed]
 ```
-
-This approach ensures that every specification is built on solid understanding rather than assumptions, while respecting the developer's time and maintaining control over the process.

package/copilot/prompts/edit-spec.prompt.md

@@ -1,20 +1,16 @@
 ---
-agent: Code Captain
+agent: agent
+description: "Modify existing feature specifications with change tracking"
 ---
 
-# Edit Spec Command
+# You are executing the Edit Spec command.
 
-## Overview
+You MUST follow these instructions exactly. Do NOT describe this process — execute it.
 
-Modify existing feature specifications using a contract-first approach that ensures complete alignment between developer and AI before updating any supporting files. This command prevents assumptions by establishing a clear "modification contract" through structured clarification rounds.
-
-## Command Process
+Your mission: Modify an existing feature specification safely and precisely using a contract-first approach. Establish complete alignment on the modifications before updating any files.
 
 ### Phase 1: Specification Loading & Change Contract (No File Modifications)
 
-**Mission Statement:**
-> Your goal is to help me modify an existing specification safely and precisely. You will deliver the updated spec package only after we both agree on the modification contract. **Important: Challenge changes that could break existing functionality or create technical debt - it's better to surface concerns early than implement problematic modifications.**
-
 #### Step 1.1: Specification Discovery & Loading
 
 **Locate Target Specification:**
@@ -83,13 +79,6 @@ Modify existing feature specifications using a contract-first approach that ensu
 - **Scope Creep**: Are we expanding beyond the original contract boundaries?
 - **Business Value**: Do changes improve or compromise original user value?
 
-**Question Categories (examples):**
-- "This change would affect [existing user story]. Should we modify that story or create a new one?"
-- "I see this conflicts with [existing implementation]. Should we plan a migration strategy?"
-- "This modification increases complexity in [area]. Is the added value worth the technical cost?"
-- "The original spec was focused on [goal]. How does this change serve that same goal?"
-- "This would require changes to [dependent system]. Have you considered the downstream impact?"
-
 #### Step 1.4: Modification Contract Proposal
 
 When confident about changes, present a modification contract:
@@ -109,7 +98,7 @@ When confident about changes, present a modification contract:
 - **New Stories Required:** [Any additional story files to be created]
 - **Stories to Remove/Combine:** [Any story files that become obsolete]
 - **Task Groups Affected:** [Which task groups within stories need modification]
-- **Technical Components Affected:** [Code/architecture areas needing updates]  
+- **Technical Components Affected:** [Code/architecture areas needing updates]
 - **Implementation Status:** [How much existing work across stories is affected]
 
 **Migration Strategy:**
@@ -125,11 +114,11 @@ When confident about changes, present a modification contract:
 - **Removed From Scope:** [What gets removed]
 - **Still Out of Scope:** [Unchanged exclusions]
 
-**⚠️ Risks & Concerns:**
+**Risks & Concerns:**
 - [Specific technical or business risks from the changes]
 - [Potential complications or dependencies]
 
-**💡 Recommendations:**
+**Recommendations:**
 - [Suggestions for safer implementation approaches]
 - [Ways to minimize disruption to existing work]
 
@@ -217,74 +206,11 @@ Options:
 - **Combine stories** if task counts become too small
 - **Reorder stories** if dependencies changed
 
-**Story-Level Task Annotations:**
-```markdown
-# In story-1-user-auth.md:
-- [x] 1.1 Write tests for user authentication ✅ (Still valid)
-- [ ] 1.2 Implement OAuth provider ⚠️ (Needs modification)
-- [ ] 1.3 Create social login UI 🆕 (New task from scope change)
-- [~~] 1.4 Implement mobile-specific auth ❌ (Moved to new story-4-mobile-auth.md)
-
-# New story-4-mobile-auth.md created if mobile auth becomes separate feature
-```
-
-**Story Management:**
-- **Split large stories**: If modifications would create >7 tasks, create additional story files
-- **Archive obsolete stories**: Move removed stories to archived/ subfolder with timestamp
-- **Update story dependencies**: Modify README.md to reflect new story relationships
-- **Maintain story cohesion**: Ensure each story delivers standalone user value
-
 #### Step 2.5: Final Update Review & Validation
 
-Present updated package with change summary:
-```
-✅ Specification successfully updated!
-
-📁 .code-captain/specs/[DATE]-feature-name/
-├── 📋 spec.md - ⭐ Updated specification
-├── 📝 spec-lite.md - ⭐ Updated AI context summary  
-├── 👥 user-stories/ - ⭐ Updated story organization
-│   ├── 📊 README.md - ⭐ Updated progress tracking and dependencies
-│   ├── 📝 story-1-{name}.md - ⭐ Modified stories (5-7 tasks each)
-│   ├── 📝 story-2-{name}.md - 🆕 New stories or combinations
-│   ├── 📂 archived/ - 🗃️ Obsolete stories (if any)
-│   └── 📝 story-N-{name}.md - ⭐ Focused task groups
-├── 📂 sub-specs/
-│   ├── 🔧 technical-spec.md - ⭐ Updated if affected
-│   └── [other sub-specs...]
-├── 💾 backups/[timestamp]/ - Original files and stories preserved
-└── 📝 CHANGELOG.md - ⭐ Change documentation
-
-## Summary of Changes:
-- **Stories Modified:** [X] existing story files updated
-- **Stories Added:** [Y] new story files created
-- **Stories Removed/Archived:** [Z] story files no longer needed
-- **Task Groups Affected:** [N] task groups reorganized
-- **Modified Components:** [List of changed technical components]
-
-## Impact on Implementation:
-- **Stories Still Valid:** [X] out of [Y] stories remain unchanged  
-- **Stories Requiring Rework:** [N] stories need modification
-- **New Stories Added:** [N] new stories created (with focused task groups)
-- **Stories Archived:** [N] stories no longer needed
-- **Total Tasks:** [N] tasks across all stories (max 5-7 per story)
-
-Please review the updated specification:
-- Does this accurately reflect the agreed modifications?
-- Are the user stories appropriately organized (5-7 tasks per story)?
-- Should any stories be further split or combined?
-- Are story dependencies correctly updated in the README?
-- Should any additional changes be made?
-
-The updated user-stories folder structure provides:
-- **Focused development**: Work on one story at a time
-- **Better organization**: Each story file is manageable and self-contained
-- **Team collaboration**: Different stories can be assigned to different developers
-- **Clear progress tracking**: README overview shows status across all stories
-- **Flexible workflow**: Stories can be completed independently where possible
-
-The original version is safely backed up in the backups folder. If you need to rollback any changes, I can help restore from backup.
-```
+Present updated package with change summary showing files modified, stories added/removed/archived, task groups reorganized, and total task count.
+
+The original version is safely backed up in the backups folder. If the user needs to rollback any changes, offer to help restore from backup.
 
 ## Tool Integration
 
@@ -299,98 +225,3 @@ The original version is safely backed up in the backups folder. If you need to r
 - Backup system for safe modification tracking
 - Change logs for audit trail and rollback capability
 - User stories organized in individual files for better management
-
-## Key Features
-
-### 1. Safe Modification Process
-- **Backup creation** before any changes
-- **Change tracking** with detailed logs
-- **Rollback capability** to restore previous versions
-- **Impact assessment** before making changes
-
-### 2. Precise Change Control
-- **Focused clarification** about specific modifications
-- **Risk assessment** for breaking changes
-- **Migration strategy** for existing implementation
-- **Selective updates** only to affected components
-
-### 3. Implementation Continuity
-- **Task status preservation** for completed work
-- **Clear annotation** of what needs rework
-- **Priority reassessment** based on changes
-- **Timeline impact** analysis
-
-### 4. Change Documentation
-- **Detailed change logs** for audit trail
-- **Before/after comparison** capability
-- **Modification rationale** capture
-- **Rollback instructions** for safety
-
-## Example Usage Flow
-
-```
-Developer: /edit-spec "user-auth" "add biometric authentication"
-
-Agent: I found your user authentication specification from 2024-01-15. Let me load the current state...
-
-[Loads spec.md, tasks.md, and sub-specs]
-
-Current specification includes email/password auth with OAuth social login. I see there are 8 user stories, with 3 already implemented in your codebase.
-
-I have a concern about adding biometric authentication: your current implementation is web-focused, but biometric auth typically requires native mobile or desktop apps. I see no mobile components in your existing specification.
-
-First question: Are you planning to add mobile app development to this specification, or do you want to use WebAuthn for browser-based biometric authentication?
-
-Developer: WebAuthn for browser-based
-
-Agent: That makes more sense with your existing web architecture. However, WebAuthn requires HTTPS and has limited browser support. I see your current implementation supports users who may be on older browsers.
-
-Should we make biometric authentication an optional enhancement for supported browsers, or do you want to require it for all users (which might break compatibility)?
-
-Developer: Optional enhancement for supported browsers
-
-Agent: [Continues with more questions about UX, fallback behavior, etc.]
-
-## Modification Contract
-
-**Target Specification:** User Authentication System (2024-01-15)
-
-**Proposed Changes:** Add WebAuthn biometric authentication as optional enhancement
-
-**Change Type:** Addition (with graceful degradation)
-
-**Impact Assessment:**
-- **User Stories Affected:** Story 2 (Login flow) needs biometric option
-- **Technical Components Affected:** Frontend auth component, browser capability detection
-- **Implementation Status:** 3/8 stories completed, none affected by this change
-
-**Migration Strategy:**
-- Existing auth flows remain unchanged
-- Add biometric as progressive enhancement
-- No breaking changes to current implementation
-
-**Updated Success Criteria:** Users can log in with biometrics on supported browsers, fallback to existing methods
-
-**⚠️ Risks & Concerns:**
-- Browser support varies (Chrome 67+, Firefox 60+, Safari 14+)
-- Requires HTTPS in production
-- UX complexity for unsupported browsers
-
-**💡 Recommendations:**
-- Feature detection before offering biometric option
-- Clear messaging when biometric unavailable
-- Analytics to track adoption rates
-
-**Effort Estimate:** ~2-3 additional days (1 story addition, modest technical complexity)
-
----
-Options: [yes/edit/compare/risks/rollback]
-
-Developer: yes
-
-Agent: ✅ Modification contract locked! Updating specification...
-
-[Updates files, creates backups, documents changes]
-```
-
-This approach ensures that specification modifications are as careful and controlled as the original creation process, while preserving existing work and providing safety mechanisms for complex changes.

package/copilot/prompts/execute-task.prompt.md

@@ -1,20 +1,18 @@
 ---
-agent: Code Captain
+agent: agent
+description: "Execute implementation tasks using TDD from specifications"
 ---
 
-# Execute Task Command
+# You are executing the Execute Task command.
 
-## Overview
+You MUST follow these instructions exactly. Do NOT describe this process — execute it.
 
-Execute a specific task and its sub-tasks systematically following a Test-Driven Development (TDD) workflow. This command reads task specifications from `.code-captain/specs/` directories and implements features with comprehensive testing, following established code standards and best practices.
-
-**Note:** This command automatically detects and lists available task specifications for selection, or executes a specific task if context is clear.
+Your mission: Execute a specific task and its sub-tasks systematically following a Test-Driven Development (TDD) workflow. Read task specifications from `.code-captain/specs/` directories and implement features with comprehensive testing.
 
 ## CRITICAL REQUIREMENT: 100% Test Pass Rate
 
-**⚠️ ZERO TOLERANCE FOR FAILING TESTS ⚠️**
+**ZERO TOLERANCE FOR FAILING TESTS**
 
-This command enforces strict test validation:
 - **NO story can be marked "COMPLETED" with ANY failing tests**
 - **100% test pass rate is MANDATORY before completion**
 - **"Edge case" or "minor" test failures are NOT acceptable**
@@ -22,8 +20,6 @@ This command enforces strict test validation:
 
 If tests fail, the story remains "IN PROGRESS" until all failures are resolved.
 
-## Command Process
-
 ### Step 1: Task Discovery & Selection
 
 **Scan for available specifications:**
@@ -110,7 +106,7 @@ For each implementation task within the story:
 4. **Validate all acceptance criteria are met for the user story**
 5. **Confirm story delivers the specified user value**
 
-**⚠️ STORY CANNOT BE MARKED COMPLETE WITH ANY FAILING TESTS ⚠️**
+**STORY CANNOT BE MARKED COMPLETE WITH ANY FAILING TESTS**
 
 ### Step 5: Story Completion & Status Updates
 
@@ -131,14 +127,3 @@ Update story file status and progress tracking files with completion details, en
 - File-based progress tracking in `.code-captain/current-task-progress.md`
 - Story status updates in specification files
 - Test execution results documentation
-
-## Quality Standards
-
-**Test-Driven Development:**
-- Tests written before implementation
-- **100% test pass rate MANDATORY before task completion**
-- **ZERO TOLERANCE for failing tests - no story completion with any failures**
-- Comprehensive coverage including edge cases
-- Regression testing for existing functionality
-
-This command ensures systematic, test-driven implementation with proper documentation and progress tracking using file-based systems compatible with GitHub Copilot.