issue-analyze

Prompt file imported from Morboz/ccpm-stable-coin-demo (.claude/commands/pm/issue-analyze.md). Fill in {{arguments}} before use. Copyright stays with the author.

Issue Analyze

Analyze an issue to identify parallel work streams for maximum efficiency.

Usage

/pm:issue-analyze <issue_number>

Quick Check

1. Find local task file:

   • First check if .claude/epics/*/{{arguments}}.md exists (new naming convention)
   • If not found, search for file containing github:.*issues/{{arguments}} in frontmatter (old naming)
   • If not found: "❌ No local task for issue #{{arguments}}. Run: /pm:import first"

2. Check for existing analysis:

   test -f .claude/epics/*/{{arguments}}-analysis.md && echo "⚠️ Analysis already exists. Overwrite? (yes/no)"

Instructions

1. Read Issue Context

Get issue details from GitHub:

gh issue view {{arguments}} --json title,body,labels

Read local task file to understand:

• Technical requirements
• Acceptance criteria
• Dependencies
• Effort estimate

2. Identify Parallel Work Streams

Analyze the issue to identify independent work that can run in parallel:

Common Patterns:

• Database Layer: Schema, migrations, models
• Service Layer: Business logic, data access
• API Layer: Endpoints, validation, middleware
• UI Layer: Components, pages, styles
• Test Layer: Unit tests, integration tests
• Documentation: API docs, README updates

Key Questions:

• What files will be created/modified?
• Which changes can happen independently?
• What are the dependencies between changes?
• Where might conflicts occur?

3. Create Analysis File

Get current datetime: date -u +"%Y-%m-%dT%H:%M:%SZ"

Create .claude/epics/{epic_name}/{{arguments}}-analysis.md:

---
issue: {{arguments}}
title: { issue_title }
analyzed: { current_datetime }
estimated_hours: { total_hours }
parallelization_factor: { 1.0-5.0 }
---

# Parallel Work Analysis: Issue #{{arguments}}

## Overview

{Brief description of what needs to be done}

## Parallel Streams

### Stream A: {Stream Name}

**Scope**: {What this stream handles}
**Files**:

- {file_pattern_1}
- {file_pattern_2}
  **Agent Type**: {backend|frontend|fullstack|database}-specialist
  **Can Start**: immediately
  **Estimated Hours**: {hours}
  **Dependencies**: none

### Stream B: {Stream Name}

**Scope**: {What this stream handles}
**Files**:

- {file_pattern_1}
- {file_pattern_2}
  **Agent Type**: {agent_type}
  **Can Start**: immediately
  **Estimated Hours**: {hours}
  **Dependencies**: none

### Stream C: {Stream Name}

**Scope**: {What this stream handles}
**Files**:

- {file_pattern_1}
  **Agent Type**: {agent_type}
  **Can Start**: after Stream A completes
  **Estimated Hours**: {hours}
  **Dependencies**: Stream A

## Coordination Points

### Shared Files

{List any files multiple streams need to modify}:

- `src/types/index.ts` - Streams A & B (coordinate type updates)
- Project configuration files (package.json, pom.xml, Cargo.toml, etc.) - Stream B (add dependencies)
- Build configuration files (build.gradle, CMakeLists.txt, etc.) - Stream C (build system changes)

### Sequential Requirements

{List what must happen in order}:

1. Database schema before API endpoints
2. API types before UI components
3. Core logic before tests

## Conflict Risk Assessment

- **Low Risk**: Streams work on different directories
- **Medium Risk**: Some shared type files, manageable with coordination
- **High Risk**: Multiple streams modifying same core files

## Parallelization Strategy

**Recommended Approach**: {sequential|parallel|hybrid}

{If parallel}: Launch Streams A, B simultaneously. Start C when A completes.
{If sequential}: Complete Stream A, then B, then C.
{If hybrid}: Start A & B together, C depends on A, D depends on B & C.

## Expected Timeline

With parallel execution:

- Wall time: {max_stream_hours} hours
- Total work: {sum_all_hours} hours
- Efficiency gain: {percentage}%

Without parallel execution:

- Wall time: {sum_all_hours} hours

## Notes

{Any special considerations, warnings, or recommendations}

4. Validate Analysis

Ensure:

• All major work is covered by streams
• File patterns don't unnecessarily overlap
• Dependencies are logical
• Agent types match the work type
• Time estimates are reasonable

5. Output

✅ Analysis complete for issue #{{arguments}}

Identified {count} parallel work streams:
  Stream A: {name} ({hours}h)
  Stream B: {name} ({hours}h)
  Stream C: {name} ({hours}h)

Parallelization potential: {factor}x speedup
  Sequential time: {total}h
  Parallel time: {reduced}h

Files at risk of conflict:
  {list shared files if any}

Next: Start work with /pm:issue-start {{arguments}}

Important Notes

• Analysis is local only - not synced to GitHub
• Focus on practical parallelization, not theoretical maximum
• Consider agent expertise when assigning streams
• Account for coordination overhead in estimates
• Prefer clear separation over maximum parallelization