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

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

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.

Previous Article

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

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

Kiro as a Team Member

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

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

Register the following secrets in your GitHub repository's Settings → Secrets and variables → Actions.

★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:

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:

1. Kiro executes a task → creates a PR


2. Security Agent issues security issues during code review → Kiro fixes them using /kiro all
   


3. Request Kiro to "summarize learned patterns in a Steering file" → added via PR


4. 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/