I tried out Kiro Web's Collaborative mode, from GitHub repository analysis to creating improvement PRs, and handling reviews with /kiro fix
This page has been translated by machine translation. View original
Introduction
Kiro Web is a development environment that allows you to code with AI while integrating with GitHub repositories in a browser. It was released as a public preview in May 2026.
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 two points I wanted to verify are as follows.
- Whether the flow of "analysis → improvement proposal → PR creation → review response" can be run on GitHub using Collaborative mode
- Whether the fix cycle can be run with
/kiro fixwhen there are errors in the technical content generated by AI
Verification Details
This verification consists of two major cycles.
Repository Used
This time I used cm-suzuki-ryo/cloudwatch-logs-query-skill, which I manage myself. It consists of a Kiro skill and knowledge base that supports query creation for CloudWatch Logs Insights. The skill includes a language selection guide, query patterns, tips, and notes, while the knowledge base contains command and function references in 3 languages.
File structure:
cloudwatch-logs-query-builder.skill.md— The skill itself (rules and pattern collection for query creation support)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 query creation support skill for CloudWatch Logs Insights. 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 required was 1 minute and 12 seconds, and credit consumption was 0.23.
Content of Improvement Proposals
The returned proposals consisted of 7 items, organized as a prioritized table.
| Priority | # | Proposal Content |
|---|---|---|
| High | #3 | Clarification of command pipeline ordering rules |
| High | #2b | Strengthening AI-generated anti-patterns |
| Medium | #5 | Addition of missing syntax examples |
| Medium | #1 | Clarification of IA constraints |
| Medium | #4 | Cost optimization guide |
| Low | #2a | Additional use cases |
| Low | #7 | Version information |
From the proposals, I selected the 2 high-priority items (#3 command ordering rules, #2b anti-pattern strengthening) along with #7 version information, which despite being low priority is useful for improving maintainability, and requested implementation 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 observed in this execution log is as follows.
- planner: Understood the repository structure and created a task plan
- coder (1st run): Added sections to the skill file based on the plan (command ordering rules, anti-patterns, version information)
- Semantic Reviewer: Analyzed the diff and output 5 review findings (redundancy, incomplete diagrams, insufficient fix proposals, etc.)
- coder (2nd run): Implemented fixes addressing all 5 review findings
This entire sequence of planner → coder → Semantic Reviewer → coder re-fix was completed internally within Kiro Web before PR creation. It is interesting to note that the review cycle ran autonomously without human intervention.
PR Creation Completed
When Sub-agent processing was complete, a PR was automatically created on GitHub. The time required was 11 minutes and 18 seconds, and credit consumption was 3.78.
Reviewing the PR on GitHub
Let's review 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 for this run also retained traces of the internal review cycle (FEAT-001 implementation → Semantic Reviewer → FEAT-002 review response).
Technical Accuracy Verification
I verified whether the PR content was technically correct. Since the target was a knowledge base (a query syntax reference for CloudWatch Logs Insights), and leaving incorrect information in the knowledge base referenced by AI would be problematic, I conducted a separate verification.
Verification was carried out in the following 2 stages.
- KB cross-referencing: Cross-checked the PR diff against the existing knowledge base to confirm consistency of claims
- Actual testing: Executed queries directly in CloudWatch Logs Insights to confirm behavior
As a result, 1 critical factual error was found.
The PR claimed that "filter cannot be placed after stats / Logs Insights QL has no HAVING equivalent," but when the following query was executed in actual testing, 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 1 group with count > 3 was returned. filter c > 3 is functioning as a post-aggregation threshold filter (HAVING equivalent).
The following issues were also confirmed.
- The "must be at the beginning" description for
filterIndex: Within the scope I tested, placing it somewhere other than the beginning did not result in a syntax error, making it inaccurate as a hard rule (recommending it as a best practice is the correct approach) - Workaround 2 (filtering with chained stats): Only collapses to a single line and does not perform group-level filtering
The AI-generated improvement proposals also contained factual errors. This reaffirmed the importance of not just creating PRs, but also having humans verify technical accuracy.
Addressing Review Feedback with /kiro fix
I posted the verification results as a PR comment, then posted /kiro fix.
When /kiro fix was posted, Kiro Web automatically launched a new session. The session title was "Addressing feedback on cm-suzuki-ryo/cloudwatch-logs-query-skill #1."
The /kiro fix behavior observed in this execution log is as follows.
- Automatic retrieval of PR comments: Retrieved the review feedback content and structured it into 3 fix points
- Scope restriction: Explicitly restricted in the orchestrator_briefing to "not change Anti-patterns #2-#7 as they have been verified as accurate"
- Delegation to coder: Delegated to Sub-agent: coder with restricted fix instructions
The fixes applied were the following 3 points.
- Anti-pattern #1 ("filter cannot be placed after stats") was retracted.
stats ... by <group> | filter <agg> > Nwas documented as a valid example showing HAVING equivalent is possible - Complete revision of the "No HAVING Equivalent" section (removed the workaround group and presented post-positioned filter as the standard approach)
- Softened
filterIndex"must be at beginning" to "recommended to place at beginning (to reduce scan)"
The 3 fixes were completed in 3 minutes and 27 seconds using 1.56 credits, and 2 commits were added to the PR.
Noteworthy is that the scope restriction worked as intended. Anti-patterns #2 through #7, which were judged to have no issues, were left untouched, and only the flagged areas were fixed. The fact that changes outside the scope pointed out in the review were not mixed in is an important practical point.
Merge
After confirming the fix content, I merged the PR. The final commit history records the entire flow of "PR comment → /kiro fix → additional commits → merge."
Summary
Using Kiro Web's Collaborative mode, I tried the complete flow from analyzing an existing repository, creating an improvement PR, to addressing review feedback with /kiro fix. Since improvement policies can be selected interactively, it is possible to create a flow where humans decide "what to fix" and leave the implementation to Kiro.
/kiro fix was convenient in that it could run fix cycles from PR comments. In this verification, additional fixes were scoped to the pointed-out areas, and no unnecessary changes were mixed in.
However, the initial PR contained a factual error: "filter cannot be placed after stats." Actual testing confirmed that filter placed after aggregation functions as a HAVING-equivalent filter. Automating PR creation and ensuring content accuracy are separate issues, and AI output requires human review and actual testing.
The total for execution on Kiro Web was 5.57 credits / approximately 16 minutes. The breakdown is 0.23 credits for analysis and proposals, 3.78 credits for improvement implementation + PR creation, and 1.56 credits for /kiro fix. Time for technical verification and CloudWatch Logs Insights scan charges are not included.
