MoonshotAI / MoonshotAI/kimi-code

feat: allow hiding skills by name via config (disabled_skills)

Open
#1,982 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
7.5k
Forks
1.2k
Avg merge
11h 53m
Merged PRs (30d)
350

Description

Problem

Many setups share a generic skill directory across tools (for example ~/.agents/skills/). Those directories often contain skills that are useful for other agents but should not appear in Kimi at all — not in the model listing, not via the Skill tool, and not in the slash menu.

Today the closest options are incomplete for that case:

  • Skill frontmatter disableModelInvocation: true only blocks automatic model invocation; the skill can still be slash-invoked and still shows up in listings.
  • A permission deny rule for Skill(...) can block the tool call, but the skill name can still remain visible in the model listing.
  • Removing or renaming files on disk breaks other tools that intentionally share the same directory.

Proposed solution

Add an optional top-level disabled_skills array in config.toml:

disabled_skills = ["grok-delegation", "pi-delegation"]

Behavior when a name matches (case-insensitive):

  • Hidden from model skill listing
  • Rejected by the Skill tool
  • Hidden from the slash menu / user activation paths
  • Files remain on disk for other tools

After editing, /reload or a new session applies the change.

Scope note

disabled_skills only covers the Skill surface. The agent may still reimplement a skill's workflow with other tools (for example Bash running a helper binary). Users who need that blocked should pair this with existing permission deny rules, which still apply in YOLO mode.

Why this fits Kimi Code

  • Opt-in, empty default — no behavior change for existing users
  • Complements rather than replaces disableModelInvocation and permission rules
  • Supports shared multi-tool skill directories without forking the skill tree per product
  • Same config surface for agent-core v1 and v2

Willingness to implement

I can open a focused PR with v1/v2 implementation, tests, bilingual docs, and a changeset if maintainers are open to this direction.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing config.toml handling and the Skill tool, model skill listing, slash menu, and /reload entry points across agent-core v1 and v2. Done means case-insensitive disabled_skills names are hidden from listings and activation paths, rejected by Skill, preserved on disk, and applied after /reload or in a new session.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
cli, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.