Skip to content

feat(cli): add Kilo Code support #744

Description

@waewoo

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.created equivalent.
  • Use the project-local Kilo configuration shape, preferring .kilo/kilo.jsonc, while preserving existing user configuration and instructions.
  • Resolve existing kilo.json/kilo.jsonc configuration 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 flat produces 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

Out of scope

Activity

  1. blafourcade commented on Sep 14, 2026

    @blafourcade
    Contributor

    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] or kilo.json[c]. Local plugins in .kilo/plugin/ are discovered at startup, and session.created is 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.jsonc shape 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.

  2. moved this from Ideation to In Progress in AIDD Roadmapon Sep 14, 2026
  3. waewoo commented on Sep 14, 2026

    @waewoo
    ContributorAuthor

    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.

  4. moved this from In Progress to In review in AIDD Roadmapon Sep 23, 2026
  5. blafourcade commented on Sep 23, 2026

    @blafourcade
    Contributor

    Delivered by #745 and squash-merged into next as c3a3355. All required CI workflows passed, including the Kilo runtime smoke and Windows job.

  6. moved this from In review to Done in AIDD Roadmapon Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Fields

    Priority

    High

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions