Sprint

---
name: sprint
description: Execute a batch of backlog tickets in parallel. Use when the user wants to build multiple unblocked tickets simultaneously with integrated QA review.
argument-hint: "optional: ticket IDs and/or --parallel N"
disable-model-invocation: true
---

# Sprint: $ARGUMENTS

You are the sprint orchestrator. You execute multiple backlog tickets in parallel, run QA on each, and present the CEO with a consolidated review.

## Process

### Phase 0 — Load & Validate

1. Read the backlog directory (`.solopreneur/backlog/`) for the relevant project. If `$ARGUMENTS` names specific tickets (e.g., `MVP-001 MVP-003`), use those. Otherwise, find all unblocked tickets: tickets where every `depends_on` entry has `status: done` or `status: tested`.

2. If no backlog directory exists, stop and guide the CEO:
   ```
   No backlog found. Let's create one first:
   /solopreneur:backlog [your spec or feature]
   ```

3. If all tickets are blocked or already done, report that and suggest next steps.

4. If any tickets involve UI work, follow the **Claude Chrome Extension setup check** (see Browser Tools in CLAUDE.md) before proceeding.

5. Check parallelism limit: use `--parallel N` from `$ARGUMENTS` if provided, else read `sprint.max_parallel_tickets` from `.solopreneur/preferences.yaml`, else default to **3**. Cap at that limit. If more tickets are unblocked, pick highest priority (lowest ticket number first).

6. Present the plan to the CEO with AskUserQuestion:
   ```
   I'll build these N tickets in parallel, each in its own isolated branch:

   - MVP-001: [title] (size: S)
   - MVP-002: [title] (size: M)
   - MVP-003: [title] (size: S)

   Proceed?
   ```

### Phase 1 — Parallel Build

On CEO approval, spawn **background Task agents** (one per ticket, `@engineer`, `isolation: "worktree"`):

Each agent receives:
- The full ticket content (requirements, acceptance criteria, file list)
- Engineering guidance: "You are a senior engineer building this ticket. Start with the simplest solution. Write clean code with proper error handling. Run tests if a test suite exists (`npm test`, `pytest`, etc.). Check each acceptance criterion before returning."
- Instructions to return structured results:
  ```
  ## Results: [TICKET-ID]
  **Status**: pass | fail
  **Files changed**: [list]
  **Tests**: [pass count]/[total] or "no test suite"
  **Acceptance criteria**:
  - [criterion 1]: pass/fail
  - [criterion 2]: pass/fail
  **Notes**: [anything the CEO should know]
  ```

Cap agents at the parallelism limit from Phase 0. If there are fewer tickets than the limit, that's fine — the sprint still works with fewer agents.

### Phase 2 — QA Review

As each build agent completes, run **foreground subagent review** (sequential, one ticket at a time):

1. **Code QA** (always): Spawn `@qa` to review the built code:
   - Code quality, security, edge cases
   - Verify each acceptance criterion against the actual code
   - Run tests if available
   - Produce severity-rated findings (Critical / Warning / Suggestion / Positive)

2. **Browser QA** (UI tickets only, when browser tools available): Delegate to `@qa` for browser-based validation — visual walk-through, screenshots, console errors, responsive checks.

3. **Design review** (UI tickets with mockups): Spawn `@designer` to compare the implementation against design mockups in `.solopreneur/designs/`:
   - Visual accuracy vs mockups
   - Spacing, alignment, responsive behavior
   - Flag any deviations

### Phase 3 — Build Report

Compile all results into a consolidated sprint report:

```
Sprint Complete: N tickets built

MVP-001: Login Form  ✓ BUILT
   Tests pass (12/12)
   QA: No critical issues

MVP-002: Dashboard  ⚠ BUILT (with warnings)
   Tests pass (8/8)
   QA: Chart overflows on mobile

MVP-003: Settings Page  ✓ BUILT
   Tests pass (5/5)
   QA: Clean
```

For each built ticket:
1. Update ticket YAML: set `status: built`, set `branch: <worktree-branch>`, set `worktree: <worktree-path>` (from the Task agent's result).
2. **Keep the worktree alive** — do NOT clean it up. The worktree is needed if `/review` finds issues and the CEO needs to fix in parallel.

If any build agents reported failures or critical QA issues, note these prominently — the CEO may want to fix before reviewing.

Suggest review:
```
-> Next: Let's review and merge what was built:
   /solopreneur:review sprint
```

If some tickets failed to build:
```
-> {N} tickets built successfully, {M} had issues.
   Review the successful ones:
   /solopreneur:review sprint

   Fix the failed ones:
   /solopreneur:build .solopreneur/backlog/{dir}/{ID}.md
```