Steering Kiro with .kiro/steering
Duration: 5 min
Steering files are persistent instructions that Kiro reads on every interaction. They let you encode project-wide conventions, constraints, and preferences so you don't have to repeat them in every prompt.
What steering files do
Without steering, you might write 'use TypeScript strict mode, Zod for validation, and never use any' in every prompt. With a steering file, you write it once and Kiro applies it automatically to everything it generates in your project.
# Project Conventions
## Language & Types
- TypeScript strict mode. Never use `any` — use `unknown` and narrow.
- Zod for all runtime validation (request bodies, env vars, API responses)
- No default exports — named exports only
## Error Handling
- All async functions must handle errors explicitly
- Use Result<T, E> pattern from neverthrow, not try/catch
- Log errors with structured JSON using pino
## Testing
- Vitest for unit tests, Supertest for integration tests
- Test files live next to source files: foo.ts → foo.test.ts
- Minimum 80% coverage on new files
## Style
- 2-space indent, single quotes, no semicolons
- Run prettier before committingSteering file types
You can have multiple steering files for different concerns:
- conventions.md — coding style and patterns
- architecture.md — system design decisions and constraints
- security.md — security rules (never log PII, always sanitise inputs)
- product.md — product context (who the users are, what they care about)
💡 Tip: Steering files are checked into git. New team members and new AI sessions both get the same context automatically — no onboarding doc needed.
Conditional steering
Steering files can be scoped to specific file patterns. A steering file with a glob of src/api/** only applies when Kiro is working on API files, keeping context focused and relevant.
❓ What is the main benefit of using .kiro/steering files?