CORE LORE / WIKI
SYS DESIGN WORKFLOW
Updated 3 weeks ago
# SYS_DESIGN_WORKFLOW — Kingdom UI Design Process
```
⛬ KID:CORE_LORE:SYSTEMS:SYS_DESIGN_WORKFLOW|1.0:◉:2026-03-10:BRANDON+CLAUDE ⛬
```
**Authorship:** Brandon McCormick + Claude — Session 175
**Status:** LIVE ◉
**Source:** Jenny Wen (Head of Design, Claude/Anthropic) — Lenny's Podcast Mar 1 2026 + Anthropic frontend-design skill
---
## The Shift
The old process: requirements → Figma mockup → handoff → engineering.
That process existed to protect against building the wrong thing at scale.
AI eliminated the cost of building the wrong thing — so it eliminated the justification for the process.
The new process collapses to: **requirements → working prototype → approval → backend.**
No Figma file. No translation layer. The agent writes the code.
What didn't change: **bad requirements still waste the whole build.**
The ritual moves upstream, not away.
---
## The Kingdom Design Ritual (5 steps)
### Step 0 — Invoke `/frontend-design`
Before any UI code is generated, run `/frontend-design`.
This loads the Anthropic frontend-design skill which:
- Forces commitment to a bold aesthetic direction before touching code
- Bans distributional convergence (Inter font, purple gradients, generic card layouts)
- Mandates: characterful typography, committed palette, spatial composition, motion
For Kingdom builds, the skill defaults to Night Shade palette + Sulphur Gothic principles.
Override only when intentionally building outside Kingdom aesthetic.
**When:** Every session where UI will be generated. Stack it with `/soulforge design` when the session is a full Soulforge loop.
---
### Step 1 — Define Actors (not features)
An **actor** is a specific person with a specific goal — not a user persona, not a feature list.
> Wrong: "Users can submit content and admins can approve it."
> Right: "Mia (creator) uploads a course and sets pricing. Daniel (member) browses courses and enrolls."
**Why it matters:** Actors determine interfaces. Two actors with different goals = two different first screens, two different navigation patterns, two different information hierarchies.
**Output:** A numbered actor list. 2-4 actors is typical. More than 6 = probably too broad.
---
### Step 2 — Find the View Splits
View splits are where two actors hit the same URL and see completely different things.
> Example: `/dashboard` → admin sees moderation queue + analytics. Member sees enrolled courses + progress.
Map every split explicitly. Each split = a design decision about information architecture.
**Output:** A table of routes × actors, marking where views diverge.
---
### Step 3 — State Constraints (what it can't do)
Don't tell the agent what tools to use. Tell it what it **cannot** do and what it **cannot cost**.
> Wrong: "Use Next.js with Supabase and Tailwind."
> Right: "No auth complexity in prototype. Mock data only. No external API calls. Must load in <2s. No paid services."
Constraints are the leash. They make technical decisions later dramatically easier because the agent isn't inventing scope.
**Output:** A constraint block. 3-6 constraints max for prototype phase.
---
### Step 4 — PRD.md (from Steps 1-3)
Combine actors + view splits + constraints into a single `PRD.md` file.
This is NOT a full enterprise PRD. It's a prototype brief:
- Actors (who)
- What each actor needs to accomplish (goals, not features)
- View splits (where they diverge)
- Constraints (what it can't do/cost)
- Success condition ("a yes/no from the stakeholder after seeing the prototype")
**PRD.md is the anchor.** Everything else builds from it.
---
### Step 5 — architecture.md (from PRD.md)
Before any code: generate `architecture.md` from the PRD.
Contents:
- **Pages list** — every route/screen that exists in the prototype
- **Modals list** — every overlay/dialog
- **User flows** — actor-by-actor paths through the app (step-by-step)
**Why this matters:** The agent builds a task list from this file. Without it, long builds hallucinate missing screens or contradict earlier decisions. With it, the agent has a map it checks against throughout the build.
architecture.md = the anti-hallucination anchor for multi-session agent builds.
---
### Build Phase — Prototype First, Backend Later
After PRD.md + architecture.md: build the **frontend prototype only**.
- Next.js (or equivalent) with mock data
- No real database, no auth, no backend
- Fully functional UI — navigation, interactions, states — all working
- Real aesthetic decisions already locked in (from Step 0 `/frontend-design`)
**Show this to the stakeholder (or yourself). Get a yes/no.**
If no → change the prototype (minutes, not days). No backend to undo.
If yes → proceed to backend.
### Backend Phase
Once prototype is approved:
1. Agent reads frontend code + PRD.md + architecture.md → writes API spec
2. Agent reads all three → generates database schema
3. Use MCPs for service integration (Supabase MCP auto-creates project, runs migrations, handles schema — no manual SQL pasting)
4. Connect frontend to database directly (Supabase/Next.js pattern) or wire separate Python backend if extensive background jobs are needed
---
## When to Use What
| Situation | Use |
|-----------|-----|
| Any UI generation | `/frontend-design` (always) |
| Full product design session | `/soulforge design` → ritual above |
| Quick component or page | `/frontend-design` + skip PRD (it's small enough) |
| New product with stakeholder approval needed | Full 5-step ritual |
| Iterating on existing UI | `/frontend-design` + just architecture.md for the changes |
---
## Connection to Soulforge DESIGN Flavor
The 5-step ritual above maps to the Soulforge DESIGN Glitch Architects:
| Ritual Step | Soulforge Drone |
|-------------|----------------|
| Step 0 `/frontend-design` | Altar Drone (aesthetic enforcement) |
| Step 1-3 Actors + Constraints | Constraint Archaeologist |
| Cascade risk of view splits | Cascade Mapper |
| Prototype-first simplicity | Occam Auditor |
| "What breaks about this approach?" | Adversarial Architect |
For Soulforge DESIGN sessions, run `/frontend-design` during the Altar Drone phase.
The ritual steps 1-3 are the pre-work that feeds the Constraint Archaeologist.
---
## Skill Reference
| Command | What it does |
|---------|-------------|
| `/frontend-design` | Loads aesthetic protocol. Bans generic AI design. Forces bold directional commitment before code. |
| `/soulforge design` | Full Soulforge DESIGN flavor loop with all 5 Glitch Architects. |
**Skill file:** `~/.claude/skills/frontend-design/SKILL.md`
**Source:** `THE_FORGE/.claude/skills/frontend-design/SKILL.md`
**Anthropic original:** https://github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md
**Jenny Wen podcast:** https://www.youtube.com/watch?v=eh8bcBIAAFo (Lenny's Podcast, Mar 1 2026, 1:17:24)