sprint

Sprint Lifecycle — Automated MCP Tool Chain

Run a complete sprint from planning to rest using code-context MCP tools. All data lives in context.db.

Phase Flow

planning → implementation → done → rest → (next sprint)

Step 0: Load Context (2 calls)

index_directory({ freshness_check: true })   # skip if <5 min old
get_resume_state()                           # single-call resume detection

Phase context — use load_phase_context() when entering each step

Step	Call
Step 1 (Planning)	load_phase_context({ phase: "tickets" })
Step 4 (Implementation)	load_phase_context({ phase: "implementation", sprint_id, ticket_id })
Step 6 (Retrospective)	load_phase_context({ phase: "retro", sprint_id })

---

Step 1: Gather Planning Context

Using data from Step 0, make informed decisions:

• Use velocity trends to set realistic committed points
• Use retro patterns to avoid past mistakes (e.g., "auth tickets were underestimated last sprint")
• Use backlog to carry over unfinished work
• Use agent workload to balance ticket assignment
• Use mood trends to reduce load on burned-out agents
• Use codebase context to inform ticket scoping — call get_file_context() for files related to planned work

Step 2: Create Sprint — start_sprint

One call creates the sprint + all tickets in planning phase:

start_sprint({
  name: "Sprint N — <descriptive name>",
  goal: "<one sentence, measurable>",
  milestone_id: <id>,
  velocity: <committed points based on velocity trends>,
  tickets: [
    { title: "...", description: "...", assigned_to: "<agent role>", story_points: N, priority: "P1" },
    ...
  ]
})

Rules:

• Assign tickets to roles from list_agents() (developer, qa, product-owner, devops)
• Total story points should match committed velocity
• Every ticket needs story points and a priority (P0-P3)
• Sprint goal must be measurable

Save the returned sprint_id — used in every subsequent call.