
tool-design-sprint-prototype-plan
Day 4 (Thursday) move of a Design Sprint that produces the planning artifact for the day. Output covers the prototype role plan (Maker, Stitcher, Writer, Asset Collector, Interviewer), prototype brief (what to build, fidelity bar, time allocation per role), canonical Five-Act Interview script (Welcome, Context, Intro, Tasks, Debrief), trial-run checklist, and Friday participant confirmation tracker. The actual prototype build is craft work outside the skill's AI invocation surface. Use Thursday morning after Wednesday's storyboard is signed off.
- Installs
- 623
- 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-prototype-plan- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads tool-design-sprint-prototype-plan automatically when relevant.
- 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.
Design Sprint Prototype Plan (Thursday morning)
Thursday is the prototype build day. This skill produces the morning planning artifact that makes the build run; it does NOT build the prototype itself. The skill assigns roles, locks the fidelity bar, drafts the Five-Act interview script, defines the trial-run gate, and confirms Friday participants. The actual building (Figma frames, slideware decks, role-play scripts, paper assemblies) is craft work the team owns through the rest of Thursday.
Family contract: docs/reference/skill-families/design-sprint-skills-contract.md. This skill is a member of design-sprint-skills.
When to Use
- It is Thursday morning of the Design Sprint and Wednesday's storyboard is signed off.
- The Friday participant tracker needs a Thursday-morning confirmation check; cancellations now trigger buffer activation.
- The interview script needs to be drafted (or refined from a prior sprint's template) before the interviewer can mock-run it Thursday afternoon.
- The team needs role assignments before parallel build work begins; ad-hoc assignment Thursday afternoon wastes 1-2 hours.
When NOT to Use
- Wednesday is not closed. Return to
tool-design-sprint-decide-and-storyboard; without a locked storyboard, the prototype has no spec. - The team is trying to use this skill to build the prototype. The prototype is craft work (per Ratified Decision 1 in the DS integration plan). This skill plans Thursday; the build happens in Figma, Keynote, paper, or whatever the medium is.
- The team has decided to skip Friday's trial run. Trial run is the gate that catches "prototype is unreachable" or "interview script confuses customer" before live interviews start. Skipping it converts Friday into a debugging session.
- Friday participant cancellations have triggered cohort-shrinks-to-fewer-than-4. Pause the sprint and decide whether to postpone Friday or accept a reduced-evidence test.
What This Skill Produces
A single bundled artifact with five sections:
- Prototype role plan: assigns 5 canonical roles (Maker, Stitcher, Writer, Asset Collector, Interviewer) across the team. Roles can double up on small teams; cannot triple up except for Asset Collector.
- Prototype brief: one-page spec covering what to build (storyboard panels in scope), fidelity bar (what "real enough" means for the medium), time allocation per role, and what's explicitly NOT being built.
- Interview script (Five-Act): canonical Five-Act structure (Welcome, Context, Intro, Tasks, Debrief) with team-supplied task wording derived from the storyboard. The act sequence is fixed; only Tasks is heavily customized.
- Trial-run checklist: the gates the prototype must pass Thursday afternoon (canonically 16:00-17:00) before Friday begins. Each gate is a yes/no item the interviewer or Maker confirms.
- Participant confirmation tracker: Thursday morning re-confirmation of all 5 Friday slots; cancellations trigger buffer-slot activation; failures cascade to a cohort-decision moment.
See references/TEMPLATE.md for the canonical structure and references/EXAMPLE.md for the Brainshelf book-catalog Thursday morning artifact.
Five Canonical Roles
Sprint book Chapter 16 defines these 5 roles. The skill assigns them; the humans fill them.
| Role | What they do | Typical owner |
|---|---|---|
| Maker | Builds the prototype surface (Figma frames, Keynote slides, role-play props). Owns visual and interaction work. | Design lead |
| Stitcher | Connects the Maker's surfaces into a coherent end-to-end flow (Figma interactions, Keynote transitions, role-play sequence). | Design lead OR engineering lead |
| Writer | Writes prototype copy (button labels, body text, error states, microcopy). Critical for credibility; bad copy breaks trust. | PM OR researcher |
| Asset Collector | Sources images, icons, sample data (book covers, names, dates, fake-but-believable data). | Anyone with free hands; often whoever isn't on the critical path. |
| Interviewer | Runs Friday's interviews. Spends Thursday afternoon drafting and mock-running the Five-Act script. | Researcher OR PM with interview experience. |
On a 4-person team, Maker and Stitcher typically merge (one design owner); Writer and Asset Collector can merge; Interviewer is always a dedicated role.
Five-Act Interview Structure
Canonical structure from Sprint book Chapter 17. The act sequence is fixed; the Tasks act is heavily customized; the other acts are mostly canonical wording.
| Act | Time | Purpose | Canonicality |
|---|---|---|---|
| Welcome | 5 min | Friendly intro; consent confirmation; explain not testing the customer | Canonical wording with team-name swap |
| Context | 5-10 min | Learn the customer's current behavior and context related to the challenge | Canonical questions; team adapts to challenge |
| Intro | 5 min | Introduce the prototype; explain it's a prototype (some things won't work) and ask the customer to think aloud | Canonical wording |
| Tasks | 20-30 min | Customer attempts the storyboard tasks; interviewer observes and probes; team observes silently from breakout room | Team-supplied wording derived from storyboard |
| Debrief | 5-10 min | Open-ended reactions; pricing questions if relevant; thank-you | Canonical structure; team adapts pricing question |
Common Pitfalls
- Treating the prototype as a deliverable instead of a learning tool. The prototype dies Friday at 17:00 PT regardless of how Friday goes. Investing engineering time in polishing it past the fidelity bar wastes Thursday.
- Polishing instead of building enough realism. Fidelity bar question: "Will a customer believe this is real for the 30-minute interview?" If yes, the prototype is done. Polishing past that point steals time from trial run and recovery.
- Interview script with leading questions. "Did you find the camera flow easy?" leads; "Walk me through what you just did" doesn't. Writer (or Interviewer) reviews script for leading questions before trial run.
- Skipping trial run. Trial run catches dead Figma links, missing assets, confusing copy, and interviewer-script-too-long failures. Always run with a fake customer (a teammate playing a target-profile customer) Thursday afternoon.
- Asset Collector role left unassigned because "it's not important." Asset Collector is the role that prevents "lorem ipsum on the demo screen" and "stock photo of a person who clearly isn't the target customer." Always assign.
- Five-Act Tasks act over-scripted. Tasks should be open-ended ("Try to capture this book and find it later in your library"); over-scripted tasks become a tutorial, not a test.
- Cancellations Thursday morning not surfaced because "we'll figure it out." Thursday morning is the last clean window to activate buffer participants. By Thursday afternoon, recruiter has lower confidence in confirmation.
Cross-Skill Usage
Prerequisites: tool-design-sprint-decide-and-storyboard. Prototype-plan consumes Wednesday's storyboard as the build spec. Without a storyboard, this skill has no panels to map roles against.
This skill does NOT invoke tool-note-and-vote. Thursday morning planning has no voting moment; the role plan and script decisions are Facilitator-led with Decider sign-off.
Next invocation in the sprint: tool-design-sprint-test-and-score Friday morning.
Canonical Sources
- Knapp, J., Zeratsky, J., and Kowitz, B. Sprint. Simon and Schuster, 2016. Thursday chapter (Chapters 14-16) and Five-Act Interview (Chapter 17).
- GV Design Sprint Guide. "Sprint Week Thursday." https://www.gv.com/sprint/
- Character Capital. "Design Sprint Day 4." https://www.character.vc
- Google Design Sprint Kit. "Thursday agenda template + Five-Act Interview script template." https://designsprintkit.withgoogle.com/
Decider Checkpoint
This skill ends with a Decider Checkpoint in references/TEMPLATE.md. The Decider approves the role plan, the fidelity bar in the prototype brief, the interview script's Tasks act, and the trial-run gate criteria. Once signed, the team disperses into parallel build work; the Decider returns Friday PM for the post-interview Decider review.
FAQ
What does the tool-design-sprint-prototype-plan skill do?
Day 4 (Thursday) move of a Design Sprint that produces the planning artifact for the day. Output covers the prototype role plan (Maker, Stitcher, Writer, Asset Collector, Interviewer), prototype brief (what to build, fidelity bar, time allocation per role), canonical Five-Act Interview script (Welcome, Context, Intro, Tasks, Debrief), trial-run checklist, and Friday participant confirmation tracker. The actual prototype build is craft work outside the skill's AI invocation surface. Use Thursday morning after Wednesday's storyboard is signed off.
How do I install tool-design-sprint-prototype-plan?
Run npx skills add https://github.com/product-on-purpose/pm-skills --skill tool-design-sprint-prototype-plan 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-prototype-plan/ (personal) or .claude/skills/tool-design-sprint-prototype-plan/ (project).
Which AI agents can use tool-design-sprint-prototype-plan?
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-prototype-plan 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-prototype-plan?
It is published by product-on-purpose in product-on-purpose/pm-skills. It has 623 recorded installs.
More from product-on-purpose/pm-skills
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.
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.
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.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
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.