Kiro works from specs. You describe a feature, it plans the work, then it builds. That structure is genuinely useful, and it has one gap: a spec describes behavior, not appearance.
Steering files close the gap.
What steering does
Kiro reads Markdown files from .kiro/steering/ in your project and treats them as persistent project knowledge. They apply across spec generation and implementation, so a rule you write once shapes every task that follows.
Each file can carry a front matter block controlling when it is included. The default is always, which is what a design contract wants.
The setup
Put DESIGN.md in your repository root. Then create .kiro/steering/design-system.md:
---
inclusion: always
---
# Design system
The visual contract for this product is DESIGN.md in the repository root.
Read it before writing any component, screen, or style, and before generating
any UI-related spec.
Rules:
- Colors, spacing, radius, and typography come only from DESIGN.md tokens.
- Component states and density follow the component rules in DESIGN.md.
- Do not introduce a new font, shadow, or gradient.
- If DESIGN.md does not define what you need, raise it in the spec instead of guessing.You can also reference the file directly so Kiro pulls its contents rather than relying on the path alone:
#[[file:DESIGN.md]]That syntax embeds the file in the steering context. Useful when your DESIGN.md is short and you want it fully present.
Scope it to UI work
Here is a nice touch for bigger repos. Instead of always, you can attach the steering file to matching paths:
---
inclusion: fileMatch
fileMatchPattern: "src/components/**"
---Now the design contract loads when Kiro touches components and stays out of the way during data-layer work.
Verify it worked
Ask Kiro to draft a spec for a small UI feature, then read the plan before approving it.
Write a spec for a settings page with a form and a save bar.
Reference the exact DESIGN.md tokens each element should use.A good result names tokens. A plan that says "use consistent spacing" means the steering file is not landing, so check the folder path and the front matter.
Common mistakes
- Putting DESIGN.md inside `.kiro/steering/`. It works, but then only Kiro can see it. Root placement keeps it usable by Cursor, Claude Code, and Copilot too.
- Writing steering as background information. Steering works best as instructions. "Use only DESIGN.md tokens" beats "our design is minimal".
- Approving specs without reading them. The spec step is where a design mistake is cheapest to catch. Use it.
What this means for you
Kiro's spec-first flow is an advantage here. Design rules enter the process before any code exists, which is the earliest possible point to catch drift.
Add the steering file once and every future spec inherits it. If you need a DESIGN.md to start from, the library has documented systems you can adapt.