# Sprint Runner > 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. - Skill: `sanky369/sprint-runner` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds add sanky369/sprint-runner` - Raw SKILL.md: https://api.skillmd.com/api/skills/sanky369/sprint-runner/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: sanky369 (https://skillmd.com/u/sanky369) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/sanky369/sprint-runner --- # 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/-/` 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/.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/.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-.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).