|
| 1 | +--- |
| 2 | +title: "Use native Kimi plugin manifests instead of a converter target" |
| 3 | +date: 2026-06-24 |
| 4 | +category: integrations |
| 5 | +module: installer |
| 6 | +problem_type: tooling_decision |
| 7 | +component: tooling |
| 8 | +severity: medium |
| 9 | +applies_when: |
| 10 | + - "Adding support for a coding-agent platform that can install plugin manifests directly" |
| 11 | + - "A proposed converter target duplicates a platform-native plugin or marketplace flow" |
| 12 | + - "Release automation must keep platform manifests in parity with canonical plugin metadata" |
| 13 | +related_components: |
| 14 | + - release-metadata |
| 15 | + - release-please |
| 16 | + - native-plugin-install |
| 17 | +tags: |
| 18 | + - kimi |
| 19 | + - native-plugins |
| 20 | + - marketplace |
| 21 | + - release-validation |
| 22 | + - converter-targets |
| 23 | +--- |
| 24 | + |
| 25 | +# Use native Kimi plugin manifests instead of a converter target |
| 26 | + |
| 27 | +## Problem |
| 28 | + |
| 29 | +Kimi Code support can look like a normal new target provider at first: add `--to kimi`, write a converter, and emit a Kimi-specific output tree. That is the wrong first move when the platform already has a native plugin manifest and custom marketplace contract. |
| 30 | + |
| 31 | +This came up when [PR #997](https://github.com/EveryInc/compound-engineering-plugin/pull/997) by [@mastepanoski](https://github.com/mastepanoski) proposed Kimi support as a converter target. The useful signal was the demand for Kimi support; the implementation shape duplicated a native install surface. |
| 32 | + |
| 33 | +## Decision |
| 34 | + |
| 35 | +Prefer Kimi's native plugin metadata over a converter target: |
| 36 | + |
| 37 | +- Commit `.kimi-plugin/plugin.json` with the Kimi manifest fields that describe this plugin, including `interface`, `skills`, `sessionStart.skill`, and `skillInstructions`. |
| 38 | +- Commit `.kimi-plugin/marketplace.json` using Kimi marketplace schema version `2`. |
| 39 | +- Keep `.kimi-plugin/plugin.json` in the root release component so release automation bumps it with the canonical plugin version. |
| 40 | +- Treat `.kimi-plugin/marketplace.json` as static catalog metadata, and validate it instead of version-bumping it. |
| 41 | +- Do not add `src/converters/claude-to-kimi.ts`, `src/targets/kimi.ts`, or a `--to kimi` CLI target unless Kimi later documents a separate generated output format that cannot be represented by the native manifest. |
| 42 | + |
| 43 | +## Why This Matters |
| 44 | + |
| 45 | +Native plugin support is a distribution contract, not a format-conversion problem. A converter target would create another generated install path to document, test, version, and clean up, while Kimi users would still need the manifest and marketplace metadata for the normal install flow. |
| 46 | + |
| 47 | +The correct support surface is therefore: |
| 48 | + |
| 49 | +- platform metadata: `.kimi-plugin/plugin.json` and `.kimi-plugin/marketplace.json` |
| 50 | +- release metadata: version parity, required fields, skill path checks, and marketplace schema validation |
| 51 | +- user docs: install and local-development instructions for Kimi's native plugin flow |
| 52 | +- target spec docs: a short spec explaining which Kimi fields are used and which unsupported runtime fields are intentionally absent |
| 53 | + |
| 54 | +## Implementation Pattern |
| 55 | + |
| 56 | +When adding a platform with a native plugin surface, wire it like a first-class release surface: |
| 57 | + |
| 58 | +1. Add the native manifest and marketplace/catalog files expected by the platform. |
| 59 | +2. Put the release-owned manifest file in `.github/release-please-config.json` as an extra file for the canonical component. |
| 60 | +3. Exclude static marketplace files from release component ownership when they do not carry a version. |
| 61 | +4. Add release validation that rejects missing manifests, version drift, missing declared asset paths, marketplace schema drift, and marketplace plugin-list drift. |
| 62 | +5. Update README install docs and `docs/specs/` so future contributors know this is native metadata, not a converter target. |
| 63 | + |
| 64 | +For Kimi specifically, validate at least: |
| 65 | + |
| 66 | +- `.kimi-plugin/plugin.json` exists |
| 67 | +- `name`, `version`, `description`, and `skills` are non-empty |
| 68 | +- `skills` points at an existing directory in the repo |
| 69 | +- the Kimi manifest version equals the root plugin/package version |
| 70 | +- `.kimi-plugin/marketplace.json` has schema `version: "2"` |
| 71 | +- marketplace plugin IDs match the Claude marketplace plugin IDs |
| 72 | +- each marketplace entry has a non-empty `source` |
| 73 | +- root-local marketplace sources such as `"."` or `"./"` are rejected because they are only local-development placeholders |
| 74 | + |
| 75 | +## Warning Signs |
| 76 | + |
| 77 | +Reconsider a proposed new target provider when: |
| 78 | + |
| 79 | +- the platform docs describe a `plugin.json`-style manifest in the source repo |
| 80 | +- the platform supports a custom marketplace or catalog pointing at repository/plugin sources |
| 81 | +- the target would mostly copy existing skills and docs without meaningful tool, permission, hook, or model conversion |
| 82 | +- install docs would need to tell users to run this repo's converter instead of the platform's documented plugin install path |
| 83 | + |
| 84 | +Those are signs the platform support belongs in native metadata and release validation. |
| 85 | + |
| 86 | +## Related |
| 87 | + |
| 88 | +- [Native plugin install strategy](./native-plugin-install-strategy.md) |
| 89 | +- [Plugin versioning requirements](../plugin-versioning-requirements.md) |
| 90 | +- [Adding converter target providers](../adding-converter-target-providers.md) |
| 91 | +- [PR #997: original Kimi support proposal](https://github.com/EveryInc/compound-engineering-plugin/pull/997) |
| 92 | +- [PR #998: native Kimi plugin support](https://github.com/EveryInc/compound-engineering-plugin/pull/998) |
0 commit comments