Summary
When the commands extra is synced to the gemini target, skillshare copies/symlinks the source .md files as-is. Gemini CLI does not recognize .md files as custom commands — it expects .toml files with a prompt field (see Gemini CLI custom commands docs). As a result, commands that work in Claude Code and Cursor are silently unavailable in Gemini.
Current behavior
With this .skillshare/config.yaml:
extras:
- name: commands
targets:
- path: .claude/commands
- path: .cursor/commands
- path: .gemini/commands
A source file extras/commands/review/review-pr.md with Claude-style frontmatter:
---
description: Code review a Bitbucket pull request
allowed-tools: ...
---
Provide a code review for the given Bitbucket pull request.
...
…gets synced to .gemini/commands/review/review-pr.md. Gemini CLI ignores it because it only scans for *.toml.
Expected behavior
When syncing the commands extra to a Gemini target, skillshare should emit a TOML file instead:
# .gemini/commands/review/review-pr.toml
description = "Code review a Bitbucket pull request"
prompt = """
Provide a code review for the given Bitbucket pull request.
...
"""
Mapping:
- YAML
description → TOML description
- Markdown body → TOML
prompt (multi-line string)
- Claude-specific frontmatter keys (
allowed-tools, disable-model-invocation, etc.) → dropped, since Gemini has no equivalent
- Argument placeholders: Claude uses
$ARGUMENTS / $1, Gemini uses {{args}} — needs translation or at minimum a documented caveat
Open questions
- Should the conversion be automatic for any target named
gemini, or opt-in via a per-target format: toml config key? Opt-in is safer if someone points a non-CLI Gemini tool at that path.
- Symlink mode obviously can't work for a format conversion — Gemini targets would need to be forced to copy mode (or error out) when this conversion is active.
- What should happen to Gemini-specific frontmatter that has no MD equivalent (e.g. if someone authors TOML-first)? Round-trip support is probably out of scope for v1.
Why it matters
Teams using skillshare across multiple AI tools assume "sync to all targets" means the commands actually work on all targets. Silent no-ops on Gemini are a surprising failure mode — either the format needs handling, or Gemini's command path needs to be excluded from the commands extra by default with a clear note in the docs.
Summary
When the
commandsextra is synced to thegeminitarget, skillshare copies/symlinks the source.mdfiles as-is. Gemini CLI does not recognize.mdfiles as custom commands — it expects.tomlfiles with apromptfield (see Gemini CLI custom commands docs). As a result, commands that work in Claude Code and Cursor are silently unavailable in Gemini.Current behavior
With this
.skillshare/config.yaml:A source file
extras/commands/review/review-pr.mdwith Claude-style frontmatter:…gets synced to
.gemini/commands/review/review-pr.md. Gemini CLI ignores it because it only scans for*.toml.Expected behavior
When syncing the
commandsextra to a Gemini target, skillshare should emit a TOML file instead:Mapping:
description→ TOMLdescriptionprompt(multi-line string)allowed-tools,disable-model-invocation, etc.) → dropped, since Gemini has no equivalent$ARGUMENTS/$1, Gemini uses{{args}}— needs translation or at minimum a documented caveatOpen questions
gemini, or opt-in via a per-targetformat: tomlconfig key? Opt-in is safer if someone points a non-CLI Gemini tool at that path.Why it matters
Teams using skillshare across multiple AI tools assume "sync to all targets" means the commands actually work on all targets. Silent no-ops on Gemini are a surprising failure mode — either the format needs handling, or Gemini's command path needs to be excluded from the
commandsextra by default with a clear note in the docs.