Architect → design on the slidey repo
An architect picks up the published slidey speaker-notes PRD and authors the design — epic, slices, ADRs, and a mermaid data-flow — all conversation-driven, no LLM.
Phase 2 of the slidey dev-story hybrid: the architect half. Carrying the published speaker-notes-export PRD into design intake, an architect reviews the requirements, refines the brief conversationally (name the notes collector, the CLI seam in src/index.js, the per-scene Markdown shape), and the design author writes a slidey runtime design — an epic, three implementation slices, two ADRs, and a mermaid spec→collectNotes→renderNotesMarkdown→out.md data-flow — published to docs/proposals/speaker-notes-export.md with a feature ticket auto-minted at issues/features/. 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
Phase 1 published the speaker-notes-export PRD on the slidey repo. Now an architect carries it into design — talking it into an epic, slices, ADRs, and a mermaid data-flow, no LLM in the loop. This session opens already at the published PRD, ready for the design handoff.
This is slidey-dev: kitsoki's dev-story hub pointed at the real slidey checkout. The published PRD sits at docs/prd/speaker-notes-export.md; the design will land at docs/proposals/speaker-notes-export.md.
Click New session. The run opens already at the published-PRD handoff — the design phase's starting line — so the architect picks up exactly where phase 1 left off.
The architect's session opens on the published speaker-notes-export PRD — phase 1's validated output, sitting at docs/prd/speaker-notes-export.md in the slidey tree. `continue` carries it into the design phase, seeded with a pointer to the PRD so the design author reads it as prior art, not a blank slate.
The architect opens the design conversation grounded in the PRD: realize the speaker-notes-export PRD as a slidey runtime design. The intake scaffolds a brief from the published requirements.
Full recorded walkthrough (8 steps)
Design has its own clarification loop. A refiner flags the gaps — name the notes collector and its seam in src/index.js, specify the per-scene Markdown shape — and the architect reworks the brief in the chat. A quality check then gates the brief before the author drafts, the same iterative shaping the PRD did with questions.
The brief passes the quality gate and the design author writes the full slidey runtime design: an epic (a spec-derived per-scene handout), three slices (a pure collectNotes(spec), the --notes CLI seam, a Markdown emitter), a mermaid spec→collectNotes→renderNotesMarkdown→out.md data-flow, and two ADRs (reuse the scene model so notes never drift; keep the transform pure and LLM-free).
Accept publishes the design to the slidey tree at docs/proposals/speaker-notes-export.md and auto-mints a feature ticket at issues/features/F-<timestamp>-speaker-notes-export.md, linking back to the design — the implementation pipeline can pick it up immediately. That's phase 2: a published PRD, talked into a slidey design with an epic, slices, ADRs, and a mermaid diagram, all conversation-driven, no LLM in the loop.
Phase 2 of the slidey dev-story hybrid: architect → design epic/slices/ADRs. The design is grounded in slidey's real shape — a pure spec→notes collector reusing the same scene model the Vue components consume, wired into the existing CLI output branches.