Repository navigation
feat(cli): add Kilo Code support #744
Copy link
Copy link
Closed
Description
Problem
AIDD provides a native flat distribution for OpenCode, but not for Kilo Code. Kilo uses its own project layout and configuration surfaces, so the OpenCode archive is not discovered as a native Kilo setup.
Scope
- Add Kilo Code as a supported AI tool and flat framework-build target.
- Materialize native
.kilo/agents,.kilo/skills, and MCP output. - Generate the Kilo-native project lifecycle plugin under
.kilo/plugin/from the relevant AIDD declarative lifecycle definitions. - Reuse the existing AIDD project-memory synchronization behavior for Kilo's independently verified
session.createdequivalent. - Use the project-local Kilo configuration shape, preferring
.kilo/kilo.jsonc, while preserving existing user configuration and instructions. - Resolve existing
kilo.json/kilo.jsoncconfiguration without creating both variants, overwriting user content, or duplicating instructions. - Register Kilo in the relevant tool, asset, translation, release, and documentation surfaces.
- Add unit, integration, golden, and real Kilo runtime smoke coverage.
Rules and flat plugin-command distribution are not part of this issue. Direct artifact generation is tracked separately in #788, flat Kilo Rules in #868, and flat Kilo command distribution requires a separate follow-up after this foundation.
Acceptance criteria
-
translate --to kilo --as flatproduces native.kilo/agents,.kilo/skills, and MCP output. - AIDD agents, skills, and MCP configuration are discoverable by a real Kilo project session.
- The lifecycle definitions are materialized as a Kilo-native project plugin under
.kilo/plugin/. - A real Kilo CLI or extension smoke test independently verifies the supported lifecycle event and invokes project-memory synchronization exactly once for a newly created Kilo session.
- The adapter reuses the existing AIDD memory-sync behavior; it does not maintain a Kilo-only duplicate.
- The adapter loads from the project-local Kilo plugin location without requiring a global installation.
- Project-local configuration uses the resolved
kilo.json[c]shape, prefers.kilo/kilo.jsonc, preserves existing user configuration and instructions, and does not create both variants or duplicate instructions. - Missing memory banks, missing managed blocks, and malformed markers do not create or overwrite user files.
- Plugin failures are non-blocking for the Kilo session and expose a useful diagnostic.
- Unit, integration, golden, and real Kilo runtime smoke tests cover the generated output, lifecycle event, configuration resolution, and failure behavior.
- Installation instructions document the flat-only Kilo layout, project-local configuration, and plugin location.
Prior art in this repo
- OpenCode's tool profile and telemetry declaration: link to
cli/src/contexts/tools/domain/profiles/opencode/profile.ts#L38-L69. - OpenCode's generated lifecycle bridge: link to
.../opencode-hooks-bridge.ts#L1-L20. - Existing AIDD project-memory hook:
plugins/aidd-context/hooks/update_memory.js. - OpenCode implementation introduced by feat(cli): one shared framework source per machine, user scope and session telemetry #795.
Out of scope
- Rules and their direct artifact generation; see feat(cli): emit rules in Kilo flat builds #868 and feat(aidd-context): add Kilo support and correct OpenCode rule guidance #788.
- Flat distribution of plugin command/workflow artifacts; the Kilo profile retains its documented command surface.
- Kilo marketplace distribution; Kilo is flat-only for this target.
- Kilo telemetry ingestion or cost reporting; Kilo's experimental OpenTelemetry surface is not yet supported by AIDD.
- Lifecycle events beyond the independently validated session-created/session-start mapping.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Type
Fields
Priority
High
Projects
- StatusShow more project fieldsDone
Activity
blafourcade commentedon Sep 14, 2026
I checked the current Kilo documentation and the separation is now clearer.
The native locations are documented:
.kilo/agents/,.kilo/skills/,.kilo/plugin/, and project configuration under.kilo/kilo.json[c]orkilo.json[c]. Local plugins in.kilo/plugin/are discovered at startup, andsession.createdis a documented event.This issue is the Kilo foundation: the tool profile, flat materialization for skills, agents and MCP, plus a Kilo-native project-memory bridge with an independently verified runtime event. The generated configuration should use the project-local
.kilo/kilo.jsoncshape so it stays alongside the generated plugin files and preserves user JSONC.Rules and commands are not part of this issue. #788 owns direct artifact generation. The OpenCode archive work will remain in #789; the Kilo archive work will move to a separate follow-up issue blocked by #744.
PR #745 is open draft work, not a closing PR for this issue. It contains the Kilo foundation alongside rules and commands. Once the issue split is in place, it should be aligned with this core scope before review and validated with a real Kilo CLI or extension smoke test.
waewoo commentedon Sep 14, 2026
Thanks, this clarifies the Kilo foundation boundary.
The issue is now aligned around the tool profile, flat materialization for agents, skills and MCP, and the independently verified project-local lifecycle plugin bridge. Rules and flat plugin-command distribution remain outside #744, with #788 owning direct generation and #868 owning flat Kilo rules. The Kilo profile retains its documented command surface.
The Kilo config contract now resolves the project-local kilo.json[c] shape while preserving existing user configuration, and the runtime event mapping must be proven with a real Kilo smoke test before treating the PR as closing work.
blafourcade commentedon Sep 23, 2026
Delivered by #745 and squash-merged into
nextas c3a3355. All required CI workflows passed, including the Kilo runtime smoke and Windows job.