PM idea → PRD on the slidey repo
A product manager talks a real slidey feature — a `--notes` speaker-notes export — from a one-line idea into a published PRD, no LLM in the loop.
The dev-story PRD discovery pipeline pointed at the real slidey repo (a Node/Vue narrated-deck renderer), via the slidey-dev instance (imports @kitsoki/dev-story as core). A product manager starts with one idea — a `slidey deck.json --notes out.md` flag that exports a printable per-scene speaker-notes handout from the same deck spec the video/PDF/web outputs share — and the pipeline shapes it through discovery, a prior-art scan, structured clarification (actor + success metric), and a drafted PRD, published to docs/prd/speaker-notes-export.md. Every beat is a deterministic state-machine step replayed from slidey-themed stubs — no real LLM, no API cost.
Can a Kitsoki story model a realistic repo workflow?
The handoffs between rooms, operator decisions, host calls, and replayed results.
The workflow is replayed from fixtures instead of improvised for the site.
An interactive clip from the kitsoki story deck — replayed from a real run, no LLM. Open full-screen →
Key beats
A product manager has an idea for the slidey deck renderer: export a printable per-scene speaker-notes handout straight from the deck spec — a `slidey deck.json --notes out.md` flag, alongside the video, PDF, and web outputs. This tour walks that idea into a published PRD on the real slidey repo, no LLM in the loop.
This is slidey-dev: kitsoki's dev-story hub pointed at the real slidey checkout. PRDs land in the slidey tree at docs/prd/<slug>.md. We'll author the speaker-notes-export PRD here.
Click New session to start a fresh run of the hub against slidey. It opens in the chat, on the engineer's-day landing.
`prd` opens a discovery conversation, not a form. The PM pitches the feature in their own words — a per-scene notes handout exported from the deck spec — and the interviewer sharpens it into a crisp problem statement before any questions or drafting begin.
Before a single question, kitsoki scouts slidey's existing outputs and proposals for overlap. The scan comes back clean — a net-new spec-derived output alongside video, PDF, and web. `confirm` carries it into the clarification round.
Full recorded walkthrough (9 steps)
Discovery isn't one-shot. A structured clarification round asks the questions that most change the PRD — who's the actor (presenters rehearsing a talk), and the success metric (decks exported to notes without rendering a full video). The PM answers in the chat, and the accumulated Q&A becomes the PRD's grounding.
With clarification settled and the prior-art scan done, the author writes the speaker-notes-export PRD into a per-session workspace and surfaces it right here — problem, target users, goals, requirements, and the open question. Accept publishes it.
The PRD is published to the real slidey tree at docs/prd/speaker-notes-export.md — a validated output the architect can pick up next. That's phase 1: a PM's one-line idea, talked into a grounded PRD on the slidey repo, with no LLM in the render loop.
A PRD isn't only prose. The PRD phase also produces a mockup of the feature — a printable per-scene speaker-notes handout — and kitsoki embeds it right in the run: a self-contained deck booted inline in the handoff room. The PM sees exactly what the feature looks like before a line of it is built, no separate renderer and no LLM.
Phase 1 of the slidey dev-story hybrid: idea → PRD + mockup. The slidey feature is real and small — a spec-derived speaker-notes export alongside slidey's existing video/PDF/web outputs — so the PRD content is grounded in what slidey actually does.