AI agent workflow

DESIGN.md for Kiro

Kiro structures AI development around specs, steering files, and hooks. That structure makes design memory more important, not less. DESIGN.md gives Kiro a visual brief alongside product requirements: color roles, spacing, density, component behavior, page patterns, and anti-patterns that keep generated frontend work aligned with your design system.

Pair DESIGN.md with Kiro specs

Kiro specs define what a feature should do. DESIGN.md defines how it should look. Before starting a UI feature, ask Kiro to read both files and include visual acceptance criteria in the spec: color roles, layout density, responsive behavior, empty states, and form behavior. This turns design taste into reviewable implementation tasks rather than chat-only guidance that is forgotten when the session ends.

What to include for Kiro workflows

For Kiro, the most useful DESIGN.md is specific and well-organized. Include product mood, semantic color roles, type scale, spacing rhythm, radius scale, page patterns, component behavior, and anti-patterns. If your project uses Tailwind, shadcn, or custom tokens, map design rules to the actual classes or variables Kiro will use in implementation. Keep the file short enough that Kiro reads all of it — 100 to 300 lines is a practical target.

Start here

Move from this landing page into deeper DESIGN.md references, examples, and guides.

Frequently asked questions

What is DESIGN.md for Kiro?

DESIGN.md is a visual instruction file that Kiro reads alongside product specs. It defines color roles, spacing, typography, component behavior, and anti-patterns so Kiro-generated frontend work follows your product design system instead of generic defaults.

How do I use DESIGN.md with Kiro specs?

Keep DESIGN.md in your repo root alongside AGENTS.md. When creating a Kiro spec for a UI feature, reference DESIGN.md and ask Kiro to include visual acceptance criteria: layout density, color roles, responsive rules, and empty states. This makes design expectations part of the spec rather than post-implementation corrections.

What should a Kiro-ready DESIGN.md include?

Product mood, semantic color roles, type scale, spacing rhythm, component variants with usage rules, page-level patterns for dashboard, settings, and form surfaces, and an anti-pattern list. Map design rules to Tailwind classes or CSS variables so Kiro can apply them directly in generated code.

Search the catalog