MCPInstall

tool-design-sprint-brief

Pre-sprint brief that locks challenge, sprint questions, team and role assignments, customer recruiting plan, prototype medium, interview format, logistics, and success criteria before Monday of a Design Sprint. Use after the readiness verdict is Go and before Monday begins. Produces a two-page artifact the team and Decider sign off on as the contract for the next five days.

Installs
620
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/product-on-purpose/pm-skills --skill tool-design-sprint-brief
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads tool-design-sprint-brief automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Design Sprint Brief

Produce the brief that aligns the team on challenge, sprint questions, participants, customer recruiting, prototype medium, interview format, logistics, and success criteria before Monday begins. A well-built brief prevents Monday morning from opening with re-litigation of "what are we testing this week?"; a missing or vague brief almost guarantees it.

Family contract: docs/reference/skill-families/design-sprint-skills-contract.md. This skill is a member of design-sprint-skills.

When to Use

  • The readiness verdict from tool-design-sprint-readiness is Go (or Conditional Go with preconditions cleared).
  • The sprint has dates blocked on calendars and you need the artifact that names what the sprint is for.
  • The team has customer recruiting active and you need to commit a recruiting plan, honorarium budget, and Friday schedule before recruiting closes.
  • A skeptical exec wants to know "what is the team doing for five days plus customer cost?" and you need an answer that fits on two pages.

When NOT to Use

  • The sprint has already started. The brief is a prep artifact, not an in-sprint deliverable. If Monday is happening, run tool-design-sprint-map-and-target instead.
  • The readiness verdict is Wait. The brief cannot fix an unready team; close the preconditions first, then re-run readiness, then invoke this skill.
  • The team wants a stakeholder strategy document. The brief is internal prep, not an external deliverable. If a stakeholder document is needed, that is a downstream artifact (the Friday scorecard or the next-step memo).
  • Customer recruiting has not started. The brief locks the recruiting plan but cannot replace the recruiter. If no recruiter is named, go back to readiness Wait verdict.

What This Skill Produces

A single bundled artifact with nine sections:

  1. Challenge statement and why-now: one paragraph naming the testable challenge and the urgency that justifies a sprint this week vs. later.
  2. Sprint questions: 2-4 specific questions the Friday testing answers. The highest-risk assumption from any prior Foundation Sprint becomes the lead question.
  3. Decider attendance windows: the load-bearing moments (Mon AM, Wed AM, Fri PM at minimum); fully blocked if available.
  4. Team roster with role assignments: who is in the room each day and what role each person plays through the week.
  5. Customer recruiting plan: target profile, source, count, incentive, recruiter owner, recruiting deadline, Friday schedule.
  6. Prototype medium decision: clickable, slideware, service role-play, paper, physical mock, or other; with rationale.
  7. Interview format: live or remote; moderated or unmoderated; recording and consent posture; observer-room setup.
  8. Logistics plan: dates, hours, location, format (in-person, remote, hybrid), tools, daily rhythm.
  9. Success criteria: observable outcomes that mark the sprint successful or not.

See references/TEMPLATE.md for the canonical structure and references/EXAMPLE.md for the Brainshelf book-catalog brief.

Inference Inputs

InputWhat the skill does with it
Readiness verdict and recommendations (from tool-design-sprint-readiness)Pulls the recommended attendees, customer recruiting plan, pre-sprint activities, and prototype medium proposal; flags any precondition that has not been closed
Challenge descriptionCompresses into the Challenge Statement and derives 2-4 sprint questions
Founding Hypothesis (optional; from a prior Foundation Sprint)The highest-risk assumption from the FS scorecard becomes the lead sprint question; the top bet becomes the design direction; the backup becomes the fallback decision if Friday invalidates
Team rosterMaps people to the required Design Sprint roles (Decider, Facilitator, PM, Design, Engineering, Researcher or Customer Expert); confirms 4-7 person band
Customer recruiting source and planLocks recruiter owner, target profile, source channel, honorarium budget, deadline, and Friday schedule
Format (in-person, remote, hybrid; per Ratified Decision 6)Branches the brief body where format affects authoring: recruiting plan (in-person requires geo-local cohort; remote allows cross-timezone), prototype medium (some media work better in-person; e.g., physical mock), interview format (live vs remote moderated), observer setup (in-room vs Zoom breakout room)
Logistics constraintsProduces the dates/hours/location/tools matrix; flags any constraint that would force the sprint to extend beyond 5 days or split across calendar weeks

Brief Length Discipline

The brief MUST fit on two pages (or two screens). The DS brief is intentionally longer than the FS brief because the customer-recruiting, prototype-medium, and interview-format sections have no FS equivalent and must be committed to before Monday.

  • Challenge Statement: one paragraph, four sentences maximum.
  • Sprint Questions: 2-4 numbered questions, each one sentence.
  • Team Roster: table with one row per person.
  • Customer Recruiting: table.
  • Prototype Medium: one paragraph including rationale.
  • Interview Format: one paragraph.
  • Logistics: table.
  • Success Criteria: 3-5 bulleted outcomes.

If the brief expands beyond two pages, the sprint is being over-engineered before it starts. The fix is not a longer brief; the fix is sharper sprint questions and a clearer prototype medium decision.

Common Pitfalls

  • Vague sprint questions. "Will users like it?" is not a sprint question. "Will 25+/year readers complete sub-3-second camera capture without abandoning?" is. Sprint questions must be answerable from Friday's 5-customer interviews.
  • Recruiting plan that does not match target customer. Recruiting from a panel that skews younger or different demographics than the named target produces Friday data that does not test the actual assumption. Cross-check recruiting source against the readiness customer profile.
  • Skipping prototype medium decision. Leaving prototype medium to Thursday morning forces the team into ad-hoc choice and risks the prototype not being testable Friday. Lock it in the brief; if needed, change it after Wednesday's storyboard but commit a default upfront.
  • Treating the brief as a stakeholder deliverable. Stakeholders read the Friday scorecard and the Decider's next-step memo, not the brief. Sharing the brief publicly invites pre-sprint debate, which the sprint is supposed to resolve.
  • Logistics drift. "We'll figure out remote vs in-person sometimes" telegraphs that the team has not committed. Either format is locked, or the readiness verdict was wrong.
  • No interview format decision. Friday interview moderator, observation-room setup, and recording/consent posture should be in the brief. Forgetting these is the most common cause of Friday running long.

Canonical Sources

  • Knapp, J., Zeratsky, J., and Kowitz, B. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon and Schuster, 2016. Chapter 3 "Set the Stage" on sprint brief composition.
  • Character Capital. "Design Sprint pre-sprint guide." https://www.character.vc
  • Google Design Sprint Kit. "Sprint brief template." https://designsprintkit.withgoogle.com/
  • AJ and Smart "Remote Design Sprint" template. Adapted for the remote and hybrid format sections.

Cross-Skill Usage

Prerequisites: tool-design-sprint-readiness. The brief expects the readiness output as its primary input. When prerequisites is honored, the brief inherits the readiness verdict, customer recruiting plan draft, attendee recommendations, and pre-sprint activities; the skill then refines and locks them.

If the team has done equivalent prep without running the readiness skill explicitly (e.g., experienced sprint facilitator who knows the readiness criteria), the brief skill can be invoked directly. In that case, the skill body prompts the team to confirm the readiness criteria are met before generating the brief.

A team coming from a Foundation Sprint should bring the Founding Hypothesis and assumption scorecard as inputs. The brief's Sprint Questions section pulls the highest-risk assumption verbatim as the lead question. No bridge skill is required; the narrative handoff is documented in _workflows/foundation-to-design.md.

Next invocation in the sprint: tool-design-sprint-map-and-target on Monday morning.

Decider Checkpoint

This skill ends with a Decider Checkpoint in references/TEMPLATE.md. The Decider signs off on scope (the challenge and sprint questions), team (the roster and attendance windows), recruiting plan (target profile, source, honorarium budget), prototype medium, interview format, and the explicit success criteria. Without sign-off, the brief is advisory; with sign-off, it is the contract for the next five days and the authorization for customer-recruiting spend.

FAQ

What does the tool-design-sprint-brief skill do?

Pre-sprint brief that locks challenge, sprint questions, team and role assignments, customer recruiting plan, prototype medium, interview format, logistics, and success criteria before Monday of a Design Sprint. Use after the readiness verdict is Go and before Monday begins. Produces a two-page artifact the team and Decider sign off on as the contract for the next five days.

How do I install tool-design-sprint-brief?

Run npx skills add https://github.com/product-on-purpose/pm-skills --skill tool-design-sprint-brief in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/tool-design-sprint-brief/ (personal) or .claude/skills/tool-design-sprint-brief/ (project).

Which AI agents can use tool-design-sprint-brief?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is tool-design-sprint-brief safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains tool-design-sprint-brief?

It is published by product-on-purpose in product-on-purpose/pm-skills. It has 620 recorded installs.

More from product-on-purpose/pm-skills

View all →

deliver-acceptance-criteria

product-on-purpose/pm-skills

Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.

Testing & QA1.1K installs

deliver-prd

product-on-purpose/pm-skills

Creates a comprehensive Product Requirements Document that aligns stakeholders on what to build, why, and how success will be measured. Use when specifying features, epics, or product initiatives for engineering handoff.

deliver-user-stories

product-on-purpose/pm-skills

Generates user stories in the standard persona, action, benefit story format from product requirements or feature descriptions. Use when breaking a feature into stories for sprint planning, writing tickets, or communicating scope to engineering. For testable Given/When/Then acceptance criteria on a story, use deliver-acceptance-criteria; for boundary and failure scenarios, use deliver-edge-cases.

deliver-edge-cases

product-on-purpose/pm-skills

Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.

Testing & QA878 installs

discover-competitive-analysis

product-on-purpose/pm-skills

Creates a structured competitive analysis comparing features, pricing, and positioning across 3-5 direct and indirect competitors, with a 2x2 map and actionable strategic recommendations. Use before entering a market, planning differentiation, or after losing deals. For market size rather than competitor positioning, use discover-market-sizing instead.

define-problem-statement

product-on-purpose/pm-skills

Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.

Business & Finance821 installs

Popular code quality & workflow skills

View category →

grill-me

mattpocock/skills

A relentless interview to sharpen a plan or design.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

handoff

mattpocock/skills

Compact the current conversation into a handoff document for another agent to pick up.

domain-modeling

mattpocock/skills

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.

codebase-design

mattpocock/skills

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

diagnosing-bugs

mattpocock/skills

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.