Sprint Brief Skill

Produce a clear, scannable sprint brief that every team member — engineer, designer, PM — can read in under three minutes and understand exactly what we're doing and why.

Required Inputs

Ask the user for these if not provided:

• Sprint name and number
• Sprint goal (1-2 sentences — flag if too vague)
• Ticket list with owners (or a description of the work)
• Known dependencies or blockers
• Carry-over items from previous sprint (if any)

Process

1. Read sprint goal and check it's specific and measurable — flag if it's too vague
2. Group tickets by theme or feature area
3. Identify the critical path — which tickets must complete for the sprint goal to be met?
4. Flag risks: tickets with unclear acceptance criteria, missing designs, unresolved dependencies
5. Note carry-over items and whether they affect this sprint's goal
6. Validate — Confirm the sprint goal is achievable given the ticket scope and capacity. If the critical path items alone would fill the sprint, flag it as overloaded.

Output Structure

Sprint [Number] Brief — [Dates]

Sprint Goal: [1-2 sentences — specific and measurable] Why This Sprint Matters: [Connect to quarterly OKR in 2-3 sentences]

What We're Building:

• [Theme 1]: [tickets and owners]
• [Theme 2]: [tickets and owners]

Critical Path: [The 2-3 tickets everything else depends on]

Risks to Flag:

• [Risk 1 + mitigation]
• [Risk 2 + mitigation]

Carry-over from Last Sprint: [List + impact on current goal]

Definition of Done: [Specific, agreed criteria for sprint success]

Deeper Materials

This skill ships with support files — use them when they are available:

• references/goal-writing.md — Writing Sprint Goals That Steer. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
• templates/brief-one-pager.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.

Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

Quality Checks

• Sprint goal is specific enough to score pass/fail at the end of the sprint
• Critical path items are named — not just "the important ones"
• Every risk has a mitigation or owner (not just "this is a risk")
• Carry-over items are connected to their impact on this sprint's goal
• Definition of Done is agreed criteria, not a task list

Anti-Patterns

• Do not write a sprint goal as a task list — the goal must be a single outcome-focused statement that can be scored pass/fail
• Do not leave the critical path unnamed — "the important tickets" is not a critical path
• Do not list risks without a mitigation or owner — a risk without a response is just a worry list
• Do not ignore carry-over items' impact on this sprint's capacity and goal
• Do not write a Definition of Done that mixes task completion with outcome criteria — they must be observable and agreed before the sprint starts