---
name: start-sprint
description: Pre-sprint setup and briefing. Verifies prior sprint hygiene, creates branch, runs briefing, and initializes sprint state.
---

# Start Sprint

Run the complete pre-sprint routine: verify prior sprint hygiene, get briefing, create branch, and initialize sprint state.

## Arguments

- First argument — optional sprint number (auto-detected if omitted)

## Steps

### 1. Determine sprint number

- If a number was provided as an argument, use it
- Otherwise, run `slope now` and use its active or next sprint; use `slope next` only if no sprint is reported
- Treat the sprint number as the current SLOPE work unit. It may be a time-boxed interval or a scope-based agent milestone.

### 2. Load bounded roadmap context

Run `slope roadmap focus --sprint=N` for the discovered sprint before loading full roadmap history.

### 3. Verify prior sprint scorecard

Check that the previous sprint's scorecard exists at `docs/retros/sprint-{N-1}.json`:
- If missing, **stop and create it first** using `/skill:post-sprint`
- If it exists, continue
- Note: the sprint-completion guard also enforces this — PR creation is blocked without a scorecard

### 4. Branch hygiene

- Run `git branch` to check for stale branches from prior sprints
- If stale branches exist, warn the user
- Create a new feature branch: `feat/sprint-{N}-<theme-slug>`

### 5. Run briefing

Run `slope briefing` to get:
- Handicap snapshot (rolling performance stats)
- Hazard index (recent gotchas by area)
- Filtered common issues relevant to this sprint's work area
- Session continuity (any handoffs from prior sessions)

If you know the sprint's work area, add filters:
```
slope briefing --categories=<area> --keywords=<topic>
```

### 6. Start sprint with workflow engine

Run `slope sprint run --workflow=sprint-standard --var sprint_id=S{N}` to start a workflow-controlled sprint.

This activates the workflow engine which:
- Controls step ordering (plan → review → implement → validate → score)
- The `workflow-step-gate` guard blocks file edits outside of `agent_work` steps
- State persists in the store — resume with `slope sprint resume` if interrupted
- Skip steps with `slope sprint skip` if not applicable

If no workflow is needed (simple fix or chore), use `slope sprint run --workflow=sprint-lightweight`.

### 6. Write sprint plan

Write the sprint plan as a markdown file (e.g., `docs/backlog/sprint-{N}-plan.md`).

The `review-tier` guard fires on plan file writes and determines the review tier. Complete the required review rounds before proceeding to implementation.

### 7. Set par and slope

Based on the sprint plan:
- **Par**: 1-2 tickets = 3, 3-4 tickets = 4, 5+ tickets = 5
- **Slope**: Count complexity factors:
  - New infrastructure or architecture (+1)
  - Multi-package changes (+1)
  - Schema or API changes (+1)
  - External API integration (+1)
  - Learning curve / unfamiliar territory (+1)

### 8. Prior art research

Before implementation begins, search for existing solutions:
- How have other projects solved this problem?
- Are there standard algorithms or approaches?
- Any relevant GDC talks, blog posts, or papers?

Save findings to `docs/` for reference during implementation.

### 9. Present sprint summary

Show the user:
- Sprint number and theme
- Par and slope
- Ticket list with planned clubs
- Key hazards to watch for (from briefing)
- Deferred findings targeting this sprint: `slope review deferred --sprint={N}`

## Important

- Never skip the prior scorecard verification — this prevents the "batch without reflection" problem
- The briefing output contains critical context; read it carefully before starting
- If the codebase map is stale, run `slope map` to refresh it