How We Build · Design

The Design Method

Prompt-driven, step-by-step, collaborator-agnostic. The standing method plus the current prompt package: Round 1 — Outside the Field.

← Kiduna — home Surfaces Orchestration Foundation Protocol Organizations Actions Roles Sentinel Legal Institutions Integrations
One prompt per session, in order. Self-contained packages. Permanent personas: Alice, Bob, Carol, David. Vocabulary is canonical or it's a question.

Design work runs as a series of prompts, executed step by step, one screen or flow at a time — written so any AI collaborator (Claude Code, Codex, or another) can execute them without house context. This page is the standing method; the current prompt package lives in design-prompts/. The product foundation every Studio and Live design works from is the Studio + Live Working Design Brief — the shared product model, surface responsibilities, non-negotiable principles, and the KDN decision log. It does not define screens; it defines what screens must honor.

The rules of the method:

  1. Every prompt package is a self-executing operating order: README.md, AGENTS.md, CLAUDE.md, and 00_START_HERE.md all carry the same imperative — you are executing, not reviewing; begin Prompt 1 immediately; the only acceptable first question is a missing file — and PASTE-THIS.txt holds the kickoff line the human pastes with the zip (chat tools read nothing until told). Also: a CANON-BRIEF.md carrying the controlling vocabulary travels with the prompts; the live design system (kiduna-studio-enamel.motodave.chatgpt.site) and the current-screens zip are referenced explicitly; the Kiduna Kit is the deep reference. Never assume the collaborator knows anything.
  2. Prompts are separated and ordered. One prompt per session. Later prompts consume earlier deliverables (the persona bible feeds every screen). Each prompt names its deliverables as files, versioned — never loose output in chat.
  3. The general design system is settled — inside the Field and outside. Prompts fine-tune screens toward buildable precision; they do not restyle. Espresso ground, Avenir body, Goudy display, sky interactions, restrained mint, gold only for Deliberate acts.
  4. The four Personas are permanent: Alice, Bob, Carol, Danny (lineage: Alice→Bob, Carol→Danny), with durable backstories, Code Names, conversational styles with Ki, invite trees, and Resources profiles. All screens are developed against them; background characters may vary, the four do not. Every important workflow is evaluated against all four patterns: Alice inspects before acting; Bob talks before summarizing; Carol explores before confirming an exact version; Danny prepares, verifies, and then commits (the brief §6 carries their full commitments and failure risks).
  5. Vocabulary is canonical or it's a question. The taxonomy governs; new words go back to Moto, never into a mock.
  6. Moto reviews each prompt's output before the next runs — same markup loop as the spec process (brackets in, folded, versioned).
  7. Results feed the kit: accepted design outputs and their fixtures enter the Kiduna Kit so engineering, design, and canon never diverge; every design turn ends with "Taxonomy updated" or "No taxonomy change," per the taxonomy impact rule.

The Studio UI system is Enamel (v0.5, 2026-07-22) — the controlling visual canon for Studio: a three-layer world where the Field is lacquer (near-black deep umber, engraved arcs, no atmospheric gradients), Realms are celestial enamel vessels (warm metal rims, dark cores, one semantic type hue, inlaid geometric crests, localized halos, labels that travel), and Allies are people — stable identities across four contextual moods (Open · Engaged · Focused · Dreaming), with camel + moon-cream identity rings and no permanent prominence advantage. Material rules: enamel deep and tactile; highlights moon cream; wire and rims camel and sun gold; dimension from material hierarchy, never glossy 3D. The recomposable system: emblems · connection grammar · talismans · background geometry, with tokens and an acceptance checklist. The full canon docs are on this site; the complete packs (Enamel v0.5 with its working website, and the broader Kiduna Design System with fonts, allies, icons, talismans, crests, and realm emblems) are in downloads (design system). The design system itself was refreshed 2026-07-26 — the same system, extended: the full brand + Studio + Live token set and preview cards (Ally medallions, Realm emblems, connection grammar, talismans, Field ground, Ki panel, Live glyphs/mobile/tablet), the allies generation system, deck templates, and the business card — installed sitewide in _ds/.

The sibling method for specifications is the spec-design process. Together they are how we build from within.