gemini-cli - 💡(How to fix) Fix Add path-based skill visibility controls for .agents/skills [1 participants]

What would you like to be added?

Summary

Gemini CLI discovers skills from both .gemini/skills and .agents/skills. That works for shared skills, but it breaks down in mixed-tool repos where .agents/skills contains some skills that should be shared and some that should only be used by another tool such as Codex. Today the workaround is skills.disabled, but that is name-based and external to the repo layout.

Why is this needed?

Problem

A common setup is:

• .agents/skills for shared skills
• .gemini/skills for Gemini-specific skills The issue is that Gemini also discovers repo-local skills in .agents/skills that are not intended for Gemini. This is manageable in small setups, but it becomes awkward as the number of skills grows or when the repo is used across multiple machines/users.

Request

Please add a more precise way to control skill visibility, ideally path-based include/exclude rules for discovery. For example:

{
  "skills": {
    "excludeGlobs": [
      ".agents/skills/codex-only/**"
    ]
  }
}

or:

{
  "skills": {
    "includePaths": [
      ".gemini/skills",
      ".agents/skills/shared"
    ]
  }
}

A metadata-based approach on individual skills would also work.

Why this would help

This would let users cleanly express:

• shared skills
• Gemini-only skills
• non-Gemini skills

without relying on a denylist by skill name.

Minimal feature that would solve it

Path/glob-based exclude support for skill discovery.

Non-goal

I am not asking to change the default discovery behavior.

I am asking for an opt-in way to make skill visibility more precise in mixed-tool repos.

Additional context

No response