Building Production-Ready Agents with Kiro: Steering, Powers, Hooks, Specs, and Skills
Learn how Kiro's five core features work together to give AI agents persistent context, on-demand tooling, and automated guardrails with a real-time fraud detection walkthrough for financial services.
The Developer's Guide to Kiro: Steering, Powers, Hooks, Specs, and Skills
How Kiro's five pillars work together to take you from prototype to production
AI code editors have changed how developers build software. But most of them optimize for the same thing: generating code faster. The gap between a working prototype and a production system remains wide. Requirements are fuzzy, conventions drift across a team, and the decisions an AI agent made during a session disappear the moment the chat window closes.
Kiro takes a different approach. Built on Code OSS and compatible with VS Code extensions, Kiro is an agentic IDE that introduces structure where other tools leave you freestyling. Five features — steering, powers, hooks, specs, and skills — form an integrated system that gives AI agents the persistent context, specialized knowledge, and automated guardrails they need to produce code that is ready for production, not just ready for a demo.
This post walks through each feature, explains how they relate to one another, and shows you how to put them to work.
Specs: Think first, build second
Most AI coding tools start and end with a prompt. You describe what you want, the agent writes code, and you hope the output matches your intent. Kiro specs flip this workflow. Instead of jumping straight to implementation, specs guide you through a structured planning process that produces artifacts you can review, share with your team, and use to hold the agent accountable.
The spec workflow has three phases:
Requirements. You provide a single prompt — something like "Add a review system for products." Kiro expands that into user stories, each with acceptance criteria written in EARS (Easy Approach to Requirements Syntax) notation. Edge cases, error states, and authorization rules surface here rather than during code review three days later. The result is a markdown document that captures what the agent assumed about your request, making those assumptions explicit and reviewable.
Design. Kiro analyzes your codebase alongside the approved requirements and generates a technical design: data flow diagrams, TypeScript interfaces, database schemas, API endpoint definitions, and component hierarchies. This is the blueprint that prevents the agent from making architectural decisions you would have caught in a design review.
Tasks. The design breaks down into sequenced, dependency-aware tasks and sub-tasks. Each task links back to the requirement it satisfies and includes details like unit tests, integration tests, loading states, and accessibility considerations. You execute tasks one at a time, reviewing diffs and agent history at each step.
Specs stay in sync with your codebase. When you modify code, you can ask Kiro to update the spec, or you can update the spec manually and let the agent regenerate tasks. This bidirectional relationship between documentation and implementation means your specs remain useful long after the initial feature is complete.
When to use specs: Feature development that spans multiple components, refactoring work that benefits from upfront planning, onboarding new team members who need to understand system behavior, or any scenario where the cost of ambiguity is high.
Steering: Persistent context that follows every conversation
Every team has conventions. Maybe you use Zod for validation, prefer named exports, or require that API error responses follow a specific schema. Without steering, you repeat these preferences in every chat session, and the agent forgets them the moment the conversation ends.
Steering files are markdown documents stored in
.kiro/steering/ (workspace-level) or ~/.kiro/steering/ (global) that give Kiro persistent knowledge about your project. Write your standards once, and they influence every interaction automatically.Kiro provides three foundational steering files to get you started:
- product.md — Your product's purpose, target users, and business objectives. Helps the agent understand why behind technical decisions.
- tech.md — Frameworks, libraries, tools, and technical constraints. The agent prefers your established stack over alternatives.
- structure.md — File organization, naming conventions, import patterns, and architectural decisions.
Beyond the foundations, you create custom steering files for anything your team cares about: API design standards, testing patterns, security policies, deployment procedures.
Inclusion modes control when steering files load:
| Mode | Behavior | Example use case |
|---|---|---|
always (default) | Loaded into every interaction | Core coding conventions, tech stack |
fileMatch | Loaded when working with files matching a glob pattern | React component patterns when editing *.tsx |
manual | Loaded on demand via #steering-file-name in chat | Troubleshooting guides, migration procedures |
auto | Loaded when the request matches a description | Domain-specific knowledge, complex workflows |
Steering files support file references with
#[[file:path/to/file]] syntax, so you can point to your OpenAPI spec, a GraphQL schema, or a reference component and keep the guidance anchored to real code.Workspace vs. global scope. Workspace steering lives in the repo and ships with your code — every team member gets the same standards. Global steering lives in your home directory and applies across all projects — personal preferences like your preferred comment style or review checklist. When both exist, workspace steering takes priority.
Powers: On-demand expertise without context overload
Connect five MCP (Model Context Protocol) servers to your IDE and you load 100+ tool definitions before writing a single line of code. That consumes tens of thousands of tokens — a significant portion of your context window — and degrades both response speed and output quality.
Powers solve this with dynamic activation. A power bundles three things:
- POWER.md — A steering file that tells the agent what MCP tools are available and when to use them.
- MCP server configuration — The tools and connection details for the underlying server.
- Steering and hooks (optional) — Automated tasks tied to the power's domain.
When you start a task, Kiro reads your prompt, evaluates installed powers against the task's keywords, and loads only the relevant power into context. Mention "payment" or "checkout" and the Stripe power activates. Switch to database work and the Supabase power takes over while Stripe deactivates.
This approach means you can install dozens of powers — Datadog, Dynatrace, Figma, Neon, Netlify, Postman, Stripe, Supabase, AWS Aurora, Strands SDK, and community-built powers from GitHub — without paying the context cost of loading them all simultaneously.
Installing a power is a one-click operation from the Kiro Powers marketplace or directly within the IDE. No JSON configuration files, no command-line setup.
Creating a power is straightforward if you want to package expertise for your team or the community. A power is a directory with a
POWER.md file, an MCP server configuration, and optional steering or hook files.Hooks: Event-driven automation that enforces your standards
Before committing code, experienced developers run through a mental checklist: Are tests updated? Is documentation current? Did I introduce a security vulnerability? Hooks automate that checklist.
A hook is a JSON configuration that maps an IDE event to an action. When the event fires, Kiro either sends a prompt to the agent (
askAgent) or runs a shell command (runCommand).Supported events:
| Event | Fires when... |
|---|---|
fileEdited | A file is saved |
fileCreated | A new file is created |
fileDeleted | A file is deleted |
promptSubmit | A message is sent to the agent |
agentStop | An agent execution completes |
preToolUse | Before a tool is executed |
postToolUse | After a tool is executed |
preTaskExecution | Before a spec task starts |
postTaskExecution | After a spec task completes |
userTriggered | Manual trigger via button click |
Example: lint TypeScript on save
1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "Lint on Save",
"version": "1.0.0",
"when": {
"type": "fileEdited",
"patterns": ["*.ts", "*.tsx"]
},
"then": {
"type": "runCommand",
"command": "npm run lint"
}
}Example: validate write operations against coding standards
1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "Review Write Operations",
"version": "1.0.0",
"when": {
"type": "preToolUse",
"toolTypes": ["write"]
},
"then": {
"type": "askAgent",
"prompt": "Verify this write operation follows our coding standards"
}
}Example: run tests after each spec task completes
1
2
3
4
5
6
7
8
9
10
11
{
"name": "Run Tests After Task",
"version": "1.0.0",
"when": {
"type": "postTaskExecution"
},
"then": {
"type": "runCommand",
"command": "npm run test"
}
}Hooks commit to version control, so they apply to every developer on the team. Set up a hook that validates the Single Responsibility Principle on new React components, and every team member gets that check automatically — no manual review step required.
You can create hooks through natural language ("Anytime a component is added, make sure it follows the single responsibility principle") or manually via the hook form in the Kiro panel.
Skills: Portable instruction packages for specialized workflows
Skills are modular instruction packages that follow the open Agent Skills standard. Where steering provides persistent project context and powers provide tool integrations, skills teach the agent how to perform specific workflows: reviewing pull requests, deploying infrastructure, running your team's release process.
Skills use progressive disclosure to keep context efficient:
- Discovery — At startup, Kiro loads only each skill's name and description.
- Activation — When your request matches a skill's description, Kiro loads the full instructions.
- Execution — The agent follows the instructions, loading scripts or reference files only as needed.
A skill is a folder containing a
SKILL.md file:1
2
3
4
5
my-skill/
├── SKILL.md # Required — frontmatter + instructions
├── scripts/ # Optional — executable code
├── references/ # Optional — documentation
└── assets/ # Optional — templatesThe
SKILL.md frontmatter tells Kiro when to activate:1
2
3
4
name: pr-review
description: Review pull requests for code quality, security issues, and test coverage. Use when reviewing PRs or preparing code for review.
Workspace skills (
.kiro/skills/) apply to a single project. Global skills (~/.kiro/skills/) apply across all workspaces. You can also invoke any skill directly with /skill-name in chat.Skills are interoperable. Because they follow an open standard, you can import skills from the community, export skills for use in other compatible AI tools, and share skills across teams.
How the five features work together
Each feature addresses a different dimension of the development workflow. Together, they form a layered system:
| Layer | Feature | What it provides |
|---|---|---|
| Planning | Specs | Structured requirements, design, and task breakdown |
| Context | Steering | Persistent project conventions and standards |
| Tools | Powers | On-demand MCP integrations with domain expertise |
| Automation | Hooks | Event-driven quality checks and workflow enforcement |
| Workflows | Skills | Reusable, portable instruction packages |
A realistic workflow looks like this: You start a feature with a spec, which generates requirements and a design grounded in your steering files' conventions. During implementation, powers activate the right MCP tools based on what you are building. Hooks enforce your testing and linting standards after every file save and spec task completion. A deployment skill handles the release when you are ready.
The result is an AI-assisted development process where the agent does not just generate code — it generates code that fits your architecture, follows your conventions, passes your tests, and is documented well enough for the next developer to pick up where you left off.
Putting it all together: Real-time fraud detection in financial services
Financial services is one of the most demanding domains for software development. Regulatory compliance, audit requirements, data sensitivity, and the need for sub-second transaction processing mean that "it works on my machine" is never enough. Let's walk through a realistic end-to-end example: building a real-time fraud detection service for a payments platform using all five Kiro features working in concert.
The scenario
Your team at a digital bank needs to build a transaction fraud scoring service. When a customer initiates a payment — card tap, wire transfer, peer-to-peer send — the service evaluates the transaction against risk rules, assigns a fraud score, and either approves, flags for manual review, or blocks the transaction. The service must meet PCI DSS requirements, respond within 200ms at the 99th percentile, produce a complete audit trail, and integrate with your existing core banking platform running on AWS.
Step 1 — Steering: Establish the regulatory and technical guardrails
Before writing a single line of code, you define steering files that encode your organization's financial services standards. These files ensure every interaction with Kiro — across every developer on the team — respects the same constraints.
.kiro/steering/product.md (always included)
1
2
3
4
5
## Product Context
This is a real-time fraud detection service for a PCI DSS-compliant
digital banking platform. All transactions must be scored within 200ms.
The service handles card-present, card-not-present, wire, and P2P
payment types. Target: 50,000 transactions per second at peak..kiro/steering/fsi-compliance.md (always included)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
inclusion: always
## Financial Services Compliance Standards
### PCI DSS Requirements
- Never log full card numbers (PAN). Mask to last four digits.
- Encrypt cardholder data at rest using AES-256 and in transit using TLS 1.2+.
- All API endpoints must enforce mutual TLS (mTLS) for service-to-service calls.
- Session tokens must expire after 15 minutes of inactivity.
### Audit Trail Requirements
- Every transaction decision (approve/flag/block) must be logged with:
timestamp, transaction ID, fraud score, rule(s) triggered, decision,
and the model version that produced the score.
- Audit logs must be immutable. Use append-only storage (e.g., Amazon QLDB
or S3 with Object Lock).
- Retain audit records for 7 years per regulatory requirement.
### Data Residency
- Transaction data must not leave the eu-west-1 region for EU customers.
- US customer data must remain in us-east-1.
### Code Standards
- All monetary values must use integer minor units (cents), never floating point.
- Use the `Decimal` type for any intermediate calculations involving currency.
- Every API response must include a correlation ID for end-to-end tracing..kiro/steering/api-patterns.md (conditional — loads when editing API files)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
inclusion: fileMatch
fileMatchPattern: ["src/api/**/*.ts", "src/routes/**/*.ts"]
## API Design Standards — Fraud Service
- All endpoints follow REST conventions under `/v1/fraud/`.
- Request validation uses Zod schemas. No runtime type assertions.
- Error responses follow RFC 7807 Problem Details format.
- Rate limiting: 1,000 requests/sec per client certificate.
- Circuit breaker pattern required for all downstream calls
(core banking, card network, sanctions list).
- Health check endpoint at `/v1/fraud/health` must verify
connectivity to the ML scoring engine and the rules database.Now, every time any developer on the team chats with Kiro — whether they are building the scoring engine, the API layer, or the audit pipeline — the agent already knows about PCI masking, audit immutability, the 200ms latency budget, and your API conventions. No one has to repeat these in a prompt.
Step 2 — Specs: Plan the fraud scoring feature with structured requirements
You open Kiro and type a single prompt:
"Build a real-time fraud scoring service that evaluates payment transactions against configurable risk rules, assigns a score from 0-100, and returns an approve/review/block decision within 200ms."
Kiro generates a spec with three phases:
Requirements — Kiro produces user stories grounded in the steering context it already has:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
## User Stories
### US-1: Score a transaction in real time
As a payment gateway, I want to submit a transaction for fraud scoring
so that I can decide whether to approve, flag, or block it before
the authorization response deadline.
**Acceptance Criteria (EARS):**
- WHEN a POST request is received at `/v1/fraud/score`
with a valid transaction payload,
THEN the service SHALL return a fraud score (0-100)
and a decision (approve | review | block) within 200ms.
- WHEN the fraud score is below 30, THEN the decision SHALL be "approve".
- WHEN the fraud score is between 30 and 70, THEN the decision SHALL be "review".
- WHEN the fraud score is above 70, THEN the decision SHALL be "block".
- WHEN the transaction contains a PAN,
THEN the PAN SHALL be masked to the last four digits
before logging or storage (PCI DSS §3.4).
### US-2: Configurable risk rules
As a fraud analyst, I want to manage risk rules through a rules engine
so that I can adjust detection thresholds without a code deployment.
### US-3: Immutable audit trail
As a compliance officer, I want every scoring decision recorded in an
append-only audit log so that I can produce evidence during regulatory audits.
### US-4: Sanctions and watchlist screening
As a compliance system, I want each transaction screened against
OFAC/EU sanctions lists so that blocked entities cannot transact.Design — Kiro analyzes your codebase and the requirements, then produces:
- A data flow diagram showing the request path from API gateway through the rules engine, ML scoring model, sanctions check, and audit logger.
- TypeScript interfaces for
TransactionRequest,FraudScoreResponse,RiskRule, andAuditEntry. - A DynamoDB schema for the rules engine configuration table and an S3 + Object Lock design for the immutable audit log.
- API endpoint definitions with Zod validation schemas that comply with the
api-patterns.mdsteering file.
Tasks — The design breaks into sequenced tasks:
- Create
TransactionRequestandFraudScoreResponsetypes with Zod schemas. - Implement the rules engine with DynamoDB-backed configuration.
- Build the ML model scoring client with circuit breaker and 150ms timeout.
- Implement sanctions list screening with OFAC API integration.
- Build the scoring orchestrator that combines rule score + ML score + sanctions result.
- Create the immutable audit logger using S3 with Object Lock.
- Implement the
/v1/fraud/scoreendpoint with mTLS and request validation. - Write unit tests for scoring logic, integration tests for the full pipeline, and load tests for the 200ms SLA.
Each task links back to the user story and acceptance criteria it satisfies. You review the spec with your team, adjust the scoring thresholds, and approve.
Step 3 — Powers: Activate the right tools at the right time
Your team has installed several powers, but Kiro only activates what is relevant to the current task:
- When you are building the DynamoDB rules table and S3 audit log, the AWS power activates — loading AWS CDK constructs, IAM policy guidance, and documentation search tools. Kiro knows to use S3 Object Lock for immutability because the power's steering includes AWS storage best practices.
- When you are setting up observability for the 200ms SLA, the Datadog power activates — providing tools to configure dashboards, set up latency monitors, and create anomaly alerts for fraud score distribution shifts.
- When you are testing the API contract with the payment gateway team, the Postman power activates — helping you generate a collection, set up mTLS certificates in the test environment, and run contract tests.
At no point are all three power's MCP tools loaded simultaneously. The context stays focused, responses stay fast, and the agent's suggestions remain relevant to whatever you are working on right now.
Step 4 — Hooks: Automate compliance checks and quality gates
You configure hooks that run automatically as the team develops:
PCI data leak prevention — Every time a file is saved, scan for patterns that look like unmasked card numbers:
1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "PCI PAN Scanner",
"version": "1.0.0",
"when": {
"type": "fileEdited",
"patterns": ["src/**/*.ts"]
},
"then": {
"type": "askAgent",
"prompt": "Scan the saved file for any hardcoded card numbers (PAN), unmasked sensitive data, or PCI DSS violations. If found, flag the exact line and suggest a remediation. Check that all PAN references use the maskPan() utility."
}
}Audit trail verification — After each spec task completes, verify that any new transaction-handling code writes to the audit log:
1
2
3
4
5
6
7
8
9
10
11
{
"name": "Audit Trail Check",
"version": "1.0.0",
"when": {
"type": "postTaskExecution"
},
"then": {
"type": "askAgent",
"prompt": "Review the code changes from the completed task. If any code path handles a transaction scoring decision (approve/review/block), verify that it writes an immutable audit entry with transaction ID, score, rules triggered, decision, and timestamp. Flag any decision path that bypasses the audit logger."
}
}Latency budget guard — Before any write operation, verify the code does not introduce synchronous calls that could blow the 200ms budget:
1
2
3
4
5
6
7
8
9
10
11
12
{
"name": "Latency Budget Review",
"version": "1.0.0",
"when": {
"type": "preToolUse",
"toolTypes": ["write"]
},
"then": {
"type": "askAgent",
"prompt": "Before writing this code, check if it introduces any synchronous blocking calls, unbounded loops, or sequential downstream calls that could exceed the 200ms latency SLA. All external calls (rules engine, ML model, sanctions check) must be parallel where possible."
}
}These hooks commit to the repo. Every developer on the team — new hires, contractors, offshore partners — gets the same compliance checks without any manual setup.
Step 5 — Skills: Reusable workflows for recurring financial services tasks
Your team creates skills for workflows they repeat across services:
.kiro/skills/fsi-threat-model/SKILL.md
1
2
3
4
name: fsi-threat-model
description: Perform a STRIDE threat model analysis for financial services APIs. Use when designing new API endpoints, reviewing authentication flows, or assessing data exposure risks in payment systems.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
## Threat Model Workflow
1. Identify all entry points (API endpoints, message queues, event triggers).
2. For each entry point, enumerate threats using the STRIDE model:
- Spoofing: Can a caller impersonate another service or user?
- Tampering: Can request data be modified in transit?
- Repudiation: Can a caller deny performing a transaction?
- Information Disclosure: Can sensitive data leak through responses, logs, or errors?
- Denial of Service: Can the endpoint be overwhelmed?
- Elevation of Privilege: Can a caller access resources beyond their authorization?
3. For each threat, assess likelihood (Low/Medium/High) and impact (Low/Medium/High).
4. Recommend mitigations referencing the project's existing security controls.
5. Output a markdown threat model document in `docs/security/`.
Reference the project's API patterns from #[[file:.kiro/steering/api-patterns.md]]
and compliance requirements from #[[file:.kiro/steering/fsi-compliance.md]]..kiro/skills/regulatory-release/SKILL.md
1
2
3
4
name: regulatory-release
description: Execute the regulated release checklist for financial services deployments. Use before deploying to staging or production environments.
1
2
3
4
5
6
7
8
9
10
11
## Regulated Release Checklist
1. Verify all spec tasks are complete and linked to requirements.
2. Confirm audit log coverage — every decision path writes an immutable record.
3. Run PCI DSS scan and confirm zero critical findings.
4. Verify data residency — EU transactions route to eu-west-1, US to us-east-1.
5. Confirm encryption at rest (AES-256) and in transit (TLS 1.2+).
6. Generate a change management record with: change description, risk assessment,
rollback procedure, and approver sign-off.
7. Run load tests and confirm p99 latency is within SLA.
8. Tag the release with a semantic version and link to the spec document.When a developer types "run the threat model for the fraud scoring API," Kiro activates the
fsi-threat-model skill, loads the full instructions and referenced steering files, and walks through each STRIDE category against the endpoints defined in the spec. When someone is ready to deploy, /regulatory-release activates the checklist and verifies each item against the actual codebase state.The result
Five features, one workflow:
- Steering established PCI DSS rules, audit requirements, latency budgets, and API conventions as persistent context that every developer and every Kiro interaction inherits.
- Specs transformed a one-line prompt into reviewable requirements, a technical design grounded in the codebase, and dependency-sequenced tasks with traceability back to user stories.
- Powers activated AWS, Datadog, and Postman MCP tools on demand — only when relevant — keeping context lean and responses fast.
- Hooks automated PCI data scanning on every save, audit trail verification after every task, and latency budget checks before every write — catching issues at authoring time, not in code review.
- Skills packaged STRIDE threat modeling and regulated release checklists as reusable, portable workflows that any team member can invoke.
The fraud scoring service ships with documented requirements, a traceable design, enforced compliance standards, automated quality gates, and a repeatable deployment process. The next time a regulator asks "how do you ensure PAN data is never logged unmasked?" the answer is not "we trust developers to remember." The answer is "we have a hook that checks every file save, a steering file that encodes the rule, and an audit trail that proves it."
That is the difference between a prototype and a production system in financial services. That is what Kiro helps you build.
Getting started
Kiro is available for Mac, Windows, and Linux. To begin:
- Download Kiro from kiro.dev/downloads .
- Generate foundational steering files from the Kiro panel to establish your project context.
- Browse and install powers from the Powers marketplace .
- Create your first spec by describing a feature in chat.
- Set up a hook to automate a routine quality check.
- Import or create a skill for a workflow your team repeats.
For a hands-on walkthrough, try the Learn by Playing tutorial which walks you through building a complete feature from spec to deployment.
Kiro is built by AWS. For documentation, visit kiro.dev/docs . Join the community on Discord . Share what you build with #builtwithkiro.
Sources: kiro.dev/docs/steering , kiro.dev/docs/powers , kiro.dev/docs/hooks , kiro.dev/docs/skills , kiro.dev/blog/introducing-kiro
Content was rephrased for compliance with licensing restrictions.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article