How to Create Steering Files for AWS Kiro from Architecture Models
This is one possible extension idea for teams that want to experiment with architecture-derived Kiro guidance. The environment, specification blocks and output format would need to be adapted to the project.
AWS Kiro uses persistent Markdown steering files to give its agent knowledge about a workspace. The files can describe product context, technology choices, project structure, coding standards, testing practices and architecture decisions.
Kiro supports workspace steering files under .kiro/steering/, including foundational files such as product.md, tech.md and structure.md. It also supports focused guidance that is always included, loaded for matching files, requested manually, or selected automatically from a description. See the Kiro steering documentation for the current file conventions.
The useful question for iSecureByDesign users is: which parts of the architecture should become Kiro guidance for this project?
A model-driven workflow
An environment configured for steering-file output can use the following workflow:
1. Model the components, connections and boundaries.
2. Add specification blocks for product, technology, structure, security and testing guidance.
3. Apply the controls that are relevant to the selected components.
4. Generate the requirements specification.
5. Use an output prompt configured for Kiro Markdown and inclusion modes.
6. Export focused files into .kiro/steering/.
For example, a database component might produce a focused Kiro file requiring the approved data-access layer, encryption, authorization checks and tests for denied access. An API component might produce file-matched guidance for route handlers and integration tests.
The important distinction is between the source and the format. The architecture and policy choices determine what guidance applies; the output prompt formats that guidance for Kiro.
Keep Kiro steering focused
Do not put every organisational policy into every steering file. Use always-included files for core project context, file-matched files for technology or directory-specific rules, and manual or automatic guidance for specialist workflows.
This is a practical form of Executable Context: the agent receives the architecture and policy context relevant to the work rather than an undifferentiated policy library.
iSecureByDesign users can explore this by extending a diagram environment with Kiro-specific specification blocks and an output prompt. The steering-files workflow article explains the broader extension model.
Related Reading
About Agentic Thoughts: This Agentic Thought was generated with AI. Agentic Thoughts are part of an ongoing process of evolving ideas about iSecureByDesign and how it may be applied to real-world problems. They are exploratory and do not necessarily represent a final product commitment, implementation, or formal advice.