kickoff-doc

# Kickoff Document from Transcript Turn a kickoff call transcript into a builder-facing reference document for a shaped project. --- ## Before You Start Ask the user: 1. **Who is the primary audience?** (Usually the builder who will implement the work.) 2. **What other inputs are there?** (Visuals, screenshots, mockups, breadboards from the session.) The transcript is your source material. The document is NOT a summary of the call — it's a **map of the territory** that was shaped. --- ## Organizing Principle: Territory, Not Timeline A kickoff transcript is sequential — people talk through things in the order they come up, circle back, go on tangents, get sidetracked by browser issues. Your job is to reconstruct the **territory they were describing**, not replay the conversation. **Organize by the thing being built.** Each section should describe one area of the system fully — so the builder can look up "how does the Criteria tab work?" and find everything in one place. **Do NOT organize by build sequence.** If the team identified slices (a sequence of vertical slices to build in order), those are managed separately — not in this document. --- ## Structure The document has two top-level sections: **Frame** and **Shape**. Both are `##` headings. Their subsections are `###`. ### 1. Frame (`## Frame`) The strategic context and boundary conditions. This is NOT fluff — the builder needs this to make judgment calls when they hit ambiguity. - `### Problem` — Why this project, why now. What's broken or missing. - `### Outcome` — The specific outcomes expected. What success looks like. ### 2. Shape (`## Shape`) One `###` section per area of the system. For each area, describe: - What it is and what's on the screen (affordances, components, data displayed) - How it relates to other areas - Design decisions that belong to THIS area — inline, not in a separate section - Edge cases or flags that were called out - What's temporary/placeholder vs. what's a real commitment **Do NOT include a Build Sequence section.** Slices are tracked separately from this document. --- ## Voice: Use Their Words The document is a record of shared understanding from the kickoff call. ### Do - Use the actual words and phrases people used on the call - Synthesize scattered discussion into clearer form (taking something said across several turns and stating it cleanly) - Capture the reasoning people gave for decisions ("we're doing X because Y") ### Don't - Put new ideas or conclusions in people's mouths - Add motivational framing they didn't express ("each piece is a foundation, not a throwaway") - Editorialize about importance or quality beyond what was said ### The Test For every sentence, you should be able to point to a moment in the transcript where someone said it or clearly meant it. If you can't, either cut it or flag it as your own synthesis. **Exception:** Editorializing that clarifies or synthesizes what was said IS fine. "The criteria screen is how filtering is expressed in the new world" — nobody said that exact sentence, but it accurately captures a point made across several turns. That's the job: make scattered discussion legible without adding your own conclusions. --- ## Design Decisions: Vertical, Not Horizontal Do NOT create a grab-bag "Design Decisions" section. Instead, put each decision inline in the section where it matters. - "Matches stored in DB not Redis" → goes in the section about matching - "Candidates must be materialized before attachment" → goes in the section about attaching - "Per-ICP match data as value objects" → goes in the section about match results If a decision only matters when building one specific area, it belongs in that area's section. The builder shouldn't have to cross-reference a separate decisions list while working on a specific screen. --- ## Process 1. **Read the full transcript.** Don't start writing after reading part of it. 2. **Identify the areas of the system** that were discussed — these become your `###` sections under `## Shape`. 3. **Draft the Frame** (`## Frame` with `### Problem` and `### Outcome`) from the framing/outcomes discussion (usually near the start of the call). 4. **Write each Shape section** (`### ...`), pulling from wherever in the transcript that area was discussed. A single section may draw from moments scattered across the whole call. 5. **Place design decisions inline** in the section they belong to. 6. **Review against the transcript** — can you point to where each claim was said?