Kiro Powers: Add Real-Browser Verification with Kane CLI

Why Can't Kiro Verify Its Own UI Work?

Kiro is an agentic IDE from AWS, available as an IDE, CLI, web, and mobile experience. Its own documentation lists six core capabilities: specs, hooks, agentic chat, steering, MCP servers, and privacy controls. Every one of them operates on text.

That is the structural blind spot. An agent whose verification primitives are unit tests, type checkers, linters, and compilers is reporting on the code surface only. The rendered UI surface stays invisible to it, which produces a specific class of failure:

• A button compiles cleanly but is wired to the wrong API endpoint.
• A redirect passes type checks and lands the user on a 404.
• A form renders without errors and never fires its validation.
• A modal opens on click and never closes on dismiss.

Each of these is technically correct code and a broken user experience. Catching them in the same session that created them is what shift-left verification means in an agentic IDE, and it is the gap the rest of this guide fills.

What Are Kiro Powers?

A power is a bundle that gives Kiro specialized expertise on demand. Kiro's powers documentation defines three components, only the first of which is required:

• POWER.md carries the instructions that tell the agent which tools it has and when to reach for them.
• MCP server configuration supplies the tools and their connection details.
• Steering files and hooks add workflow guidance and event-triggered automation.

The reason powers exist is a context budget. Kiro's documentation states that loading multiple MCP servers at once can consume over 50,000 tokens, close to 40% of the context window, before the agent processes any actual task, and that with too much context agents slow down. Powers avoid that by matching installed keywords against the conversation and loading only what is relevant.

That dormant-until-needed model is why browser verification fits well as a power. Most conversations in an IDE do not need Chrome. The ones that mention a smoke test, a deploy check, or a broken UI flow do.

How Do You Install the Kane CLI Power in Kiro?

Kane CLI ships a Kiro power in its public repository under integrations/kiro-powers, authored by TestMu AI and licensed Apache-2.0. It is not in Kiro's curated powers directory as of July 2026, so you install it as a custom power from a local folder.

Clone the repository first, then point Kiro at the subdirectory:

git clone https://github.com/LambdaTest/kane-cli.git
# the power lives at: kane-cli/integrations/kiro-powers/

• Open Kiro and go to the Powers panel, marked by the ghost icon with a lightning bolt.
• Select Add Custom Power.
• Choose Import power from a folder.
• Select the integrations/kiro-powers directory inside your clone, which is the folder containing POWER.md.
• Click Install, then activate it by mentioning a keyword such as browser, smoke test, or kane-cli.

Reach for the folder import rather than the GitHub URL import. Kiro's GitHub route requires a valid POWER.md in the repository root, and Kane CLI keeps its power file one level down at integrations/kiro-powers/POWER.md, so a root import finds nothing to install.

What the power actually contains is six steering files and one hook template. The steering set splits by workflow rather than dumping one manual on the agent: kane-cli-run for one-shot browser objectives, kane-cli-testmd for committable replayable tests, kane-cli-testrun for batch suites, kane-cli-generate for authoring test cases with no browser, plus assurance and fair-evaluation guidance. POWER.md tells Kiro which one to load for a given task.

Note: Kane CLI is free to start on the Starter plan, which runs local Chrome with 100 credits. Create a free account

How Do You Run Kane CLI From the Kiro Terminal?

Skip the power entirely if you want to drive verification yourself. Kane CLI needs Node.js 18 or higher and Google Chrome installed locally, and it launches Chrome over the DevTools Protocol on ports 9222 to 9230. Three commands in Kiro's integrated terminal get you to a first result.

npm install -g @testmuai/kane-cli

kane-cli login --username <email> --access-key <key>

kane-cli run "go to https://www.testmuai.com/selenium-playground/, click Simple Form Demo, fill the message field with 'kiro power check', click Get Checked Value, assert the page contains 'kiro power check'" --agent

Credentials come from the TestMu AI dashboard under Settings and then Keys. Use kane-cli login --oauth instead when you would rather approve a browser consent screen than paste a key, and confirm either path with kane-cli whoami. No config file, no selectors, and no test framework are involved.

Objectives combine three patterns worth learning early. Actions use imperative verbs such as go to, click, and fill. Assertions use assert, verify, or confirm and fail the run when the condition does not hold. Extractions use the explicit store X as 'name' syntax, because vague phrasing like "tell me the price" does not reliably persist a value.

Add --name to keep a one-shot run instead of discarding it. That writes a test file to .testmuai/tests/ that you can move into the repository and replay later with kane-cli testmd run, where the first run authors each step and every later run replays from a cache with no model cost. Without --name the run is ephemeral.

How Do You Make Kiro Verify Its Own Work?

The power covers most workflows. Wire the pieces yourself when you want direct control over when Kiro reaches for a browser and what it does with the verdict.

{"type":"recording_state","enabled":true,"session_id":"078780db-..."}
{"type":"project_folder_auto_defaulted","project_name":"KaneAI Generated","folder_name":"Untitled"}
{"type":"bifurcation","count":1,"flows":["Navigate then get the page title, assert the page contains 'Selenium Playground'"]}
{"step":2,"status":"done","remark":"navigate: Navigate to https://www.testmuai.com/selenium-playground/"}
{"step":3,"status":"done","remark":"analyze: ANALYZE(title, 'PRIMARY: current page title value', key='page_title')"}
{"type":"run_end","status":"...","duration":28.7,"credits_consumed":9.13,"session_dir":"~/.testmuai/kaneai/sessions/078780db-..."}

kane-cli run "..." --agent --headless 2>/dev/null | tail -1 | jq -r '.status'

---
inclusion: fileMatch
fileMatchPattern: "src/components/**/*.tsx"
---

# Browser verification with Kane CLI

After any UI change, verify it before marking the task complete.

Command: kane-cli run "<objective>" --url <app_url> --agent --headless
Parse the final line only. status is "passed" or "failed".

App notes:
- Local dev runs on http://localhost:3000
- Login is at /auth/signin
- Split flows longer than 15 steps into separate runs

{
  "enabled": true,
  "name": "Kane CLI - Verify on change",
  "version": "1",
  "when": {
    "type": "fileEdited",
    "patterns": [
      "src/**/*.{ts,tsx,js,jsx,vue,svelte}",
      "app/**/*.{ts,tsx,js,jsx}",
      "next.config.*",
      "vercel.json"
    ]
  },
  "then": {
    "type": "askAgent",
    "prompt": "Frontend files changed. Run a Kane CLI smoke test, parse the output, present results in plain language with screenshots, and propose fixes for any failed step."
  }
}

Which Path Should You Choose?

The four paths are additive rather than exclusive. Most teams start with the power and add the hook once they trust the results.

That fourth path is a single pointer. Kane CLI publishes machine-readable agent instructions at testmuai.com/kane-cli/agents.md, covering flags, objective patterns, output parsing, variables and secrets, and parallel execution. The same pattern works in other agentic tools, whether that is verifying Gemini CLI output or having Claude Code prove the feature it just wrote.

Note: Kane CLI is the terminal surface of TestMu AI's agentic testing stack, and KaneAI runs the same natural-language flows at scale on the platform. Explore KaneAI

Your First Verified Kiro Run

Start with the shortest path that produces evidence. Install Kane CLI, run kane-cli login, and give it one objective against a flow you already know is working, so you learn what a pass looks like before you need to read a failure.

Then add the pieces in order. Import the power from the cloned folder, add a fileMatch steering file scoped to your UI directory, and copy the hook template once you trust the objectives. Each step moves verification earlier without changing the syntax you already learned.

The Kane CLI documentation covers the full flag reference and authentication model, and the three modes of Kane CLI explains when to pick interactive, headless, or agent mode. For the CI side of the same loop, see how to connect Kane CLI to GitHub Actions and gate a pipeline on the exit code.

Kiro made specs the unit of work. Adding a browser to the loop makes proof the unit of done, and it stops developers from being the manual test step between the agent and the deploy.