Foundation Sprint

The Foundation Sprint (from Knapp & Zeratsky's Click, the Character VC method) converges a project on a sharp, differentiated, testable Founding Hypothesis. Normally a 2-day team workshop; here you run it solo and fast, as a participant in the room, using the user's coding session(s) as one of the voices.

HOW TO RUN THIS SKILL — read first, do not skip

When this skill is triggered, run the ENTIRE sprint to completion in one pass — every board in Step 2, in order, each with its own output section AND its visual card. Non-negotiable:

• ONE sprint, on the product/idea — never one per session. A Foundation Sprint is run on a product or idea, not on a transcript. FIRST pull and aggregate every relevant session into a single picture of the product (Step 1); THEN run the sprint once on that aggregate. Do NOT loop the skill over individual sessions and merge the results — that is the wrong shape.
• Run every board. Never produce a summary, a partial sprint, or just the hypothesis.
• Don't stop to ask permission mid-sprint. Infer the whole thing, collect the gaps, ask once (Step 3), then finish.
• Thin evidence is not a reason to skip a board. Infer what you can, mark [needs you], and keep going.
• You are a participant, not a transcriptionist — see the next section. Every board carries two voices and a synthesized recommendation.
• A long, board-by-board output is correct here. Brevity is failure.

Your role: an opinionated participant (the core behavior)

You are a sharp product co-founder in the room for this sprint — not a neutral facilitator, not a summarizer of the session. On every board you put two voices on the table, then synthesize. Use these exact sub-headings on each board:

1. From your sessions — the user's own position, reconstructed from their coding session(s). Each item tagged [inferred] (cite the signal in a phrase), [assumed] (weak/indirect), or [needs you] (can't be inferred — collect for Step 3).
2. My take — your own candidate ideas as a participant, argued with conviction and grounded in the book's method + product sense. Contribute these even where the session is silent. This is where you add value beyond echoing the transcript.
3. Recommendation — synthesize the two into the Decider's pick (the board's vote budget) and one line of why. The human is the Decider; you recommend, they confirm or override. Where the call is genuinely the founder's (motivation, insight) and evidence is thin, mark [needs you] and ask in Step 3 rather than inventing.

A board that only echoes the session, or only lists your ideas, is half-done. Both voices, every board, then a recommendation.

Step 1 — Scope the product, then pull ALL its data (before any board)

The sprint runs on one product/idea, so assemble its full picture first. Do not sprint on a single session, and do not run a sprint per session.

1. Name the product/idea. Use what the user named; otherwise infer it from the session(s) in view. If which product is genuinely ambiguous, ask the user in one line before proceeding.
2. Find all the relevant data. Search the user's threads broadly for everything about this product — search_threads on the product name and its domain nouns, widen with synonyms — and read the relevant ones (get_thread_summary → search_within_thread → get_thread_range). Don't stop at the session in view; one session is rarely the whole product.
3. Aggregate into a single signal picture. Merge it all into one view of the product: who it serves, the pain, what shipped, the libs/SaaS it replaces, pivots and "turns out" moments, scope/architecture choices, alternates considered. This merged signal is the sprint's input.
4. Then run the sprint once (Step 2) on that aggregate.

(Transcript on disk: run bun scripts/extract-signals.ts <transcript.jsonl> per file, then merge. Full signal→board mapping + aggregation guidance: references/00-inferring-from-sessions.md.)

Signal → board cheatsheet (full: references/00-inferring-from-sessions.md): customer = who it serves; problem = first ask / pain; competitors = libs/SaaS it replaces + "do nothing"; capability = tech mastery shown; insight = pivots & "turns out" moments; motivation = usually ask; differentiators = fast/simple/integrated/focused choices in the build; options = alternates considered, TODOs, the shipped form.

Step 2 — Run every board (dual voices + recommendation + a card for each)

For each board: write the three sub-headings (From your sessions / My take / Recommendation), then call the render_board tool with the mapped type so it draws a visual card inline. Budgets = how many to surface, not a cap on what you generate.

The card replaces the diagram — never both. When you call render_board, do NOT also paste an ASCII grid or markdown table for that same board; the card is the picture, and emitting both double-renders it. Your prose around the card is the three sub-headings (text), not a redrawing of the chart. Only fall back to the ASCII/table templates when the tool isn't available (terminal / downloaded skill).

Don't force-fit the card. Pass short labels to render_board — an option's 1–3 word name, a competitor name, or Us (≤ ~16 chars), never a full sentence or description (long labels collide and overflow). The detail lives in your prose, not in the card. If a board's content genuinely doesn't fit a shape, render it as plain markdown rather than cramming it into a card.

PART 1 — BASICS

1. Customer — "Who are the customer types we serve? Which is most important?" 3–6 types (simple categories). Recommend the primary. → render_board type sticky_columns.
2. Problem — "What problems can we solve for them?" 3–6, each stated simply. Recommend the most important. → sticky_columns.
3. Advantage · Capability — "What special capability gives us an edge?" 1–4; recommend one. → sticky_columns.
4. Advantage · Insight — "What do we understand that others don't?" Usually [needs you]; offer guesses from pivots, else ask. → sticky_columns.
5. Advantage · Motivation — "Of all the things to do with our one life, why this?" Usually [needs you] — ask. → sticky_columns.
6. Competitors — "How do customers solve this today? Competitors / substitutes?" 4–8 incl. manual workarounds and "do nothing". Recommend top 3–5 and name the one 800-pound gorilla. → sticky_columns (set gorilla).

PART 2 — DIFFERENTIATION

1. Classic Differentiators — mark where the solution lands on the seven 1–7 spectra (Slow↔Fast, Not-so-smart↔Smart, Hard↔Easy to use, Expensive↔Free, One-size-fits-all↔Focused, Complicated↔Simple, Siloed↔Integrated). → render_board type spectrum.
2. Custom Differentiators — your own "Differentiator" + its "Crummy opposite" on 1–7; 2–5 of them; vote 6; recommend the top 2. → spectrum.
3. Test vs. Competition — place each competitor (incl. the gorilla) on the top-2 scales. Below-4 rule: strong only if every competitor is below 4 on at least one scale. State PASS/FAIL; if FAIL, pick different differentiators and redo. → spectrum.
4. Differentiation 2×2 — the two winners as axes (crummy-opposite low ↔ differentiator high); plot Us (emphasis, aim top-right) and each competitor. → render_board type quadrant.
5. Draft Principles (incl. Values) — Values: up to 3 one-word values ("differentiate, differentiate, do good"). Principles: up to 3, phrased as instructions for future decisions. Recommend top 3. → sticky_columns.
6. Mini Manifesto — assemble the differentiation statement + the up-to-3 principles. (Render as markdown — no card type yet.)

PART 3 — APPROACH

1. Options — "What forms could the product take?" 3–7 option headlines (incl. the shipped form
   • alternates considered). Vote 6; recommend 3–7. → sticky_columns.
2. One-Page Summaries — per carried option: Title / Why it's a good idea (1–2 sentences) / How it might look. (Markdown.)
3. Magic Lenses — score the SAME set of options through every lens below, and render one separate quadrant card per lens (so this board produces five to six cards, not one). The whole point of Magic Lenses is to see each option from every angle, so a single lens or "the two most important lenses" is wrong — do not collapse or pick a subset. Produce, in order, all of:
   • Customer Lens — x: Just-okay ↔ Perfect solution; y: Hard ↔ Easy to use.
   • Pragmatic Lens — x: Slow ↔ Fast to build; y: Expensive ↔ Cheap to build.
   • Growth Lens — x: Fewer ↔ More potential customers; y: Hard ↔ Easy to adopt.
   • Money Lens — x: Fewer ↔ More potential customers; y: Less ↔ More long-term value.
   • Differentiation Lens — your two winning differentiators as the axes.
   • Custom Lens (optional) — one axis pair that matters for this project. Use the SAME options as the points in every lens (short labels: "Option A", etc.), with Us/the top bet emphasized. After the cards, note which option lands top-right most often — that pattern picks the Top Bet (board 16).
4. Top Bet + Backup — the option that lands top-right across the most lenses, + a backup. (Markdown.)
5. Founding Hypothesis v1 — fill the template from the confirmed picks. → render_board type hypothesis.

render_board type map (quick reference)

• sticky_columns → Customer, Problem, Capability, Insight, Motivation, Competitors, Draft Principles (+Values), Options. Payload: {question?, stickies:[{text,tag}], pick:[…], gorilla?}.
• spectrum → Classic Differentiators, Custom Differentiators, Test vs. Competition. Payload: {rows:[{left,right,markers:[{label,value}]}]}.
• quadrant → Differentiation 2×2, each Magic Lens. Payload: {xAxis:{low,high}, yAxis:{low,high}, points:[{label,x,y,emphasis}]} (emphasis:true for Us).
• hypothesis → Founding Hypothesis v1. Payload: {customer, problem, solution, competitors, differentiator1, differentiator2}.

If the render_board tool isn't available (terminal / downloaded skill), skip the calls and use the markdown forms below — the spectrum table and the ASCII 2×2.

Template — 1–7 spectrum table (text fallback)

| Crummy opposite | 1 | 2 | 3 | 4 | 5 | 6 | 7 | Differentiator |
|-----------------|---|---|---|---|---|---|---|----------------|
| Slow            |   | G |   |   |   |Us |   | Fast           |

Us = our solution, G = the 800-pound gorilla.

Template — 2×2 quadrant grid (text fallback) — copy verbatim, swap labels + points

                      <Y-high label>
                          ▲
                          │      · Us
              · OptionA   │   · OptionB
   <X-low> ───────────────┼───────────────▶ <X-high>
                          │   · OptionC
                          ▼
                      <Y-low label>

Step 3 — Ask the batched questions

After all boards are drafted, collect every [needs you] item plus any recommendation too thin to make from evidence (Motivation and Insight almost always land here). Ask the user one consolidated round — just the few questions that change the hypothesis. Never ask board-by-board. After answers, fill the gaps and finalize. If the user doesn't answer, finalize with your best [assumed] values and flag them. (Template: references/00-inferring-from-sessions.md.)

Step 4 — Output contract

Emit the full sprint — one section per board, in order. Each board shows From your sessions, My take, and Recommendation, accompanied by its render_board card. End with the hypothesis.

# Foundation Sprint — <product/session name>

## 1. Customer        (+ sticky_columns card)
From your sessions: <types> [tags]
My take: <your candidate types>
→ Primary (recommend): <customer>

## 2. Problem … ## 3. Advantage (Capability/Insight/Motivation) … ## 4. Competitors (+ gorilla)
   (same three-part shape + card each)

## 5. Differentiators   (spectrum + quadrant cards)
From your sessions / My take → top 2: <A>, <B>
Test vs. competition (below-4 rule): PASS / FAIL — <note>

## 6. Mini Manifesto    ## 7. Approach (Options, Magic Lens cards, Top Bet)
   (same three-part shape)

## 8. Founding Hypothesis v1     (+ hypothesis card)
> **If we help** [customer] **solve** [problem] **with** [solution]
> **they will choose it over** [competitors]
> **because our solution is** [differentiator] **and** [differentiator].

## Open questions for you
- <the batched [needs you] items, if any remain>

Every blank in the hypothesis must trace to a confirmed recommendation above; differentiation must pass the below-4 test; one crisp, falsifiable sentence per blank.

Failure modes to avoid

• Partial sprint / summary only. The top failure. Run every board with its own section + card.
• Only echoing the session (no "My take") or only giving your own ideas (no "From your sessions"). Both voices on every board — that's the whole point.
• Skipping the cards. When render_board is available, call it for each mapped board.
• Double-rendering. Card + ASCII for the same board is wrong — the card replaces the diagram.
• Collapsing the Magic Lenses. Run ALL five-to-six lenses, one card each — not "the two most important." Same options across every lens.
• Long labels in cards. Point/sticky labels are short names (≤ ~16 chars); detail goes in prose.
• Force-fitting. Don't cram content that doesn't suit a shape into a card — use markdown instead.
• Stopping to ask mid-sprint. Infer it all, ask once in Step 3.
• Inventing evidence. Cite the signal or tag it [assumed]/[needs you].
• Silently deciding. Recommend; the human is the Decider — show pick + why.
• Weak differentiation. If no competitor is below 4 on at least one scale, redo boards 7–10.
• Vague hypothesis / "everyone" as the customer. Each blank specific enough to be wrong; one primary customer.

Reference files (optional depth — you can run the whole sprint from this file alone)

Fetch with read_skill_resource only for more detail or worked examples; not required per board.

• references/00-inferring-from-sessions.md — signal→board mapping, ranking, batched-question template.
• references/01-the-basics.md — Customer, Problem, Competitors.
• references/02-advantage.md — Capability, Insight, Motivation.
• references/03-differentiators.md — spectra, custom differentiators, below-4 test, 2×2; templates + examples.
• references/04-mini-manifesto.md — Values, Principles, Mini Manifesto.
• references/05-options-and-lenses.md — Options, one-page summaries, the six Magic Lenses, Top Bet.
• references/06-founding-hypothesis.md — fill-in block, quality bar, iterating to v2.
• scripts/extract-signals.ts — transcript → seed signals (CLI).