Generate a structured sprint brief from sprint data and goals. Use when asked to write a sprint brief, create a sprint summary, document sprint goals and scope, or produce a team-facing sprint overview. Produces a scannable brief with sprint goal, rationale, grouped work, critical path, risks, and definition of done.
Start a fresh conversation. Replace the highlighted placeholders.
Use sprint-brief to create a scannable sprint brief from [sprint name and goal], [tickets with owners], and [dependencies, blockers, and carry-over], including a named critical path, actionable risks, definition of done, assumptions, and quality score.
Required inputs
[sprint name and goal]
[tickets with owners]
[dependencies, blockers, and carry-over]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: sprint-briefdescription: "Generate a structured sprint brief from sprint data and goals. Use when asked to write a sprint brief, create a sprint summary, document sprint goals and scope, or produce a team-facing sprint overview. Produces a scannable brief with sprint goal, rationale, grouped work, critical path, risks, and definition of done."
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
Work from what is given. If any of these is missing, still produce the complete output: fill each gap with a reasonable assumption marked (assumed, confirm) and list those assumptions at the end. Ask a question first only when the core subject itself is missing (there is nothing to write about).
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
Read sprint goal and check it's specific and measurable — flag if it's too vague
Group tickets by theme or feature area
Identify the critical path — which tickets must complete for the sprint goal to be met?
Flag risks: tickets with unclear acceptance criteria, missing designs, unresolved dependencies
Note carry-over items and whether they affect this sprint's goal
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]
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.
Dimension
0
5
10
Goal scoreability
Goal is a task list or a vague direction ("make progress on X") — nobody could score it at sprint end
Goal states one outcome but the pass/fail line is fuzzy (no number, date, or observable test)
Goal is a single outcome statement with an explicit pass/fail test anyone on the team could apply on the last day
Critical path precision
No critical path, or "the important tickets" — reader can't tell which slippage is fatal
Critical path tickets are named but without sequencing or the date/trigger at which the goal fails
Named tickets in dependency order, with the deadline that kills the goal and a clear fatal-vs-survivable split from the rest of the board
Risk actionability
Risks are a worry list — no mitigations, no owners
Each risk has a mitigation or an owner, but responses are generic ("monitor closely")
Every risk has a concrete mitigation with a ready-by date and a single named owner, and states whether it threatens the goal or just a ticket
Capacity honesty
Carry-over listed without impact; board is silently overloaded
Carry-over impact on the goal is stated, but the brief doesn't act on it — overload is flagged as a risk and left there
Carry-over is costed against capacity and the brief shows the resolution: named scope cuts, a de-scoped goal, or an explicit team-agreed overload acceptance
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