記事公開日
Best Practices for Configuring AWS Kiro Steering
Key Points of This Article
This article explains design guidelines for maximizing the "Steering" feature of the AI assistance tool "AWS Kiro." Incorporating specific "correct vs. incorrect" validation examples from actual testing, we will introduce document creation techniques to improve AI response accuracy and three common anti-patterns to avoid.
- Improving Accuracy via "One Definition per File":
Splitting files by role—such as API standards or security—prevents AI confusion. Structuring files based on the "5 Recommended File Configurations" suggested in the official documentation directly leads to accurate responses (suppression of hallucinations). - Documenting Specific Constraints and Background (Why):
By clearly stating the implementation intent, such as specific values like "passwords must be 4+ characters" or the background for using localStorage, you can ensure consistent code output regardless of who provides the instructions. - Control via "Positive and Negative" Examples:
Utilize Markdown to present recommended code in contrast with non-recommended code (anti-patterns). Our verification proved that these definitions allow Kiro to accurately judge whether existing code complies with established rules.
Introduction
Hello. This is Goto from the DX Solution Sales Division.
I would like to explain the best practices for configuring Steering in AWS Kiro.
For those who want to know more about the Steering feature itself, please check out this article.
*The reference examples in this article are based on the ToDo list application created in the post below.
Best Practices for Configuring Steering
It is important to define steering files in a structure that is easy for the AI to understand.
Since existing design documents or proposals are written in a format easy for humans to read, they may be difficult for AI to interpret as-is. Therefore, please set your definitions with the following points in mind.
1 file for 1 definition item
Attempting to describe the project overview in too much detail often leads to redundancy. No matter how well you define it in Steering, an excessive amount of information can confuse the AI, making it difficult to guarantee accuracy.
Avoid consolidating all rules into one large file; instead, split files based on their specific roles.
Reference Examples
As a general steering file strategy, the official documentation recommends creating the following files. By splitting them into several files, the AI can more easily distinguish definitions and output higher-precision responses. Please refer to these when creating steering files at the start of your project.
・API Standards (api-standards.md)
Defines REST conventions, error response formats, authentication flows, and versioning strategies.
・Testing Approach (testing-standards.md)
Establishes unit test patterns, integration test strategies, and coverage expectations.
・Code Style (code-conventions.md)
Specifies naming patterns, file organization, and architectural decisions.
・Security Guidelines (security-policies.md)
Documents authentication requirements, data validation rules, and vulnerability prevention.
・Deployment Process (deployment-workflow.md)
Outlines build steps, environment configurations, and deployment procedures.
● For official documentation on Steering, please refer to the following:
Ensuring Specificity in Documentation
Kiro generates predicted responses based on Steering rules. Do not use abstract language in definitions; ensure everything is explicitly stated. For the AI to provide accurate information, documents must be presented concretely to ensure consistent responses regardless of who gives the instructions.
Reference Example
Here is an example definition for password constraints to be referenced when creating user login scripts.
File name: "passwordrule.md"
--- inclusion: fileMatch fileMatch: ["script.js"] --- # Specific Constraints for Authentication Logic ## 1. Input Validation - **Constraint**: Require at least 3 characters for the username and at least 4 characters for the password. - **Alert**: If conditions are not met, display "Please enter at least 3 characters for the username" and "Please enter at least 4 characters for the password" in Japanese. - **Background (Benefit)**: To prevent invalid data from being saved to localStorage and avoid app crashes caused by data integrity errors. ## 2. Behavior on Login Failure - **Condition**: If the username does not exist or the password does not match. - **Action**: 1. Display an alert saying "Incorrect username or password." 2. Clear the value of the password input field (`loginPassword`). 3. Move focus to `loginPassword`. - **Background (Benefit)**: To clearly inform the user what went wrong while ensuring they can immediately re-enter data without compromising UX (usability). ## 3. Security: Password Handling - **Constraint**: Always use the `hashPassword` method during registration and verification; do not compare or store raw passwords. - **Background (Benefit)**: Based on the steering security policy, this protects user privacy even if localStorage data is accessed.
Point 1: Avoid Abstract Expressions
Point 2: Document the Background of Definitions
By documenting the background of implementation, the AI can grasp the project's nature, workflow, and rules, thereby increasing the accuracy of its responses. It also provides the benefit of making it easier to share project definitions when working in a team.Providing "Correct" and "Incorrect" Code Examples
Leverage the features of Markdown to present specific code examples. This configuration makes it easier for the AI to output code in the correct format. It allows the AI to better judge what kind of response is required.
Reference Example
Definition settings for storage key usage and saving methods.
File name: "storagekeyrule.md"
---
inclusion: fileMatch
fileMatch: ["script.js"]
---
# Storage Management Correct/Incorrect Examples
## 1. User-Specific Data Separation
- **Rule**: localStorage keys must always be retrieved via `this.storageKeys`, with the username appended to the end.
### ✕ Incorrect (Negative Example)
```javascript
// Reason: Using a fixed key name will mix data with other users
const data = localStorage.getItem('todoTasks');
// Recommended: Dynamically use keys per user authenticated by AuthManager
this.storageKeys = {
tasks: `todoTasks_${username}`,
deletedTasks: `todoDeletedTasks_${username}`
};
// When calling
const savedTasks = localStorage.getItem(this.storageKeys.tasks);
```
Point 1: Clearly State Code Examples
By presenting correct and incorrect code, the AI will understand the developer's intent and check it when creating scripts.
The following blog post verifies the created Steering in action. Please check it out!
Anti-patterns to Avoid
Next, let's discuss anti-patterns. Using settings like the ones below will prevent you from maximizing AWS Kiro's performance and lead to unstable responses.
Inclusion of Confidential Information
Avoid writing confidential data directly in Steering. Since the AI uses Steering as a base for code generation, there is a risk of unintentionally including sensitive data.
To prevent accidental information leaks, always ensure that important data is entered manually!
As a countermeasure, it may be effective to create a Security Policy Steering file and have it checked after every execution.
Mixing Steering with Fluctuating Tasks
Do not write progress on ongoing tasks or temporary work notes into Steering! Steering is for describing "permanent constraints."
Separate fluctuating task information into tasks.md or Specifications (Specs) to prevent AI confusion.
Not Updating Steering
As development progresses, it is common for initially decided designs or libraries to change. If steering file content remains outdated (for example, containing deprecated function names or old specifications), the AI will generate incorrect code based on "old rules," leading to unexpected errors or regressions.
Therefore, update Steering regularly to ensure it always contains the latest information!
As a countermeasure, always review relevant steering files whenever new features are added or refactoring is performed. Example: Check and update at the following times.
- Review during sprint planning and architecture changes
- Reference test files after restructuring
- Treat steering changes like code changes and make reviews mandatory
Summary
What did you think? In this post, we explained the best practices for AWS Kiro Steering. The Steering feature is extremely convenient for maintaining consistency across an entire project. However, neglecting settings can actually degrade the work performance. Follow these best practices to get the most out of Kiro!
↓ QES will continue to actively share information about Kiro, so please stay tuned!
** We aim to become Japan's #1 resource for Kiro! Our mission is to evangelize this technology by empowering end-users with top-tier education and technical support. **
If you have requests such as "I want to know more about this service" or "Support for AWS environment construction and migration," please feel free to contact us via our Contact Form. Also, check out the following links!
＜QES Related Solutions/Blogs＞
＜The AWS Security Promotion Consortium, in which QES participates, has released a white paper＞
※ Amazon Web Services, the ”Powered by Amazon Web Services” logo, and other AWS trademarks used in the blog are trademarks of Amazon.com, Inc. or its affiliates.
