What feature would you like to see?
Kimi Code currently recognizes an explicit Skill slash command only when / appears at the
beginning of the entire TUI input.
This works for a short prompt such as:
/skill:code-review review this change
However, after a user has started writing a longer or multi-line prompt, there is no
convenient way to open the Skill picker and explicitly activate another Skill. A / skill:<name> token written later in the prompt is currently treated as ordinary text.
This makes prompts that need multiple Skills awkward to compose. Users must either plan the
Skill before writing the prompt or manually type exact Skill names and rely on the model to
interpret them.
Relying on a later model invocation is not equivalent to explicit user activation. In
particular, if a Skill has disableModelInvocation: true, the model is correctly prevented
from invoking it through the Skill tool even though the user explicitly wrote its name in
the prompt.
Proposed experience
Allow users to select Skills anywhere in a TUI prompt, similarly to inserting an @ file
reference:
- Typing
/ after whitespace — including spaces, tabs, and newlines — opens a Skill-only
completion menu.
- Selecting an item inserts its canonical Skill token, such as
/skill:code-review .
- Recognized Skill tokens remain visible and highlighted in the original prompt.
- A single prompt can explicitly activate multiple Skills.
- Manually typed tokens should behave the same as tokens selected from the completion menu
when they exactly match a registered Skill.
- Each Skill is activated once, in first-occurrence order.
- All referenced Skills are activated as explicit user invocations before the original prompt
is submitted.
- The original prompt, including its Skill tokens and media attachments, is preserved
unchanged.
- All Skill activations and the prompt start exactly one agent turn.
- Validation and submission are atomic: if any referenced Skill is invalid, no Skill is
activated, no context is changed, and the prompt is not submitted.
- The Skill activations and their originating prompt behave as one logical submission,
including when using /undo.
For example:
/skill:code-review review code in the current working directory,
fix any potential bugs, then commit it using /skill:git-commits
Both code-review and git-commits should be activated by the user as part of the same
prompt.
Compatibility and scope
The existing leading / behavior should remain unchanged:
- A
/ at the beginning of the input continues to open the complete slash-command menu.
- The mid-input picker contains only Skills; built-in non-Skill commands and plugin commands
are excluded.
- Unknown
/tokens, paths, URLs, fractions, and other slash-containing text remain ordinary
prompt text.
- Mid-input Skill tokens do not introduce a new argument syntax; the existing leading
/ skill:<name> args form remains available when Skill arguments are needed.
- Shell mode keeps its existing path-completion behavior.
- This proposal covers the CLI/TUI. Web UI support is out of scope.
This does not change the policy for model-initiated Skill tool calls. It only ensures that
registered Skill tokens explicitly entered by the user are handled as user activations.
Additional information
I have a working implementation and would be happy to submit a PR if the maintainers agree
with this direction.
The implementation currently includes:
- Inline Skill autocomplete after whitespace and across multiple lines
- Skill-only fuzzy matching in the mid-input completion menu
- Highlighting for recognized inline Skill tokens
- Multiple explicit user Skill activations in one prompt
- Deduplication in first-occurrence order
- Atomic validation and prompt submission through the SDK
- Exactly one agent turn for the combined submission
- One logical
/undo unit for the Skill activations and their originating prompt
- Preservation of prompt text and media attachments
- Support for queued prompts
- Focused Core, SDK, TUI, autocomplete, highlighting, replay, and undo tests
Related prior work: #135 fixed how leading slash-activated Skills are represented to the
model. This proposal extends explicit user activation to inline and multi-Skill prompts; it
does not change the policy for model-initiated Skill tool calls.
Prototype
Selecting multiple Skills in one prompt:
Both referenced Skills are activated before the agent turn begins:
Additional information
No response
What feature would you like to see?
Kimi Code currently recognizes an explicit Skill slash command only when
/appears at thebeginning of the entire TUI input.
This works for a short prompt such as:
However, after a user has started writing a longer or multi-line prompt, there is no
convenient way to open the Skill picker and explicitly activate another Skill. A
/ skill:<name>token written later in the prompt is currently treated as ordinary text.This makes prompts that need multiple Skills awkward to compose. Users must either plan the
Skill before writing the prompt or manually type exact Skill names and rely on the model to
interpret them.
Relying on a later model invocation is not equivalent to explicit user activation. In
particular, if a Skill has
disableModelInvocation: true, the model is correctly preventedfrom invoking it through the
Skilltool even though the user explicitly wrote its name inthe prompt.
Proposed experience
Allow users to select Skills anywhere in a TUI prompt, similarly to inserting an
@filereference:
/after whitespace — including spaces, tabs, and newlines — opens a Skill-onlycompletion menu.
/skill:code-review.when they exactly match a registered Skill.
is submitted.
unchanged.
activated, no context is changed, and the prompt is not submitted.
including when using
/undo.For example:
Both
code-reviewandgit-commitsshould be activated by the user as part of the sameprompt.
Compatibility and scope
The existing leading
/behavior should remain unchanged:/at the beginning of the input continues to open the complete slash-command menu.are excluded.
/tokens, paths, URLs, fractions, and other slash-containing text remain ordinaryprompt text.
/ skill:<name> argsform remains available when Skill arguments are needed.This does not change the policy for model-initiated Skill tool calls. It only ensures that
registered Skill tokens explicitly entered by the user are handled as user activations.
Additional information
I have a working implementation and would be happy to submit a PR if the maintainers agree
with this direction.
The implementation currently includes:
/undounit for the Skill activations and their originating promptRelated prior work: #135 fixed how leading slash-activated Skills are represented to the
model. This proposal extends explicit user activation to inline and multi-Skill prompts; it
does not change the policy for model-initiated Skill tool calls.
Prototype
Selecting multiple Skills in one prompt:
Both referenced Skills are activated before the agent turn begins:
Additional information
No response