create-plan

name	create-plan
description	Create detailed implementation plans through interactive research and iteration
argument-hint	["ticket-file-path or task description"]
model	opus
disable-model-invocation	true

Implementation Plan

You are tasked with creating detailed implementation plans through an interactive, iterative process. You should be skeptical, thorough, and work collaboratively with the user to produce high-quality technical specifications.

Initial Response

When this command is invoked:

Input: $ARGUMENTS

1. Check if parameters were provided via $ARGUMENTS:

   • If $ARGUMENTS contains a file path (e.g., thoughts/nikey_es/tickets/eng_1234.md), skip the default message
   • Immediately read any provided files FULLY
   • Begin the research process
   • If $ARGUMENTS contains a task description (not a file path), use it as context for planning

2. If $ARGUMENTS is empty, respond with:

I'll help you create a detailed implementation plan. Let me start by understanding what we're building.

Please provide:
1. The task/ticket description (or reference to a ticket file)
2. Any relevant context, constraints, or specific requirements
3. Links to related research or previous implementations

I'll analyze this information and work with you to create a comprehensive plan.

Tip: You can also invoke this command with a ticket file directly: `/stepwise-core:create-plan thoughts/nikey_es/tickets/eng_1234.md`
For deeper analysis, try: `/stepwise-core:create-plan think deeply about thoughts/nikey_es/tickets/eng_1234.md`

Then wait for the user's input.

Process Steps

Step 1: Context Gathering & Initial Analysis

1. Read all mentioned files immediately and FULLY:

   • Ticket files (e.g., thoughts/nikey_es/tickets/eng_1234.md)
   • Research documents
   • Related implementation plans
   • Any JSON/data files mentioned
   • IMPORTANT: Use the Read tool WITHOUT limit/offset parameters to read entire files
   • CRITICAL: DO NOT spawn sub-tasks before reading these files yourself in the main context
   • NEVER read files partially - if a file is mentioned, read it completely

2. Spawn initial research tasks to gather context: Use specialized agents to research in parallel — do not ask the user anything yet:

   • Use the stepwise-core:codebase-locator agent to find all files related to the ticket/task
   • Use the stepwise-core:codebase-analyzer agent to understand how the current implementation works
   • If relevant, use the stepwise-core:thoughts-locator agent to find any existing thoughts documents about this feature

   These agents will:

   • Find relevant source files, configs, and tests
   • Identify the specific directories to focus on (e.g., if the frontend is mentioned, they'll focus on frontend/ or web/)
   • Trace data flow and key functions
   • Return detailed explanations with file:line references

3. Read all files identified by research tasks:

   • After research tasks complete, read ALL files they identified as relevant
   • Read them FULLY into the main context
   • This ensures you have complete understanding before proceeding

4. Analyze and verify understanding:

   • Cross-reference the ticket requirements with actual code
   • Identify any discrepancies or misunderstandings
   • Note assumptions that need verification
   • Determine true scope based on codebase reality

5. Present informed understanding — no questions:

   Based on the ticket and my research of the codebase, I understand we need to [accurate summary].
   
   I've found that:
   - [Current implementation detail with file:line reference]
   - [Relevant pattern or constraint discovered]
   - [Potential complexity or edge case identified]
   

   Do NOT list questions here. All open questions are resolved in Step 3 via grill-me.

Step 2: Research & Discovery

After presenting the Step 1 findings (no clarifications yet — those happen in Step 3):

1. If the user corrects any misunderstanding:

   • DO NOT just accept the correction
   • Spawn new research tasks to verify the correct information
   • Read the specific files/directories they mention
   • Only proceed once you've verified the facts yourself

2. Create a research todo list using TodoWrite to track exploration tasks

3. Spawn parallel sub-tasks for comprehensive research:

   • Create multiple Task agents to research different aspects concurrently
   • Use the right agent for each type of research:

   For deeper investigation:

   • stepwise-core:codebase-locator - To find more specific files (e.g., "find all files that handle [specific component]")
   • stepwise-core:codebase-analyzer - To understand implementation details (e.g., "analyze how [system] works")
   • stepwise-core:codebase-pattern-finder - To find similar features we can model after

   For historical context:

   • stepwise-core:thoughts-locator - To find any research, plans, or decisions about this area
   • stepwise-core:thoughts-analyzer - To extract key insights from the most relevant documents

   Each agent knows how to:

   • Find the right files and code patterns
   • Identify conventions and patterns to follow
   • Look for integration points and dependencies
   • Return specific file:line references
   • Find tests and examples

4. Wait for ALL sub-tasks to complete before proceeding

5. Present research findings — facts only, no invented options or questions:

   Based on my research, here's what I found:
   
   **Current State:**
   - [Key discovery about existing code]
   - [Pattern or convention to follow]
   - [Constraint or dependency discovered]
   
   **Options mentioned in the codebase** (only if explicitly found — e.g., a features file, a comment, existing patterns):
   - [Option explicitly referenced in file:line]
   

   Do NOT invent design options or list pros/cons. Only surface options explicitly documented in the codebase. All design decisions happen in Step 3 via grill-me.

Step 3: Interrogation Phase

Do not ask questions yourself — not even one. Use the Skill tool to invoke /stepwise-core:grill-me now.

Why: grill-me walks down the decision tree one branch at a time, with a recommended answer per question. If you ask inline, you will dump a list and lose the structured resolution that makes this valuable. Any question you feel tempted to ask here belongs inside grill-me.

Pass grill-me the full context from your research: current state, design options found, and all unresolved decisions. Let grill-me drive the conversation from there.

Only proceed to Step 4 once grill-me has resolved all open design decisions and you have shared understanding with the user on every choice.

Step 4: Plan Structure Development

Once aligned on approach:

1. Create initial plan outline:

   Here's my proposed plan structure:
   
   ## Overview
   [1-2 sentence summary]
   
   ## Implementation Phases:
   1. [Phase name] - [what it accomplishes]
   2. [Phase name] - [what it accomplishes]
   3. [Phase name] - [what it accomplishes]
   
   Does this phasing make sense? Should I adjust the order or granularity?
   

2. Get feedback on structure before writing details

Step 5: Detailed Plan Writing

After structure approval:

1. Initialize thoughts directory if needed:

   • Check if thoughts/ directory exists
   • If it doesn't exist, use the thoughts-management Skill to initialize it:

     bash ${CLAUDE_PLUGIN_ROOT}/skills/thoughts-management/scripts/thoughts-init
     

   • This creates the complete directory structure for organizing plans

2. Write the plan to thoughts/shared/plans/YYYY-MM-DD-ENG-XXXX-description.md

   • Format: YYYY-MM-DD-ENG-XXXX-description.md where:
     • YYYY-MM-DD is today's date
     • ENG-XXXX is the ticket number (omit if no ticket)
     • description is a brief kebab-case description
   • Examples:
     • With ticket: 2025-01-08-ENG-1478-parent-child-tracking.md
     • Without ticket: 2025-01-08-improve-error-handling.md

3. Use this template structure:

# [Feature/Task Name] Implementation Plan

## Overview

[Brief description of what we're implementing and why]

## Current State Analysis

[What exists now, what's missing, key constraints discovered]

## Desired End State

[A Specification of the desired end state after this plan is complete, and how to verify it]

### Key Discoveries:
- [Important finding with file:line reference]
- [Pattern to follow]
- [Constraint to work within]

## What We're NOT Doing

[Explicitly list out-of-scope items to prevent scope creep]

## Implementation Approach

[High-level strategy and reasoning]

## Phase 1: [Descriptive Name]

### Overview
[What this phase accomplishes]

### Changes Required:

#### 1. [Component/File Group]
**File**: `path/to/file.ext`
**Changes**: [Summary of changes]

```[language]
// Specific code to add/modify
```

### Success Criteria:
- [ ] Migration applies cleanly: `make migrate`
- [ ] Unit tests pass: `make test-component`
- [ ] Type checking passes: `npm run typecheck`
- [ ] Linting passes: `make lint`
- [ ] Integration tests pass: `make test-integration`

**Note**: Add "Manual Verification" section ONLY if truly needed (UI aesthetics, subjective UX). For TDD projects with automated tests, this section should be absent.

---

## Phase 2: [Descriptive Name]

[Similar structure with both automated and manual success criteria...]

---

## Testing Strategy

### Unit Tests:
- [What to test]
- [Key edge cases]

### Integration Tests:
- [End-to-end scenarios]

### Manual Testing Steps:
1. [Specific step to verify feature]
2. [Another verification step]
3. [Edge case to test manually]

## Performance Considerations

[Any performance implications or optimizations needed]

## Migration Notes

[If applicable, how to handle existing data/systems]

## References

- Original ticket: `thoughts/nikey_es/tickets/eng_XXXX.md`
- Related research: `thoughts/shared/research/[relevant].md`
- Similar implementation: `[file:line]`

Step 6: Sync and Review

1. Present the draft plan location:

   I've created the initial implementation plan at:
   `thoughts/shared/plans/YYYY-MM-DD-ENG-XXXX-description.md`
   
   Please review it and let me know:
   - Are the phases properly scoped?
   - Are the success criteria specific enough?
   - Any technical details that need adjustment?
   - Missing edge cases or considerations?
   

2. Iterate based on feedback - be ready to:

   • Add missing phases
   • Adjust technical approach
   • Clarify success criteria (both automated and manual)
   • Add/remove scope items

3. Continue refining until the user is satisfied

4. When plan is finalized, inform the user:

   Implementation plan complete: `thoughts/shared/plans/[filename].md`
   
   Next steps in the workflow:
   - Review and approve the plan
   - Use `/stepwise-core:implement-plan thoughts/shared/plans/[filename].md` to execute it
   - Or use `/stepwise-core:iterate-plan thoughts/shared/plans/[filename].md [changes]` to refine further
   
   Tip: Use `/clear` to free up context before starting implementation
   

Important Guidelines

1. Be Skeptical:

   • Question vague requirements
   • Identify potential issues early
   • Ask "why" and "what about"
   • Don't assume - verify with code

2. Be Interactive:

   • Don't write the full plan in one shot
   • Get buy-in at each major step
   • Allow course corrections
   • Work collaboratively

3. Be Thorough:

   • Read all context files COMPLETELY before planning
   • Research actual code patterns using parallel sub-tasks
   • Include specific file paths and line numbers
   • Write measurable success criteria with clear automated vs manual distinction
   • automated steps should use make whenever possible - for example make -C frontend check instead of cd frontend && npm run fmt

4. Be Practical:

   • Focus on incremental, testable changes
   • Consider migration and rollback
   • Think about edge cases
   • Include "what we're NOT doing"

5. Track Progress:

   • Use TodoWrite to track planning tasks
   • Update todos as you complete research
   • Mark planning tasks complete when done

6. No Open Questions in Final Plan:

   • If you encounter open questions during planning, STOP
   • Research or ask for clarification immediately
   • Do NOT write the plan with unresolved questions
   • The implementation plan must be complete and actionable
   • Every decision must be made before finalizing the plan

Success Criteria Guidelines

CRITICAL RULE FOR TDD PROJECTS:

• If a phase writes/runs automated tests → NO "Manual Verification" section needed
• If it can be tested with code (assert X == Y) → It MUST be an automated test
• Manual verification is ONLY for subjective qualities (aesthetics, "feel", human judgment)

Always separate success criteria into two categories:

1. Automated Verification (can be run by execution agents):

   • Commands: make test, pytest -v, npm run lint, etc.
   • Files should exist, code compiles, tests pass

2. Manual Verification (RARELY needed in TDD):

   • Visual appearance requiring aesthetic judgment
   • Subjective UX ("does it feel responsive?")
   • Real assistive technology testing (screen readers)
   • Cross-browser visual compatibility

INVALID Manual Verification (write tests instead):

• "Review test output" → Redundant, covered by automated
• "Verify function returns correct value" → Should be unit test
• "Test with input X produces output Y" → Should be test
• "Confirm calculation is correct" → Should be unit test

Format examples:

Example 1 - TDD Test Phase (NO manual verification):

### Success Criteria:
- [ ] All tests pass: `pytest tests/ -v`
- [ ] No linting errors: `pylint src/`

Example 2 - Web UI Feature (justified manual verification):

### Success Criteria:

#### Automated Verification:
- [ ] Component tests pass: `npm test components/Button`
- [ ] E2E tests pass: `playwright test button.spec.ts`

#### Manual Verification:
- [ ] Button animation feels smooth (subjective)
- [ ] Visual appearance matches mockup (aesthetic judgment)

Common Patterns

For Database Changes:

• Start with schema/migration
• Add store methods
• Update business logic
• Expose via API
• Update clients

For New Features:

• Research existing patterns first
• Start with data model
• Build backend logic
• Add API endpoints
• Implement UI last

For Refactoring:

• Document current behavior
• Plan incremental changes
• Maintain backwards compatibility
• Include migration strategy

Sub-task Spawning Best Practices

When spawning research sub-tasks:

1. Spawn multiple tasks in parallel for efficiency
2. Each task should be focused on a specific area
3. Provide detailed instructions including:
   • Exactly what to search for
   • Which directories to focus on
   • What information to extract
   • Expected output format
4. Be EXTREMELY specific about directories:
   • If the ticket mentions "frontend" or "web UI", specify frontend/ or web/ directory
   • If it mentions "backend" or "API", specify backend/ or api/ directory
   • Never use generic terms - always specify the exact directory structure
   • Include the full path context in your prompts
5. Specify read-only tools to use
6. Request specific file:line references in responses
7. Wait for all tasks to complete before synthesizing
8. Verify sub-task results:
   • If a sub-task returns unexpected results, spawn follow-up tasks
   • Cross-check findings against the actual codebase
   • Don't accept results that seem incorrect

Example of spawning multiple tasks:

# Spawn these tasks concurrently:
tasks = [
    Task("Research database schema", db_research_prompt),
    Task("Find API patterns", api_research_prompt),
    Task("Investigate UI components", ui_research_prompt),
    Task("Check test patterns", test_research_prompt)
]

Example Interaction Flow

User: /create-plan
Assistant: I'll help you create a detailed implementation plan...

User: We need to add parent-child tracking for Claude sub-tasks. See thoughts/nikey_es/tickets/eng_1478.md
Assistant: Let me read that ticket file completely first...

[Reads file fully]

Based on the ticket, I understand we need to track parent-child relationships for Claude sub-task events in the hld daemon. Here's what I found in the codebase: [findings with file:line references]

[Research continues, then Step 3 invokes grill-me for all design decisions...]