@devobsessed/code-captain 0.0.6 → 0.0.9

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

@@ -13,22 +13,26 @@ Generate comprehensive feature specifications using a contract-first approach th
 ### 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
 - Analyze current codebase architecture and patterns using `codebase`
 - Load project context files (`tech-stack.md`, `code-style.md`, `objective.md`)
 - **Output:** Context summary (no files created yet)
 
 #### Step 1.2: Gap Analysis & Silent Enumeration
+
 **Internal Process (not shown to user):**
+
 - Silently list every missing fact, constraint, or requirement
 - Identify ambiguities in the initial description
 - Note potential integration points and dependencies
 - Catalog unknowns across these domains:
   - Purpose & business value
-  - Target audience & user personas  
+  - Target audience & user personas
   - Technical constraints & requirements
   - Success criteria & acceptance tests
   - Scope boundaries (in/out of scope)
@@ -39,7 +43,9 @@ Generate comprehensive feature specifications using a contract-first approach th
   - Risk tolerance & implementation approach
 
 #### Step 1.3: Structured Clarification Loop
+
 **Rules:**
+
 - Ask ONE focused question at a time
 - After each answer, re-scan codebase for new context if relevant
 - Continue until reaching 95% confidence on deliverable
@@ -49,6 +55,7 @@ Generate comprehensive feature specifications using a contract-first approach th
 - **Challenge ideas that don't make technical or business sense** - better to surface concerns early than build the wrong thing
 
 **Critical Analysis Responsibility:**
+
 - If requirements seem technically infeasible with current architecture, explain why and suggest alternatives
 - If scope seems too large for a single feature, recommend breaking it down
 - If user requests conflict with existing patterns found in codebase, point out the inconsistency
@@ -56,40 +63,45 @@ Generate comprehensive feature specifications using a contract-first approach th
 - If performance/security/scalability concerns arise, surface them proactively
 
 **Pushback Phrasing Examples:**
+
 - "I see a potential issue with [requirement] because [technical reason]. Would [alternative approach] work better?"
 - "Based on your existing codebase, [proposed approach] might conflict with [existing pattern]. How should we handle this?"
 - "The scope you're describing sounds like it might be 3-4 separate features. Should we focus on [core piece] first?"
 - "I'm concerned that [requirement] could create [specific problem]. Have you considered [alternative]?"
 
 **Question Categories (examples):**
+
 - "What specific user problem does this solve, and who experiences it?"
-- "Should this integrate with [existing system found in codebase], or remain separate?"  
+- "Should this integrate with [existing system found in codebase], or remain separate?"
 - "What does 'success' look like - how will we measure if this works?"
 - "Are there performance requirements (response time, throughput, scale)?"
 - "What UI/UX constraints exist - web only, mobile responsive, accessibility needs?"
 - "What's your risk tolerance - prefer stable/proven approaches or cutting-edge solutions?"
 
 **Transition to Contract:**
+
 - When confidence is high, present contract without declaring it "final"
 - Use phrases like "I think I have enough to create a solid contract" or "Based on our discussion, here's what I understand"
 - Always leave room for more questions if needed
 
 #### Step 1.4: Echo Check (Contract Proposal)
+
 When confident, present a contract proposal with any concerns surfaced:
 
 **Format:**
+
 ```
 ## Specification Contract
 
 **Deliverable:** [One clear sentence describing what will be built]
 
-**Must Include:** [Critical requirement that makes this valuable]  
+**Must Include:** [Critical requirement that makes this valuable]
 
 **Hardest Constraint:** [Biggest technical/business limitation to navigate]
 
 **Success Criteria:** [How we'll know it's working correctly]
 
-**Scope Boundaries:** 
+**Scope Boundaries:**
 - In Scope: [2-3 key features]
 - Out of Scope: [2-3 things we won't build]
 
@@ -104,7 +116,7 @@ When confident, present a contract proposal with any concerns surfaced:
 ---
 Options:
 - Type 'yes' to lock this contract and create the spec package
-- Type 'edit: [your changes]' to modify the contract  
+- Type 'edit: [your changes]' to modify the contract
 - Type 'risks' to explore potential implementation risks in detail
 - Type 'blueprint' to see the planned folder structure and documents
 - Ask more questions if anything needs clarification
@@ -115,37 +127,20 @@ Options:
 **Triggered only after user confirms contract with 'yes'**
 
 #### Step 2.1: Determine Current Date
-**Objective:** Get current date for folder naming and document timestamps
-
-**Date Determination Process:**
-
-1. **CREATE** directory if not exists: `.code-captain/specs/`
-2. **CREATE** temporary file: `.code-captain/specs/.date-check`
-3. **READ** file creation timestamp from filesystem
-4. **EXTRACT** date in YYYY-MM-DD format
-5. **DELETE** temporary file
-6. **STORE** date in variable for folder naming
-
-**Fallback Method:** If file system method fails:
-1. **STATE**: "I need to confirm today's date for the specification folder"
-2. **ASK**: "What is today's date? (YYYY-MM-DD format)"
-3. **WAIT** for user response
-4. **VALIDATE** format matches `^\d{4}-\d{2}-\d{2}$`
-   - year: 2024-2030
-   - month: 01-12
-   - day: 01-31
-5. **STORE** date for folder naming
-
-**Error Handling:**
-- **IF** date_invalid: USE fallback_method
-- **IF** both_methods_fail: ERROR "Unable to determine current date"
+
+Get current date by running: `npx @devobsessed/code-captain date`
+
+This returns the current date in `YYYY-MM-DD` format for folder naming:
+`.code-captain/specs/[DATE]-[feature-name]/`
 
 #### Step 2.2: Create Directory Structure
+
 **Generated folder (using determined date):**
+
 ```
 .code-captain/specs/[DATE]-{feature-name}/
 ├── spec.md                    # Main specification (from contract)
-├── spec-lite.md              # Condensed version for AI context  
+├── spec-lite.md              # Condensed version for AI context
 ├── user-stories/             # Individual user story files
 │   ├── README.md             # Overview and progress tracking
 │   ├── story-1-{name}.md     # Individual user story with focused tasks
@@ -155,12 +150,13 @@ Options:
     ├── technical-spec.md     # Architecture & implementation details
     ├── database-schema.md    # Database changes (if needed)
     ├── api-spec.md          # API documentation (if needed)
-    └── ui-wireframes.md     # UI/UX specifications (if needed)  
+    └── ui-wireframes.md     # UI/UX specifications (if needed)
 ```
 
 #### Step 2.3: Generate Core Documents
 
 **spec.md** - Built directly from the locked contract:
+
 ```markdown
 # [Feature Name] Specification
 
@@ -169,46 +165,51 @@ Options:
 > Contract Locked: ✅
 
 ## Contract Summary
+
 [Echo check content verbatim]
 
 ## Detailed Requirements
+
 [Expanded from clarification responses]
 
 ## Implementation Approach
+
 [Technical strategy based on codebase analysis]
 ```
 
 **user-stories/ folder structure** - Individual user story files for better organization:
 
 **user-stories/README.md** - Overview and progress tracking:
+
 ```markdown
 # User Stories Overview
 
-> **Specification:** [Feature Name]
-> **Created:** [DATE]
-> **Status:** Planning
+> **Specification:** [Feature Name] > **Created:** [DATE] > **Status:** Planning
 
 ## Stories Summary
 
-| Story | Title | Status | Tasks | Progress |
-|-------|-------|--------|-------|----------|
-| 1 | [Story title] | Not Started | 5 | 0/5 |
-| 2 | [Story title] | Not Started | 4 | 0/4 |
-| 3 | [Story title] | Not Started | 6 | 0/6 |
+| Story | Title         | Status      | Tasks | Progress |
+| ----- | ------------- | ----------- | ----- | -------- |
+| 1     | [Story title] | Not Started | 5     | 0/5      |
+| 2     | [Story title] | Not Started | 4     | 0/4      |
+| 3     | [Story title] | Not Started | 6     | 0/6      |
 
 **Total Progress:** 0/15 tasks (0%)
 
 ## Story Dependencies
+
 - Story 2 depends on Story 1 completion
 - Story 3 can run parallel to Story 2
 
 ## Quick Links
+
 - [Story 1: User Login](./story-1-user-login.md)
 - [Story 2: Password Reset](./story-2-password-reset.md)
 - [Story 3: Profile Management](./story-3-profile-management.md)
 ```
 
 **user-stories/story-1-{name}.md** - Individual story files (max 5-7 tasks each):
+
 ```markdown
 # Story 1: [Title from contract deliverable]
 
@@ -217,27 +218,32 @@ Options:
 > **Dependencies:** None
 
 ## User Story
+
 **As a** [user type from clarification]
 **I want to** [action from contract]  
 **So that** [value from contract must-include]
 
 ## Acceptance Criteria
+
 - [ ] Given [context], when [action], then [outcome]
 - [ ] Given [context], when [action], then [outcome]
 - [ ] Given [context], when [action], then [outcome]
 
 ## Implementation Tasks
+
 - [ ] 1.1 Write tests for [specific component]
 - [ ] 1.2 [Focused technical step]
-- [ ] 1.3 [Focused technical step] 
+- [ ] 1.3 [Focused technical step]
 - [ ] 1.4 [Focused technical step]
 - [ ] 1.5 Verify acceptance criteria are met
 - [ ] 1.6 Verify all tests pass
 
 ## Notes
+
 [Any specific technical considerations, risks, or dependencies for this story]
 
 ## Definition of Done
+
 - [ ] All tasks completed
 - [ ] All acceptance criteria met
 - [ ] Tests passing
@@ -261,6 +267,7 @@ Options:
 **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
@@ -269,6 +276,7 @@ Options:
 - 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
@@ -277,12 +285,14 @@ Options:
 - **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
 
 **Task Breakdown Strategy:**
+
 - If a story would have >7 tasks, split into multiple stories
 - Each story should deliver standalone user value
 - Tasks within a story should be cohesive and related
@@ -292,12 +302,13 @@ Options:
 #### Step 2.6: Final Package Review & User Validation
 
 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  
+├── 📝 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
@@ -334,6 +345,7 @@ Once you're satisfied with the specification, I can help you start implementatio
 ## Tool Integration
 
 **Primary tools:**
+
 - `codebase` - Scanning existing architecture and patterns
 - `search` - Finding related specifications and documentation
 - `editFiles` - Creating specification documents
@@ -341,6 +353,7 @@ Once you're satisfied with the specification, I can help you start implementatio
 - `fetch` - External research for best practices
 
 **Documentation organization:**
+
 - Specifications stored in `.code-captain/specs/[DATE]-{feature-name}/`
 - User stories organized in individual files for better management
 - Technical sub-specs created only when relevant
@@ -348,22 +361,26 @@ Once you're satisfied with the specification, I can help you start implementatio
 ## 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  
+### 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  
+- **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
@@ -385,7 +402,7 @@ First question: You mentioned "real-time multiplayer chat with blockchain integr
 
 Developer: I want messages to be permanently stored and verifiable, plus users should pay crypto to send messages to prevent spam
 
-Agent: I understand the anti-spam goal, but I'm concerned about the user experience. If users have to wait 30+ seconds for transaction confirmation before each message appears, that breaks the "real-time" chat experience. 
+Agent: I understand the anti-spam goal, but I'm concerned about the user experience. If users have to wait 30+ seconds for transaction confirmation before each message appears, that breaks the "real-time" chat experience.
 
 Would a hybrid approach work better - immediate message delivery with blockchain settlement in the background? Or are you thinking of a different model where users pre-purchase message credits?
 
@@ -427,4 +444,4 @@ 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.
+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/explain-code.prompt.md

@@ -133,34 +133,16 @@ Files are named using the format: `[DATE]-[target-name].md` where DATE is YYYY-M
 
 ## Auto-Save Behavior
 
-All explanations are automatically saved to `.code-captain/explanations/` using the format `[DATE]-[target-name].md`. The system uses the same date determination process as the research command to ensure consistent timestamps.
+All explanations are automatically saved to `.code-captain/explanations/` using the format `[DATE]-[target-name].md`.
 
-## Date Determination Process
+Get current date by running: `npx @devobsessed/code-captain date`
 
-### Primary Method: File System Timestamp
-
-1. **CREATE** directory if not exists: `.code-captain/explanations/`
-2. **CREATE** temporary file: `.code-captain/explanations/.date-check`
-3. **READ** file creation timestamp from filesystem
-4. **EXTRACT** date in YYYY-MM-DD format
-5. **DELETE** temporary file
-6. **STORE** date in variable for file naming
-
-### Fallback Method: User Confirmation
-
-If file system method fails:
-
-1. **STATE**: "I need to confirm today's date for the explanation file"
-2. **ASK**: "What is today's date? (YYYY-MM-DD format)"
-3. **WAIT** for user response
-4. **VALIDATE** format matches `^\d{4}-\d{2}-\d{2}$`
-5. **STORE** date for file naming
-
-**Example filename:** `.code-captain/explanations/2024-01-15-AuthenticationFlow.md`
+**Example filename:** `.code-captain/explanations/2025-09-27-AuthenticationFlow.md`
 
 ## Integration Points
 
 ### With Other Commands
+
 ```
 # Saved explanations can be referenced by other commands
 /research authentication
@@ -240,6 +222,7 @@ All explanations use a consistent intermediate technical level that balances acc
 ## Tool Integration
 
 **Primary tools:**
+
 - `codebase` - Analyzing code structure and dependencies
 - `search` - Finding related components and existing explanations
 - `editFiles` - Creating explanation documents
@@ -247,6 +230,7 @@ All explanations use a consistent intermediate technical level that balances acc
 - `usages` - Understanding how code is used throughout the system
 
 **Documentation organization:**
+
 - Explanations stored in `.code-captain/explanations/`
 - Date-prefixed filenames for chronological organization
 - Cross-references to related explanations and components
@@ -289,4 +273,4 @@ Track effectiveness through:
 - Performance profiling integration
 - Security vulnerability highlighting in explanations
 - Code quality suggestions as part of explanations
-- Integration with documentation generation tools
+- Integration with documentation generation tools

package/copilot/prompts/new-command.prompt.md

@@ -33,7 +33,7 @@ A meta command that creates new Code Captain commands following established patt
 **Interactive Specification Building:**
 Ask clarifying questions to build complete command specification:
 
-1. **Command Category**: "Is this a [Setup/Analysis/Implementation/Integration] command?"
+1. **Command Category**: "Is this a [Foundation/Analysis/Specification/Implementation/Quality/Meta] command?"
 2. **Execution Style**: "Should this use contract style (extensive clarification rounds like create-spec) or direct execution (immediate action like swab)?"
 3. **Usage Pattern**: "Does it take arguments, flags, or is it standalone?"
 4. **AI Coordination**: "Does it need AI prompts for complex decision-making?"
@@ -88,20 +88,35 @@ mode: agent
 - Clear step-by-step execution
 - Progress feedback and completion confirmation
 
-**Setup/Analysis Commands:**
+**Foundation Commands:**
+- Project initialization steps
+- Planning and product setup workflows
+- Configuration and environment setup
+
+**Analysis Commands:**
 - Context scanning steps
-- File generation workflows
-- Progress tracking workflows
+- Research and analysis workflows
+- Documentation review and assessment
+
+**Specification Commands:**
+- Specification creation and editing
+- Structured documentation workflows
+- Contract-based clarification processes
 
 **Implementation Commands:**
 - TDD workflows if applicable
 - Code modification steps
-- Verification procedures
+- Task execution procedures
 
-**Integration Commands:**
-- Platform-specific API interactions
-- Sync and conflict resolution
-- Error handling patterns
+**Quality Commands:**
+- Health and status reporting
+- QA-oriented checks and validations
+- Lightweight remediation workflows
+
+**Meta Commands:**
+- Command scaffolding and documentation updates
+- Code understanding and explanation
+- Process and tooling refinements
 
 ### Step 3: Documentation Integration
 
@@ -179,9 +194,12 @@ TEMPLATE STRUCTURE:
 TEMPLATE ADAPTATION RULES:
 - Contract Style commands: Include clarification phases, contract establishment, critical analysis, user agreement checkpoints
 - Direct Execution commands: Include immediate action workflows, minimal interaction, clear progress feedback
-- Setup/Analysis commands: Include context scanning, file generation, progress tracking
-- Implementation commands: Include TDD workflows, code modification, verification
-- Integration commands: Include API interactions, sync, error handling
+- Foundation commands: Include project initialization, planning workflows, configuration setup
+- Analysis commands: Include context scanning, research workflows, documentation assessment
+- Specification commands: Include specification creation, structured documentation, contract-based processes
+- Implementation commands: Include TDD workflows, code modification, task execution
+- Quality commands: Include health and status reporting, QA-oriented checks and validations, lightweight remediation workflows
+- Meta commands: Include command scaffolding and documentation updates, code understanding and explanation, process and tooling refinements
 - All commands: Include clear examples, tool coordination, progress tracking
 - CRITICAL: Be language and shell agnostic - use codebase, search instead of language-specific commands or hardcoded file extensions
 
@@ -228,29 +246,50 @@ echo "command-name" | grep -E '^[a-z][a-z0-9-]*[a-z0-9]$'
 ls .github/prompts/ | grep "^command-name.prompt.md$"
 ```
 
+### Command Categories
+
+Commands are organized into logical categories:
+
+1. **Foundation** (`initialize`, `plan-product`)
+2. **Analysis** (`research`, `create-adr`)  
+3. **Specification** (`create-spec`, `edit-spec`)
+4. **Implementation** (`execute-task`)
+5. **Quality** (`status`, `swab`)
+6. **Meta** (`new-command`, `explain-code`)
+
 ### Template Selection Logic
 
 **Command Categories and Templates:**
 
-1. **Setup/Analysis** (`initialize`, `research`, `explain-code`)
+1. **Foundation** (`initialize`, `plan-product`)
+   - Project initialization workflows
+   - Planning and setup processes
+   - Configuration and environment preparation
+
+2. **Analysis** (`research`, `create-adr`)
    - Context scanning workflows
    - Documentation generation
-   - Progress tracking emphasis
+   - Research and assessment emphasis
 
-2. **Planning/Specification** (`create-spec`, `create-adr`, `plan-product`)
+3. **Specification** (`create-spec`, `edit-spec`)
    - Interactive clarification phases
    - Structured output formats
    - Contract-based workflows
 
-3. **Implementation** (`execute-task`, `swab`)
+4. **Implementation** (`execute-task`)
    - Code modification workflows
    - TDD patterns
-   - Verification steps
+   - Task execution steps
+
+5. **Quality** (`status`, `swab`)
+   - Health and status reporting
+   - QA-oriented checks and validations
+   - Lightweight remediation workflows
 
-4. **Integration** (`sync`, `create-github-issues`)
-   - Platform API interactions
-   - Sync and conflict handling
-   - Status reporting
+6. **Meta** (`new-command`, `explain-code`)
+   - Command scaffolding and documentation updates
+   - Code understanding and explanation
+   - Process and tooling refinements
 
 
 

package/copilot/prompts/research.prompt.md

@@ -30,6 +30,7 @@ Conduct systematic research on a topic using structured phases that build upon e
 4. Plan research phases and approach
 
 **Research Structure:**
+
 - Phase 1: Define scope and questions [in_progress]
 - Phase 2: Initial discovery [pending]
 - Phase 3: Deep dive analysis [pending]
@@ -87,7 +88,7 @@ Conduct systematic research on a topic using structured phases that build upon e
 2. Create recommendations based on research
 3. Identify next steps or areas requiring further investigation
 4. Document sources and evidence for claims
-5. Determine current date using robust file system method (see Date Determination Process below)
+5. Get current date using: `npx @devobsessed/code-captain date`
 6. Create research document in `.code-captain/research/` folder using the standardized format below
 7. Present findings in appropriate format (summary document, recommendations)
 
@@ -121,40 +122,18 @@ Conduct systematic research on a topic using structured phases that build upon e
 - **Further Research:** [What questions remain]
 - **Decision Points:** [Key choices that need to be made]
 
-## Date Determination Process
-
-### Primary Method: File System Timestamp
-
-1. **CREATE** directory if not exists: `.code-captain/research/`
-2. **CREATE** temporary file: `.code-captain/research/.date-check`
-3. **READ** file creation timestamp from filesystem
-4. **EXTRACT** date in YYYY-MM-DD format
-5. **DELETE** temporary file
-6. **STORE** date in variable for folder naming
-
-### Fallback Method: User Confirmation
-
-If file system method fails:
-
-1. **STATE**: "I need to confirm today's date for the research folder"
-2. **ASK**: "What is today's date? (YYYY-MM-DD format)"
-3. **WAIT** for user response
-4. **VALIDATE** format matches `^\d{4}-\d{2}-\d{2}$`
-   - year: 2024-2030
-   - month: 01-12
-   - day: 01-31
-5. **STORE** date for folder naming
+## Date Determination
 
-### Error Handling
+Get current date by running: `npx @devobsessed/code-captain date`
 
-- **IF** date_invalid: USE fallback_method
-- **IF** both_methods_fail: ERROR "Unable to determine current date"
+This returns the current date in `YYYY-MM-DD` format for folder naming:
+`.code-captain/research/[DATE]-[topic-name]-research.md`
 
 ## Research Document Template
 
-**First, determine the current date using the process above.**
+**First, get the current date using: `npx @devobsessed/code-captain date`**
 
-Create a markdown file in `.code-captain/research/[DATE]-[topic-name]-research.md` where `[DATE]` is determined using the robust date process.
+Create a markdown file in `.code-captain/research/[DATE]-[topic-name]-research.md`.
 
 **Example:** `.code-captain/research/2024-01-15-blockchain-supply-chain-research.md`
 
@@ -253,6 +232,7 @@ Use the following structure:
 ## Tool Integration
 
 **Primary tools:**
+
 - `fetch` - Web research and external information gathering
 - `search` - Finding existing research and related documentation
 - `editFiles` - Creating research documents and reports
@@ -260,6 +240,7 @@ Use the following structure:
 - `codebase` - Understanding project context and existing knowledge
 
 **Documentation organization:**
+
 - Research documents stored in `.code-captain/research/`
 - Date-prefixed filenames for chronological organization
 - Cross-references to related project documentation
@@ -300,6 +281,7 @@ Use the following structure:
 ## Example Research Progression
 
 **Initial Phase:**
+
 ```
 - Research blockchain solutions for supply chain [in_progress]
 - Analyze implementation approaches [pending]
@@ -309,6 +291,7 @@ Use the following structure:
 ```
 
 **After Phase 2:**
+
 ```
 - Research blockchain solutions for supply chain [completed]
 - Analyze implementation approaches [in_progress]
@@ -319,6 +302,7 @@ Use the following structure:
 ```
 
 **Final:**
+
 ```
 - Research blockchain solutions for supply chain [completed]
 - Analyze implementation approaches [completed]
@@ -326,4 +310,4 @@ Use the following structure:
 - Determine date using file system method [completed]
 - Create research document in .code-captain/research/ [completed]
 - Create recommendation report [completed]
-```
+```