Trying Out Kiro Web's Collaborative Mode: From Analyzing a GitHub Repository to Creating an Improvement PR and Handling Review Feedback with /kiro fix

Introduction

Kiro Web is a development environment that lets you code with AI while connecting to GitHub repositories right in your browser. It was released as a public preview in May 2026.

https://kiro.dev/changelog/web/introducing-kiro-web-preview/

https://dev.classmethod.jp/articles/kiro-web-preview/

Iwasa's article introduced the setup of Kiro Web and README generation in Autonomous mode. As a follow-up, this time I used Collaborative mode (Autonomous OFF) to analyze an existing repository, create an improvement PR, and then automatically fix review comments with /kiro fix.

The three points I wanted to verify are as follows.

• Can the flow of "analysis → improvement proposals → PR creation → review handling" be run on GitHub in Collaborative mode?
• If the technical content generated by the AI contains errors, can the fix cycle be run with /kiro fix?
• When asking Kiro Web to review a PR, what quality of review does it return?

What I Tested

This verification consists of two main cycles.

Repository Used

I used cm-suzuki-ryo/cloudwatch-logs-query-skill, which I manage myself. It consists of a Kiro skill and a knowledge base that support writing CloudWatch Logs Insights queries. The skill includes a language selection guide, query patterns, tips, and cautions, and the knowledge base includes command and function references for three languages.

File structure:

• cloudwatch-logs-query-builder.skill.md — The skill itself (rules and pattern collection for query-writing support)
• cloudwatch-logs-query-languages-reference.md — Knowledge base (command and function reference for QL/PPL/SQL)
• readme.md / readme-jp.md — Usage instructions

Requesting Analysis

I connected the repository to Kiro Web and made the following request in Collaborative mode.

This repository is a skill that supports writing CloudWatch Logs Insights queries. Please read the skill and the knowledge base, and propose improvements if there are any.

Kiro cloned the repository, read all four files, and then returned improvement proposals. It took 1 minute 12 seconds and consumed 0.23 credits.

Contents of the Improvement Proposals

The response contained 7 proposals, organized as a table with priorities.

From the proposals, I chose the two high-priority items (#3 command ordering rules, #2b anti-pattern strengthening), plus #7 version information, which is low priority but useful for improving maintainability, and asked for the improvements to be implemented and a PR to be created.

Multi-stage Execution by Sub-agents

After I submitted the fix request, Kiro Web launched Sub-agents to carry out the implementation. The flow observed in this execution log was as follows.

1. planner: Understood the repository structure and created a task plan
2. coder (1st run): Added sections to the skill file based on the plan (command ordering rules, anti-patterns, version information)
3. Semantic Reviewer: Analyzed the diff and output 5 review comments (redundancy, incomplete diagrams, deficient fix proposals, etc.)
4. coder (2nd run): Addressed the 5 review comments and applied fixes

This series of planner → coder → Semantic Reviewer → coder re-fix was completed inside Kiro Web before the PR was created. It's interesting that the review cycle ran autonomously without any human intervention.

PR Creation Completed

When the Sub-agents finished, a PR was automatically created on GitHub. It took 11 minutes 18 seconds and consumed 3.78 credits.

Checking the PR on GitHub

Let's check the contents of the created PR.

• Branch name: improve/command-ordering-and-antipatterns
• Number of commits: 4 (implementation + task state management)
• Author: kiro-agent[bot] on behalf of @cm-suzuki-ryo
• Diff: +419/-7 lines

The PR description contained a summary of the implemented improvements written in Japanese. The commit history also retained traces of the internal review cycle (FEAT-001 implementation → Semantic Reviewer → FEAT-002 review handling).

Verifying Technical Accuracy

I verified whether the PR content was technically correct. Since the target this time is a knowledge base (a query syntax reference for CloudWatch Logs Insights), any factual error would leave incorrect information in the knowledge base the AI refers to, so I performed a separate verification.

The verification was done in the following two stages.

1. KB cross-check: Compared the PR diff against the existing knowledge base to confirm the consistency of the claims
2. Hands-on verification: Ran actual queries in CloudWatch Logs Insights to confirm their behavior

As a result, I found one serious factual error.

The PR claimed that "filter cannot be placed after stats / Logs Insights QL has no HAVING equivalent," but when I ran the following query on a real environment, it worked normally.

stats count(*) as c by @logStream | filter c > 3 | sort c desc

Of the 5 groups (count: 9, 3, 3, 3, 2), only the one group with count > 3 was returned. filter c > 3 works as a post-aggregation threshold filter (the HAVING equivalent).

I also confirmed the following additional problems.

• The filterIndex "must be first" statement: In the range I tried, placing it somewhere other than first did not cause a syntax error, so it is inaccurate as a hard rule (the recommendation as a best practice is correct)
• Workaround 2 (narrowing with chained stats): It only collapses the result to a single row and does not narrow down by group

The AI-generated improvement proposals also contained factual errors. This reaffirmed that, beyond just creating PRs, human verification of technical accuracy is important.

Review Handling with /kiro fix

I posted the verification results as a PR comment, followed by /kiro fix.

When I posted /kiro fix, Kiro Web automatically started a new session. The session title was "Addressing feedback on cm-suzuki-ryo/cloudwatch-logs-query-skill #1".

The behavior of /kiro fix observed in this execution log was as follows.

1. Automatic retrieval of PR comments: Retrieved the content of the review comments and structured it into three fix points
2. Scope limitation: The orchestrator_briefing explicitly restricted the scope, stating "Anti-patterns #2-#7 are verified as accurate, so do not change them"
3. Delegation to coder: Delegated to Sub-agent: coder with restricted fix instructions

The following three changes were made.

1. Retracted Anti-pattern #1 ("filter cannot be placed after stats"). Added stats ... by <group> | filter <agg> > N as a correct example showing that a HAVING equivalent is possible
2. Completely revised the "No HAVING Equivalent" section (removed the workarounds and presented post-stats filter as the proper approach)
3. Relaxed the filterIndex "must be first" to "placing it first is recommended (to reduce scanning)"

The three fixes were completed in 3 minutes 27 seconds using 1.56 credits, and 2 commits were added to the PR.

What is notable is that the scope limitation worked. It left Anti-patterns #2–#7, which I had judged to have no problems, untouched and fixed only the points raised. Not having changes slip in outside the scope raised in the review is an important point in practical use.

Merge

After checking the changes, I merged the PR. The final commit history records the full flow of "PR comment → /kiro fix → additional commits → merge."

Additional Verification: Asking Kiro Web to Review a PR

After merging PR #1, I created PR #2, which adds JOIN/subquery syntax. I tried asking Kiro Web to review this PR.

Review Request

I made the following request to Kiro Web.

Please review PR #2 of this repository.

I specified six review perspectives.

1. Accuracy (consistency with the official AWS documentation)
2. Completeness (omissions in explanations of parameters, constraints, and behavior)
3. Quality of sample queries (syntactic correctness, best practices such as adding limit)
4. Consistency with the skill file (contradictions between reference.md and skill.md)
5. Validity of the language selection guide (reflecting the current state where JOIN/subqueries are available in all three languages)
6. Consistency with existing content (unified notation, format, and granularity)

Review Results

Kiro Web launched Sub-agent: Semantic Reviewer and returned 5 structured comments. It took 5 minutes 51 seconds and consumed 1.82 credits.

It also included a summary of ratings by perspective: accuracy ◯, completeness △, sample quality △, consistency ◯, language selection guide ◎, uniformity ◯. The comments were specific, each including the location, the reason, and the recommended action.

Limitation: Cannot Post PR Comments

When I asked it to post the review results as PR comments, it turned out that Kiro Web currently has no comment-posting capability. The constraints Kiro identified are as follows.

• GitHub Power tool: read-only (only get_comments and list_pr_comments)
• GitHub CLI (gh): not installed
• Direct GitHub API calls: blocked by the network mode "Repository access only"
• Gateway: dedicated to Git operations and does not support the REST API

This posting attempt consumed 1 minute 51 seconds and 1.00 credit, and ultimately the comments could not be posted. Since the review results are output in Markdown format in the chat, a human needs to paste them manually onto the PR page.

Running the Improvement Cycle with Kiro CLI

Since Kiro Web alone cannot write review results to the PR, from here I ran the cycle in cooperation with the local Kiro CLI. The flow is as follows.

1. A human transcribes the Kiro Web review results as a PR comment (posted with gh pr comment)
2. Tell Kiro CLI the review content and discuss the response policy
3. Kiro CLI judges each comment and verifies in us-east-1 those that require hands-on verification
4. Commit and push fixes based on the verification results
5. Ask Kiro Web for a re-review → Approve
6. Merge with Kiro CLI

The decision table produced by Kiro CLI is as follows.

For the three of the five comments judged to need action, I performed hands-on verification on the CLI. I created a test log group, actually ran the queries, checked the error messages, and then added the constraints. For the two judged as not needing action, I also recorded the rationale for "why we are not acting" in the commit message and the PR comment.

After pushing the fixes, I asked Kiro Web for a re-review, and it confirmed that all five comments had been addressed and returned a "ready to merge" verdict. Finally, I performed a squash merge from Kiro CLI and closed PR #2.

The Three-party Collaboration Setup

What was achieved with PR #2 is the following division of roles.

The human's roles are "judgment" and "relay." In the current situation where Kiro Web cannot write comments, a human has to bridge by copy-pasting, but that also means the review content can be visually checked before moving on to the next step, which prevents blindly applying the AI's comments.

Whereas the /kiro fix in PR #1 was a cycle completed within Kiro Web, PR #2 ran the review → verification → fix → re-review cycle among three parties: "Kiro Web × human × Kiro CLI."

Summary

Using Kiro Web's Collaborative mode, I tried analysis of an existing repository, improvement PR creation, review handling with /kiro fix, and even requesting a PR review. Because you can choose the improvement policy interactively, you can create a flow in which a human decides "what to fix" and Kiro handles the implementation.

/kiro fix was convenient in that it can run a fix cycle from PR comments. In this verification, additional fixes were limited to the scope raised, and no unnecessary changes slipped in.

When requesting a PR review, specifying the review perspectives returns structured comments. However, at present there is no PR comment-posting feature, so a human must transcribe the review results manually. I covered this limitation through cooperation with Kiro CLI and confirmed that the improvement cycle of "Kiro Web (review) → human (judgment/relay) → Kiro CLI (verification/fixes) → Kiro Web (re-review)" can be run. Although there is the effort of a human bridging by copy-paste, the review content can be visually checked before moving on, which reduces the risk of blindly applying the AI's comments.

The first PR contained the factual error that "filter cannot be placed after stats." Hands-on verification confirmed that a post-aggregation filter works as a HAVING-equivalent narrowing. Automating PR creation and the accuracy of the content are separate matters, and AI output requires human review and hands-on verification.

The total for runs on Kiro Web was 8.39 credits / about 25 minutes. The breakdown is as follows.

This does not include time for technical verification or CloudWatch Logs Insights scan charges.