openspec-replan

# OpenSpec Replan

Adaptive refinement skill for blocked or drifted changes. Proposes revised tasks or pivots.

## Workflow: Analyze → Propose → Confirm → Apply

```mermaid
flowchart LR
    A["Analyze blocker/drift"] --> B["Read context"]
    B --> C["Propose revisions"]
    C --> D{"User approval?"}
    D -->|Yes| E["Apply changes"]
    D -->|No| F["Discard"]
    E --> G["Document blocker"]

    classDef action fill:#C8E6C9,stroke:#388E3C,color:#000
    classDef gate fill:#E1BEE7,stroke:#7B1FA2,color:#000
    classDef discard fill:#FFCDD2,stroke:#D32F2F,color:#000

    class A,B,C,E,G action
    class D gate
    class F discard
```

**Critical**: Always wait for user confirmation before applying changes (ask_first trust zone).

## Exploration Strategy

Before replanning, consult `openspec/project.md` → Exploration Strategy section:

1. **Context sources**: Read `primary` files (project.md, proposal.md, specs)
2. **Must-read files**: CLAUDE.md, settings.json (project constraints)
3. **Tools**: Use configured codebase tools (Glob, Grep, Read, or MCP if enabled)
4. **Existing tasks**: Read tasks.md to understand current plan
5. **Philosophy**: Read Execution Philosophy section for current mode and principles

## Commands

### replan

Revise tasks when implementation is blocked.

**Input**: `$ARGUMENTS` = `change-id [blocker-description]`

**Workflow**:
1. Read `openspec/changes/{change-id}/tasks.md`, proposal.md, specs
2. Identify blocker (from argument or ask user)
3. Analyze which tasks are affected
4. **Minimal change preference**: Revise only affected tasks, not entire list
5. Propose revised tasks with blocker context
6. **Wait for user approval** before applying
7. If approved: Update tasks.md with revisions
8. Document blocker as comment in tasks.md

**Proposal format**:
```
## Replan Proposal for {change-id}

### Blocker
{blocker description}

### Affected Tasks
- {task-number}: {original} -> {revised}
- {task-number}: REMOVED (blocked)
- NEW {task-number}: {n