gemini-cli - 💡(How to fix) Fix SKILL.md parity with Claude Code

What would you like to be added?

Claude Code supports several extensions to the agents skill format. It would be great if some of them could be supported by Gemini CLI as well.

In particular:

• String substitutions in the skill contents Claude Code reference: $ARGUMENTS and ${CLAUDE_SKILL_DIR} are the ones I've found most useful. The latter is very useful for referencing a script or resource in the skill's scripts directory.
• Injecting dynamic context from shell command execution Claude Code reference: Useful for setup steps that need to run each time a script runs. Makes the agent's job easier by not having to invoke tools to run those setup commands.
• Pre-approve tools for a skill Claude Code reference: I find this extremely useful, especially when running skills in a subagent where Gemini CLI does not support any interactive permission prompts. Of course the tool/permission names won't be 100% compatible between Claude Code and Gemini CLI, but would be easy enough to migrate.
• Launching skills in a subagent Claude Code reference: context: fork to run the skill in a subagent of a configurable type. Though I find that the Claude Code implementation of this is actually quite confusing, since the flag is silently ignored when a skill is invoked from within an existing subagent. It honestly seems like a pretty poorly designed abstraction, so maybe not worth bringing over right now.

Why is this needed?

Supporting these extensions in Gemini CLI would make it much easier for users who have written custom skills to migrate from Claude Code to Gemini CLI, as well as make a large library of Claude Code skills compatible with Gemini CLI.

Additional context

I understand that some of these extensions might restrict how exactly skills are being executed. E.g. dynamic context and string substitutions imply that each time a skill is invoked, its content needs to be re-inserted into the context (since the substitutions make it different each time). Pre-approved tools require that the lifecycle of a given skill's execution is well defined, since those tools should only be pre-approved while the skill is "executing". I haven't checked what Gemini CLI's current implementation for Agent Skills looks like, so not sure if it would even be possible to support these additions without a major redesign.

Last but not least, there's a tradeoff here between sticking to an open, widely shared standard (Agent Skills), and adding custom extensions just to provide feature parity with a competitor's product. Pragmatically, the latter IMO could allow more people to try out and migrate to Gemini CLI, but it could also open a rabbit whole of new user expectations whenever the compatibility is not 100%.