Building Better Infrastructure with Kiro: A Quick Guide to Steering, Hooks, and MCP

After working with genAI tools for infrastructure projects, I've learned that if the setup takes more than 5 minutes or I can't understand it end-to-end, I tend to abandon it for day-to-day work. What actually works are the rule sets and steering docs you can drop into your repo. While these files and features are specific to Kiro, most agentic IDE offerings include variations of these processes.

Here's your five minute write up to hopefully unlock some efficiencies in your workflow. Remember for the time being, new users get 500 additional bonus credits! That will last you quite a while, so feel free to install Kiro and play aroud with the below.

Foundational Steering Files: Your Project's DNA

Kiro provides foundational steering files to establish core project context. You can generate these files as follows:

• Product Overview (product.md) - Defines your product's purpose, target users, key features, and business objectives. This helps Kiro understand the "why" behind technical decisions and suggest solutions aligned with your product goals.
• Technology Stack (tech.md) - Documents your chosen frameworks, libraries, development tools, and technical constraints. When Kiro suggests implementations, it will prefer your established stack over alternatives.
• Project Structure (structure.md) - Outlines file organization, naming conventions, import patterns, and architectural decisions. This ensures generated code fits seamlessly into your existing codebase.

These foundation files are included in every interaction by default, forming the baseline of Kiro's project understanding.

Technology Stack in Practice

Here's what a tech.md file looks like in our infrastructure project:

# Technology Stack

## Core Tools
- **Terraform**: ~> 1.0 with HCL
- **AWS Provider**: ~> 5.0 (always pinned)
- **terraform-aws-modules**: Exclusive module source

## Key Constraints
- Use terraform-aws-modules when available
- Single main.tf unless >1000 lines total
- IAM policies inline with resources using aws_iam_policy_document
- Separate AWS accounts per environment

This isn't just documentation—Kiro uses this to make intelligent suggestions that fit your established patterns. You can see we are declaring AWS provider and base terraform versions. This in conjunction with the terraform MCP, (using Kiro Powers), will ensure that generated code respects the versions outlined in this file.

Project Structure Standards

The structure.md file defines clear organizational patterns:

## Small Infrastructure (<1000 lines)
main.tf          # All resources
variables.tf     # Input variables  
outputs.tf       # Output values
versions.tf      # Provider versions
terraform.tfvars # Variable values

## Large Infrastructure (>1000 lines)
main.tf          # Core resources
s3.tf            # S3 buckets + policies
lambda.tf        # Lambda functions + IAM
api-gateway.tf   # API Gateway resources

The beauty here is that Kiro knows when to split files and follows your exact naming patterns.

Domain-Specific Standards

Our terraform-standards.md shows how to create context-aware steering files:

---
inclusion: fileMatch
fileMatchPattern: "**/*.tf"
---

# Terraform Code Standards

## Required IAM Pattern
data "aws_iam_policy_document" "policy_name" {
  statement {
    effect = "Allow"
    actions = [
      "service:Action1",
      "service:Action2"
    ]
    resources = ["${aws_resource.example.arn}/*"]
  }
}

resource "aws_iam_role_policy" "policy_name" {
  name   = "policy-name"
  role   = aws_iam_role.role_name.id
  policy = data.aws_iam_policy_document.policy_name.json
}

The frontmatter fileMatchPattern: "**/*.tf" ensures this steering file only activates when working with Terraform files, keeping context focused and relevant. In this example, we are suggesting to use native terraform data{} blocks, instead of a conversion, like jsonencode{}, which is usually generated by AI agents in Terraform.

Team Consistency Through Shared Standards

Push these docs to your git repository. When your entire team uses the same steering files, you get consistent code output across all team members. Your standards for Terraform versions, tech stack preferences, and code structure will be considered every time any team member uses the agent.

Global and Team Steering

Global steering files reside in your home directory under ~/.kiro/steering/, and apply to all workspaces. Global steering files can be used to inform Kiro of conventions that apply to all your workspaces.

In case of conflicting instructions between global and workspace steering, Kiro will prioritize the workspace steering instructions. This allows you to specify global directives that generally apply to all your workspaces, while preserving the ability to override those directives for specific workspaces.

Team steering can be implemented by pushing steering files to users' PCs via MDM solutions or Group Policies, or downloaded by users to their PCs from a central repository, and placed into the ~/.kiro/steering folder.

Using these docs as a team provides better consistency in generated code output, as your standards, tech stack, and code structure will be considered every time the agent is used.

Hooks: Automation That Actually Works

A unique feature of Kiro is the use of hooks. Agent hooks are powerful automation tools that streamline your development workflow by automatically executing predefined agent actions when specific events occur in your IDE. With hooks, you eliminate the need to manually request routine tasks and ensure consistency across your codebase.

What are agent hooks?

Agent hooks are automated triggers that execute predefined agent prompts or shell commands when specific events occur in your IDE. Rather than manually asking for routine tasks to be performed, hooks set up automated responses to events.

There are three categories of hooks:

• File hooks - Trigger on file save, create, or delete (with glob patterns)
• Contextual hooks - Trigger on prompt submit or agent completion
• Manual hooks - Trigger on-demand via UI or slash commands

Agent hooks transform your development workflow through intelligent automation. By setting up hooks for common tasks, you can:

• Maintain consistent code quality
• Prevent security vulnerabilities
• Reduce manual overhead
• Standardize team processes
• Create faster development cycles

Learn more about hook types and hook actions.

The Compliance Hook That Changes Everything

Here's the hook we use in our project - kiro-recheck-steering.kiro.hook:

{
  "enabled": true,
  "name": "terraform-compliance-validator",
  "description": "Validate all changes against steering standards with clear pass/fail output (v3)",
  "version": "1",
  "when": {
    "type": "agentStop"
  },
  "then": {
    "type": "askAgent",
    "prompt": "Running terraform compliance validation...\n\nReview all files that were created, modified, or deleted in the last agent execution against ALL steering documents in .kiro/steering/\n\nCheck compliance with any and all standards, requirements, and guidelines found in the steering directory.\n\nOutput format:\n- If ALL files are compliant: \"Terraform compliance check passed\"\n- If ANY violations found: \"Terraform compliance check failed\" followed by details"
  }
}

The use case is simple: sometimes AI agents have amnesia and forget everything laid out in the steering docs. This hook makes the agent reevaluate its compliance with the steering docs after it has completed a task, removing the often manual task of checking its work.

After every Kiro execution, this hook:

1. Reviews all modified files
2. Checks compliance against ALL steering documents
3. Provides clear pass/fail output
4. Lists specific violations with recommended fixes

This means your infrastructure stays compliant without manual reviews.

MCP Support: Controlled Context

MCP (Model Context Protocol) is really just a way to give more context to the agent on the specific toolsets that you want it to use. For example, the MCP referenced in our mcp.json leverages Kiro's new Powers ability.

Kiro Powers

Kiro powers give your AI agent instant access to specialized knowledge for any technology. Powers package your tools, workflows, and best practices into a format that Kiro can activate on-demand. When you mention relevant keywords, Kiro loads the power's context and tools automatically.

HashiCorp is a Kiro Powers launch partner, providing official Terraform integration.

Benefits of the Terraform Power

Once the Terraform power is installed, whenever you mention infrastructure or Terraform-related tasks, the power activates automatically, providing access to best practices, configuration templates, and deployment workflows. As mentioned previously, the Terraform power for Kiro can significantly reduce token and context consumption.

The context is only active when you need it. The Terraform tools stay hidden until you specifically mention things like "Terraform", "infrastructure", or "deployment." This dynamic loading keeps your context window clear and ensures the Terraform power is only running when you actually need it, providing a cleaner, more efficient, and more focused developer experience.

This HashiCorp-developed Kiro power enables developers to build, manage, and deploy cloud infrastructure using Terraform's declarative configuration language — all with the intelligent assistance of Kiro's AI agent.

Simple MCP Setup

The MCP server allows the agent to verify generated Terraform against the version of Terraform we are using. MCP might seem complicated to set up, but from the deployment docs, I found that I could install the MCP with a one-liner using brew:

brew install terraform-mcp-server

What this means is our steering files can have specific rules to enforce that generated Terraform code uses a specific Terraform version—an issue with AI agents is even if they use the correct library, they could use an outdated version. This resolves that.

Our mcp.json configuration gives Kiro exactly the capabilities it needs:

{
  "mcpServers": {
    "filesystem": {
      "command": "uvx",
      "args": ["mcp-server-filesystem", "/path/to/allowed/files"],
      "disabled": false,
      "autoApprove": ["read_file", "list_directory"]
    },
    "git": {
      "command": "uvx", 
      "args": ["mcp-server-git"],
      "disabled": false,
      "autoApprove": ["git_status", "git_log"]
    }
  }
}

The autoApprove settings eliminate friction for safe operations while maintaining security boundaries.

Putting It All Together

This combination of steering files, hooks, and MCP integration creates a development environment where:

• Standards are enforced automatically through compliance hooks
• Context stays relevant through conditional steering files
• Tool integration is seamless through MCP servers
• Team consistency is maintained through shared steering files

The result is infrastructure code that follows your standards, uses the right tool versions, and gets validated automatically—without manual oversight.

Interactive Project Explorer

Click through the project structure below to see how all these pieces work together in a real Terraform infrastructure project. All files are available for reference or copying into your own projects.

# Project Structure

## File Organization

### Small Infrastructure (<1000 lines)
```
main.tf          # All resources
variables.tf     # Input variables  
outputs.tf       # Output values
versions.tf      # Provider versions
terraform.tfvars # Variable values
```

### Large Infrastructure (>1000 lines)
```
main.tf          # Core resources
s3.tf            # S3 buckets + policies
lambda.tf        # Lambda functions + IAM
api-gateway.tf   # API Gateway resources
variables.tf / outputs.tf / versions.tf
```

## Naming Conventions
- Resources: `${var.environment}-service-purpose` (kebab-case)
- Variables: snake_case (`vpc_cidr`, `instance_type`)
- Files: AWS service names (`s3.tf`, `lambda.tf`)

## Environment Management
```hcl
# variables.tf
variable "environment" {
  description = "Environment name"
  type        = string
  validation {
    condition     = contains(["dev", "stage", "prod"], var.environment)
    error_message = "Environment must be dev, stage, or prod."
  }
}
```

**Environment tfvars pattern:**
```hcl
# dev.tfvars
environment   = "dev"
vpc_cidr      = "10.0.0.0/16"
instance_type = "t3.micro"

# prod.tfvars  
environment   = "prod"
vpc_cidr      = "10.100.0.0/16"
instance_type = "t3.medium"
```

## IAM Policy Architecture
Keep IAM policies inline with resources using aws_iam_policy_document:

```hcl
data "aws_iam_policy_document" "lambda_policy" {
  statement {
    effect = "Allow"
    actions = [
      "logs:CreateLogGroup",
      "logs:CreateLogStream", 
      "logs:PutLogEvents"
    ]
    resources = ["arn:aws:logs:*:*:*"]
  }
}

resource "aws_iam_role_policy" "lambda_policy" {
  name   = "lambda-policy"
  role   = aws_iam_role.lambda.id
  policy = data.aws_iam_policy_document.lambda_policy.json
}
```

## Security Patterns
```hcl
# S3 bucket security configuration
module "s3_bucket" {
  source  = "terraform-aws-modules/s3-bucket/aws"
  version = "~> 3.0"
  
  bucket = "${var.environment}-secure-bucket"
  
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
  
  versioning = { enabled = true }
  
  server_side_encryption_configuration = {
    rule = {
      apply_server_side_encryption_by_default = {
        sse_algorithm = "AES256"
      }
    }
  }
}
```

# Project Structure

## File Organization

### Small Infrastructure (<1000 lines)
```
main.tf          # All resources
variables.tf     # Input variables  
outputs.tf       # Output values
versions.tf      # Provider versions
terraform.tfvars # Variable values
```

### Large Infrastructure (>1000 lines)
```
main.tf          # Core resources
s3.tf            # S3 buckets + policies
lambda.tf        # Lambda functions + IAM
api-gateway.tf   # API Gateway resources
variables.tf / outputs.tf / versions.tf
```

## Naming Conventions
- Resources: `${var.environment}-service-purpose` (kebab-case)
- Variables: snake_case (`vpc_cidr`, `instance_type`)
- Files: AWS service names (`s3.tf`, `lambda.tf`)

## Environment Management
```hcl
# variables.tf
variable "environment" {
  description = "Environment name"
  type        = string
  validation {
    condition     = contains(["dev", "stage", "prod"], var.environment)
    error_message = "Environment must be dev, stage, or prod."
  }
}
```

**Environment tfvars pattern:**
```hcl
# dev.tfvars
environment   = "dev"
vpc_cidr      = "10.0.0.0/16"
instance_type = "t3.micro"

# prod.tfvars  
environment   = "prod"
vpc_cidr      = "10.100.0.0/16"
instance_type = "t3.medium"
```

## IAM Policy Architecture
Keep IAM policies inline with resources using aws_iam_policy_document:

```hcl
data "aws_iam_policy_document" "lambda_policy" {
  statement {
    effect = "Allow"
    actions = [
      "logs:CreateLogGroup",
      "logs:CreateLogStream", 
      "logs:PutLogEvents"
    ]
    resources = ["arn:aws:logs:*:*:*"]
  }
}

resource "aws_iam_role_policy" "lambda_policy" {
  name   = "lambda-policy"
  role   = aws_iam_role.lambda.id
  policy = data.aws_iam_policy_document.lambda_policy.json
}
```

## Security Patterns
```hcl
# S3 bucket security configuration
module "s3_bucket" {
  source  = "terraform-aws-modules/s3-bucket/aws"
  version = "~> 3.0"
  
  bucket = "${var.environment}-secure-bucket"
  
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
  
  versioning = { enabled = true }
  
  server_side_encryption_configuration = {
    rule = {
      apply_server_side_encryption_by_default = {
        sse_algorithm = "AES256"
      }
    }
  }
}
```

Getting Started

To implement this approach in your infrastructure projects:

1. Generate foundational steering files through the Kiro panel (Steering section → Generate Steering Docs)
2. Add domain-specific standards with appropriate file matching patterns
3. Set up compliance hooks to validate changes automatically
4. Configure MCP servers for the integrations you need
5. Push steering files to your git repository for team consistency

Start with the three foundation files, then add domain-specific rules and hooks as your project grows.