I tried out Kiro Web's Collaborative mode, from GitHub repository analysis to creating improvement PRs, and handling reviews with /kiro fix

Introduction

Kiro Web is a development environment where you can code with AI while integrating with GitHub repositories 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/

In iwasa-san's article, the setup of Kiro Web and README generation in Autonomous mode are introduced. As a follow-up, I tried the flow of analyzing an existing repository in Collaborative mode (Autonomous OFF), creating an improvement PR, and then automatically fixing review feedback with /kiro fix.

The three points I wanted to verify are as follows.

• Whether the flow of "analysis → improvement proposal → PR creation → review response" can be run on GitHub in Collaborative mode
• Whether the fix cycle can be run with /kiro fix if there are errors in AI-generated technical content
• What level of quality is returned when asking Kiro Web for a PR review

Verification Details

This verification is composed of two major cycles.

Repository Used

This time I used cm-suzuki-ryo/cloudwatch-logs-query-skill, which I manage. It consists of a Kiro skill and knowledge base that assists with creating CloudWatch Logs Insights queries. The skill includes a language selection guide, query patterns, tips, and precautions, while the knowledge base contains commands and function references for three languages.

File structure:

• cloudwatch-logs-query-builder.skill.md — Skill body (rules and pattern collection for query creation assistance)
• cloudwatch-logs-query-languages-reference.md — Knowledge base (QL/PPL/SQL command and function reference)
• 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 is the current repository, a CloudWatch Logs Insights query creation assistance skill. Please read the skill and knowledge base and suggest any improvements.

Kiro cloned the repository, read all 4 files, and returned improvement proposals. The time taken was 1 minute and 12 seconds, with a credit consumption of 0.23.

Content of Improvement Proposals

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

From the proposals, I selected the 2 high-priority items (#3 command ordering rules, #2b anti-pattern strengthening) plus #7 version information, which despite being low-priority is useful for improving maintainability, and requested implementation of improvements and PR creation.

Multi-step Execution by Sub-agent

When the fix request was submitted, Kiro Web launched a Sub-agent to proceed with implementation. The flow observable from the execution log this time was as follows.

1. planner: Grasps repository structure and creates task plan
2. coder (1st pass): Adds sections to skill file based on plan (command ordering rules, anti-patterns, version information)
3. Semantic Reviewer: Analyzes diff and outputs 5 review findings (redundancy, incomplete diagrams, inadequate fix proposals, etc.)
4. coder (2nd pass): Implements fixes addressing all 5 review findings

This series of planner → coder → Semantic Reviewer → coder re-fix was completed internally within Kiro Web before PR creation. It is interesting that the review cycle ran autonomously without human intervention.

PR Creation Complete

When Sub-agent processing was complete, a PR was automatically created on GitHub. The time taken was 11 minutes and 18 seconds, with a credit consumption of 3.78.

Checking the PR on GitHub

Let's check the content 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 this time also retained traces of the internal review cycle (FEAT-001 implementation → Semantic Reviewer → FEAT-002 review response).

Verifying Technical Accuracy

I verified whether the PR content was technically correct. In this case, the target was the knowledge base (CloudWatch Logs Insights query syntax reference), and since leaving incorrect information in the knowledge base that AI references would be problematic, I conducted separate verification.

Verification was carried out in the following two stages.

1. KB cross-referencing: Cross-checking the PR diff against the existing knowledge base to confirm consistency of claims
2. Live testing: Actually executing queries in CloudWatch Logs Insights to confirm behavior

As a result, one critical factual error was discovered.

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 live infrastructure, it worked correctly.

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

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

In addition, the following issues were also confirmed.

• The "must always be first" description for filterIndex: Within the range I tested, placing it somewhere other than first did not result in a syntax error, so it is inaccurate as a hard rule (the correct framing is as a best practice recommendation)
• Workaround 2 (filtering with chained stats): Only results in one row being aggregated, not filtering by group unit

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

Review Response with /kiro fix

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

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

The behavior of /kiro fix observable from the execution log this time was as follows.

1. Automatic PR comment retrieval: Retrieves review feedback and structures it into 3 fix points
2. Scope restriction: Explicitly restricts in orchestrator_briefing that "Anti-patterns #2-#7 are verified accurate and should not be changed"
3. Delegation to coder: Delegates to Sub-agent: coder with restricted fix instructions

The content that was fixed consisted of the following 3 points.

1. Anti-pattern #1 ("filter cannot be placed after stats") is retracted. Documents that stats ... by <group> | filter <agg> > N enables a HAVING equivalent as a positive example
2. Complete revision of the "No HAVING Equivalent" section (removes workaround group and presents post-filter as the standard approach)
3. Relaxes filterIndex's "must always be first" to "recommended to place first (to reduce scans)"

All 3 fixes were completed in 3 minutes and 27 seconds with 1.56 credits, and 2 commits were added to the PR.

Noteworthy is that the scope restriction was working. Anti-patterns #2–#7, which I judged to have no issues, were left untouched, and only the pointed-out areas were fixed. The fact that changes outside the scope indicated in the review do not get mixed in is an important practical point.

Merge

After confirming the fixes, I merged the PR. The final commit history records the entire flow of "PR comment → /kiro fix → additional commits → merge."

Additional Verification: Requesting a PR Review from Kiro Web

After merging PR #1, I created PR #2 to add JOIN/subquery syntax. I tried requesting a review for this PR on Kiro Web.

Review Request

I made the following request to Kiro Web.

Please review PR #2 of this repository.

I specified 6 review criteria.

1. Accuracy (consistency with AWS official documentation)
2. Completeness (missing explanations of parameters, constraints, behavior)
3. Sample query quality (correctness of syntax, best practices such as adding limit)
4. Consistency with skill file (contradictions between reference.md and skill.md)
5. Validity of language selection guide (reflecting the current state where JOIN/subquery can be used in all 3 languages)
6. Consistency with existing content (unification of notation, format, and granularity)

Review Results

Kiro Web launched Sub-agent: Semantic Reviewer and returned 5 findings in a structured format. The time taken was 5 minutes and 51 seconds, with a credit consumption of 1.82.

A per-criteria evaluation summary was also included, with results of accuracy ◯, completeness △, sample quality △, consistency ◯, language selection guide ◎, and uniformity ◯. The findings are specific, with the target location, reason, and recommended response provided as a set.

Constraint: Unable to Post PR Comments

When I asked Kiro Web to post the review results as PR comments, I found that Kiro Web currently lacks the ability to post comments. The constraints confirmed by Kiro are as follows.

• GitHub Power tool: Read-only only (get_comments, list_pr_comments only)
• GitHub CLI (gh): Not installed
• Direct GitHub API calls: Blocked because network mode is "Repository access only"
• Gateway: Dedicated to Git operations, not compatible with REST API

This posting attempt consumed 1 minute and 51 seconds and 1.00 credit, but ultimately no comment was posted. Since review results are output in Markdown format in the chat, a human must manually paste them onto the PR page.

Running the Improvement Cycle in Conjunction with Kiro CLI

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

1. Human transcribes Kiro Web's review results as a PR comment (posted with gh pr comment)
2. Share review content with Kiro CLI and discuss response policy
3. Kiro CLI evaluates each finding and performs live testing in us-east-1 for those requiring it
4. Commits and pushes fixes based on verification results
5. Requests re-review from Kiro Web → Approve
6. Merges with Kiro CLI

The judgment table produced by Kiro CLI is as follows.

For the 3 out of 5 findings that were judged to require action, live testing was conducted in the CLI. A test log group was created, queries were actually executed, error messages were confirmed, and then constraints were added. For the 2 findings judged to require no action, the rationale for "why no action was taken" was also recorded in commit messages and PR comments.

After pushing the fixes, when I asked Kiro Web for a re-review, it confirmed that all 5 findings had been addressed and returned a "ready to merge" verdict. Finally, a squash merge was executed from Kiro CLI to close PR #2.

The Three-Party Collaboration Structure

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

The human's role is "judgment" and "relay." Given the current situation where Kiro Web cannot write comments, humans need to act as a bridge through copy-pasting, but this also means that review content can be visually confirmed before proceeding to the next step, which prevents AI findings from being applied blindly.

While PR #1's /kiro fix was a cycle completed entirely within Kiro Web, PR #2 took the form of running the review→verification→fix→re-review cycle among the three parties of "Kiro Web × Human × Kiro CLI."

Summary

Using Kiro Web's Collaborative mode, I tried analyzing an existing repository, creating an improvement PR, handling review feedback with /kiro fix, and even requesting a PR review. Because improvement policies can be selected interactively, a flow can be created where humans decide "what to fix" and leave implementation to Kiro.

/kiro fix was convenient in that it could run the fix cycle from PR comments. In this verification, fixes were limited to the pointed-out scope and no unnecessary changes were mixed in.

When requesting a PR review, specifying review criteria returns structured findings. However, at this point there is no PR comment posting feature, and review results must be manually transcribed by a human. I confirmed that this constraint can be covered through integration with Kiro CLI, and that the improvement cycle of "Kiro Web (review) → Human (judgment/relay) → Kiro CLI (verification/fix) → Kiro Web (re-review)" can be run. While there is the hassle of humans acting as a bridge through copy-pasting, it allows for visually confirming review content before proceeding, which reduces the risk of blindly applying AI findings.

The initial PR contained a factual error: "filter cannot be placed after stats." Live testing confirmed that a filter after aggregation works as a HAVING-equivalent filter. Automating PR creation and accuracy of content are separate issues, and AI output requires human review and live testing.

The total execution on Kiro Web was 8.39 credits / approximately 25 minutes. The breakdown is as follows.

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