morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #2385] [Feature] Kiro-cli support #798

New issue

Open

opened 2026-10-15 18:28:33 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-15 18:28:33 +00:00

Owner

Originally created by @k1shan-k on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2385

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Setup, packaging, or upgrade

Current limitation

Kiro-cli by aws is something which should be supported by default as choosing of agents in setup.

Use cases

No response

Desired outcome and success criteria

kiro-cli is added on the list of supported ide/agent system.

Expected interaction with targets

Not sure yet

Target and scope details (optional)

No response

Verification available so far

Idea only; I need help defining checks

Verification details (optional)

No response

Alternatives considered

No response

Possible direction

No response

References

No response

Originally created by @k1shan-k on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2385 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Setup, packaging, or upgrade ### Current limitation Kiro-cli by aws is something which should be supported by default as choosing of agents in setup. ### Use cases _No response_ ### Desired outcome and success criteria kiro-cli is added on the list of supported ide/agent system. ### Expected interaction with targets Not sure yet ### Target and scope details (optional) _No response_ ### Verification available so far Idea only; I need help defining checks ### Verification details (optional) _No response_ ### Alternatives considered _No response_ ### Possible direction _No response_ ### References _No response_

bsakaguchi added the

P3: low

area: cli

enhancement

labels

2026-10-15 18:28:33 +00:00

bsakaguchi commented

2026-10-15 18:28:34 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 12, 2026):

Hi @k1shan-k, thank you for the feature request!

To evaluate adding kiro-cli to rea setup, we need specific details about its integration contract:

Configuration & Discovery Protocol:
- How does kiro-cli store registered MCP servers or agent tools? (e.g., global config file path like ~/.kiro/settings.json, environment variables, or project-local configs?)
- Does it support standard stdio MCP transport natively?
Setup Automation Contract:
- Per REA guidelines (AGENTS.md and CONTRIBUTING.md), rea setup changes must be additive, idempotent, and include backups without mutating unrelated settings or installing external software.
- What exact JSON structure or command is required to register REA as an MCP server with kiro-cli?

Please update the issue with these technical details or references to Kiro-cli's documentation so we can establish an actionable scope and verification test cases.

@matbrgz commented on GitHub (Oct 12, 2026): Hi @k1shan-k, thank you for the feature request! To evaluate adding `kiro-cli` to `rea setup`, we need specific details about its integration contract: 1. **Configuration & Discovery Protocol:** - How does `kiro-cli` store registered MCP servers or agent tools? (e.g., global config file path like `~/.kiro/settings.json`, environment variables, or project-local configs?) - Does it support standard stdio MCP transport natively? 2. **Setup Automation Contract:** - Per REA guidelines (`AGENTS.md` and `CONTRIBUTING.md`), `rea setup` changes must be additive, idempotent, and include backups without mutating unrelated settings or installing external software. - What exact JSON structure or command is required to register REA as an MCP server with `kiro-cli`? Please update the issue with these technical details or references to Kiro-cli's documentation so we can establish an actionable scope and verification test cases.

bsakaguchi commented

2026-10-15 18:28:34 +00:00

Author

Owner

@caliboycoder commented on GitHub (Oct 14, 2026):

Thanks @matbrgz. I checked this against Kiro's MCP docs and a logged-in kiro-cli 2.31.0 on macOS, using the default agent engine. Items marked (docs) come from documentation only. Everything else I ran myself.

1. Configuration and discovery

The format is JSON with a top-level mcpServers object. There are two locations (docs):
- User: ~/.kiro/settings/mcp.json
- Workspace: <project>/.kiro/settings/mcp.json
Precedence, highest first (docs): a custom agent's mcpServers, then the workspace file, then the user file. A same-name workspace rea entry would shadow the user one, so doctor should report that. Setup should write only the user file.
stdio is supported natively. An entry with command is a local stdio server, and an entry with url is a remote server.
Verified: my existing rea entry in ~/.kiro/settings/mcp.json (command: /opt/homebrew/bin/npx, args: ["-y","rea-agents@6.4.0","mcp"], env.PATH, disabled: false, autoApprove: []) is picked up by Kiro CLI. kiro-cli mcp status --name rea reports scope default, agent kiro_default, timeout 120000 ms, disabled false.

2. Registration entry

{
  "mcpServers": {
    "rea": {
      "command": "/absolute/path/to/rea",
      "args": ["mcp"],
      "env": {},
      "disabled": false
    }
  }
}

The documented fields are command (required), args, env, disabled, autoApprove and disabledTools. No transport type field is needed. Setup should preserve an existing autoApprove. Kiro CLI doesn't load .env files, so literal env values from the launcher are the safer choice.

3. Findings that shape the setup design

Setup should edit the file directly, not call kiro-cli mcp add.
- It only worked once I was logged in. In a fresh HOME it fails with "You are not logged in".
- It rewrote my test file and dropped an unrelated top-level key I had added. Unrelated server entries were kept.
- Re-adding an existing name fails (exit 1) unless --force is used, and the help text says --force overwrites the entry. That is not additive or idempotent.
- It writes "env": {} and pretty-prints the file.
Skills are not discovered from the shared directory. With the REA skill in ~/.agents/skills, Kiro CLI listed no skills. As a control, a skill in .kiro/skills/ in a temp workspace was listed. This matches the skills docs, which list only ~/.kiro/skills/<name>/SKILL.md (user) and .kiro/skills/ (workspace). Setup should install the bundled reverse-engineer-anything skill into ~/.kiro/skills.
Custom agents don't see rea unless they set "includeMcpJson": true.
- I tested two agents. The one without the flag could not see rea.
- The one with the flag got rea attached, and kiro-cli mcp list showed it with a [legacy] marker.
- Custom agents also need a skill://~/.kiro/skills/*/SKILL.md entry in resources to see skills (docs).
- Setup shouldn't edit agent files, but the docs should mention this.
Tools are exposed as @rea/<tool_name>.
Config changes apply on save (docs: hot-reload). Telling the user to start a new session is the safe instruction.

4. Verification I ran

kiro-cli chat --no-interactive --require-mcp-startup exited 0 with rea enabled. The help text says it exits 3 if any enabled server fails to start, which makes it a usable doctor and native-check hook.
I ran a real tool call: kiro-cli chat --no-interactive --trust-tools=@rea/list_documents "Call list_documents once". It ran @rea/list_documents, which completed, and REA returned target_unavailable: no app is open. That is REA's own error, so the full round trip works.

5. Proposed test plan

Fixture tests with a temporary HOME:
- create the file when it doesn't exist
- upsert into a file with another server and an extra top-level key
- idempotent re-run
- .rea.backup creation
- refuse malformed JSON
- doctor flags disabled: true and a shadowing workspace entry
- uninstall removes only rea
- skill installed under ~/.kiro/skills
Optional native check, manual because it needs a login: kiro-cli chat --no-interactive --require-mcp-startup.

Not verified

Windows paths (I assume %USERPROFILE%\.kiro\...).
Whether Kiro tolerates comments or trailing commas in mcp.json. I'd treat it as strict JSON, as setup does for Pi and ZCode.
The V3 agent engine (--v3). I tested the default engine only. The docs say the MCP file locations are the same.
Whether Kiro desktop and Kiro CLI should be one client ID or two. I lean toward one, since they share config.

@caliboycoder commented on GitHub (Oct 14, 2026): Thanks @matbrgz. I checked this against Kiro's [MCP docs](https://kiro.dev/docs/mcp/configuration.md) and a logged-in `kiro-cli 2.31.0` on macOS, using the default agent engine. Items marked (docs) come from documentation only. Everything else I ran myself. ## 1. Configuration and discovery - The format is JSON with a top-level `mcpServers` object. There are two locations (docs): - User: `~/.kiro/settings/mcp.json` - Workspace: `<project>/.kiro/settings/mcp.json` - Precedence, highest first (docs): a custom agent's `mcpServers`, then the workspace file, then the user file. A same-name workspace `rea` entry would shadow the user one, so doctor should report that. Setup should write only the user file. - stdio is supported natively. An entry with `command` is a local stdio server, and an entry with `url` is a remote server. - Verified: my existing `rea` entry in `~/.kiro/settings/mcp.json` (`command: /opt/homebrew/bin/npx`, `args: ["-y","rea-agents@6.4.0","mcp"]`, `env.PATH`, `disabled: false`, `autoApprove: []`) is picked up by Kiro CLI. `kiro-cli mcp status --name rea` reports scope `default`, agent `kiro_default`, timeout 120000 ms, disabled `false`. ## 2. Registration entry ```json { "mcpServers": { "rea": { "command": "/absolute/path/to/rea", "args": ["mcp"], "env": {}, "disabled": false } } } ``` The documented fields are `command` (required), `args`, `env`, `disabled`, `autoApprove` and `disabledTools`. No transport `type` field is needed. Setup should preserve an existing `autoApprove`. Kiro CLI doesn't load `.env` files, so literal `env` values from the launcher are the safer choice. ## 3. Findings that shape the setup design - **Setup should edit the file directly, not call `kiro-cli mcp add`.** - It only worked once I was logged in. In a fresh `HOME` it fails with "You are not logged in". - It rewrote my test file and dropped an unrelated top-level key I had added. Unrelated server entries were kept. - Re-adding an existing name fails (exit 1) unless `--force` is used, and the help text says `--force` overwrites the entry. That is not additive or idempotent. - It writes `"env": {}` and pretty-prints the file. - **Skills are not discovered from the shared directory.** With the REA skill in `~/.agents/skills`, Kiro CLI listed no skills. As a control, a skill in `.kiro/skills/` in a temp workspace was listed. This matches the [skills docs](https://kiro.dev/docs/skills.md), which list only `~/.kiro/skills/<name>/SKILL.md` (user) and `.kiro/skills/` (workspace). Setup should install the bundled `reverse-engineer-anything` skill into `~/.kiro/skills`. - **Custom agents don't see `rea` unless they set `"includeMcpJson": true`.** - I tested two agents. The one without the flag could not see `rea`. - The one with the flag got `rea` attached, and `kiro-cli mcp list` showed it with a `[legacy]` marker. - Custom agents also need a `skill://~/.kiro/skills/*/SKILL.md` entry in `resources` to see skills (docs). - Setup shouldn't edit agent files, but the docs should mention this. - **Tools are exposed as `@rea/<tool_name>`.** - **Config changes apply on save** (docs: hot-reload). Telling the user to start a new session is the safe instruction. ## 4. Verification I ran - `kiro-cli chat --no-interactive --require-mcp-startup` exited 0 with `rea` enabled. The help text says it exits 3 if any enabled server fails to start, which makes it a usable doctor and native-check hook. - I ran a real tool call: `kiro-cli chat --no-interactive --trust-tools=@rea/list_documents "Call list_documents once"`. It ran `@rea/list_documents`, which completed, and REA returned `target_unavailable: no app is open`. That is REA's own error, so the full round trip works. ## 5. Proposed test plan - Fixture tests with a temporary `HOME`: - create the file when it doesn't exist - upsert into a file with another server and an extra top-level key - idempotent re-run - `.rea.backup` creation - refuse malformed JSON - doctor flags `disabled: true` and a shadowing workspace entry - uninstall removes only `rea` - skill installed under `~/.kiro/skills` - Optional native check, manual because it needs a login: `kiro-cli chat --no-interactive --require-mcp-startup`. ## Not verified - Windows paths (I assume `%USERPROFILE%\.kiro\...`). - Whether Kiro tolerates comments or trailing commas in `mcp.json`. I'd treat it as strict JSON, as setup does for Pi and ZCode. - The V3 agent engine (`--v3`). I tested the default engine only. The docs say the MCP file locations are the same. - Whether Kiro desktop and Kiro CLI should be one client ID or two. I lean toward one, since they share config.

bsakaguchi referenced this issue

2026-10-16 21:16:14 +00:00

[PR #798] [MERGED] fix(process): clarify Windows capture support and recovery #2247

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:29:37 +00:00

bsakaguchi added

enhancement

and removed