feat(init): add Kiro IDE support #648
Conversation
- Add Kiro IDE to AI_TOOLS registry with skillsDir '.kiro' - Create kiro adapter generating .kiro/steering/opsx-*.md files - Use 'inclusion: always' frontmatter for Kiro steering files - Register kiro in CommandAdapterRegistry - Add legacy cleanup path pattern for Kiro - Add unit tests for kiro adapter - Update docs/supported-tools.md with Kiro configuration Generated with Kiro IDE using Claude Opus 4.5
📝 WalkthroughWalkthroughAdds Kiro IDE support: new Changes
Sequence Diagram(s)sequenceDiagram
participant CLI as CLI
participant Registry as CommandAdapterRegistry
participant Adapter as kiroAdapter
participant FS as Filesystem
CLI->>Registry: request adapter for tool "kiro"
Registry->>Adapter: select kiroAdapter
CLI->>Adapter: provide CommandContent (id, name, body, description)
Adapter->>Adapter: formatFile() -> markdown with YAML frontmatter
Adapter->>FS: write `.kiro/steering/opsx-<id>.md`
FS-->>CLI: file created
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Review CompleteYour review story is ready! Comment !reviewfast on this PR to re-generate the story. |
Greptile OverviewGreptile SummaryAdded Kiro IDE support to OpenSpec following the established adapter pattern. Key Changes:
Notes:
Confidence Score: 4/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant User
participant CLI as OpenSpec CLI
participant Registry as CommandAdapterRegistry
participant KiroAdapter as kiroAdapter
participant FS as File System
User->>CLI: openspec init --tools kiro
CLI->>Registry: Load adapters
Registry->>KiroAdapter: register(kiroAdapter)
Note over KiroAdapter: toolId: 'kiro'<br/>skillsDir: '.kiro'
loop For each command (explore, new, apply, etc.)
CLI->>KiroAdapter: getFilePath(commandId)
KiroAdapter-->>CLI: .kiro/steering/opsx-{commandId}.md
CLI->>KiroAdapter: formatFile(content)
Note over KiroAdapter: Format with frontmatter:<br/>inclusion: always
KiroAdapter-->>CLI: Formatted markdown with YAML
CLI->>FS: Write file to .kiro/steering/
FS-->>CLI: Success
end
CLI->>FS: Write skills to .kiro/skills/
FS-->>CLI: Complete
CLI-->>User: Kiro IDE configured
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| function escapeYamlValue(value: string): string { | ||
| const needsQuoting = /[:\n\r#{}[\],&*!|>'"%@`]|^\s|\s$/.test(value); | ||
| if (needsQuoting) { | ||
| const escaped = value.replace(/\\/g, '\\\\').replace(/"/g, '\\"').replace(/\n/g, '\\n'); | ||
| return `"${escaped}"`; | ||
| } | ||
| return value; | ||
| } |
There was a problem hiding this comment.
unused function - escapeYamlValue is defined but never called in formatFile
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/core/command-generation/adapters/kiro.ts
Line: 15:22
Comment:
unused function - `escapeYamlValue` is defined but never called in `formatFile`
How can I resolve this? If you propose a fix, please make it concise.![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@src/core/command-generation/adapters/kiro.ts`:
- Around line 13-15: The file-level comment that describes the Kiro steering
file frontmatter incorrectly lists name and description as YAML frontmatter
fields; update that comment so it only documents the supported frontmatter keys
(inclusion and fileMatchPattern) and note that name and description are emitted
into the markdown body (not the YAML frontmatter) — edit the top comment block
in src/core/command-generation/adapters/kiro.ts to remove references to
name/description from the frontmatter section and clarify that only inclusion
and fileMatchPattern belong in YAML while name/description are body content
(referencing the existing emitted keys "inclusion" and "fileMatchPattern" in the
code).
| * File path: .kiro/steering/opsx-<id>.md | ||
| * Frontmatter: inclusion (always), name, description | ||
| * |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n src/core/command-generation/adapters/kiro.tsRepository: Fission-AI/OpenSpec
Length of output: 1427
🌐 Web query:
Kiro IDE steering file specification frontmatter fields format
💡 Result:
Kiro steering files (.kiro/steering/*.md or ~/.kiro/steering/*.md) can start with optional YAML frontmatter that controls when the file is loaded. The frontmatter:
- Must be the very first content in the file (no blank lines/content before it)
- Uses YAML, wrapped in
---/---delimiters (i.e., “triple dashes”) [1]
Supported frontmatter fields (documented)
inclusion
Controls when the steering file is included [1]:
always(default behavior)fileMatchmanual[1]
fileMatchPattern
Only used when inclusion: fileMatch. It’s a glob pattern, and can be either:
- a single string, or
- an array of strings (multiple globs) [1]
Examples
Always included
---
inclusion: always
---[1]
Conditional (file match)
---
inclusion: fileMatch
fileMatchPattern: "components/**/*.tsx"
---or multiple patterns:
---
inclusion: fileMatch
fileMatchPattern: ["**/*.ts", "**/*.tsx", "**/tsconfig.*.json"]
---[1]
Manual inclusion
---
inclusion: manual
---Included on demand by referencing #steering-file-name in chat [1]
Source: Kiro “Steering” docs (updated Jan 24, 2026) [1].
Remove name/description from the frontmatter comment—they are markdown body content, not YAML fields.
The Kiro steering file specification documents only inclusion and fileMatchPattern as supported frontmatter fields. The code correctly emits only inclusion: always in frontmatter, with name and description appearing in the markdown body (lines 35, 37). Update the comment to reflect the actual implementation and spec.
Suggested fix
- * Frontmatter: inclusion (always), name, description
+ * Frontmatter: inclusion (always)Also applies to: 31-33
🤖 Prompt for AI Agents
In `@src/core/command-generation/adapters/kiro.ts` around lines 13 - 15, The
file-level comment that describes the Kiro steering file frontmatter incorrectly
lists name and description as YAML frontmatter fields; update that comment so it
only documents the supported frontmatter keys (inclusion and fileMatchPattern)
and note that name and description are emitted into the markdown body (not the
YAML frontmatter) — edit the top comment block in
src/core/command-generation/adapters/kiro.ts to remove references to
name/description from the frontmatter section and clarify that only inclusion
and fileMatchPattern belong in YAML while name/description are body content
(referencing the existing emitted keys "inclusion" and "fileMatchPattern" in the
code).
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@openspec/changes/add-kiro-support/tasks.md`:
- Around line 8-9: The spec files incorrectly document a single fixed steering
file name; update cli-init/spec.md and kiro-integration/spec.md to state that
Kiro produces per-command steering files using the pattern
`.kiro/steering/opsx-<commandId>.md` to match the adapter implementation; mirror
the logic in src/core/command-generation/adapters/kiro.ts by referencing its
getFilePath() behavior and replace any occurrences of
`.kiro/steering/openspec.md` with the per-command pattern and an explanatory
note that `<commandId>` corresponds to the command's id.
🧹 Nitpick comments (2)
openspec/changes/add-kiro-support/specs/cli-init/spec.md (1)
31-49: Clarify where users can add custom content.The file structure examples show all content wrapped within the OpenSpec managed markers (
<!-- OPENSPEC:START -->/<!-- OPENSPEC:END -->). However, the update requirements inkiro-integration/spec.md(line 103) specify preserving "user content outside the markers."Consider adding an example or note showing where users can safely add custom content that won't be overwritten during
openspec update.Also applies to: 55-73
openspec/changes/add-kiro-support/specs/kiro-integration/spec.md (1)
54-55: Consider explaining Kiro's file reference syntax.The spec mentions using Kiro's
#[[file:]]syntax but doesn't explain its purpose or behavior. For readers unfamiliar with Kiro IDE, a brief note explaining that this syntax allows Kiro to include the referenced file's content in the AI context would improve clarity.Also applies to: 60-61
| - [x] 1.2 Register Kiro steering file path pattern `.kiro/steering/opsx-<id>.md` in the configurator system | ||
| - [x] 1.2 在配置器系统中注册 Kiro steering 文件路径模式 `.kiro/steering/opsx-<id>.md` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's find and examine the tasks.md file
find . -name "tasks.md" -type f | head -20Repository: Fission-AI/OpenSpec
Length of output: 1387
🏁 Script executed:
# Search for the spec files mentioned in the review
find . -name "spec.md" -type f | head -20Repository: Fission-AI/OpenSpec
Length of output: 1670
🏁 Script executed:
# Search for Kiro adapter implementation
find . -type f -name "*kiro*" | head -30Repository: Fission-AI/OpenSpec
Length of output: 109
🏁 Script executed:
# Search for references to the path patterns mentioned
rg "kiro/steering" --type md -A 2 -B 2Repository: Fission-AI/OpenSpec
Length of output: 10087
🏁 Script executed:
# Read the tasks.md file to see the exact content around lines 8-9
cat -n openspec/changes/add-kiro-support/tasks.md | head -30Repository: Fission-AI/OpenSpec
Length of output: 1726
🏁 Script executed:
# Read the Kiro adapter implementation
cat -n src/core/command-generation/adapters/kiro.tsRepository: Fission-AI/OpenSpec
Length of output: 1427
🏁 Script executed:
# Read the kiro-integration spec file
cat -n openspec/changes/add-kiro-support/specs/kiro-integration/spec.md | head -100Repository: Fission-AI/OpenSpec
Length of output: 4564
🏁 Script executed:
# Read the cli-init spec file to see what it says about the file path
cat -n openspec/changes/add-kiro-support/specs/cli-init/spec.md | head -150Repository: Fission-AI/OpenSpec
Length of output: 3870
🏁 Script executed:
# Let me check the proposal file to confirm the intended design
cat -n openspec/changes/add-kiro-support/proposal.md | grep -A 5 -B 5 "kiro/steering"Repository: Fission-AI/OpenSpec
Length of output: 2945
🏁 Script executed:
# Also check if there are any other references to understand the intent better
rg "opsx-" openspec/changes/add-kiro-support/ -A 2 -B 2Repository: Fission-AI/OpenSpec
Length of output: 1187
Update specs to match Kiro adapter implementation—files are per-command, not single.
The Kiro adapter implementation (src/core/command-generation/adapters/kiro.ts) and tasks correctly use the per-command pattern .kiro/steering/opsx-<commandId>.md, but the spec files contradict this. Both cli-init/spec.md and kiro-integration/spec.md specify .kiro/steering/openspec.md (a single fixed filename), which conflicts with the actual implementation.
Update the spec files to reflect that Kiro generates per-command steering files at .kiro/steering/opsx-<commandId>.md, mirroring the adapter's getFilePath() method. This aligns specs, implementation, and task descriptions.
🤖 Prompt for AI Agents
In `@openspec/changes/add-kiro-support/tasks.md` around lines 8 - 9, The spec
files incorrectly document a single fixed steering file name; update
cli-init/spec.md and kiro-integration/spec.md to state that Kiro produces
per-command steering files using the pattern
`.kiro/steering/opsx-<commandId>.md` to match the adapter implementation; mirror
the logic in src/core/command-generation/adapters/kiro.ts by referencing its
getFilePath() behavior and replace any occurrences of
`.kiro/steering/openspec.md` with the per-command pattern and an explanatory
note that `<commandId>` corresponds to the command's id.
1 participant
Generated with Kiro IDE using Claude Opus 4.5
Summary by CodeRabbit
New Features
Documentation
Behavior
Tests