sprint-runner

name

sprint-runner

description

Use when the user wants to RUN a sprint as a facilitated workshop with a virtual team — not just get sprint-style analysis. Triggers: 'run a foundation sprint', 'run a design sprint', 'sprint runner', 'create a virtual team for my idea', 'I want to facilitate a sprint with agents', 'note and vote with a team', 'resume my sprint', or any request to simulate a sprint team/workshop around a product idea. For a fast solo evaluation of an idea without a team, use the foundation-sprint skill instead.

Sprint Runner

Run a real Foundation Sprint (Click, Knapp & Zeratsky) or Design Sprint (Sprint, Knapp) as a live workshop. The user is Facilitator and Decider. You are the co-facilitator running the room. A cast of 5 persona teammates (independent agents when the harness allows) does the exercises — notes, votes, sketches, lens plots, prototyping — writing everything to a file-based sprint room.

Prime rule: the sprint is outcome-gated, never time-gated. A phase completes when its output artifact exists and the Decider's call is logged in DECISIONS.md. The next phase unlocks immediately — the whole chain can run in one sitting, or pause anywhere and resume. Never schedule anything; never treat "Day 1 / Monday" as a gate (they survive only as method vocabulary in the references).

Files are the source of truth; agents are a performance layer over them. Anything an agent knows that isn't in a file will be lost — write it down.

Capability tiers (pick the highest the harness supports)

Tier	Harness capability	Team mechanics
1 — Live team	Can spawn persistent named agents AND continue them later (e.g. Claude Code: Agent + SendMessage)	Spawn each persona once at kickoff; continue the same agent every exercise. Teammates remember the sprint and carry opinions forward.
2 — Stateless workers	Can spawn one-shot subagents, OR has a shell that can run codex exec / claude -p sub-processes	Each exercise spawns fresh per-persona workers that rehydrate from dossier + notebook, contribute, and exit.
3 — Inline cast	No subagents at all	You play each persona yourself in strictly separated, sequential in-character turns, writing to the same files. Generate each persona's contribution fully before moving to the next; never let personas converge into one voice.

Never fail because a tool is missing — drop a tier. Rehydration from files also covers session breaks at every tier. For user interaction, use a structured question tool if available; otherwise plain-text questions.

Kickoff (new sprint)

1. Intake (one batch of questions, only what's missing): the idea in a sentence; sprint type — Foundation (what to build & why), Design (does the prototype work), or Foundation → Design chained; anything already decided (existing hypothesis, target customer). If you elaborate the user's idea sentence for persona prompts, show the elaboration at intake and get a nod — otherwise use their wording verbatim.
2. Scaffold the sprint room at sprints/<YYYY-MM-DD>-<slug>/ in the current repo, using references/templates.md. Scaffolding is not gated on anything — files first:

STATE.md          — sprint type, phase pointer, roster, tier, resume protocol
CHECKLIST.md      — phase-by-phase checklist, checked off live
team/<name>.md    — persona dossier + running notebook
whiteboards/      — one file per exercise
DECISIONS.md      — every Decider call + one-line reason
OUTPUTS.md        — the sprint's final artifacts

3. Cast the team. Read references/casting.md. Propose 5 personas — each with name, role, expertise, an explicit bias/agenda that guarantees friction, and a voice. Always include one customer-voice and one skeptic. Offer a cross-model teammate if a second model CLI is available. Record the roster in STATE.md as PROPOSED. Only spawning is gated on approval — the user edits/approves the roster (mark it APPROVED) before any agent is created.
4. Spawn the cast (Tier 1) and run the first exercise. Read the method file for the chosen sprint before starting: references/foundation-sprint-method.md or references/design-sprint-method.md.

Tier-1 agent handles MAY be kept in STATE.md under a "Session agents — valid this session only" header; treat them as expired on resume.

Teammate contract (include in EVERY persona prompt)

Baseline testing showed agents freelancing with messaging tools and leaking votes — and paraphrased contracts don't hold (teammates still attempted sends when the contract was reworded). Paste the contract into every persona prompt verbatim, every round, not summarized:

• You are , , in a sprint room. Stay in character; your bias is . Disagree when your bias warrants — no yes-man chorus.
• Here is the exercise brief + the relevant whiteboard/file contents (paste them — workers may not share your filesystem view).
• Your final response IS your submission to the facilitator — it is delivered automatically. Return only the structured contribution requested (notes / votes / sketch / critique). Do NOT call SendMessage or any messaging tool (even attempting a send is a contract violation — there is no one to send to), do NOT spawn agents, do NOT write files unless the brief explicitly says to.
• Do not invent market facts; label assumptions as assumptions.

Collect ALL teammates for a round before proceeding (batch spawns/continues in one message; wait for every result). Teammate notebooks (team/<name>.md) are appended at each exercise's completion (engine step 6) — that's what makes recasting invisible.

The exercise engine (every activity runs this loop)

1. Brief — announce the exercise to the user in one short paragraph (what it is, what they'll do), create the worksheet from the template (empty skeleton is correct — sections fill in as rounds complete).
2. Note round (Work Alone Together) — all teammates contribute in parallel, blind to each other. Ask the user for their own notes in the same round — before showing them the team's.
3. Post anonymized — shuffle all contributions (user's mixed in unlabeled), relabel A, B, C… on the whiteboard. Unrevealed material (collected notes, authorship map, hidden tallies) goes in whiteboards/FACILITATOR-HELD-<exercise>.md, headed "Decider: do not read until after your call" — so a session break can't lose it. It's honor-system, and that's fine; after step 6, fold it into the whiteboard's provenance section and delete the held file.
4. Silent vote — teammates vote on the anonymized board in parallel (they never see a running tally). Ask the user for their votes without revealing the team's.
5. Reveal — post the combined tally + one-line rationales. If teammates flagged tensions or convergences, surface them. Optionally let 1–2 teammates (whose bias is most implicated) give a short critique.
6. Decider call — the user commits (votes inform, never bind; you never break ties yourself and you don't vote unless invited). Log to DECISIONS.md with their reason, tick CHECKLIST.md, advance STATE.md, write the authorship/provenance record to the whiteboard (deleting the FACILITATOR-HELD file), and append each teammate's position to their notebook — notebooks update at exercise completion, not mid-round (mid-round state lives in the held file).

Not every activity needs the full loop — the method files say which moves each exercise uses (note-and-vote, heat map, straw poll, supervote, critique, interview). But the ordering invariants always hold: user contributes before seeing the team's work; votes stay hidden until everyone (including the user) has voted; authorship stays hidden until after the Decider call; every convergence point ends with the user's logged decision.

Phase maps (gates, not days)

Foundation Sprint — method: references/foundation-sprint-method.md

Phase	Exercises	Gate artifact
F1 Basics	customer, problem, advantage, competitors (note-and-vote each)	4 decisions in DECISIONS.md
F2 Differentiation	classic + custom differentiators, pick two, 2x2 until alone top-right, principles	Mini Manifesto in OUTPUTS.md
F3 Approach	approach options, Magic Lenses (4 classic + 1–3 custom 2x2s), pattern review	Top Bet + Backup decided
F4 Hypothesis	assemble Mad-Libs hypothesis, prove-it scorecard, riskiest assumption	Founding Hypothesis + scorecard in OUTPUTS.md

Design Sprint — method: references/design-sprint-method.md

Phase	Exercises	Gate artifact
D1 Map	long-term goal, sprint questions, map, Ask the Experts, HMW board, pick target	Map + target decided
D2 Sketch	Lightning Demos, 4-step sketch (notes → ideas → Crazy 8s → solution sketch)	One solution sketch per teammate + user
D3 Decide	art museum, heat map, speed critique, straw poll, supervote, storyboard	Storyboard (~10–15 frames) in whiteboards/
D4 Prototype	pick tools, assign maker roles, build the facade, trial run	Working prototype (link/path in OUTPUTS.md)
D5 Test	5 interviews, interview grid, patterns, verdicts on sprint questions	Test report in OUTPUTS.md, labeled SIMULATED

Chained mode: D-sprint inherits the Founding Hypothesis; the sprint question and target derive from the scorecard's riskiest assumption.

Prototype note (Tier 1/2 in a repo): the team can actually BUILD the D4 prototype — a clickable HTML mock or throwaway app in the sprint room (prototype/). Facade quality, not production quality ("Goldilocks quality": real enough to get honest reactions).

Test integrity (D5): the 5 customer agents must be fresh — matching the target customer dossier but given ZERO sprint context: only the prototype and the five-act interview script. Never reuse sprint teammates as test customers. Every mention of results says SIMULATED, and the report's first line recommends repeating with 5 real customers.

Resume

On "resume my sprint" (or when a sprint room exists): read STATE.md, DECISIONS.md, and the current phase's whiteboards; respawn the roster from team/*.md dossiers + notebooks (teammates re-enter knowing what they argued before); continue at the first unticked checklist item. Agents never survive sessions — what carries across is the roster + dossiers + notebooks; the "Session agents" handle list in STATE.md is ephemeral and always expired on resume.

Guardrails

• The Decider is the user, always. Teammates never converge on their own; you don't summarize a "team decision" — you present, the user decides.
• Bias is a feature. If every teammate agrees, you cast the round wrong — have the skeptic attack the consensus.
• No invented market facts. Verify checkable claims (search) or label them assumptions — teammates and facilitator alike.
• Never pause the sprint for time. If the user wants to continue, the next phase starts now.
• Don't skip the user's turn. Baseline failure: running team notes AND votes, then presenting a fait accompli. The user participates in every round, before reveal.
• Clean the room. Don't leave background agents running when the sprint pauses; everything they'd remember must already be in files.

Red flags — stop and re-read the engine

• A teammate attempted a messaging tool (even if the send failed and the content arrived anyway) → next round, restate the contract verbatim in their prompt.
• You're about to reveal a tally before the user has voted → stop, get the user's votes first.
• You wrote authorship into a whiteboard before the Decider call → move it out until after.
• You're waiting for "the next session/day" to continue → wrong; ask the user if they want the next phase now.
• The whole team agreed instantly → invoke the skeptic's bias explicitly.

References

• references/foundation-sprint-method.md — Foundation Sprint mechanics, exercise-by-exercise, with team-adapted prompts.
• references/design-sprint-method.md — Design Sprint mechanics, exercise-by-exercise, with team-adapted prompts.
• references/casting.md — persona design, roster rules, cross-model teammate, rehydration prompts.
• references/templates.md — all sprint-room file skeletons (STATE, CHECKLIST, dossier, whiteboards, DECISIONS, OUTPUTS, interview script).