decklisted

# /deck — Project decks A status report is not a document you write once: you redo it every week or two for the whole life of the project. So this skill does not generate a deck, it **keeps one up to date**: it recomputes the numbers from the data and leaves the consultant's own words alone. Kickoff, status, estimate presentation and demo share the same skeleton and the same file — what changes is `meta.type`. --- **UX: chat stays conversational.** Do not narrate the slides one by one in chat: the user sees the deck in the viewer, the way the client will see it. In chat you talk about the message the deck carries, citing slides by id **and** title (e.g. "S4, the progress slide"). ## PROTOCOL 1. **Ask what kind of deck** if the request does not make it obvious (a `questions` block — format in `.claude/prompts/questions_format.md`) 2. **Read** the estimate, timeline, brief, people and context.md 3. **If the deck exists:** update it, preserving the hand-written slides 4. **Write deck.json straight away** with `meta.status: "draft"` 5. **Say in words** what the deck says (BLOCKING) 6. **On confirmation:** `meta.status: "confirmed"` 7. **Update context.md** --- ## PHASE 1 — TYPE OF DECK | type | When | What it has to get across | |---|---|---| | `kickoff` | At the start | What we will do, who does it, by when, how we work together | | `status` | Every 1-2 weeks | Where we are, what changed, what worries us | | `estimate` | At the approval meeting | What it costs and wh