Show the state.
AI work is never a blank spinner.
AI-NATIVE DESIGN SYSTEM · 01
Design for what can think, act, and ask.
A system for AI products that earn trust through evidence, control, and recovery.
Explore the systemInstall Ayodhya's skills →EIGHT PRINCIPLES
Ask at the edge.
Infer routine context. Verify risk.
Keep control human.
Preview effects before commitment.
Ground the answer.
Attach evidence to every claim.
Make recovery useful.
Failure leaves a useful next step.
Design the whole lifecycle.
Follow work from intent to outcome.
Accessible before intelligent.
Access is a foundation, not a feature.
Compose, don't surprise.
New capability must preserve familiar control.
FOUNDATIONS
Editorial hierarchy.
Operational control.
A 4px spacing base, a responsive 12-column grid, clear state language, 44px touch targets, and type that stays readable under pressure.
Evidence before interface.
Display stays above 28px. Body copy remains a neutral grotesk. Mono is reserved for tokens, values, and provenance.
TOKENS · REFERENCE → SEMANTIC → COMPONENT
Name the role, not the paint.
ayodhya.{category}.{role}.{state}.{variant}
#0B0907#17120F#F3EEE5#B9AFA2#D8AD63#A77932#5F725F#A34732#32658ASemantic AI roles include thinking, acting, evidence, approval, uncertainty, and stale. Gold is brand and editorial emphasis only. State never depends on color alone.
Machine-readable tokens →SIX FLAGSHIP COMPONENTS
State, evidence, authority, recovery.
Button
One clear action with every state visible.
Beta · owner Ayodhya · reviewed Sep 2026Field
Input, help, validation, and recovery in one reading order.
Beta · owner Ayodhya · reviewed Sep 2026Streaming response
Readable progress with pause and stop.
Beta · owner Ayodhya · reviewed Sep 2026Tool call
What ran, why, evidence, outcome, and recovery.
Beta · owner Ayodhya · reviewed Sep 2026Approval gate
Human authority at the edge of an effect.
Beta · owner Ayodhya · reviewed Sep 2026Evidence chip
Source, freshness, and access in compact form.
Beta · owner Ayodhya · reviewed Sep 2026AI STATE MODEL
Never collapse the system into one confidence color.
- System state
- idle · thinking · acting · done · failed
- Evidence state
- grounded · partial · absent · stale
- Authority state
- observe · draft · approve · execute
- Recoverability
- undo · retry · correct · take over
- Connectivity
- live · delayed · offline
ACCESSIBILITY PROMISE
Accessible before intelligent.
WCAG 2.2 AA is the baseline: keyboard paths, 2px focus indicators, semantic HTML, batched streaming announcements, no focus theft, 400% zoom, 320px reflow, reduced motion, forced colors, RTL, and 30-50% language expansion.
KeyboardVoiceOver / NVDA / TalkBackReduced motionForced colors
BOOKMARKS · 8 BOOKMARKED SYSTEMS
Ayodhya's favourite design systems.
Systems I use to test the completeness of this one - tokens, components, language, accessibility, and the discipline to keep them coherent.
For keeping one product language coherent across platforms without forcing sameness.
Multi-platform coherenceOpen system ↗For pairing a precise token system with component guidance you can inspect, test, and use.
Open, inspectable craftOpen system ↗For treating agent-ready documentation and customization as part of the system, not an integration added later.
Agent-ready by designOpen system ↗Open the Astryx library in Figma ↗
Designer's kits · 1
Open the Astryx library in Figma ↗For a token architecture that can scale without losing intent.
Token architectureOpen system ↗For keeping the Figma library, component states, local variables, and implementation aligned one to one.
Design-to-code parityOpen system ↗For adaptive theming when one language must flex across contexts.
Adaptive themingOpen system ↗For product guidance that gives a component judgment, not only anatomy.
Product guidanceOpen system ↗For governance that keeps consistency alive through scale and time.
Governance at scaleOpen system ↗Studied, not copied. Ayodhya builds on the discipline, then defines its own AI-native rules.
FOR AGENTS · BETA FOUNDATION
Give agents the rules, not screenshots.
Read, validate, and compose from versioned tokens, component contracts, patterns, and scenarios. This is an agent-ready foundation until reconstruction and version-pinning acceptance pass.
Use the Ayodhya design system for this interface. Read the manifest and the pattern/component schemas needed for the task. Compose only from declared components and semantic tokens. Report unsupported needs and deviations. Do not publish or change the system.
AGENT DESIGN SKILLS · 11 STUDIED
Agent design skills.
The skills, guardrails, and workspaces I study to keep agent-made interfaces specific, usable, and true to their product.
Featured review stack
7UI prompting skillactive
Design-first UI prompting
Meng To · MIT- type direction
- image and crop
- rhythm
- variation
Why it is here
For specifying type, image, crop, rhythm, and variation before the model reaches for a template.
Prompt like a system, not a moodboard.Interface audit skillactive
Hallmark
Nutlope · MIT- audit
- redesign
- review
- improve
Why it is here
For giving an agent clear verbs to inspect and improve a rendered interface.
Critique must lead to a changeAgent skill and commandsactive
Impeccable
Paul Bakaus · Apache-2.0- 1 skill
- 23 commands
- 61 detector rules
Why it is here
For turning aesthetic critique into explicit commands and detector rules.
Taste needs an operational vocabularyInteraction skill collectionactive
Skills for Designers and Engineers
Emil Kowalski · MIT- emil-design-eng
- animate
- review animations
- improve animations
- animation vocabulary
Why it is here
For translating interaction craft into a shared vocabulary designers, engineers, and agents can act on.
Polish needs shared language1 related
Source repository ↗Aesthetic guardrailv2 experimental
Taste Skill
Leonxlnx · MIT- taste constraints
- anti-slop critique
Why it is here
For making aesthetic constraints visible before generic interface habits take over.
Guardrails before decoration1 related
Source repository ↗UI quality skill setactive
UI Skills
Ibelick · MIT- baseline-ui
- improve-ui
- fixing-accessibility
Why it is here
For turning spacing, hierarchy, interaction, and accessibility into a repeatable finishing pass.
Taste needs a quality floor.1 related
Source repository ↗Browser quality skill setactive
Web Quality Skills
Addy Osmani · MIT- performance
- accessibility
- browser evidence
Why it is here
For proving the finished interface works in the browser, not only in the design review.
A beautiful screen still has to survive evidence.Foundations & workspaces
2Agent skill
Frontend Design
Anthropic- frontend design
- visual judgment
Why it is here
The baseline that made visual judgment portable inside a coding-agent workflow.
Portable visual judgmentLocal-first design workspaceactive
OpenDesign
nexu-io · Apache-2.0- design context
- agent collaboration
Why it is here
For keeping product design context local, legible, and close to the work.
Context belongs beside the product1 related
Source repository ↗Reference library
2Anti-slop skill familyactive
Scoville
Benjamin Stelzer · MIT- design critique
- UI critique
- code critique
- writing critique
Why it is here
For separating visual, implementation, and writing guardrails without pretending they are the same job.
Specific critique beats one generic scoreDesign reasoning skillv2.0
UI UX Pro Max
Next Level Builder · MIT- 192 reasoning rules
- 119 UX guidelines
- 74 font pairings
Why it is here
For exposing a wide design reasoning surface an agent can consult before it renders.
Breadth still needs product judgmentPEOPLE IN DESIGN · 1 FOLLOWED
People I follow in design.
Designers and design engineers whose work sharpens how I think about systems, interaction, and craft.
Emil Kowalski
Design Engineer · Linear- motion
- interaction
- design engineering
For the care he brings to how interfaces move, feel, and behave - and for making that judgment legible to designers and engineers.
WHAT TO STUDYPurposeful motion, timing and easing, interaction detail, and the bridge between design judgment and production code.
GOVERNANCE
Open by evidence, not by claim.
Draft → beta → stable → deprecated. Tokens and components use semantic versions, owners, review dates, changelogs, migration notes, RFCs, and visual checks at desktop, 390px, and forced colors.