run-epic

What this skill does

# Devloop Run Epic

Execute an epic phase-by-phase. Tasks run inline by default; subagents are spawned per task `[model:X]` annotation (same pattern as `/devloop:run`). **You are the orchestrator -- execute the phase, validate tests, commit, promote the next phase.**

## Step 1: Load State

Read `.devloop/epic.json`.

- **No file**: "No epic found. Use `/devloop:epic <topic>` to create one." STOP.
- **`--status`**: Display phase tracker and STOP.
- **`status: "complete"`**: "Epic already complete." STOP.
- **`--phase N`**: Override current phase and re-promote.

## Step 2: Validate Plan

Read `.devloop/plan.md`. Verify `**Phase**:` matches `epic.json.current_phase`.
- Mismatch or missing: run `${CLAUDE_PLUGIN_ROOT}/scripts/promote-phase.sh --force`.
- All tasks `[x]`: skip to Step 5 (already completed).

## Step 3: Execute Phase

Read `epic.json` for context (user_stories, invariants, negative_cases, test_command). Keep this context in working memory while executing the phase.

**Execute plan.md tasks inline**, following the same model-annotation pattern as `/devloop:run`:

- **`[model:haiku]` tasks**: spawn `devloop:haiku-worker`.
- **`[model:sonnet]` tasks**: spawn `devloop:swarm-worker` (sonnet).
- **No annotation**: execute inline (no subagent). This is the default — most tasks should be inline.
- Respect `[depends:N.M]` constraints and `[parallel:X]` groupings.
- Do NOT commit or modify epic.json/epic.md during execution (that's Step 5).

Use the epic context to guide your work:
- User stories anchor WHY the tasks exist.
- Invariants / negative cases are testable constraints that must hold.
- Run `test_command` after implementation tasks.

**Fallback (opt-in only)**: If the phase is very large (>15 tasks) *and* session context is already heavy, you MAY delegate the whole phase to a single sonnet subagent in a fresh context. This is a last-resort fresh-context reset, not the default path.

## Step 4: Validate Completion

1. Run `${CLAUDE_PLUGIN_ROOT}/scripts/check-plan-complete.sh .devloop/plan.md`.
   - Incomplete: **AskUserQuestion**: "Retry" or "Skip remaining".

2. Run tests (unless `--skip-tests` or `test_command` is null).
   Use Monitor for real-time streaming when `test_command` matches a known long-running pattern
   (test suites: `npm test`, `pytest`, `go test`, `cargo test`, etc.; builds; full-codebase linting).
   Example:
   ```
   Monitor({ description: "epic phase tests", command: "<test_command> 2>&1 | grep --line-buffered -E 'PASS|FAIL|Error|ok|error|passed|failed'", timeout_ms: 300000, persistent: false })
   ```
   Fallback: if Monitor errors, run `test_command` with Bash directly.
   - Fail: **AskUserQuestion**: "Fix and retry" or "Skip tests".

## Step 5: Commit & Advance

1. Commit: `git add` changed files, commit with `feat: phase N -- phase-name`.
2. Update `epic.json`: mark phase `"complete"`, record commit hash, increment `current_phase`.
3. Update `epic.md` Phase Tracker table.
4. If all phases complete: Report done. **AskUserQuestion**: "Ship it" or "Review". STOP.
5. Promote next phase: run `${CLAUDE_PLUGIN_ROOT}/scripts/promote-phase.sh --force`.

Report:
```
Phase N complete and committed.
Phase M loaded: "Phase Name" (X tasks)
```

## Step 6: Pause Point

The next phase is already loaded in plan.md. **AskUserQuestion**:
- **Continue now**: Loop to Step 3 in the same session.
- **Clear and run**: "Run `/clear`, then `/devloop:run-epic` to execute Phase M." STOP.

## Recovery

`run-epic` is resumable. `epic.json` is the source of truth:
- Mid-phase: plan.md has partial progress, execution picks up remaining tasks.
- Post-phase: detects plan complete, skips to validation.
- After `/clear`: reads epic.json, resumes from correct phase.

If the repo is in a broken state (e.g. orphaned changes, mismatched plan), run-epic will detect the mismatch in Step 2 and re-promote the correct phase. Tests in Step 4 catch implementation issues before committing.

---
**Now**: Load epic state and begin.