MCPInstall

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
  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-prototype-plan 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 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

RoleWhat they doTypical owner
MakerBuilds the prototype surface (Figma frames, Keynote slides, role-play props). Owns visual and interaction work.Design lead
StitcherConnects the Maker's surfaces into a coherent end-to-end flow (Figma interactions, Keynote transitions, role-play sequence).Design lead OR engineering lead
WriterWrites prototype copy (button labels, body text, error states, microcopy). Critical for credibility; bad copy breaks trust.PM OR researcher
Asset CollectorSources images, icons, sample data (book covers, names, dates, fake-but-believable data).Anyone with free hands; often whoever isn't on the critical path.
InterviewerRuns 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.

ActTimePurposeCanonicality
Welcome5 minFriendly intro; consent confirmation; explain not testing the customerCanonical wording with team-name swap
Context5-10 minLearn the customer's current behavior and context related to the challengeCanonical questions; team adapts to challenge
Intro5 minIntroduce the prototype; explain it's a prototype (some things won't work) and ask the customer to think aloudCanonical wording
Tasks20-30 minCustomer attempts the storyboard tasks; interviewer observes and probes; team observes silently from breakout roomTeam-supplied wording derived from storyboard
Debrief5-10 minOpen-ended reactions; pricing questions if relevant; thank-youCanonical 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

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

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.