Forem: Nao San

[AWS] Strategies to make KAA work like a member of the project team [Kiro]

Nao San — Sun, 05 Apr 2026 06:41:33 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

【AWS】KAAをPJメンバーの1人のように活躍してもらう工夫【Kiro】 #DevTools - Qiita

はじめに前回の記事では Kiro Autonomous Agent (KAA) の基本機能を紹介しました。GitHub Issue でタスクを指示すると、リポジトリを分析し、実装して PR を作成するところまでを自動で行うフロンティアエージェントです。本記事では、Ki...

qiita.com

Introduction

In the previous article, we introduced the basic functions of Kiro Autonomous Agent (KAA). It's a frontier agent that automatically analyzes the repository, implements the task, and creates a pull request when a task is assigned via GitHub Issue.

This article will explore how to integrate Kiro Autonomous Agent into your development workflow as a "member of your team." Specifically, we will build a series of flows using GitHub Actions and AWS APIs to automatically retrieve and implement issues from Backlog, and notify Slack of completion reports.

This time, we explored various ways to utilize the basic functions of the Kiro autonomous agent, which we covered in the previous article, to make it a valuable member of your team.

[AWS] Catching Up on the Basic Functions of Kiro Autonomous Agent (Preview) [FrontierAgents]

Nao San for AWS Community Builders

Apr 1

[AWS] Catching up on the basic functions of Kiro Autonomous Agent (Preview) [FrontierAgents]

#aws #devtools #kiro #frontieragent

Comments

11 min read

Kiro as a Team Member

This section outlines how Kiro's features can replicate the actions of human developers working in a team.

Team Member Actions	How to Achieve This in Kiro
Check Issues with an Issue Management Tool	Automatically Retrieve Backlog Issues with GitHub Actions → Convert to GitHub Issues
Write Code According to Team Conventions	Steering File + Persistence Context
Respond to Code Review Feedback	`/kiro all`, `/kiro fix`
Report Completion	Slack Webhook Notification with GitHub Actions
Learn from Feedback	Learn from Code Reviews

In this article, we will build the "Acquire Issues → Implement → Report Completion" flow using GitHub Actions and implement "Convention Adherence" with a Steering File.

Image of FrontierAgent utilization including Kiro autonomation agent

Preparation

Step 1: Creating the Steering File

First, create a Steering file in the default branch of the target repository. The Kiro Autonomous Agent automatically reads the Markdown files in the .kiro/steering/ folder when the task starts.

Branch Naming Conventions

.kiro/steering/branch-naming.md:

# Branch Naming Conventions

Please create branch names in the following format:

- Format: `feature-{issue number}-{brief description of the issue}`
- Example: `feature-PROJ-123-add-search-function`
- If the issue number is included in the title or body of the GitHub Issue, please use that.
- If the issue number is unknown, please confirm the issue number with the user before creating the branch. Do not create a branch without an issue number.

Coding Standards

.kiro/steering/coding-standards.md:

# Coding Standards

## Error Handling
- Return only a generic error message ("Internal server error") in the response within the catch block.
- Log detailed error information only to CloudWatch Logs using console.error.
- Do not include stack traces or error messages in the response body.

## Input Validation
- Always validate input values for API endpoints.
- Use an enumeration of allowed values.

## Naming Conventions
- Lambda handler filenames should be in camel case (e.g., createTodo.ts).
- Variable and function names should be in camel case.
- Constants should be in uppercase snake_case (e.g., TABLE_NAME).

Architecture Patterns

.kiro/steering/architecture.md:

# Architecture Patterns

## Lambda Handler Structure
- Create a separate Lambda handler file for each endpoint.
- The handler receives an APIGatewayProxyEvent and returns an APIGatewayProxyResult.
- Use DynamoDBDocumentClient from @aws-sdk/lib-dynamodb for DynamoDB access.
- Obtain the table name from the environment variable TABLE_NAME.

## CDK Stack
- The infrastructure definition is written in lib/todo-api-stack.ts.
- The Lambda function uses NodejsFunction.

Commit and push these files to the default branch.

↓Create a .kiro/steering folder directly under the project directory, as shown below.

Step 2: Create a virtual user "Kiro" in Backlog

Create a virtual user for Kiro in Backlog. This will create a system where tasks are automatically assigned to the Kiro Autonomous Agent simply by changing the assignee of an issue to "Kiro".

Step 2: Create a virtual user "Kiro" in Backlog

Create a virtual user for Kiro in Backlog. ## Step 3: Creating a GitHub Actions Workflow

Automatically Fetching Backlog Issues → Creating GitHub Issues

.github/workflows/sync-backlog.yml:

name: Sync Backlog to GitHub Issues
on:
workflow_dispatch: # First, manually run to verify functionality
# After verifying functionality, uncomment the following to enable scheduled execution
# schedule:
# - cron: '0 0 * * 1-5' # Weekdays 9 AM (JST) = UTC 0:00
# - cron: '0 9 * * 1-5' # Weekdays 6 PM (JST) = UTC 9:00 (If there are more than 10 issues)

jobs:
sync:
runs-on: ubuntu-latest
steps:
- name: Fetch Backlog issues assigned to Kiro
env:
BACKLOG_SPACE_ID: ${{ secrets.BACKLOG_SPACE_ID }}
BACKLOG_API_KEY: ${{ secrets.BACKLOG_API_KEY }}
BACKLOG_PROJECT_ID: ${{ secrets.BACKLOG_PROJECT_ID }}
BACKLOG_KIRO_USER_ID: ${{ secrets.BACKLOG_KIRO_USER_ID }}
GH_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }} # Use PAT instead of GITHUB_TOKEN (see Step 4 for reason)
MAX_ISSUES: 10 # Match Kiro's concurrent execution limit
run: |
TODAY=$(TZ=Asia/Tokyo date +%Y-%m-%d)

# Retrieve by assignee=Kiro, status=Not handled (1), start date=Today, in order of priority
# Note: Backlog URLs are .backlog.com and .backlog.jp There are two types:
# Note: GitHub Actions runners operate in UTC, so TZ=Asia/Tokyo is specified to match Japan Standard Time.
# Please change according to your environment.
ISSUE=$(curl -s "https://${BACKLOG_SPACE_ID}.backlog.jp/api/v2/issues?apiKey=${BACKLOG_API_KEY}&projectId[]=${BACKLOG_PROJECT_ID}&assigneeId[]=${BACKLOG_KIRO_USER_ID}&statusId[]=1&startDateSince=${TODAY}&startDateUntil=${TODAY}&sort=priority&order=asc&count=${MAX_ISSUES}")

echo "$ISSUES" | jq -c '.[]' | while read -r ISSUE; do
ISSUE_KEY=$(echo "$ISSUE" | jq -r '.issueKey')
ISSUE_ID=$(echo "$ISSUE" | jq -r '.id')
SUMMARY=$(echo "$ISSUE" | jq -r '.summary')
DESCRIPTION=$(echo "$ISSUE" | jq -r '.description // ""')
PRIORITY=$(echo "$ISSUE" | jq -r '.priority.name // "中"')

# Check if the same issue already exists
EXISTING=$(gh issue list --search "$ISSUE_KEY" --json number --jq 'length')
if [ "$EXISTING" -gt 0 ]; then
echo "Skip: $ISSUE_KEY already exists"
continue
fi
# Create a GitHub Issue
gh issue create \
--title ">$ISSUE_KEY] $SUMMARY" \
--body "## Backlog Issue: $ISSUE_KEY

**Priority**: $PRIORITY

$DESCRIPTION

*Automatic integration from Backlog (Start Date: ${TODAY})*" \
--label "kiro"

# Update Backlog issue status to "Processing (2)"
curl -s -X PATCH \
"https://${BACKLOG_SPACE_ID}.backlog.jp/api/v2/issues/${ISSUE_KEY}?apiKey=${BACKLOG_API_KEY}" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "statusId=2"

echo "Created & updated: $ISSUE_KEY"
done

Points:

Filters by statusId[]=1 (not supported), so issues already in processing are not retrieved.
Backlog after GitHub Issue creation The issue status is automatically updated to "Processing (2)" to prevent duplicate retrieval of the same issue in the next execution.
MAX_ISSUES: 10 is the value corresponding to Kiro's concurrent execution limit. If there are more than 10 issues, it can be handled by running it twice, at 9 AM and 6 PM.

Slack Notification When PR is Created

When the Kiro Autonomous Agent creates a PR, GitHub Actions automatically sends a notification to Slack. At the same time, the Backlog issue key (e.g., FS-2) is extracted from the PR title, and the Backlog issue status is updated to "Processed". The comment "PR created. Please review it. {PR URL}" is automatically added to the issue.

.github/workflows/notify-slack.yml:

name: Notify Slack on Kiro PR
on: 
pull_request: 
types: [opened]

jobs: 
notify: 
if: contains(github.event.pull_request.body, '@kiro-agent') 
runs-on: ubuntu-latest 
steps: 
- name: Send Slack notification and update Backlog 
env: 
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} 
BACKLOG_SPACE_ID: ${{ secrets.BACKLOG_SPACE_ID }} 
BACKLOG_API_KEY: ${{ secrets.BACKLOG_API_KEY }} 
run: | 
PR_TITLE="${{ github.event.pull_request.title }}" 
PR_URL="${{ github.event.pull_request.html_url }}"

# Notify Slack
curl -X POST "$SLACK_WEBHOOK_URL" \
-H "Content-Type: application/json" \
-d "{\"text\": \"🤖 Kiro has created a PR\n*${PR_TITLE}*\n${PR_URL}\"}"

# Extract the Backlog issue key from the PR title (e.g., [FS-2] or (FS-2) → FS-2)
ISSUE_KEY=$(echo "$PR_TITLE" | grep -oP '[(\[]([A-Z]+-\d+)[)\]]' | tr -d '[]()' | head -1)

if [ -n "$ISSUE_KEY" ]; then

# Update the Backlog issue status to "Processed (3)" and add a comment

curl -s -X PATCH \
"https://${BACKLOG_SPACE_ID}.backlog.jp/api/v2/issues/${ISSUE_KEY}?apiKey=${BACKLOG_API_KEY}" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "statusId=3&comment=PR created. Please review it.%0A${PR_URL}"
fi

Points:

Since the body of PRs created by Kiro includes This pull request was generated by @kiro-agent, use this as an if condition to filter and only notify Kiro's PRs.
Extract the issue key from the PR title and automatically update the Backlog status to "Processed".
Add the PR URL as a comment to the Backlog issue.

Step 4: Registering GitHub Secrets

Secret Name	Content	How to Obtain
BACKLOG_SPACE_ID	Backlog Space ID	The `xxxxx` part of the Backlog URL `https://xxxxx.backlog.jp`
BACKLOG_API_KEY	Backlog API Key	Backlog → Personal Settings → API → "Issue New API Key"
BACKLOG_PROJECT_ID	Numerical ID of the target project	Check with the Backlog API `https://{spaceId}.backlog.jp/api/v2/projects?apiKey={apiKey}`
BACKLOG_KIRO_USER_ID	Numerical ID of the Kiro user	Check with the Backlog API `https://{spaceId}.backlog.jp/api/v2/users?apiKey={apiKey}`
SLACK_WEBHOOK_URL	Slack Incoming Webhook URL	Slack → App Management → Incoming Webhooks → "Add New Webhook to Workspace"
PERSONAL_ACCESS_TOKEN	GitHub Personal Access Token	Generated via GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens. `Issues: Read and write` permission is required.

★This time, it's set in Repository secrets.

BACKLOG_PROJECT_ID and BACKLOG_KIRO_USER_ID require numerical IDs. Since these may not be directly visible on the Backlog screen, it's best to access the API URL above in a browser and check the JSON.

Why is a Personal Access Token Required?

The default token for GitHub Actions (GITHUB_TOKEN) operates as a virtual account called github-actions[bot]. When the Kiro Autonomous Agent accepts the /kiro command, it verifies that the commenter is a GitHub user registered with Kiro. Since bot accounts cannot be registered with Kiro, /kiro comments from GITHUB_TOKEN are ignored.

Using a Personal Access Token ensures that comments are posted from your own account, allowing Kiro to recognize the /kiro command and initiate the task.

Step 5: Creating GitHub Labels

Pre-create the labels that the GitHub Actions workflow will assign when creating an issue. Create the following two labels from Issues → Labels → New label in your GitHub repository:

Label Name	Description	Purpose
`kiro`	Assign a task to the Kiro Autonomous Agent	Kiro automatically starts the task

Scenario 1: Having Kiro implement Backlog issues

Once preparation is complete, we will actually run the flow.

Registering Issues and Changing Assignees

Organize issues in sprint planning and change the assignee of issues to be handled by Kiro to "Kiro". By setting a start date, it will be automatically converted to a GitHub Issue on the morning of that day.

↓Create an issue by specifying the start date

↓Set Kiro as the assignee

Create an Issue with GitHub Actions

At 9 AM on weekdays (or manually executed), GitHub Actions will call the Backlog API to retrieve Kiro's assigned issues starting today, sorted by priority, and convert them into GitHub Issues. Issues are assigned the kiro label, so the Kiro Autonomous Agent automatically starts the task.

↓This time, we'll run it manually to confirm.

↓Confirm that the Issues have been created.

The daily retrieval limit is 10, in line with Kiro's concurrent execution limit. If there are more than 10 issues, you can handle them by running the process twice a day, at 9 AM and 6 PM.

The retrieved issues are automatically updated to "Processing" on Backlog, so they will not be retrieved twice in subsequent runs.

Kiro Implements and Creates a PR

The Kiro Autonomous Agent analyzes the repository and proceeds with the implementation according to the conventions of the Steering file.

↓Confirmed that the PR was created. Confirmed that the branch name was also created in the specified format.

SecurityAgent automatically performs code review on the PR.

Notes on Task Order Dependencies

Each task in the Kiro Autonomous Agent runs in an independent sandbox and cannot reference the state of other tasks. Tasks with the same start date run in parallel, so it's not possible to control the order, such as "start task B after task A is completed."

When entrusting tasks with order dependencies to Kiro, use the following methods:

Stagger Start Dates: Plan tasks with dependencies, staggering their start dates by one day each (e.g., Task A: Monday, Task B: Tuesday). GitHub Actions only retrieves tasks with today's start date, so the order is naturally controlled.
Combine into a Single Task: Describe dependent tasks as a single task and have Kiro implement them all at once. Leveraging Kiro's multi-repository support, changes spanning multiple repositories can also be handled in a single task.

It's best to select tasks that are independent of each other and organize dependent tasks using the methods described above for smoother execution.

Automatic Slack Notification for Backlog Issue Updates

When a Pull Request (PR) is created, GitHub Actions automatically sends a notification to Slack.

↓ Confirm that the Backlog issue status has changed to "Processed"

↓ Confirm that a comment requesting a PR review has been added to the Backlog issue.

Scenario 2: Implementing the DevOps Agent's Agent-ready spec in Kiro

DevOps Agent preventative recommendations may include an "Agent-ready specification." This is a structured document for coding agents and can be used directly as instructions for Kiro.

Copying the Agent-ready spec to a GitHub Issue

Open the recommendation details in the DevOps Agent Web App, copy the contents of the Agent-ready spec, and paste it into a GitHub Issue.

"Agent Readiness Specs" on the "Prevention" screen

"Agent Readiness Specs" on the "Incident Response" screen

The Agent-ready spec includes the following:

Problem overview and root cause
Summary of recommended approach
Repository requiring changes
Specific code changes (file paths, implementation considerations)
Test requirements
Phased Implementation Plan

This structured content directly serves as instructions for Kiro, saving the effort of rewriting requirements manually.

↓ Specifying "kiro" as a label will initiate Kiro's response.

Verification Results

A PR has been created.

Kiro accurately understood the structured content of the Agent-ready spec and implemented it comprehensively:

Introduction of test infrastructure: Added Jest, ts-jest, ESLint, and aws-sdk-client-mock to devDependencies
24 test cases: Unit tests for 5 Lambda handlers. March 29, 2026 Including regression testing of the incident (case where pathParameters is undefined)
3-stage CI/CD pipeline: build (TypeScript compilation + ESLint) → test (Jest + 85% coverage threshold) → deploy (CDK deployment of main branch only)
README documentation: Added CI/CD pipeline overview, test commands, and contributing workflow

Of particular note is the inclusion of regression testing that correctly reproduces the incident background (regression due to PR #4) included in the Agent-ready spec. It was confirmed that the structured information in the Agent-ready spec functioned directly as instructions for Kiro.

Learning Feedback Loop

The Kiro Autonomous Agent learns from code review feedback. We will verify how to document this learning as a Steering file and share it with the entire team.

Feedback in Code Reviews

Feedback is provided in code reviews for PRs created by Kiro.

An important point is that the only thing influencing the learning process is the feedback from the task creator (myself).

In Scenario 2, there were several suggestions from Security Agents in the PR, so this time we will revise based on these suggestions and have the Kiro autonomous agent learn from them.

To make this your own feedback, comment "/kiro all" and have Kiro correct all the issues pointed out by the SecurityAgent.

↓ Enter "/kiro all" in the comment

↓ Kiro autonomous agent Image

Output Learned Patterns to a Steering File

Create the following Issue in Kiro and tag it with kiro:

Title:

``` Summarize Patterns Learned from Code Reviews in a Steering File



Details:


``` Summarize the patterns learned from feedback in previous code reviews in `.kiro/steering/learned-patterns.md`.

Based on feedback received in past tasks and points raised in code reviews,
organize the patterns that should be automatically considered in future tasks.

↓ Screenshot of the Issue creation screen

Upon checking the PR from the Kiro autonomous agent, a Steering document reflecting the review content was created as follows:
↓ PR content

↓ Steering Content (Contains patterns learned from code reviews)

Verification Results

Kiro analyzed past PR history and created a Steering file that systematically summarizes the patterns pointed out in code reviews. The generated learned-patterns.md file included the following categories:

Authentication & Authorization: userId guarding, ownership checks (IDOR prevention), API Gateway authentication settings
Input Validation: pathParameters undefined checks, JSON.parse crash prevention, XSS prevention
Error Handling: Stack trace concealment, response order to prevent information leakage
DynamoDB Operations: UpdateCommand upsert prevention
Testing: Assertion method for the absence of vulnerabilities
Change Scope: Changes only within the scope requested in the Issue

Of particular note is that each pattern referenced specific PR numbers (#3, #4, #5, #34, etc.) and included Security Agent's findings (IDOR, XSS, stack trace leakage).

While the official documentation states that "only feedback from task creators influences learning," Kiro appears to be able to analyze the entire PR history of the repository to obtain information. "Persistent learning" and "referencing PR history" are considered different mechanisms.

This verification confirmed that the following feedback loop actually works:

Kiro executes a task → creates a PR
Security Agent issues security issues during code review → Kiro fixes them using /kiro all
Request Kiro to "summarize learned patterns in a Steering file" → added via PR
Team members review and approve → tacit knowledge is documented and shared with the entire team

Current limitations of Frontier agents, including the Kiro autonomous agent

Direct instructions from Slack to Kiro are not possible (indirect flow: Slack → GitHub Issue → Kiro)
Starting a Security Agent design review requires manual operation in the Web App (upload can be automated via API)
The DevOps Agent's Agent-ready spec requires manual copying from the Web App (API reference not yet published)
There is no function to explicitly export Kiro's learned content (needs verification through an indirect method of requesting Steering file creation)

In conclusion

GitHub Actions and AWS API By leveraging this approach, we were able to bring the Kiro Autonomous Agent closer to being a "member of the team."

We were able to build a configuration where Kiro follows the same workflow as a human developer, from retrieving Backlog issues and implementation to review by the Security Agent, Slack notifications, and updating Backlog status. By providing team conventions in a Steering file, Kiro can write code that "befits a team member" from its very first task.

We also confirmed that the DevOps Agent's Agent-ready spec can be used directly as instructions for Kiro, and that patterns learned from past PR history can be output as Steering files.

Currently, indirect collaboration via GitHub Issues is the main method, but as the Frontier Agents ecosystem evolves, the scope of direct collaboration and automation between agents may expand even further.

Reference

Kiro autonomous agent

https://kiro.dev/docs/autonomous-agent/

Creating tasks

https://kiro.dev/docs/autonomous-agent/using-the-agent/creating-tasks/

AddArtifact API - AWS Security Agent

https://docs.aws.amazon.com/securityagent/latest/APIReference/API_AddArtifact.html

BatchGetFindings API - AWS Security Agent

https://docs.aws.amazon.com/securityagent/latest/APIReference/API_BatchGetFindings.html

Backlog API

https://developer.nulab.com/docs/backlog/

[AWS] Catching up on the basic functions of Kiro Autonomous Agent (Preview) [FrontierAgents]

Nao San — Wed, 01 Apr 2026 11:57:45 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/dff5729a2bab7fe84d73

Introduction

Kiro Autonomous Agent is an AWS Frontier Agent that autonomously executes development tasks. When you assign a task via a GitHub Issue, it automatically analyzes the codebase, plans, implements the changes, and creates a pull request.

This article provides an overview of Kiro Autonomous Agent and explains its basic usage, with screenshots.

After reading this article, you will be able to:

Understand the mechanisms and features of Kiro Autonomous Agent
Create tasks from GitHub Issues or the Kiro UI and have the agent execute development tasks
Review generated pull requests and improve the agent's quality through feedback

In a previous article, we introduced other AWS Frontier Agents: Security Agent and DevOps Agent.

[AWS] AWS Security Agent & DevOps Agent Setup Guide [FrontierAgents]

https://dev.to/aws-builders/aws-aws-security-agent-devops-agent-setup-guide-frontieragents-lbn

[AWS] Achieving AIOps with FrontierAgents [FrontierAgent]

https://dev.to/aws-builders/aws-achieving-aiops-with-frontier-agents-frontier-agent-2i7f

The Kiro Autonomous Agent introduced here is a service classified as a "Frontier Agent," just like the agents mentioned above, and is responsible for the development phase. In future articles, we plan to examine the integration of these three Frontier Agents.

What is Kiro Autonomous Agent?

Frontier Agents

AWS offers a category of highly autonomous AI agents called "Frontier Agents." Unlike traditional AI assistants, they have the following three characteristics:

Autonomous: Once the goal is specified, the agent itself determines how to achieve it.
Scalable: It can perform multiple tasks simultaneously and distribute work to sub-agents.
Independent Operation: It can operate for hours to days without human intervention.

Currently, AWS offers three Frontier Agents.

Agent	Phase	Role
Kiro Autonomous Agent	Development	Autonomous execution of development tasks (feature implementation, bug fixing, test creation)
AWS Security Agent	Development to Deployment	Security review and penetration testing
AWS DevOps Agent	Deployment to Operation	Incident response and prevention recommendations

This article introduces the Kiro Autonomous Agent, which is responsible for the development phase.

Overview of Kiro Autonomous Agent

The Kiro Autonomous Agent is a frontier agent that independently performs development tasks. From feature implementation to bug fixing, it operates asynchronously in an isolated sandbox environment.

Currently, it is being rolled out in preview to Kiro Pro, Pro+, and Power users in stages.

Key Features:

Autonomous Task Execution: Assign tasks from GitHub Issues or the Kiro UI to analyze the repository, plan, implement, and create a pull request.
Multi-Repository Support: A single task can span multiple repositories, creating a pull request for each.
Persistent Context: Maintain context across sessions and continuously learn from code review feedback.
GitHub Integration: Start tasks from GitHub Issues using the /kiro command or kiro label. Feedback commands for pull requests (/kiro all, /kiro fix) are also available.
Chat Function: Discuss approaches before creating tasks and steer (correct direction) during task execution. Limit of one task per chat.
Team Tool Integration: Connect to team tools such as GitHub, Jira, and Slack.
Steering File: Define team standards, conventions, and architectural patterns in .kiro/steering/ to improve agent output quality.

How to Create a Task

There are two main ways to assign a task to the Kiro Autonomous Agent.

Setup (First Time Only)

Before creating a task, you need to link your GitHub account.

Access app.kiro.dev/agent and log in with your Kiro account.

From Settings, click "Connect" Select “GitHub”

Kiro Agent GitHub App Authorize

Select repositories to grant access to

A repository will be displayed if both of the following conditions are met:

The Kiro Agent GitHub App is installed and authorized for that repository.
Your GitHub account has access rights to that repository.

Note: When selecting repositories, please select only trusted repositories. Especially when mixing public and private repositories, the agent follows the instructions of the code within the repository, so it can be affected if malicious code is included.

↓This is what it will look like when completed

↓You can also see Kiro under "Installed GitHub Apps" on the GitHub screen

Method 1: Creating Tasks from the Kiro UI

You can create tasks directly from the Kiro web interface.

Multi-repository tasks are also possible:

"Add a new API endpoint to the backend service and update the frontend client."

Method 2: Creating from a GitHub Issue

You can also assign tasks using GitHub Issues. This may be more natural for developers, as it allows them to utilize the agent without disrupting their usual workflow.

Starting with the `/kiro` command

Writing /kiro in a GitHub Issue comment will cause the agent to receive it as a task.

Starting with the `kiro` label

You can also start a task by adding the kiro label to a GitHub Issue. Adding the label allows the agent to utilize all comments on the Issue as contextual feedback.

↓When an issue is published, Kiro will start implementation

↓ You can also confirm that the task is running on the Kiro web interface.

Note: When using the /kiro command, your GitHub account must be registered with Kiro. If not registered, you will be prompted to sign up. Also, the Kiro Agent GitHub App must be installed on the target repository.

Chat Function

You can chat with the agent before and after creating a task.

Before Task Creation

Discuss implementation approaches
Confirm requirements and constraints
Get the agent's opinion on technical decisions

The agent will answer using web searches, learning from past code reviews, and context from other tasks.

Task Execution

Even after a task is created, you can continue chatting and do the following:

Steering the implementation approach
Providing additional requirements or constraints
Requesting additional work after reviewing initial results

Additional comments and steering will update the scope of the current task. You cannot create a second task in the same chat. If you want to work on another task, start a new chat.

Task Execution Flow

Once a task is assigned to an agent, it operates in the following structured process:

``
① Environment Setup

Starting the sandbox, loading the MCP server

↓
② Repository Analysis

Clone the repository and analyze the codebase

↓
③ Plan → Execute (One-Shot Progress)

Planning, distributing work to sub-agents,

Implementing while iterating through change verification

*Pause and ask questions only if there are unclear points

↓
④ Completion

Creating a PR, monitoring feedback and CI results
`plaintext

Notably, the process proceeds from planning (③) to execution and PR creation (④) in one go. You won't be asked to approve the plan midway through. The agent will only enter a "Needs attention" state and ask questions if they are unsure of what to do.

Let's actually perform the task and follow each step.

Topic

This time, we will request an agent to "add a priority function" to the TODO app (API Gateway + Lambda + DynamoDB + Cognito CDK configuration) used in the previous article series.

The existing TODO app has the following CRUD APIs:

Method	Path	Description
POST	/todos	Create TODO
GET	/todos	Get a list of my TODOs
GET	/todos/{id}	Get TODO details
PUT	/todos/{id}	Update TODO
DELETE	/todos/{id}	Delete TODO

The current TODO data model consists of the fields id, userId, title, description, completed, createdAt, and updatedAt. We're requesting a task to add a priority (high/medium/low) field here, allowing filtering by priority when retrieving the list.

Reasons for choosing this task:

It allows us to evaluate whether the agent can understand existing code patterns (Lambda handler structure, DynamoDB access patterns) and implement them consistently.
It requires changes across multiple files (createTodo, getTodos, updateTodo + CDK stack definition), allowing us to see the agent's planning ability.
It's not too complex and has a good scope for an article topic.

Task to request from the agent

Request the task via GitHub Issue or Kiro UI as follows:

`
Add priority functionality to the TODO app.

Requirements:

Add a priority field (high/medium/low) to TODOs
Allow specifying priority when creating a TODO (default is medium)
Allow changing priority when updating a TODO
Add filtering by priority parameter to GET /todos
Implement in accordance with existing code patterns (Lambda handler structure, error handling) `plaintext

Step 1: Environment Setup

Upon receiving a task, the agent first launches an isolated sandbox environment. Cloning the repository, installing dependencies, loading the MCP server, etc., are performed automatically.

Step 2: Repository Analysis

The agent analyzes the codebase to understand the project structure, the technology stack being used, and existing patterns.

Step 3: Planning → Execution → PR Creation

Based on the analysis results, the agent internally plans and proceeds with implementation.

↓After implementation is complete, the changes will be summarized and explained.

↓PR creation is completed, and the GitHub URL is provided.

↓"Give The "feedback" was feedback regarding the preview version of the service.

↓GitHub screen

The agent internally plans and then proceeds with implementation. It doesn't pause at the planning stage to await approval; it proceeds directly from planning to execution to PR creation. It only enters the "Needs attention" state and asks questions if there are any unclear points.

In short, developers primarily intervene after a pull request (PR) has been created. By reviewing the PR and providing feedback using the /kiro all or /kiro fix commands if necessary, the agent will commit the fix.

The clearer the task description, the higher the likelihood that the agent will implement it as intended. Discussing the approach via chat beforehand is also effective.

Once implementation is complete, the agent creates a PR on GitHub. The PR includes a description of the changes, the implementation approach, and any trade-offs considered. Both the task creator and the agent are listed as co-authors in the commit.

Feedback on PRs

There are several ways to provide feedback on a PR.

Feedback from app.kiro.dev/agent

Feedback can also be provided from the task view.

GitHub Actions feedback (automatic checks, tests, security scans) is automatically handled when a user provides feedback.

Once feedback is provided, the task transitions from Queued to In progress, and the agent begins working on the fix.

↓Check on GitHub screen

Feedback Commands on GitHub

/kiro all: Addresses all comments from all reviewers at once
/kiro fix: Addresses comments in a specific conversation thread

If there are comments you don't want to address, delete them or reply with your opinion before using the command.

↓ Comments with /kiro fix are immediately marked as "read"

↓ Confirm that the modification has started on the Kiro web screen.

↓When the modification is complete, you will be guided to the pull request you created.

↓You can also check Kiro's work on GitHub

Task Lifecycle

A task transitions through the following states:

Status	Description
Queued	Waiting state when the concurrent execution limit (10 tasks) is reached.
In progress	Agent is actively working.
Needs attention	User input or confirmation is required.
Completed	Task completed, PR created. Further work is possible with feedback.
Cancelled	Cancelled. Cannot be resumed.

The "Needs attention" status occurs when the agent is unsure of what to do or needs additional information. Answering the question will allow the agent to resume work.

Even in the "Completed" status, you can request further work by sending feedback to the PR.

Persistent Context and Learning

One of the distinctive features of the Kiro Autonomous Agent is persistent context and continuous learning.

Persistent Context

The agent maintains context across sessions. Understanding the codebase gained from the first task is utilized in subsequent tasks.

Learning from Code Reviews

When you send code review feedback to a pull request, the agent learns from that feedback. Feedback such as "This is how we write code in our team" or "Please avoid this pattern" will be reflected in future tasks.

Importantly, only the feedback from the task creator (yourself) influences the agent's learning. Comments from other reviewers do not affect the agent's learning.

Utilizing Steering Files

In addition to code review feedback, you can also communicate the team's standards, conventions, and architectural patterns to the agent in advance by placing Steering files in the .kiro/steering/ directory.

.kiro/ └── steering/ ├── coding-standards.md # Coding Conventions ├── architecture.md # Architectural Patterns └── testing.md # Testing Policy

Defining Steering files makes it easier for agents to generate code that conforms to the team's conventions from their first task. The official documentation highlights the following uses as particularly effective:

Coding conventions
Architectural patterns
Technology stack preferences
Testing approaches

In conclusion

Kiro Autonomous Agent is a frontier agent that autonomously performs repository analysis, planning, implementation, and PR creation simply by assigning tasks via GitHub Issues.

This time, we requested a feature modification for an existing TODO app from the Kiro Autonomous Agent.

Previously, Kiro would start implementation only after specification creation, confirmation, and approval. However, in this test, after a human communicated the requirements, the process went straight to PR creation.

While Kiro's more autonomous operation reduces human intervention, it seems necessary to communicate the initial requirements and specifications more accurately.

Since it's still in preview, we don't know what it will be like after GA, but I'm looking forward to the future where humans and Frontier Agents like Kiro collaborate to create great things.

Reference

Kiro autonomous agent

https://kiro.dev/docs/autonomous-agent/

Setup

https://kiro.dev/docs/autonomous-agent/setup/

Using the agent

https://kiro.dev/docs/autonomous-agent/using-the-agent/

Creating tasks

https://kiro.dev/docs/autonomous-agent/using-the-agent/creating-tasks/

Chatting with the agent

https://kiro.dev/docs/autonomous-agent/using-the-agent/chatting/

GitHub Integration

https://kiro.dev/docs/autonomous-agent/github/

Agent Sandbox

https://kiro.dev/docs/autonomous-agent/sandbox/

Amazon launches frontier AI agents

https://www.aboutamazon.com/news/aws/amazon-ai-frontier-agents-autonomous-kiro

[AWS] Achieving AIOps with Frontier Agents [Frontier Agent]

Nao San — Tue, 31 Mar 2026 22:12:24 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/22b87cd8d28e3675e5c2

Introduction

In the previous article, we explained the setup of AWS Security Agent and DevOps Agent. This article will explain more practical ways to use them.
Security Agent can perform security reviews of GitHub pull requests (PRs) and design document reviews.
DevOps Agent can use AI to investigate, analyze, and predict incidents related to GitHub repositories and resources deployed on AWS.
By using these in conjunction, you can improve the efficiency of AI-powered development and operations (DevOps), essentially achieving AIOps.

[AWS] AWS Security Agent & DevOps Agent Setup Guide [FrontierAgents]

https://qiita.com/Nana_777/items/b5edfacdb00c3e9f6d17

Prerequisites

This article assumes that the Security Agent and DevOps Agent have already been set up (Agent Space creation, GitHub integration, and code review activation).

Challenges of DevOps

To accelerate system development and operation while ensuring quality, the following challenges exist:

Security reviews fail to keep pace with development speed, becoming a release bottleneck.
Penetration testing is conducted only a few times a year, operating on a different timeline than the development cycle.
Incident response is dependent on individual employees, and preventative measures are not fed back into the next development cycle.
Security knowledge gained in the development phase is not carried over to the operations phase.

To address these challenges, combining two AWS Frontier Agents, "AWS Security Agent" and "AWS DevOps Agent," allows for the creation of a system where AI performs security reviews and incident monitoring more autonomously.

This article uses a simple TODO application as an example to introduce the overall structure of combining these two agents and follows the construction procedure with a specific scenario.

Two Frontier Agents

AWS Security Agent

The AWS Security Agent is a Frontier Agent that protects applications throughout the entire development lifecycle. It primarily provides three functions.

Design Security Review

Before writing code, the design documentation is validated against the organization's security requirements. Based on the requirements defined by the security team in the AWS console (approved authorization libraries, logging standards, data access policies, etc.), design flaws are identified early.

Code Security Review

Pull requests (PRs) on GitHub are automatically detected and analyzed against the organization's security requirements and common vulnerabilities (insufficient input validation, SQL injection, etc.). Findings are provided directly as PR comments on GitHub, allowing developers to receive security feedback within their normal workflow.

Penetration Testing

Multi-stage attack scenarios are executed on demand to identify vulnerabilities that cannot be detected by automated scanning tools (DAST/SAST). If vulnerabilities are found, a PR including impact analysis, reproducible attack paths, and corrective code is automatically generated on GitHub.

AWS DevOps Agent

The AWS DevOps Agent is a frontier agent that autonomously resolves and prevents incidents.

24/7 Autonomous Incident Response

Investigation begins the moment an alert or support ticket is generated. It correlates telemetry data from observability tools (Amazon CloudWatch, Datadog, New Relic, etc.), code change history from GitHub repositories, and deployment history from CI/CD pipelines (GitHub Actions) to identify the root cause.

Preventive Recommendations

It analyzes past incident patterns and proposes improvements in the following areas:

Observability: Enhanced monitoring, alerting, and logging
Infrastructure Optimization: Auto-scaling and capacity tuning
Deployment Pipeline Enhancement: Addition of tests and validations (including improvements to GitHub Actions workflows)

Application Topology

It automatically maps resources and their relationships, visualizing them as a topology graph. This helps understand the overall impact on the architecture during incident investigations.

GitHub-centric features

The Security Agent monitors, comments on, and generates corrective PRs for GitHub pull requests, while the DevOps Agent utilizes code changes and deployment history from GitHub repositories for analysis.

Integration Diagram of Each Service

By combining the two agents, you can build a security check and incident analysis configuration like the one shown below.

The key point is that GitHub functions as the hub for the integration of each service.

The Security Agent interacts with developers through PRs on GitHub, and the DevOps Agent utilizes GitHub's code change and deployment history for analysis.

Subject: TODO App Configuration

This section introduces the configuration of the TODO app used in this scenario.

AWS Configuration (Serverless)

[Client]
↓ HTTPS
[API Gateway]
↓
[Lambda] ←→ [DynamoDB]
↑
[Cognito] (Authentication)
[CloudWatch] (Monitoring → DevOps Agent references)
[GitHub Actions] (CI/CD)

API Gateway + Lambda: CRUD API for TODOs
DynamoDB: Storing TODO data
Cognito: User authentication (JWT token)
CloudWatch: Metrics, logs, alarms
GitHub Actions: Deployment to staging and production environments (SAM or CDK)

*See the DevOpsAgent topology screenshot below for the configuration diagram.

API Endpoints:

Method	Path	Description
POST	/todos	Create TODO
GET	/todos	Your Get TODO list
GET	/todos/{id}	Get TODO details
PUT	/todos/{id}	Update TODO
DELETE	/todos/{id}	Delete TODO

Although the configuration is simple, we will intentionally include several vulnerabilities during development to elicit detection from the Security Agent.

Service integration procedure followed with a specific scenario

Step 1: Design Review (Security Agent × AWS Console)

Create a design document for the TODO application and upload it to the Security Agent. The design document should include the following:

API endpoint design
Authentication and authorization flow (Cognito + JWT)
Data model (DynamoDB table design)
Error Handling Policy

↓ Select Start with Web App

Security The agent validates the design document against your organization's security requirements and returns findings.

After a short wait, the status will change to Completed.

The review results can be viewed in a summary to see how many issues were found for each level of urgency.

Each review result is displayed in a list.

You can view the details of each review result.

Review results can be downloaded as a CSV file

Review results can also be downloaded as a CSV file.

The following review results were obtained this time:

Item	Result	Points of Concern
Authentication Best Practices	COMPLIANT	Cognito + JWT authentication is appropriate
Authorization Best Practices	NON_COMPLIANT	Owner checks that allow users to access only their own TODOs are not described in the design
Secret Protection	INSUFFICIENT_DATA	It is unclear whether Lambda uses IAM roles or how secrets are managed and rotated
Default Security Settings	INSUFFICIENT_DATA	Default settings such as DynamoDB encryption, API Gateway TLS enforcement, and Cognito password policy are not described
Log Protection	INSUFFICIENT_DATA	Masking of sensitive data, log retention period, and access control are not described
Information Protection	INSUFFICIENT_DATA	DynamoDB encryption and API Gateway TLS enforcement are not explicitly stated
Audit Log	INSUFFICIENT_DATA	Undefined log entry content and which events to log
Tenant Isolation	INSUFFICIENT_DATA	Multi-tenant configuration, but no owner verification code
Custom Requirement (Owner Verification)	INSUFFICIENT_DATA	Owner verification logic for GET/PUT/DELETE /todos/{id} is not described in the design

The developer will revise the design based on these points and proceed with implementation.

Step 2: Code Review (Security Agent × GitHub PR)

Implement the code based on the revised design and create a PR on GitHub. Here, the PR will intentionally include several vulnerabilities to observe how the Security Agent works.

todo-api-security-demo/
├── bin/
│ └── todo-api.ts # CDK entry point
├── lib/
│ └── todo-api-stack.ts # CDK stack definition
├── lambda/
│ ├── createTodo.ts # No input validation (intentional)
│ ├── getTodos.ts
│ ├── getTodo.ts # No authorization check (intentional)
│ ├── updateTodo.ts # No authorization check or input validation (intentional)
│ └── deleteTodo.ts # No authorization check (intentional)
├── package.json
├── cdk.json
└── tsconfig.json

When you create a PR, the Security Agent automatically detects and analyzes the code. I will submit a pull request for code containing a vulnerability for testing purposes.

I will receive a message from SecurityAgent indicating that it is under review.

After SecurityAgent's review is complete, the review results will be returned.

Security Agent's findings clearly state three points: "What is the problem?", "Why is it important?", and "How should it be fixed?", allowing developers to take immediate action.

``
What is the problem? The catch block serializes both (error as Error).message and (error as Error).stack into an HTTP 500 response body. In a Lambda environment, the .stack internal file path (e.g., /var/task/lambda/createTodo.js:NN), DynamoDB table name, and AWS SDK call chain are exposed.

Why is this important? Because if stack traces and error messages are leaked, attackers can gain precise knowledge of internal implementation details, table names, code structure, etc., directly reducing the effort required for targeted attacks.

What are the recommendations? Replace the response body of the catch block with only a hardcoded static string: body: JSON.stringify({ message: 'Internal server error' }). Log the full error only to CloudWatch: console.error(error).

`plaintext

Below are some of the issues discovered:

Information leakage (stack trace)
Missing owner check (IDOR)
XSS (Cross-site scripting)

Developers should review the reports on GitHub and commit fixes. If the Security Agent re-checks and finds no issues, merge the PR.

Step 3: Incident Monitoring (DevOps Agent × Production Environment)

After correcting the code review findings, merging, and deploying, the DevOps Agent updates the application topology. For a TODO app, the dependency between API Gateway → Lambda → DynamoDB is visualized as the topology.

The DevOps Agent correlates the following data to monitor the impact of deployments:

CloudWatch metrics (Lambda error rate, API Gateway 5xx rate, DynamoDB throttling)
CloudWatch Logs (Lambda execution logs)
GitHub repository code change diffs
GitHub Actions Deployment History

Here, to observe the DevOps Agent's incident investigation behavior, we intentionally deploy code containing a bug to generate an error. We introduce a bug in the Lambda handler that causes a runtime error, resulting in a 500 error when a request is sent to the API. When a CloudWatch alarm (Lambda error rate threshold exceeded) is triggered, the DevOps Agent automatically begins an investigation.

Confirm that a CloudWatch alarm occurred.

Investigate recent alarms with DevOpsAgent.

An alarm investigation is initiated.

The investigation status can be checked on the dashboard.

After the investigation is complete, the "Investigation Timeline" will show what was investigated and the underlying cause.

The DevOps Agent correlated GitHub pull request history, code change diffs, and CloudWatch error logs to accurately identify the root cause.

The "Root Cause" tab provides explanations of the root cause and its scope of impact.

Clicking the "Generate mitigation plan" button displayed in the Root Cause tab creates a mitigation plan.

The mitigation request outlines specific actions for resolution.

Summary of Mitigation Plan:

Recommends creating a new PR to revert PR #4, reapplying the security fixes from PR #3, and redeploying with CDK.
Proposes the following requirement changes for agent-enabled specifications:
Implement input validation for the todoId parameter in getTodo.ts
Implement secure error handling in all Lambda handlers (do not include stack traces in the response)
Implement user ownership checks in getTodo.ts

Detected incidents and response methods are registered as Issues on GitHub.

Because DevOpsAgent compiles information on incidents and response methods, registering this information as a GitHub Issue is less burdensome.
A cycle can be established where registered Issues are addressed using Kiro, reviewed by SecurityAgent, deployed, and then monitored again by DevOpsAgent.

Note: Extending DevOps Agent with MCP Servers
DevOps Agent supports MCP (Model Context Protocol), and its functionality can be extended by adding an MCP server to the Agent Space. For example, by hosting and connecting to a GitHub MCP server, it is possible to automatically create GitHub Issues based on the investigation results. However, currently, a hosted endpoint URL is not provided, so you will need to host your own MCP server.

Step 4: Preventive Recommendations (DevOps Agent)

DevOps Agent analyzes the application configuration and past incident patterns and presents preventive recommendations.
Select "Prevention" from the left menu of the web app.

Select "Run Now".

Please wait a moment for the results to appear.

↓Summary of Content

`
Category: Governance
Recommendation: "Implement CI/CD automation and comprehensive quality gates using GitHub Actions to prevent code regressions from reaching production."
Background: This incident involved code without input validation being deployed to production without quality gates, resulting in 100% failure of all GetTodoFunction requests.
Specific Proposal: Implement a system that runs automated tests, code coverage verification (85% or higher), TypeScript type checking, and ESLint static analysis during PR merges, and only allows CDK deployment after all checks have passed.

Based on the root cause identified in the incident investigation in Step 3 (security fix reverting to production without quality gates), specific actions to prevent recurrence are presented.

Step 5: Reflection in the Next Development Cycle

Based on the DevOps Agent's investigation results, mitigation plan, and preventive recommendations, these will be reflected in the next development cycle. Here, we add the requirements presented by the DevOps Agent in Step 3 to the Security Agent's custom security requirements so that they are automatically verified in subsequent code reviews.

This time, we will add "secure handling of error responses," which was pointed out in the mitigation plan in Step 3. Also, the "CI/CD quality gate using GitHub Actions" suggested in the preventative recommendation in Step 4 will be addressed separately as a task for the development team.

Adding a custom requirement for the Security Agent

↓The following settings were made, and "Create and enable security requirement" was performed.

Item	Content
Security Requirement Name	Secure Handling of Error Responses
Description	Do not include internal implementation details (stack trace, error message, file path) in Lambda handler error responses
Applicability	Applies to all Lambda handlers that process API endpoints, especially those that return error responses in catch blocks.
Compliance Requirements	Compliant: When an error is caught in a catch block, the response should only return a generic error message (e.g., "Internal server error"), and detailed error information should only be logged to CloudWatch Logs using console.error. Violation: Implementations that include (error as Error).message or (error as Error).stack in the response body of the catch block.
Corrective Guidance	Replace the catch block response with JSON.stringify({ message: "Internal server error" }) and log it using console.error("Error:", error).

By adding this requirement, if a developer submits a pull request in the next development cycle with code that includes a stack trace in the response, the Security Agent will automatically detect it as a violation of the organization's requirements.

This completes the integration.

Steps 1-2: Security Agent detects design and code vulnerabilities
Step 3: DevOps Agent investigates the incident and presents the root cause and mitigation plan
Step 4: DevOps Agent presents preventative recommendations (implementation of CI/CD quality gates)
Step 5: Reflect the mitigation plan and preventative recommendations in the Security Agent's organizational requirements and development tasks

In the next development cycle, the Security Agent will perform a review with the newly added organizational requirements reflected, so the same types of problems will be detected at the design and code stage.

Supplement: Utilizing Kiro IDE when automatic remediation is insufficient

While many cases can be handled by the automatically generated fix PRs from the Security Agent within the service integration, not all cases are covered.

For example, recommendations requiring architectural-level changes, such as "implementation of CI/CD quality gates" in Step 4, need to be implemented by the developer. In such cases, Kiro IDE complements the developer's efforts.

We'll proceed with the implementation while discussing "We want to add a quality gate to GitHub Actions" in Kiro's chat.
By defining the team's coding conventions and architectural patterns in the Steering file (.kiro/steering/), we can generate code that conforms to those conventions.

While the Security Agent and DevOps Agent are the main players in this collaboration, Kiro becomes a reliable partner for "fixes that require human thought and implementation."

Key Points for Implementation

Step-by-Step Implementation Approach

There's no need to immediately build a service integration configuration. You can implement it step by step using the following methods:

Step 1: Start with Security Agent Code Review

This is the easiest approach, as you can begin simply by connecting a GitHub repository. First, enable code review for an existing repository and see what kind of feedback you receive.

Step 2: Add Penetration Testing

Once you've seen the benefits of code review, add penetration testing. Run it on a staging environment and see if you can find vulnerabilities that automated scanning tools might miss.

Step 3: Deploy DevOps Agent to the Production Environment

Connect the observability tool (CloudWatch) and GitHub repository to the DevOps Agent and enable incident investigation and preventative recommendations.

Step 4: Inter-Service Integration Configuration

Establish an operational flow that reflects DevOps Agent's preventative recommendations in the Security Agent's organizational requirements. This completes the integration.

Considerations

Defining organizational security requirements is crucial for quality: Security Agent performs reviews based on defined requirements, so ambiguous requirements will reduce the accuracy of the review. It is recommended to start small and gradually enrich the requirements.
GitHub repository permission settings: Ensure that you properly configure which repositories Security Agent can access.
Integration with GitHub Actions pipelines: Consider where in the deployment pipeline to incorporate the timing of penetration test execution.
Division of roles between teams: Clearly defining roles, such as having the security team define organizational requirements, the development team handle code reviews, and the operations team evaluate preventative recommendations, will ensure smoother operation.

Summary

By combining AWS Security Agent and DevOps Agent, you can build a collaborative configuration of "Design → Code Review → Deployment → Incident Monitoring → Prevention → Next Development Cycle".

This time, we verified it with a simple TODO app. The Security Agent detected a missing authorization check as NON_COMPLIANT during the design review and pointed out IDOR, stack trace leaks, and XSS vulnerabilities at the line-of-code level during the code review. The DevOps Agent, upon incident occurrence, correlated GitHub PR history and code changes to accurately identify the root cause and presented mitigation plans and preventative recommendations (implementation of CI/CD quality gates).

This integration enables the following:

GitHub-centric workflow: Developers can receive security feedback without disrupting their usual GitHub workflow.
No human bottleneck: Security reviews and incident investigations are performed autonomously by AI agents.
Closed feedback integration configuration: DevOpsAgent's findings and preventative recommendations are reflected in the SecurityAgent's organizational requirements and automatically verified in the next development cycle.

Start with GitHub PR reviews using SecurityAgent. Simply connecting your GitHub repository is the first step towards accelerating DevOps.

Setup instructions are explained in the following article.

https://dev.to/aws-builders/aws-aws-security-agent-devops-agent-setup-guide-frontieragents-lbn

[AWS] AWS Security Agent & DevOps Agent Setup Guide [FrontierAgents]

Nao San — Sun, 29 Mar 2026 04:18:35 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/b5edfacdb00c3e9f6d17

Introduction

AWS services classified as Frontier Agents include "Kiro Autonomous Agent," "AWS Security Agent," and "AWS DevOps Agent."
Since I don't yet have access to "Kiro Autonomous Agent," this article will explain the setup procedures for starting to use "AWS Security Agent" and "AWS DevOps Agent."
AWS Security Agent and AWS DevOps Agent are services where AI agents autonomously support security and reliability from development to operations.
By using these two services, you can build a configuration that automatically reviews GitHub pull requests using "Security Agent" and a configuration that monitors and investigates incidents using "DevOps Agent."

What are AWS Security Agent / DevOps Agent?

Frontier Agents

AWS Security Agent and DevOps Agent are services provided by AWS that are classified as "Frontier Agents." Frontier agents are a new category of AI agents that differ from traditional AI assistants in their higher level of autonomy, possessing the following three characteristics:

Autonomous: Once a goal is specified, the agent itself determines how to achieve it.
Scalable: It can execute multiple tasks simultaneously and distribute the workload.
Independent Operation: It can operate for hours to days without human intervention.

Currently, AWS offers three Frontier agents:

Agent	Role
AWS Security Agent	Security verification throughout the entire development lifecycle
AWS DevOps Agent	Incident response, prevention, and operational improvement
Kiro Autonomous Agent	Autonomous execution of development tasks

This article explains the setup procedures for the Security Agent and DevOps Agent.

AWS Security Agent

The AWS Security Agent is a service that automatically verifies the security of applications throughout the entire development lifecycle. It mainly has three functions.

Design Security Review: Before writing code, verify the design documentation against the organization's security requirements.
Code Security Review: Automatically analyze GitHub pull requests and provide vulnerability detection as pull request comments.
Penetration Testing: Run attack scenarios on-demand against deployed applications to discover vulnerabilities and automatically generate fix pull requests.

AWS DevOps Agent

The AWS DevOps Agent is a service that autonomously resolves and prevents incidents. It has three main functions:

Autonomous Incident Response: Immediately initiates investigation upon alert and identifies the root cause.
Preventive Recommendations: Analyzes past incident patterns and suggests improvements to observability, infrastructure, and pipelines.
Application Topology: Automatically maps and visualizes dependencies between resources.

Integration with GitHub

Both services work in conjunction with GitHub. The setup process is as follows:

Developer creates a pull request (PR) on GitHub
↓
Security Agent automatically detects the PR
↓
Developer posts a vulnerability report as a PR comment
↓
Developer fixes, merges, and deploys
↓
DevOps Agent detects the deployment and monitors by correlating code changes and metrics

The Security Agent operates as a GitHub App and automatically generates comments on PRs and corrected PRs. The DevOps Agent also operates as a GitHub App, but it is read-only and uses code changes and deployment history as material for incident investigations.

This article explains the setup procedure for achieving this integration.

AWS Security Agent Setup

Creating an Agent Space

First, create an Agent Space for your Security Agent. An Agent Space is a logical container that holds the repositories and configurations that the Security Agent can access.

1: Open "AWS Security Agent" in the AWS Management Console.
*As of March 29, 2026, this is available in "United States (Northern Virginia)".

2: Select "Create Agent Space".

*On the initial screen, select "Set up AWSSecurityAgent".

3: Enter a name for the Agent Space (Example: test-security-space-2026)

4: Select "Set up AWS SecurityAgent" to complete the creation. Image 1

↓Confirm that AgentSpace has been created
Image 2

Adding GitHub Integration

Next, connect Security Agent and GitHub.

1: Select the Agent Space you created.
2: Select "Enable code review".
image.png

3: Select "GitHub" from "Create a new registration" and then select "Next".
image.png

4: Click "Install and authenticate". You will be redirected to:

5: On the GitHub side, select the account or organization where you want to install the AWS Security Agent GitHub App.

6: Select the repositories you want to allow access to:

"All repositories": Allow access to all repositories
"Only select repositories": Select only specific repositories (recommended)

7: Select "Install and authorize"
8: You will be redirected to the AWS console. Enter your registration name and select Connect.

Enabling Code Review

Once GitHub integration is complete, enable code review.

1: Select "Enable Code Review" in Agent Space.

image.png

2: Select your connected GitHub Organization or user.

image.png

3: Select the repository to enable code review (select using the checkbox) and select "Connect".

4: Select code review settings:

Security requirement validation: Check compliance with custom security requirements
Security vulnerability findings: Detect common security vulnerabilities
Security requirements and vulnerability findings: Check both (recommended)

5: Confirm that the code review is ready.

Setting Organizational Security Requirements (Optional)

To make Security Agent code reviews more effective, you can define organization-specific security requirements.

1: Select "Security Requirements" in Agent Space

2: Add a custom requirement (e.g., "API Resource Access Owner Check)

In the example screenshot above, the following definitions were made:
Security Requirement Name:

API Resource Access Owner Check

Description:

Verify that the requesting user is the owner of the resource when retrieving, updating, or deleting resources at an API endpoint.

Applicability:

Applies to all API endpoints that manage data per user. In particular, endpoints that access individual resources by specifying the resource ID in the path parameter (GET /resources/{id}, PUT /resources/{id}, DELETE /resources/{id}, etc.) are targeted.

Compliance Condition:

Compliance: Handlers that retrieve, update, or delete resources should compare the authenticated user's ID with the resource owner ID and return a 403 Forbidden if they do not match.
Non-Compliance: Implementations that retrieve resources from the database using only the resource ID in the path parameter and return a response without owner verification.

Corrective Guidance:

Add a check to compare the userId (owner ID) with the authenticated user's ID after retrieving the resource. If they do not match, return a 403 Forbidden response.

3: Creating and Enabling Security Requirements

This setting is optional, but enabling it will allow the Security Agent to perform reviews in accordance with your team's standards.

Operation Verification

To verify that the setup was completed correctly, let's create a test PR.

1: Create a feature branch in the target repository.

2: Make some code changes and create a pull request (PR).

SecurityAgent reviews the PR, so you need to make some changes.

In this case, since the code was already on the branch, we made a change to add a README file.

3: Check if Security Agent posts the review results as a comment on the PR.

SecurityAgent and AmazonQ automatically review the PR, and
SecurityAgent "AWS Security Agent" The pull request is currently under review. Feedback will be submitted shortly.
↓
AmazonQ: "The additions to the README documentation are well-structured and appropriate. The use case correctly demonstrates the API authentication pattern using Cognito, and all sensitive information is protected with appropriate placeholders. No critical issues were identified."
↓
SecurityAgent: "No issues were identified."
The review proceeded in this manner.

If the Security Agent comments are displayed, the setup is complete.

Please also conduct a human review, and if there are no problems, merge the PR.

*Although the branch intentionally contained vulnerable code beforehand, the review only focused on the content of this PR.

AWS DevOps Agent Setup

Creating an Agent Space

You also need to create an Agent Space for the DevOps Agent. The DevOps Agent's Agent Space is a container that defines the AWS accounts to be monitored, tool integrations, and access permissions.

1: Open "AWS DevOps Agent" in the AWS Management Console.

2: Select "Create Agent Space" (or "Start Setup" the first time) to create the Agent Space.

Since I am Japanese, I selected "Japanese" for the Agent response language so that the results would be returned in Japanese.

Adding GitHub Integration

Connect the DevOps Agent to GitHub. The DevOps Agent's GitHub integration is registered at the AWS account level and can be shared across multiple Agent Spaces.

1: Open the "Features" tab on the details screen of the DevOpsAgent you created.
2: Click "Add Source" in the "Pipeline" section.

3: Select "Register" for "GitHub".

4: Select connection type:

User: Your personal GitHub account
Organization: GitHub Organization

5: Clicking "Submit" will redirect you to GitHub.
6: Select the account to install the AWS DevOps Agent GitHub App.

7: Select the repository you want to allow access to.

8: Verify that the repository registered in the pipeline is displayed.

Difference from Security Agent: The DevOps Agent's GitHub App has read-only access to repositories. It receives deployment events and code changes and uses them for correlation analysis during incident investigations.

About Observability Tools

The DevOps Agent automatically gains access to Amazon CloudWatch within the same AWS account when creating an Agent Space. Since CloudWatch access permissions are included in the primary account's role settings, no additional connection configuration is required.

If you are using third-party tools such as Datadog, New Relic, Dynatrace, or Splunk, separate connection configuration is required. These can be added from the "Features" tab in the DevOps Agent.

Operation Verification

Verify that the setup was completed correctly.

Prerequisites: To check the topology and resource status of the DevOps Agent, some application must be deployed within your AWS account. If you haven't deployed one yet, please deploy your application first. The DevOps Agent currently operates in the US region, but it can also recognize resources from applications deployed in other regions, such as the Tokyo region.

1: Verify that the topology is built in the DevOps Agent Web App.

2: Ask a simple question in DevOps Agent Chat (e.g.: "Please tell me the current status of the resources."

If the topology is displayed and you receive a response in Chat, the setup is complete.

What you can do with DevOps Agent

In this chat, you can check various aspects of the deployed configuration with the AI.
It seems like it can be effectively used to check the system's contents and find areas for improvement.

For example, you can do the following:

Check Resource Details

If you ask, "Please tell me about the Lambda function [Lambda Name]," it will provide you with details about that resource, as shown below:

Vulnerability Assessment

If you ask, "Are there any vulnerabilities in the Lambda function's code?", it will provide you with a vulnerability assessment report.

Summary

This article explained the setup procedures for AWS Security Agent and DevOps Agent.

This setup enables the Security Agent to automatically review GitHub pull requests and identify vulnerabilities, while the DevOps Agent allows for the construction of application topologies, configuration verification, and incident monitoring and investigation.
We believe that applying SecurityAgent and DevOpsAgent can further improve the efficiency of security assessments and operational monitoring of deliverables. We will continue to share information about FrontierAgents in future articles.

References

What is AWS Security Agent?

https://docs.aws.amazon.com/securityagent/latest/userguide/what-is.html

About AWS DevOps Agent

https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent.html

Review code security findings in GitHub

https://docs.aws.amazon.com/securityagent/latest/userguide/review-code-findings-github.html

Public preview pricing and limits - AWS DevOps Agent

https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-public-preview-pricing-and-limits.html

AWS Security Agent FAQs

https://aws.amazon.com/security-agent/faqs/

[AWS] Parallel execution of tasks using Kiro's custom subagents [Kiro]

Nao San — Sat, 07 Feb 2026 22:54:51 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/c63d0734542981a89672

Introduction

Custom Subagents were implemented in Kiro's IDE on February 5, 2026.
By utilizing custom subagents, you can define and execute routine tasks in parallel.
This article explains how to use Custom Subagents.

Conclusion

Custom subagents can execute arbitrarily defined tasks.
Useful for automating repetitive tasks.
Multiple custom subagents can be executed in parallel.
Detailed definition and accuracy verification are required to ensure custom subagents function as expected.
In this test, some unexpected results were observed with the custom subagent.
Content that is not specified in detail is determined by the AI, resulting in results that are unexpected.
Too much detail can lead to overloading the context window and making maintenance difficult.

Subagents

When executing multiple tasks, multiple subagents can execute tasks in parallel under instructions from Kiro's main agent.

For example, if multiple issues are registered on GitHub, the main agent can be asked to retrieve the issues and execute tasks using multiple subagents. The multiple subagents will then share the tasks.

This reduces the overall time it takes to complete tasks.

↓ Subagent Image

Custom Subagent

The February 5, 2026, update to Kiro implemented the custom subagent feature.
As the name suggests, custom subagents allow you to predefine the tasks to be performed by the subagent (which tools to use and how to execute them).

Custom Subagent Use Cases

When using custom subagents, it's useful to define tasks that are "repeated," "have a set procedure," and "have complex assumptions, constraints, and procedures."

For example, a custom subagent that reviews code using the same tool, with the same criteria and emphasizing the same perspectives, or a custom test execution subagent that outputs results according to a format specified by a human each time, would be effective.

Illustration of the Difference Between Custom Agents and Skills

A similar feature is AgentSkills, but AgentSkills are like a collection of functions that extend the main agent. The PDF-related SKILL.md file introduced last time defines a set of PDF-related functions such as "Create PDF," "Merge PDF," and "Split PDF."
In contrast, custom agents define the details of a single task, such as a review task, including which tools (MCP or Skills) to use, the steps to take, and what to pay attention to when executing the task.

Previous AgentSkills article

https://qiita.com/Nana_777/items/4d05e92622f928481e29

↓ Illustration of the difference between custom agents and Skills

In the diagram above, Skills is like a carpentry manual that describes how to make chairs, desks, and other items. Custom subagents are like specialized craftsmen who make chairs and desks.

Custom Subagent Definition

You can define custom subagents by chatting with Kiro.
There is no strict formatting other than the attribute, but you can generally define the following:

Attribute

name

Required. This is the agent's unique identifier, and the custom subagent will be called by this name.
As such, it must be unique among other agents.
Only lowercase letters and hyphens are allowed.

description

Required. This is a short sentence (one or two lines) that describes the agent's role and function. If you want to target any languages, specify this here.

tools

Specify the rule categories the agent can use.
Categories include the following:

read: Read a file
write: Write a file
shell: Execute a shell command
web: Web search
spec: Spec file operations (only valid in spec mode)
includeMcpJson: If true, include all MCP tools.
@ < mcp_server>: Include all tools from a specific MCP server.
@ < mcp_server>/< tool>: Include a specific tool from a specific MCP server. For other tool definitions, refer to the Kiro documentation.

model

Optional. Specify a model ID if you want to use a specific AI model.
If not specified, the default model (the model used when calling the custom subagent) will be used.

For example, define the attribute as follows:


---
name: cdk-code-reviewer
description: "An agent that performs detailed reviews of AWS CDK code from the perspectives of best practices, security, cost optimization, and performance. It provides assessments based on the Well-Architected Framework and specific improvement suggestions in Japanese."
tools: ["read", "write"]
---

Agent Roles and Responsibilities

Describe the subagent's roles and tasks.

This section will overlap with the description and procedures listed in the Attributes, but it should provide a list of the tasks the subagent will perform without providing detailed instructions.


## AWS CDK Code Review Agent

You are an expert agent specializing in AWS CDK (Cloud Development Kit) code reviews.

### Roles and Responsibilities
1. **Security** - Evaluate based on the security pillar of the AWS Well-Architected Framework
2. **Cost Optimization** - Reduce unnecessary costs and recommend efficient resource utilization
3. **Performance** - Ensure optimal resource configuration and scalability
4. **Reliability** - Evaluate high availability, disaster recovery, and backup strategies
5. **Operational Excellence** - Review monitoring, logging, and deployment strategies
6. **Best Practices** - CDK-specific recommended patterns and naming conventions

About Tools Used (MCP, Powers, Skills, etc.)

When calling tools external to Kiro, define the tool name and its purpose as follows:

### Available Tools

#### AWS Infrastructure as Code Power
Use the following tools during your review:

1. **cdk_best_practices** - Get the CDK Best Practices Guide
- Be sure to do this at the start of your review
- Refer to the latest security guidelines, architecture patterns, and development workflows

2. **search_cdk_documentation** - Search the official CDK documentation
- Verify the correct usage of specific constructs
- Research recommended settings for properties and methods

3. **search_cdk_samples_and_constructs** - Search CDK code samples
- See implementation examples following best practices
- Check for language-specific idioms

4. **validate_cloudformation_template** - Validate a CloudFormation template
- Check the syntax of templates synthesized with CDK code
- Validate resource properties

5. **check_cloudformation_template_compliance** - Check security compliance
- Ensure compliance with AWS Control Tower proactive controls
- Detecting Violations of Security Best Practices

Task Execution Procedure

Enter the title and details of each step to perform the task.
Details include which tools will be used and which commands will be executed.
For example, define it as follows:

### Review Process
#### 1. Code Analysis
(Details of the procedure, what to consider during this step)
#### 2. Security Check
(Details of the procedure, what to consider during this step)
#### 3. Cost Optimization Check
(Details of the procedure, what to consider during this step)
#### 4. Performance Check
(Details of the procedure, what to consider during this step)
#### 5. Best Practice Check
(Details of the procedure, what to consider during this step)

Output Format

In what language? In what format, such as Markdown?
If the output format is fixed and you want to assign values, define it by enclosing it in "

```" as follows:



## AWS CDK Code Review Results

### Summary
- Review Target: [File/Directory Name]
- Issues Found: Critical: X, High: Y, Medium: Z, Low: W
- Overall Rating: [Excellent/Good/Needs Improvement/Severe Issues]

### Critical (Severe)
#### [Issue Title]
**Location**: `File Name:Line Number`
**Problem**: [Specific Problem Description]
**Risk**: [Security Risk, Cost Impact, Performance Impact, etc.]
**Recommended Action**: [Specific Fix]

Error Handling

Define the desired behavior when an error occurs during execution of a custom subagent.
For example, define it as follows:



### Error Handling

- Detailed analysis of error messages when test execution fails
- Suggests running `npm install` if there are dependency issues
- Identifies stack definition issues when CDK synth fails
- Suggests test optimization when a timeout error occurs

Usage Examples

Define usage examples when using a custom subagent that generates multiple documents, such as when you want to generate only some of the documents.
Define it as follows:



### Usage Example

If a user requests "Generate project documentation":
1. Analyze the project structure
2. Read key files
3. Generate a comprehensive set of documentation
4. Report an overview of the generated documentation

If a user requests "Generate only API documentation":
1. Identify the public API
2. Analyze the details of each API element
3. Generate API.md
4. Report the generated documentation

Verifying the operation of a custom subagent

Creating a custom subagent

As an example, we created three agents: a "CDK code review agent," a "documentation generation agent," and a "test execution agent."

Requesting parallel execution

To run the subagents we created in parallel, we send a chat request saying, "Please generate documentation, review CDK code, and run tests. If possible, please run them in parallel."

↓ We were able to confirm that the custom subagents were running in parallel.

Execution Results

The following results were confirmed after the custom subagents were executed.

The code review executed the defined tasks and output the results in the specified format.

↓ Specifying the output format for code review results

↓ Actual output results

The test execution custom subagent does not handle undefined errors.

The test execution custom subagent executed the tests and output the results as defined.
However, test coverage was determined to be 0% due to a problem with the Jest configuration.
This is likely because the custom subagent has not defined any behavior to correct issues when coverage values are inaccurate due to insufficient configuration.
If you want the configuration to be corrected when a problem occurs, you will need to explicitly define in the custom subagent which issues the corrections should be made when they occur.

Project documentation generation also generated documentation other than what was defined.

The custom documentation generation subagent defines the following files, as shown in the screenshot below:
README.md: Project overview, installation, and quick start
API.md: Detailed API specifications and references
ARCHITECTURE.md: System architecture and design philosophy
USAGE.md: Detailed usage instructions and sample code
CONTRIBUTING.md: Developer guide (if necessary)
Five types of files were defined.

As shown in the screenshot below, nine files were actually generated, including "PROJECT_OVERVIEW.md," which contains the project summary that should have been included in the README.

This result appears to be an autonomous decision made by the custom subagent based on the following criteria:

Agent Autonomous Decision-Making: Determine an appropriate structure for the project's scale.
Readability Considerations: Keep README.md concise.
Separation of Concerns: Separate information for different purposes into different files.
Best Practices: Follow industry standards for document structure.

If you want to prevent such autonomous decision-making by the agent, you need to define stronger behavioral restrictions, such as "Create only defined files, and do not create any other files."

Verification of the Efficiency of Sequential and Parallel Execution

In this verification, we reviewed, tested, and created documentation, and then measured the execution time to see if it truly improved efficiency.
AI Model: ClaudeHaiku 4.5
Verification Method: Kiro measured the sequential and parallel execution times.

Comparison Results: With parallelization, all tasks were completed within the execution time of the longest task.

The results, as shown in the image above, were as follows:
Sequential execution took a total of 115 seconds (45 seconds for review, 30 seconds for testing, 40 seconds for documentation).
Parallel execution took a total of 45 seconds (45 seconds for the longest task, likely the review task).
These results show that parallel execution reduced the overall task completion time to 45 seconds, the longest task, resulting in an efficiency improvement of approximately 61%.

Key Points for Creating Custom Subagents

In this test, some results did not meet expectations.
To prevent problems like this from occurring, I will list some key points for creating custom subagents.

Subdivide Custom Agent Tasks

Reduce Context Amount

By creating independent custom subagents in smaller units, the amount of context defining the tasks each custom subagent is responsible for is reduced, preventing the context window from becoming overwhelmed.
Furthermore, by dividing tasks into parallelizable units, the content of each divided task can be described in more detail.

Reduce Overall Execution Time

In this test, parallelization enabled all tasks to be completed within the execution time of the longest task executed simultaneously.
Therefore, by subdividing tasks and shortening the time required to complete the longest task, the overall task execution time can be reduced.

Write constraints rather than procedures. Define error cases.

In this testing, we encountered issues where the test coverage was output as 0% and the design document for the deliverable was split due to task procedures not being specified.
While it's difficult to predict what problems will arise, defining avoidable behaviors, such as "Don't do this" and "Don't ignore the problem if this result occurs," may bring the results closer to your expectations.

Delegate delegable tasks to tools

Using tools such as Skills and MCP is also effective in reducing context.
Redefining tasks that can be achieved with Skills or MCP into a custom subagent not only constricts context, but also potentially reduces task quality by not using a trusted tool.
If the content you want to define in a custom subagent includes functionality provided by Skills or MCP, be sure to call those tools.

Conclusion

Custom subagents can execute multiple tasks in a predefined sequence and can even execute multiple subagents in parallel.
Automatically executing multiple tasks with a predefined sequence in parallel improves development efficiency.

Verifying the granularity of the definition and the accuracy of the results is necessary to ensure that custom subagents work as expected.

In this testing, we observed unexpected issues not being automatically fixed, resulting in 0% test coverage, and unexpected files being generated when generating documentation.

To ensure that custom subagents work as expected, more detailed and specific definitions are required. However, providing too much detail can constrict the context window and result in incomplete results.

It is necessary to carefully review the AI's output and have repeated discussions with the AI to improve the accuracy of custom subagents.

[AWS] The difference between Kiro's Steering and AgentSkills [Kiro]

Nao San — Sat, 07 Feb 2026 02:28:28 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/4d05e92622f928481e29

Introduction

Agent Skills was implemented in Kiro's IDE on February 5, 2026.
At first glance, the functionality appears to be quite similar to the previously available Steering feature.
This article explains how to use AgentSkills.

Conclusion *Author's subjective opinion

AgentSkills and Steering basically accomplish the same thing, but they have different design philosophies and usage.
My personal approach to using AgentSkills and Steering
Workspace-specific rules and Kiro behavior rules should be defined in Steering.
Examples: Translating Kiro responses to Japanese, coding conventions, project structure, etc.
Organizational or team rules that span workspaces and operations that require specialized knowledge should be defined in Skills.
Examples: Database operations (backup, restore, connection, migration procedures), deployment procedures, tricks, etc.
While specialized knowledge can easily be confused with MCP, it seems best to define team-specific procedures in Skills.
Unlike MCP, it seems convenient to script small tricks and define them as Skills.
There are many useful Skills shared on GitHub, making it easy to import and share Skills.

↓ An example of how to use Steering and AgentSkills

Think of Steering as a carpentry rulebook (defining which tools to use and how to ensure safety), while AgentSkills are like defining which tools to use in which steps when making a chair.

Agent Skills

Portable instruction packages based on the open AgentSkills standard.
By defining specific task steps as Skills, rather than leaving it up to the AI to guess, you can ensure the task is performed exactly as defined.
For a detailed explanation, see the link below.

↓ Kiro documentation page

https://kiro.dev/docs/skills/

↓ Open AgentSkills documentation

https://agentskills.io/home

How to Create Agent Skills

Importing Already Created Skills

To import already created skills, you can do so from the Kiro IDE.

Select the Kiro icon from the left menu of Kiro and select the "+" sign to the right of the "AGENT STEERING & SKILLS" item (update your IDE if necessary).

After selecting the "+" sign, a menu will open where you can select where to import your skills.
The differences between "Skills agent skills" and "Global agent skills" displayed in the initial menu are as follows:

Skills agent skills: Skills applied to the current workspace
Saved in [Workspace path]/.kiro/skills/
Global agent skills: Skills applied to all workspaces on the user's PC
Saved in ~/.kiro/skills/
*For example, "~" is "C:\Users[Username]\"

You can import skills by retrieving the URL of the skills published on GitHub, or by selecting the file from your local PC.

Public Skills

Several skills are publicly available on GitHub, and can be imported into Kiro using the steps described above.

↓ Skills Sample

https://github.com/anthropics/skills/tree/main/skills

Try Importing Skills from GitHub

In this example, we'll import the following PDF manipulation skills.

https://github.com/anthropics/skills/tree/main/skills/pdf

As shown in the previous steps, import by specifying the GitHub URL.

After importing, a set of files managed on GitHub was downloaded to your local PC.

Creating a New Skill

As with Steering, create a new skill using an .md file.
You can create it manually or by chatting with Kiro.

Skills Storage Location

As mentioned above, the scope of application of the content changes depending on the file's storage location.
Use the appropriate method depending on the content of the skill and the scope of its application.

Skills applied to the current workspace: Save to [Workspace Path]/.kiro/skills/
Skills applied to all workspaces on the user's PC: Save to ~/.kiro/skills/

:::note warn
Caution! The Kiro IDE will not recognize md files placed directly under the skills folder.
Manage them in the same hierarchy as skills imported from GitHub: .kiro/skills/[Skill Name]/SKILL.md.
Placing md files directly under skills will not display them in the IDE.
:::

When Skills are Invoked

Controlled by Description

Kiro's Steering uses "inclusion" to control whether the skill is always applied, applied by file type, or manually applied.
Skills are controlled by the "description" entry.
The Skills I imported from GitHub earlier said, "Use this skill if a user mentions or requests the creation of a .pdf file."
Let's test it.

Creating a text file with PDF Skills

I asked Kiro to "create a .txt file containing a brief description of Kiro."
As a result, it created a text file without using any Skills.

Converting a text file to PDF with PDF Skills

I asked Kiro to "convert a .txt file containing a brief description of Kiro to PDF."
As a result, the PDF Skills were invoked and the conversion to PDF was performed.

When asked how they used Skills, they provided the following response:

From their response, we can see that they used Skills and even executed the appropriate scripts within Skills.

Conclusion

Kiro's Steering and Skills have very similar functions and definitions, making it difficult to distinguish between them at first glance.
When chatting with Kiro, I was told that they are functionally identical. In fact, if you use Steering and Skills in a creative way, you may be able to achieve similar results.
However, as noted in the Kiro documentation, Steering defines workspace (project)-specific context and criteria, while Skills can be used as a reusable workflow independent of workspaces, potentially leading to more efficient development and systematic product management.
Please give Skills a try with Kiro!

[AWS] Testing whether Kiro's web tools can be used in conjunction with other features [Kiro]

Nao San — Sun, 01 Feb 2026 01:22:09 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/e20bc79d935a13e620f1

Introduction

On December 18, 2025, Kirono IDE announced Web Tools as a new feature.
In this article, we'll examine how Web Tools can be combined with the Steering and Hooks features.

Web Tools

This is one of the new features announced on December 18, 2025.
Previously, Kiro would respond to questions via chat without searching the web, but with the implementation of this new feature, it can now retrieve web information as needed to provide a response.

Usage Examples

Kiro uses Web Tools when searching for the latest library versions or when explicitly requesting web information.

Result of asking for the latest AWS CDK version

↓ Kiro attempts to invoke the web tool

↓ Kiro searches several sources and provides the final answer

Information search by explicitly requesting a web search

↓ When I asked, "Please search the web for information and briefly explain what Kiro is," a web tool was launched.

Steering External Information Reference

The steering file defines rules for Kiro's behavior and output, but you don't need to write the text directly in a single file.
You can also reference information from other files.

Verification 1: Calculating fees by referencing the pricing table in the workspace from the steering file

We will verify whether Kiro can calculate fees from the information in a local file referenced by the steering file.

Preparation: Preparing the local file and steering file

[Local File]

This time, we will enter a portion of the information from the "Postman" pricing table (as of February 1, 2026) from the following website into the local file.

https://www.postman.com/pricing/

The information to be entered into the local file is as follows:


## Postman Pricing Plan List

Retrieved: February 1, 2026
Source: https://www.postman.com/pricing/

### Plan Overview

| Plans | Pricing | Billing | Key Features |
|--------|------|----------|----------|
| **Free** | $0 | - | Free for up to 3 users |
| **Basic** | $14/user/month | Annual billing | Full team collaboration (unlimited invites) |
| **Professional** | $29/user/month | Annual billing | Invite-only workspaces, advanced features |
| **Enterprise** | $49/user/month | Annual billing | SSO, SAML, advanced RBAC, audit logging |

### Detailed Features of Each Plan

#### Free Plan ($0)
- **Users**: Up to 3 users
- **API Client**: HTTP, GraphQL, gRPC, WebSocket, MQTT supported
- **Mock Servers**: 1,000 requests/month
- **Collection Recovery**: 1 day
- **Monitors**: 1,000 requests/month
- **Postman AI**: 50 credits/user/month
- **Packages**: 3
- **Payment Method**: Credit card only

#### Basic Plan ($14/user/month)
- **Users**: Unlimited (charged per user)
- **Mock Servers: 10,000 requests/month
- Collection Recovery: 30 days
- Monitors: 10,000 requests/month
- Postman AI: 400 credits/user/month
- Packages: 3
- Private APIs in Spec Hub: 3
- Postman API Calls: 100,000/month
- Payment Method: Credit card only
- Billing: Annual billing only
(Omitted)

[Steering File]

The steering file contains the rules for POSTMAN fee calculations, as shown below.
In this case, the pricing table is created within a workspace, so the rules reference the workspace.

##[[file:postman-pricing-plans.md]]

This statement refers to a file in your workspace.

---
inclusion: always
---

## Pricing Rules

### Postman Pricing Calculation

When calculating or estimating Postman pricing, be sure to refer to the following file:

##[[file:postman-pricing-plans.md]]

#### Notes on Calculation

1. **Annual Billing Only**: Basic, Professional, and Enterprise plans are billed annually only.
2. **Per-User Billing**: Each plan is charged per user.

#### Calculation Example

- Monthly Fee x Number of Users x Number of Months = Total Amount
- However, an annual contract is required, so a minimum of 12 months is required for the calculation.

#### Items to Check When Estimating

- Number of Users
- Contract Length (Annual Contract Only)

Execution: Ask Kiro to calculate Postman fees

Let's ask Kiro, "What is the total fee for five users using Postman on the Basic plan for three years?"
As a result, the calculation was performed by referencing the local pricing table via the steering file, as shown in the image below.
Since no web tools were called, we can confirm that no web information was referenced.

Verification 2: Testing operation with a steering file that references web information

Change the information referenced in the steering file to the actual Postman URL and perform the test.

Preparation: Change the steering file's reference to a web URL

The steering file was changed from a local file to a web URL, as shown below.

## Pricing Rules

### Postman Pricing Calculation

When calculating or quoting Postman pricing, be sure to refer to the following URL:

https://www.postman.com/pricing/

#### Notes on Calculation

1. **Annual Billing Only**: Basic, Professional, and Enterprise plans are billed annually only.
2. **User-Based Billing**: Each plan is charged per user.

#### Calculation Example

- Monthly Fee x Number of Users x Number of Months = Total Amount
- However, since an annual contract is required, a minimum of 12 months' worth of calculations is required.

#### Items to Check When Estimating

- Number of Users
- Contract Length (Annual Contract Only)

Execution: Ask Kiro to Calculate Postman Pricing

Let's ask Kiro, "What is the total cost for five users using Postman on the Basic plan for three years?"

As a result, the web tool was called via steering and the calculation was performed.

Referencing External Information for Hooks

As we verified in the steering section, we will verify whether Hooks can be integrated with web tools.

Verification: Verifying the Correctness of File Contents Using a Web Tool

As a simple verification method, we will write the POSTMAN fee calculation results in a file, then use the hook function to call the web information and verify it.

Preparation

[Hooks]

I created a hook with the following conditions:

Event: Manual Trigger
Title: Postman Pricing Plan Verification
Description: Obtain the latest pricing information from https://www.postman.com/pricing/ and verify that the contents of postman-pricing-plans.md are accurate.
Instructions for Kiro Agent: Obtain the latest Postman pricing information from https://www.postman.com/pricing/ and thoroughly verify that the contents of postman-pricing-plans.md (including pricing, features, and limitations) are accurate. Please point out any discrepancies.

[Verification File]

We will change the contents of the verification file "postman-pricing-plans.md."
To verify the data using incorrect information, we have changed the price of the Basic plan from "$14" to "$15."

## Postman Pricing Plan List

Retrieved: February 1, 2026
Source: https://www.postman.com/pricing/

### Plan Overview

| Plans | Pricing | Billing | Key Features |
|--------|------|----------|----------|
| **Free** | $0 | - | Free for up to 3 users |
| **Basic** | $15/user/month | Annual billing | Full team collaboration (unlimited invites) |
| **Professional** | $29/user/month | Annual billing | Invite-only workspaces, advanced features |
| **Enterprise** | $49/user/month | Annual billing | SSO, SAML, advanced RBAC, audit logging |

Execution

Execute a manual Hook.
This time, we'll invoke it using the "slash command," which was newly implemented on December 3, 2025.

↓ Enter "slash" in the chat field to invoke a manual command.

After execution, the URL specified in the Hook was invoked, and the error in the file was identified.
(Although not shown in the screenshot, they also suggested modifications to the file contents.)

Conclusion

Combining DevTools Features Expands the Range of Use

DevTools offers a variety of features, not just Kiro.
The Web Tools feature, while limited to just "searching web information" by itself, expands its range of use by combining it with other features. In this article, we used it to obtain the latest information and ensure accurate calculations for billing.
There are many simple, detailed features that are often overlooked individually, but it's fun to think about what you can do when combined with other features, and it may improve the efficiency of your current tasks.
Check the tool's change history to see if there are any features you can use.

[AWS] Kiro steering application timing and scope verification [Kiro]

Nao San — Sat, 31 Jan 2026 01:46:01 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/9130b466b5cb82e3a82e

Introduction

By configuring Kiro's Steering file, you can keep Kiro aware of unique coding conventions, best practices, and other rules that must always be kept in mind during product development.

A steering file can be applied to all files at all times, but you can also control the timing and scope of application.

In this article, we examined the scope and timing of Kiro's Steering.

Conclusion

Steering application timing can be controlled in three ways: always (default), under specific conditions, and explicitly specified.
Verification process description
Steering application scope can be controlled in two ways: globally (everything on an individual's PC) and by workspace (application).
Verification process description
Workspaces take priority in steering application scope.
To ensure that the generative AI generates accurate, expected results, more detailed rules must be clearly documented.

What is Steering?

In Kiro, steering refers to the rules that Kiro applies to what it generates.
Specification-driven development uses SPECs, and Vibe coding uses prompts that are entered on an ad-hoc basis. However, it can be tedious to write down rules that must be executed every time, or rules that apply across all projects at an organizational level.
By defining these rules as steering, you can avoid having to enter prompts every time or writing them in the specification (SPEC).
Furthermore, to ensure that AI-generated results are more accurate and less prone to rework, more detailed and specific rules are required.
Steering is also effective in avoiding situations where specifications become too detailed and difficult to read.

How to Create a Steering File

You can create a steering file by having Kiro create it through Kiro chat, by manually placing a ".md" file in the appropriate Kiro directory, or by using the Kiro IDE as shown below.

How to Create Using Kiro's IDE

Select the Kiro icon in Kiro's sidebar menu to display the Kiro feature menu.
Select the "+" sign in the upper right corner of the "AGENT STEERING" section in the Kiro feature menu.

A dialog box will appear, allowing you to select one of three creation methods.
Details for options 1 and 2 from the top will be explained later, but the options are as follows:

[Workspace Name] agent steering: Steering file applied only to the currently open workspace.
Global agent steering: Steering file applied to all workspaces opened on the currently used PC.
Project steering files: Kiro automatically generates a steering file recommended by Kiro based on the contents of the currently open workspace (for the workspace).

Once created, it will appear in the "AGENT STEERING" column as shown below.
[Workspace Name] agent steering

Global agent steering

Project steering files *The generated file will vary depending on the workspace contents.

Steering Application Timing

There are three steering application timing patterns.

Default

This setting defines a steering file that defines rules that are always applied.
If you add the following to the beginning of the steering file or do not specify inclusions, the rules in the steering file will be used by default.

---
inclusion: always
---

Conditional (applies only to specific files)

For rules that you want to apply only to specific files, you can specify the scope of application by specifying "inclusion: fileMatch" as shown below, and then specifying "fileMatchPattern: "【Application Condition】"" on the next line.
For example, you can define a rule that applies only to .txt files in the TEST02 folder by specifying "fileMatchPattern: "TEST02/*/.txt"".

---
inclusion: fileMatch
fileMatchPattern: "【Application Condition】"
---

Manual Reflection (Applies only when explicitly specified)

This setting applies to rules you want to apply at any time.
By adding the following to the beginning of a steering file, you can set the rule for manual reflection.
To apply a rule, instruct Kiro in chat to "apply the rule in "[steering file name].md" and generate a result with that rule applied.

---
inclusion: manual
---

Verification: Steering files for different application timings

Preparation: Creating three steering file patterns

I created three steering files and prepared three empty folders.
The steering file contents are as follows:

str01-JPN.md: Rule to always create files in Japanese
str02-ENG.md: Rule to always create files in English, with the condition "Only text files generated in TEST2"
str03-SPA.md: Rule for creating files in Spanish only when explicitly instructed

With this file in place, have the user create a text file in each folder.

Test 1: Create a text file in the TEST01 folder (the steering file should always be applied).

Enter the following in the Kiro chat and execute it.

Create a text file in the TEST01 folder.
The file contents should briefly explain what Kiro is.

The chat response referenced the contents of "str01-JPN.md," and a Japanese text file was generated.

The file contents are also written in Japanese.

Verification ②: Create a text file in the TEST02 folder (the steering file applied under the conditions should be applied).

Enter the following in Kiro chat and execute it (only the folder name has been changed):

Create a text file in the TEST02 folder.
Please include a brief explanation of what Kiro is in the file contents.

The chat response referenced the contents of "str02-ENG.md" and generated an English text file.

The file contents are also written in English.

:::note info
The problem of English being used for more than just the file contents
In this test, even the chat responses and filename are in English, apart from the file contents. This occurs because the rules in the steering wheel do not specify the chat responses or filename.
If you want the AI to perform as expected, you must provide more detail in the prompts, including the steering wheel.
:::

Test 3: Generate a text file in the TEST03 folder (it should be generated in Japanese if not specified, or in Spanish if explicitly specified).

Enter the following in Kiro chat and execute it (only the folder name has been changed):

Create a text file in the TEST03 folder.
Please include a brief explanation of what Kiro is in the file contents.

The chat response had previously verified "str01-JPN.md" and then "str02-ENG.md" in order, so perhaps an automatic inference was run and "str03-SPA.md" was read.
However, as explained in the response, the default rule was ultimately applied.
"I created a file called 'kiroexplanation.txt' in the TEST03 folder and included a brief Japanese explanation of Kiro. The steering rule for str03-SPA.md has 'inclusion: manual' specified, so it will only be applied when explicitly referenced in chat and will not be automatically applied to the TEST03 file. The workspace-level str01-JPN.md rule will be applied by default." "

The created file is also written in Japanese.

Next, let's explicitly specify the steering file to apply.
Enter the following in the Kiro chat and execute it (clearly specify the steering file to load):

Create a text file in the TEST03 folder.
Include a brief explanation of Kiro in the file's contents.
This time, apply the rules for the steering file "str03-SPA.md."

Perhaps because the file was explicitly specified, the referenced steering file name was not included in the chat response, but a Spanish file was generated.

The file contents are also written in Spanish.

Steering Scope

The steering scope is determined by the directory in which the Kiro steering file is placed.
The scope of application is divided as follows depending on the placement location:

Workspace (specific to each project)

(In a Windows environment) Steering files placed in the following directory are rules that are valid only within the workspace in which the steering file is placed.
This is a good place to define system-specific rules during development.

C:\Users\[Username]\[Workspace Path]\.kiro\steering

Global (for all projects referenced in your local Kiro environment)

(In a Windows environment) Steering files placed in the following directory are rules that apply to all workspaces on your current PC.

This is useful for rules common to your organization or team, or for rules that affect Kiro's behavior, such as when you want Kiro to always respond in your native language.

C:\Users\[Username]\.kiro\steering

Verification: Does the placement of the steering file affect the steering applied?

Preparation: Place one steering file globally (for your own use) and one in each of the two workspaces.

Three steering files were created.

str-GLOBAL.md: Global steering file. Include the word "GLOBAL" in the first line of the text.

str-WORK01.md: Steering file for workspace 01. Write "WORK01" on the last line of the text.
str-WORK02.md: Steering file for workspace 02. Add the word "WORK02" to the last line of the text.

Test 1: Generate a text file in Workspace 01 (the contents of the GLOBAL and WORK01 steering files will be applied)

Enter the following in the Kiro chat in Workspace 01 and execute it.

Create a text file.
Include a brief explanation of what Kiro is in the file's contents.

The characters specified in the steering file are also included in the first and last lines of chat responses.
This issue can be avoided by including a statement such as "chat responses excluded" in the steering file.

Checking the generated text file, we can see that the contents of the GLOBAL and WORK01 steering files have indeed been applied.

Verification ②: Generate a text file in Workspace02 (the contents of the GLOBAL and WORK02 steering files are applied).

With Workspace01 already present, in Workspace02, enter the following in the Kiro chat and execute it.

Create a text file.
Please include a brief explanation of what Kiro is in the file contents.

Although the steering file contents were not applied to this chat response message, we can see that the processing itself referenced the steering file.

Checking the contents of the generated file confirms that the global steering and workspace-specific steering file contents were applied.

Verification: Is there a priority between global and workspace steering files? Checking the behavior of conflicting steering files.

For this verification, we prepared steering files that produce different results under the same conditions.
Both of these steering files define rules for the last line.

str-GLOBAL.md: Global steering file. The first line of the text should contain the word "GLOBAL."
str-WOAK03.md: Steering file for workspace 03. Write "WORK03" in the first line of the text.

If you create a text file in this state, what will the first line look like?
In Workspace 03, enter the following in the Kiro chat and execute it.

Create a text file.
Include a brief explanation of what Kiro is in the file's contents.

As a result, the workspace rules took precedence.

The generated file also has the word "WORK03" added to the first line, in accordance with the rules defined in the workspace steering file.

Conclusion

In this article, we examined the behavior of the steering file.
By controlling the timing and scope of application of the rules defined in the steering file, we believe we can have Kiro generate the desired results more efficiently.
Furthermore, in this testing, Kiro's behavior was unstable in areas that were not clearly described (for example, even "chat responses" and "file names" were written in different languages).
It seems that the key to ensuring that AI-driven development deliverables meet expectations is how detailed the rules are.

[AWS] The best CDK code that anyone can write with the power of Kiro [Kiro]

Nao San — Mon, 15 Dec 2025 08:50:16 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/02b26afa8b5d4480b14f

Introduction

In a previous article, I created an API test environment using Kiro Powers in Postman. This time, I'll explain how to implement CDK code using Kiro Powers, which is related to implementing IaC code, including the CDK.

↓ Previous Kiro Powers articles

https://dev.to/aws-builders/aws-power-up-kiro-with-kiro-powers-5620

Conclusion

Kiro Powers' "Build AWS infrastructure with CDK and CloudFormation" is highly recommended. It's a useful tool for beginners and advanced users alike.

Recommended Points of "Build AWS infrastructure with CDK and CloudFormation"

Streamline CDK learning for beginners
High-quality code implementation that always reflects the latest best practices
Efficient implementation verification

MCP Servers for CDK

There have been several MCP tools available to support CDK development. I'll introduce them.

Deprecated "AWS CDK MCP Server"

https://awslabs.github.io/mcp/servers/cdk-mcp-server

The "AWS CDK MCP Server" was the first MCP server to support CDK development. However, this MCP server has been deprecated as its functionality has been integrated into the AWS IaC MCP Server, which offers broader support.

Replacement "AWS IaC MCP Server"

https://awslabs.github.io/mcp/servers/aws-iac-mcp-server

The AWS IaC MCP Server is an MCP server that supports IaC code creation and troubleshooting.
It allows you to search documentation for not only AWS CDK but also services including CloudFormation, perform compliance checks, and troubleshoot deployments.

Kiro powers "Build AWS infrastructure with CDK and CloudFormation" that internally invokes AWS IaC MCP Server

https://github.com/kirodotdev/powers/tree/main/aws-infrastructure-as-code

A recent new feature in Kiro, powers, supports CDK and CloudFormation development.

This power is called "Build AWS infrastructure with CDK and CloudFormation."

This power is actually an "AWS IaC MCP Server," but it offers benefits unique to powers, such as dynamic activation of MCP tools.

Configuring "Build AWS infrastructure with CDK and CloudFormation"

Setting it up in KiroIDE is easy.
As mentioned in a previous article, you can install it by selecting "Build AWS infrastructure with CDK and CloudFormation" from the official Kiro page or the powers menu in Kiro IDE.

Clicking the Install button will add the settings to mcp.json. You can then use it by setting the variable to a valid profile name for your environment.

What you can do with Build AWS infrastructure with CDK and CloudFormation

By using Kiro's chat feature and asking Kiro questions in natural language, you can accomplish the following:

Research and design support before writing code

You can obtain configuration patterns and implementation samples to help you implement CDK code.
For example, you can use sample code as a reference when learning about or implementing AWS CDK.
In the example below, when I requested a CDK code sample using TypeScript, Kiro (powers) called up several MCP functions and suggested the results.

In this test, we obtained the following answers along with specific code:

Project initialization procedure
Basic stack structure
Practical example
Lambda + DynamoDB pattern
API Gateway + Lambda + DynamoDB pattern
S3 + CloudFront static site
VPC + RDS + Lambda Patterns
Best Practices
Configurable Constructs
Environment-Specific Configurations (How to Set Environment-Dependent Variables for Development and Production Environments)
Test Examples
Main Commands
Commands for building, generating CloudFormation templates, listing stacks, deploying, checking differences, deleting stacks, and running tests Related Functions: search_cdk_documentation, search_cdk_samples_and_constructs

Applying Best Practices

As shown in the code sample above, this tool not only generates code but also applies CDK best practices.
Kiro (powers) calls the cdk_best_practices function to obtain best practice information.

Related Function: cdk_best_practices

Code Verification and Quality Improvement

This tool validates the contents of CloudFormation templates, discovering and correcting deprecated definitions.
In the example below, it discovered and corrected a deprecated runtime version.

In terms of security and compliance, this test also uncovered and fixed six issues:

S3_BUCKET_DEFAULT_LOCK_ENABLED (Object Lock disabled)
S3_BUCKET_LOGGING_ENABLED (Access logging disabled)
S3_BUCKET_NO_PUBLIC_RW_ACL (Insufficient public read/write access control)
S3_BUCKET_REPLICATION_ENABLED (Replication disabled)
S3_BUCKET_VERSIONING_ENABLED (Versioning disabled)
IAM_NO_INLINE_POLICY_CHECK (Using inline policies)

Kiro also fixes deprecations and security issues that are often overlooked through manual checks, so you can rest assured.

Related functions: validate_cloudformation_template, check_cloudformation_template_compliance

Troubleshooting

Kiro (powers) can also be used to resolve issues such as deployment failures.

It can suggest solutions based on known failure patterns and retrieve CloudTrail logs to investigate problems.

Related functions: troubleshoot_cloudformation_deployment, include_cloudtrail

Build AWS infrastructure with CDK and CloudFormation Summary of when and where it is available

Item	When there is no Power	When there is Power
Documentation Research	Search in your browser or ask the AI. The freshness and reliability of the source information is uncertain	You can obtain the latest, reliable official information at the time of execution.
Implementation Example Search	Search in your browser or ask the AI. The freshness and reliability of the source information is uncertain	Obtain official samples by language. High-quality official AWS implementation examples make it easy to compare multiple patterns.
Best Practices	Read official documentation and understand it yourself before implementation. It is uncertain whether the information is up to date	Obtain the latest best practices all at once. Comprehensive guide including CDK-NAG rules. Standardize security configurations.
API Specification Review	Read official documentation and understand it yourself before implementation.	Instantly obtain complete specifications for specific constructs. Integrated display of properties, methods, and usage examples. Related constructs are also suggested.
Code Validation	Manually perform code validation using tools such as cfn-lint.	Automatically validate synthesized templates. Check syntax, schema, and security all at once. Obtain specific correction suggestions.
Development Time	The quality and efficiency of investigation, implementation, and verification depend on the developer. Takes a relatively long time.	Access to the latest official information improves the quality and efficiency of investigation, implementation, and verification. High-quality implementation is possible in a relatively short time.
Quality	Depends on developer skill. Possibility of not being able to obtain the latest information. Possibility of security implementation omissions.	Uniform automated checks based on official AWS standards prevent oversights. Ensures high consistency. Prevents security implementation omissions.
Learning Benefits	It's difficult to learn consistently based on the latest information and best practices	Systematic knowledge acquisition, integrated implementation and theory learning, and natural acquisition of best practices

Conclusion

AWS CDK offers a significant advantage in terms of abstraction. However, the learning curve seems relatively higher than CloudFormation, especially in terms of implementation techniques and environment construction. Furthermore, frequent feature additions and improvements make it difficult to keep up.
Kiro Powers, the "Build AWS infrastructure with CDK and CloudFormation" tutorial introduced here, allows you to learn using the latest documentation, best practices, and code that reflects them. In addition to learning, it also allows you to efficiently verify and troubleshoot implementations, making it a useful tool for beginners and advanced users alike.

[AWS] DevTools Evangelism CodeBuild Edition [CodeBuild]

Nao San — Tue, 09 Dec 2025 06:08:39 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/4ffe5e508b3eed3ff27d

Introduction

I've introduced several AWS DevTools in previous articles, but this time I'll introduce AWS CodeBuild.
AWS CodeBuild is often used to automate routine tasks before deploying your work, such as testing and compiling source code.
I've previously introduced AWS CodeCommit and AWS CodeDeploy in my articles, and AWS CodeBuild is often mentioned as part of the same Code series.

*Note: Since the Qiita Advent Calendar, held in Japan in December, has already filled up, this article is not related to the Advent Calendar.

Prerequisites

While many people set up automated execution using tools like AWS CodePipeline or GitHub Actions, this article aims to spread the word about DevTools, so I'll introduce the basics of how to use the tool.

What is AWS CodeBuild?

AWS CodeBuild compiles source code stored in S3, AWS CodeCommit, and GitHub, and runs unit tests.
It is often used to update artifact repositories and test and compile code before deployment when implementing CI/CD.

↓ The image looks like this (generated with Google Gemini)

What we'll try in this article

Running CloudFormation tests (AWS CloudFormation Guard) with CodeBuild

What is AWS CloudFormation Guard?

A tool that tests whether the definitions in a CloudFormation template are as intended.
You write definition rules in YAML format and it checks whether the rules match the template contents.
For example, you can define rules such as a Lambda function's "timeout setting" being "90 seconds" or "less than 90 seconds."

Configuring CodeBuild

Creating a CodeBuild Project

In the AWS CodeBuild console, select "Create Project."

Enter a project name and select the default project.

The source provider will use the AWS CodeCommit repository created previously.

Since we want to create a project with minimal configuration, we'll select a managed image for the environment image and Lambda for the compute.

Select "Use buildspec file" to run the build according to the buildspec file managed in the AWS CodeCommit repository.

Creating a Test Object

In this example, we want to test Cfn-Guard against a CloudFormation template, so we'll create a CloudFormation template, a Cfn-Guard rule file, and a BuildSpec file for CodeBuild.

CloudFormation Template

This time, we will only define the Lambda function.
This Lambda function has the following definitions:

Timeout setting: 30 seconds
Runtime version: python3.9
Policy: AWSLambdaBasicExecutionRole

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Lambda function CloudFormation template'

Resources:
MyLambdaFunction:
Type: AWS::Lambda::Function
Properties:
FunctionName: MyLambdaFunction
Runtime: python3.9
Handler: index.lambda_handler
Role: !GetAtt LambdaExecutionRole.Arn
Timeout: 30
Code:
ZipFile: |
def lambda_handler(event, context):
return {
'statusCode': 200,
'body': 'Hello from Lambda!'
}

LambdaExecutionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: lambda.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

Outputs:
LambdaFunctionArn:
Description: 'Lambda Function ARN'
Value: !GetAtt MyLambdaFunction.Arn

Cfn-guard Rule File

This time, we are checking that the Lambda function has the following definition:

Timeout setting: 900 seconds or less
Runtime version: One of "python3.9", "python3.10", "python3.11", "nodejs18.x", or "nodejs20.x"
Policy: Ensure that overly strict policies such as PowerUserAccess and AdministratorAccess are not set.

# Lambda function security and best practices rules

# Ensure Lambda function has a timeout set
rule lambda_timeout_check {
Resources.*[ Type == "AWS::Lambda::Function" ] {
Properties.Timeout exists
Properties.Timeout <= 900
}
}

# Ensure Lambda function uses supported runtime
rule lambda_runtime_check {
Resources.*[ Type == "AWS::Lambda::Function" ] {
Properties.Runtime in ["python3.9", "python3.10", "python3.11", "nodejs18.x", "nodejs20.x"]
}
}

# Ensure IAM role follows least privilege
rule iam_role_managed_policy_check {
Resources.*[ Type == "AWS::IAM::Role" ] {
Properties.ManagedPolicyArns exists
Properties.ManagedPolicyArns.* != "arn:aws:iam::aws:policy/PowerUserAccess"
Properties.ManagedPolicyArns.* != "arn:aws:iam::aws:policy/AdministratorAccess"
}
}

BuildSpec

The build spec defines what CodeBuild will do.
In this example, the following is defined:

install (Installation Phase)

Install Rust (CloudFormation Guard is written in Rust)
Set environment variables for Cargo (Rust's package manager)
Install cfn-guard

phases:
install:
runtime-versions:
rust: 1.70
commands:
- echo "Installing CloudFormation Guard..."
- cargo install cfn-guard

pre_build (Pre-Build Phase)

Print the start time
Check the cfn-guard version
Verify that it was installed correctly

pre_build:
commands:
- echo "Pre-build phase started on `date`"
- cfn-guard --version

build (build phase)

Run CloudFormation Guard validation
Validate lambda-template.yaml using the rules in lambda-rules.guard
Display a detailed summary with --show-summary all

build:
commands:
- echo "Build phase started on `date`"
- echo "Running CloudFormation Guard validation..."
- cfn-guard validate --rules lambda-rules.guard --data lambda-template.yaml --show-summary all

post_build (post-build phase)

Print the completion time and completion message

post_build:
commands:
- echo "Post-build phase completed on `date`"
- echo "CloudFormation Guard validation completed"

reports section

Generate a report named cfn-guard-report
Include all files in the current directory
Preserve path structure

reports:
cfn-guard-report:
files:
- '**/*'
base-directory: '.'
discard-paths: no

Repository Contents

You can separate template and rule files into separate folders, but in this example, we placed the three files in the same hierarchy.

Run a Build

Run a build using the "Start Build" button.

:::note warn
Runtime error occurred
In my environment, a quota-related error occurred.
I contacted AWS Support and the issue was resolved after a few days (the cause is unknown).

Cannot have more than 0 concurrent builds on LINUX_LAMBDA_CONTAINER machines with the BUILD_LAMBDA_2GB compute type for the account.

:::

Build History

You can check the build status in the "Build History" section, which shows "In Progress," "Succeeded," or "Failed."

Build Log

You can view the build log in the build history details.

↓ The build log confirms that the Cfn-guard check passed.

Conclusion

In this article, we introduced AWS CodeBuild.
It can automatically run pre-defined tests on assets managed in AWS CodeCommit, making it useful for automated testing before deployment.
You can also configure a pipeline that runs tests with AWSCodeBUild in conjunction with changes to assets in AWSCodeCommit and, in some cases, automates deployments with AWSCodeDeploy, but we'll cover that in another article.

Reference

↓ Official AWS CodeBuild documentation

https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/builds-working.html

↓ AWS CodeBuild BlackBelt documentation (Japanese)

https://pages.awscloud.com/rs/112-TZM-766/images/20201125_AWS_BlackBelt_AWS_CodeBuild.pdf

Previous related articles

↓ AWS CodeCommit

https://dev.to/aws-builders/aws-devtools-evangelism-codecommit-edition-43e
↓ AWS CodeDeploy

https://dev.to/aws-builders/aws-devtools-evangelism-codedeploy-edition-deg

[AWS] Power up Kiro with Kiro powers [Kiro]

Nao San — Fri, 05 Dec 2025 10:09:56 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/27742e76bf47f9aa5fd5

Introduction

This is the sixth post in the Japan AWS Top Engineers Advent Calendar 2025.

On December 3, 2025, powers was announced as a new feature for Kiro.
In this post, we'll demonstrate powers from installation to execution.

↓ Click here for the Japan AWS Top Engineers Advent Calendar 2025.

https://qiita.com/advent-calendar/2025/aws-top-engineers

What is kiro powers...

For more details, please read the article below, but I'll share my impressions after trying it out.
What is Kiro Powers?

An enhanced version of MCP
Kiro and powers work more closely together to do various things
Installing powers on Kiro is easy, with a UI similar to installing a VSCode extension
Kiro performs requested operations and settings even if you don't know how to use the connected devices
It's just like "learning kung fu" in The Matrix
While traditional MCP servers preload all tools, powers are activated only when relevant
Instead of bulk loading, tokens are dynamically loaded as needed, eliminating waste.

https://aws.amazon.com/jp/blogs/news/introducing-powers/

↓ Powers page on the Kiro homepage

https://kiro.dev/powers/

How to add powers

How to add from a web page

You can install the powers introduced on the Kiro page with one click from the following site.

https://kiro.dev/powers/

Kiro IDE How to add it from the left menu

There's a Kiro Power icon in Kiro's left menu (if it's not there, you'll need to update Kiro). Selecting it will show you the current installation status of Kiro Powers and a list of officially recommended Kiro Powers that you can install.

You can also select an already created power from the list of recommendations.

Recommended power You can also add any custom powers not listed here, such as those published on GitHub.

Add and try Postman powers

Try one-click installation from the web page

After updating Kiro's IDE to the latest version, click "Add to Kiro +" in Postman to add the power.

Once the installation begins, your browser will transition to the installation screen.

A confirmation dialog will appear in your browser. Select "Open Kiro."

The Postman power addition screen opens in the Kiro IDE.

Continue the installation in the Kiro IDE screen

Select "+ Install" next to the powers displayed in the Kiro IDE to begin the installation.
A security warning dialog about changing environment variables will appear, but select Accept.

A dialog box will appear confirming successful installation.

You can confirm that the power has been added in the KiroIDE MCP list.

The definitions are written in mcp.json. While other MPC server definitions are written directly under "mcpServers," powers are written under "mcpServers" within the "powers" definition.
*In this case, we're using Postman powers, so setting the Postman API key obtained from your Postman account in "POSTMAN_API_KEY" completes the setup.

Trying out Postman powers

I asked Kiro via chat how to run Postman powers.
Postman powers were used, and he confirmed the power settings and configured them on Postman.

I was able to confirm that a workspace had been created in Postman.

Try running the API with Kiro's Postman powers

Try it with the API defined in the CDK created in the previous article

This time, we have the API configuration tested in the previous CDK article, so we will test this API.
↓ Previous article on creating an API with CDK

https://dev.to/aws-builders/aws-devtools-evangelism-cdk-edition-4bih

Chat with Kiro and request API testing using Postman powers

Let's also ask Kiro to run the API test.

After requesting the API test, Postman's powers were used to create test code in Postman, and the test was executed.

I checked the Postman screen and found that the API call settings and test code had been added.

Conclusion

Kiro Powers is great.
I still need to read and understand the documentation, but it looks like I can easily integrate Kiro with other tools to power it up.
In this case, I used Postman, but it's also great that powers allows me to use natural language even if I'm not familiar with the tools called by powers. This also reduces the effort required for people to learn detailed instructions for the tools that need to be integrated.

[AWS] DevTools Evangelism Kiro's Edition

Nao San — Thu, 04 Dec 2025 06:06:22 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

https://qiita.com/Nana_777/items/d71dacb97e1e99375b36

Introduction

This is the fifth post in the Japan AWS Top Engineers Advent Calendar 2025.

Today, I'd like to introduce Kiro, a character who frequently appears in my Advent Calendar-related posts.

I've written about Kiro in several past articles, so I'll quote those articles and provide an overall overview of Kiro.

↓ Japan AWS Top Engineers Advent Calendar 2025 is here

https://qiita.com/advent-calendar/2025/aws-top-engineers

↓ My previous article on Kiro

https://dev.to/aws-builders/aws-we-tried-out-the-popular-kiro-features-including-applying-rule-files-and-implementing-from-54di

↓ Some of the images in this article are slides I used at JAWS-UG Morning Meeting #72

https://speakerdeck.com/naonana777/hua-ti-noai-ide-kirosanwoshi-sitemita

What is AWS Kiro?

This is a service provided by AWS and comes in two versions: an IDE and a CLI.

It offers most of the capabilities of Amazon QDeveloper, such as chatting with AI and Vibe coding, but it also has several features not available in Amazon QDeveloper, such as specification-driven development and multimodal AI interaction.
Recently, I've been using the Kiro IDE version more often than Amazon QDeveloper on VSCode.

What You Can Do with AWS Kiro

Kiro's Icons are Cute

While many AWS service icons are cool, Kiro's icons, featuring a ghost motif, are very cute.

Kiro Can Do Almost Everything VSCode Can Do

VSCode is a commonly used IDE tool, and Kiro has most of its functionality.

If you're familiar with VSCode, I highly recommend Kiro, as it allows you to display terminals and consoles, install extensions, and more.

Agentic chat

Ask Kiro for research

Even if you're not involved in development, you can chat with Kiro to find out anything.
↓ I asked Kiro what Kiro is.

Ask Kiro to investigate an error

When you pass an error message to Kiro, he'll explain how to resolve it.
If any configuration changes or software installations are required to resolve the error, he'll confirm with you as you proceed.
↓ Example of a conversation when requesting an error investigation

Implementation assistance with Vibe coding

Requesting implementation from Kiro

By explaining your desired implementation in a chat with Kiro and submitting a request, Kiro will implement it.
↓ I requested Kiro to create CDK code.

Improve the accuracy of your deliverables with specification-driven development (Spec).

Kiro enables specification-driven development.
Instead of immediately starting implementation in response to a request, as with Vibe Coding, we create the requirements, design, and task list needed to complete the implementation before starting implementation.

You can align your understanding of the task list until completion. You can see your progress.

With Vibe coding, implementation had to proceed without any clarity on how much interaction would be required until completion, or what tasks would be performed.
With spec-driven development, the task list and specifications are generated in files before implementation, so the list of tasks recognized by the AI can be aligned with human understanding before implementation can proceed.
If the task list or specifications need revision, you can request corrections from Kiro via chat.
Additionally, because you can see which task is currently being performed on the task list, it's easy to understand how far you've progressed and how much work remains.

↓ Specification-Driven Development Image

↓ You can select Specification-Driven Development by selecting "Spec" from the "New Session" menu in Kiro chat.

↓ Files created with Specification-Driven Development

Predefine implementation rules with Steering

When implementing, you may want to adhere to coding conventions outside of design, as well as guidelines and rules that should be kept in mind for each function.
Kiro manages these rules as steering files and reflects them in the implementation.
You can have Kiro create general rules for the steering file, or you can create your own rules.
↓ Screen capture of Kiro creating a steering file

↓ Example of a steering file created by Kiro

Expanding the scope of use by using an MCP server

Kiro can call MCP server functions.
There are two ways to configure an MCP server in Kiro:

Connect to a remote MCP server
Enter connection information for the remote MCP server in mcp.json and use the features remotely.
Configure an MCP server on your local PC and connect.
Clone the MCP server published on GitHub to your local PC via Git and then access it in Kiro.
Even for an MCP server on your local PC, you'll need to enter settings in mcp.json.

The Kiro IDE screen displays a list of configured MCP servers in the lower left corner. A green check mark appears next to the name of an MCP server that is successfully connected.
↓ Viewing MCP servers in Kiro IDE

From the Kiro homepage

Which MCP server you use is up to you, but the Kiro homepage lists commonly used MCP servers in a "Server directory."
Clicking [+ Add Kiro] next to each MCP server name on this page will add the necessary settings to Kiro's mcp.json file.

↓Kiro Server Directory Page

https://kiro.dev/docs/mcp/servers/

:::note warn
Some fine-tuning is required after adding Kiro.
If your PC is running Windows, you may need to set environment variables.
If you are unable to connect to the MCP server using only [+ Add Kiro], please refer to the official page of each MCP server to complete the setup.
↓ Example: Official AWS MCP Server Page
https://awslabs.github.io/mcp/
:::

↓ My previous article on setting up a remote MCP server
https://dev.to/aws-builders/aws-one-click-mcp-installation-with-kiro-kiro-2ipo

Local MCP Server Example: Using an MCP server for backlog, implement a backlog issue.

By using the backlog-mcp-server available on github, you can read Backlog issues from Kiro and update the content of those issues in projects open in Kiro.

One development style known as "issue-driven development" allows Kiro to handle everything from reading issues to implementing them, a task that previously required manual intervention to create issues, read and understand them, and then implement them.

This requires more effort than ever to define the content of issues in a way that's easy for AI to understand, but being able to assign issues to Kiro like a team member will broaden the scope of its use.

↓ My previous article about the BakLog MCP server

https://dev.to/aws-builders/aws-get-backlog-issues-via-the-mcp-tool-and-have-kiro-fix-them-kiro-59p7

↓ BakLog MCP server GitHub

https://github.com/nulab/backlog-mcp-server?tab=readme-ov-file

Multimodal

Evaluate architecture through image chat

Kiro can recognize not only text but also image content.
You can use this feature to have Kiro explain and suggest areas for improvement in your architecture diagram.
The architecture diagram doesn't have to be a beautifully formatted image created with a tool like draw.io; even a whiteboard drawing is fine.

I asked Kiro to review my architecture diagram.

I asked Kiro to suggest improvements to a simple architecture diagram.
The following is the message I sent to Kiro:
"Please let me know if there are any other AWS services that are needed, based on AWS best practices."
Kiro's response suggested the necessary AWS services.
Also, perhaps because I happened to have a CDK project open in the IDE, he gave me some advice on implementing it with the CDK.

naws.com/0/192949/0319343e-c68b-4eef-a019-1f288f43e05d.png)

Spec Development Based on Architecture Diagrams

Not only can you chat with Kiro based on architecture diagrams, but you can also provide images of architecture diagrams as prompts for spec development.
Kiro will create a spec file (requirements, design, and task list) based on the architecture diagram.

Let's try it using the configuration diagram in the AWS documentation at the following URL:

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/websocket-api-step-functions-tutorial.html

What should I do in this situation?

Is team development possible?

Splitting spec files

Spec files can be split by functional group, for example, rather than having a single set of three files for a single application: requirements, design, and task list.
Splitting spec files allows team members to divide up their tasks and develop in parallel.

↓ The result of dividing the calculator application specs into functions.

Synchronizing deliverables and task progress in the task list

If each team performs their own tasks or if implementation is performed using a method other than Kiro for some reason, the progress in the task list may differ from the actual implementation progress.
In such cases, you can update the task list progress by clicking "update tasks" in the task list or by requesting Kiro via chat to update the task list progress. This will ensure that the task list progress matches the actual implementation.

↓ My previous article on spec splitting

https://dev.to/aws-builders/aws-how-to-do-team-development-with-kiro-spec-spec-division-external-implementation-1aan

How to revert Kiro's execution results to their pre-execution state

Checkpoint

When chatting with Kiro about Vive coding, unexpected changes may be made to the application.
In Kiro's chat box, there is a retry button above the request you made to Kiro.
Even if multiple files have been changed by a human request, you can press this button to revert them to the state they were in before the request to Kiro.

↓ Retry button

How to keep up with Kiro information

Refer to the Kiro official page's changelog and blog

If you want to learn more about Kiro, we recommend the official documentation page.
If you want to know the latest updates or how to use it, you'll probably find some useful information on the official page.
The Kiro changelog page shows the Kiro version number and the features added in that version.

↓ Kiro Changelog Page

https://kiro.dev/changelog/

The Kiro changelog page briefly lists Kiro's updates, but for those who want more detailed information on how to use new features, the Kiro blog page is also available.
Kiro users introduce new features and various usage methods with detailed instructions, which should help you expand your Kiro usage.

↓ Kiro Blog

https://kiro.dev/blog/

Conclusion

Kiro has been attracting attention since its launch in 2025.
It is frequently updated, and there are many interesting features that are too numerous to cover in this article.
Kiro is particularly known for its spec-driven development, but it also has many features that can be used for purposes other than spec-driven development. Please check out Kiro's features and use cases on user blogs.
You're sure to find a situation where it can be used in your own tasks.

Reference

↓ Kiro Official Documentation

https://kiro.dev/

Forem: Nao San

[AWS] Strategies to make KAA work like a member of the project team [Kiro]

【AWS】KAAをPJメンバーの1人のように活躍してもらう工夫【Kiro】 #DevTools - Qiita

Introduction

Previous Article

[AWS] Catching up on the basic functions of Kiro Autonomous Agent (Preview) [FrontierAgents]

Kiro as a Team Member

Image of FrontierAgent utilization including Kiro autonomation agent

Preparation

Step 1: Creating the Steering File

Branch Naming Conventions

Coding Standards

Architecture Patterns

Step 2: Create a virtual user "Kiro" in Backlog

Automatically Fetching Backlog Issues → Creating GitHub Issues

Slack Notification When PR is Created

Step 4: Registering GitHub Secrets

Why is a Personal Access Token Required?

Step 5: Creating GitHub Labels

Scenario 1: Having Kiro implement Backlog issues

Registering Issues and Changing Assignees

Create an Issue with GitHub Actions

Kiro Implements and Creates a PR

Notes on Task Order Dependencies

Automatic Slack Notification for Backlog Issue Updates

Scenario 2: Implementing the DevOps Agent's Agent-ready spec in Kiro

Copying the Agent-ready spec to a GitHub Issue

Verification Results

Learning Feedback Loop

Feedback in Code Reviews

Output Learned Patterns to a Steering File

Verification Results

Current limitations of Frontier agents, including the Kiro autonomous agent

In conclusion

Reference

[AWS] Catching up on the basic functions of Kiro Autonomous Agent (Preview) [FrontierAgents]

Introduction

Related Articles

What is Kiro Autonomous Agent?

Frontier Agents

Overview of Kiro Autonomous Agent

How to Create a Task

Setup (First Time Only)

Access app.kiro.dev/agent and log in with your Kiro account.

From Settings, click "Connect" Select “GitHub”

Kiro Agent GitHub App Authorize

Select repositories to grant access to

Method 1: Creating Tasks from the Kiro UI

Method 2: Creating from a GitHub Issue

Starting with the /kiro command

Starting with the kiro label

Chat Function

Before Task Creation

Task Execution

Task Execution Flow

Topic

Task to request from the agent

Step 1: Environment Setup

Step 2: Repository Analysis

Step 3: Planning → Execution → PR Creation

Feedback on PRs

Feedback from app.kiro.dev/agent

Feedback Commands on GitHub

Task Lifecycle

Persistent Context and Learning

Persistent Context

Learning from Code Reviews

Utilizing Steering Files

In conclusion

Reference

[AWS] Achieving AIOps with Frontier Agents [Frontier Agent]

Introduction

Previous Article

Prerequisites

Challenges of DevOps

Two Frontier Agents

AWS Security Agent

Design Security Review

Code Security Review

Penetration Testing

Starting with the `/kiro` command

Starting with the `kiro` label