docs: add Gemini CLI spec and update README with gemini target

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kieran Klaassen
2026-02-14 20:34:31 -08:00
parent 201ad6d0fb
commit 8351851a13
2 changed files with 128 additions and 2 deletions

View File

@@ -12,9 +12,9 @@ A Claude Code plugin marketplace featuring the **Compound Engineering Plugin**
/plugin install compound-engineering
```
## OpenCode, Codex, Droid, Cursor & Pi (experimental) Install
## OpenCode, Codex, Droid, Cursor, Pi & Gemini (experimental) Install
This repo includes a Bun/TypeScript CLI that converts Claude Code plugins to OpenCode, Codex, Factory Droid, Cursor, and Pi.
This repo includes a Bun/TypeScript CLI that converts Claude Code plugins to OpenCode, Codex, Factory Droid, Cursor, Pi, and Gemini CLI.
```bash
# convert the compound-engineering plugin into OpenCode format
@@ -31,6 +31,9 @@ bunx @every-env/compound-plugin install compound-engineering --to cursor
# convert to Pi format
bunx @every-env/compound-plugin install compound-engineering --to pi
# convert to Gemini CLI format
bunx @every-env/compound-plugin install compound-engineering --to gemini
```
Local dev:
@@ -44,6 +47,7 @@ Codex output is written to `~/.codex/prompts` and `~/.codex/skills`, with each C
Droid output is written to `~/.factory/` with commands, droids (agents), and skills. Claude tool names are mapped to Factory equivalents (`Bash``Execute`, `Write``Create`, etc.) and namespace prefixes are stripped from commands.
Cursor output is written to `.cursor/` with rules (`.mdc`), commands, skills, and `mcp.json`. Agents become "Agent Requested" rules (`alwaysApply: false`) so Cursor's AI activates them on demand. Works with both the Cursor IDE and Cursor CLI (`cursor-agent`) — they share the same `.cursor/` config directory.
Pi output is written to `~/.pi/agent/` by default with prompts, skills, extensions, and `compound-engineering/mcporter.json` for MCPorter interoperability.
Gemini output is written to `.gemini/` with skills (from agents), commands (`.toml`), and `settings.json` (MCP servers). Namespaced commands create directory structure (`workflows:plan``commands/workflows/plan.toml`). Skills use the identical SKILL.md standard and pass through unchanged.
All provider targets are experimental and may change as the formats evolve.

122
docs/specs/gemini.md Normal file
View File

@@ -0,0 +1,122 @@
# Gemini CLI Spec (GEMINI.md, Commands, Skills, MCP, Settings)
Last verified: 2026-02-14
## Primary sources
```
https://github.com/google-gemini/gemini-cli
https://geminicli.com/docs/get-started/configuration/
https://geminicli.com/docs/cli/custom-commands/
https://geminicli.com/docs/cli/skills/
https://geminicli.com/docs/cli/creating-skills/
https://geminicli.com/docs/extensions/writing-extensions/
https://google-gemini.github.io/gemini-cli/docs/tools/mcp-server.html
```
## Config locations
- User-level config: `~/.gemini/settings.json`
- Project-level config: `.gemini/settings.json`
- Project-level takes precedence over user-level for most settings.
- GEMINI.md context file lives at project root (similar to CLAUDE.md).
## GEMINI.md context file
- A markdown file at project root loaded into every session's context.
- Used for project-wide instructions, coding standards, and conventions.
- Equivalent to Claude Code's CLAUDE.md.
## Custom commands (TOML format)
- Custom commands are TOML files stored in `.gemini/commands/`.
- Command name is derived from the file path: `.gemini/commands/git/commit.toml` becomes `/git:commit`.
- Directory-based namespacing: subdirectories create namespaced commands.
- Each command file has two fields:
- `description` (string): One-line description shown in `/help`
- `prompt` (string): The prompt sent to the model
- Supports placeholders:
- `{{args}}` — user-provided arguments
- `!{shell}` — output of a shell command
- `@{file}` — contents of a file
- Example:
```toml
description = "Create a git commit with a good message"
prompt = """
Look at the current git diff and create a commit with a descriptive message.
User request: {{args}}
"""
```
## Skills (SKILL.md standard)
- A skill is a folder containing `SKILL.md` plus optional supporting files.
- Skills live in `.gemini/skills/`.
- `SKILL.md` uses YAML frontmatter with `name` and `description` fields.
- Gemini activates skills on demand via `activate_skill` tool based on description matching.
- The `description` field is critical — Gemini uses it to decide when to activate the skill.
- Format is identical to Claude Code's SKILL.md standard.
- Example:
```yaml
---
name: security-reviewer
description: Review code for security vulnerabilities and OWASP compliance
---
# Security Reviewer
Detailed instructions for security review...
```
## MCP server configuration
- MCP servers are configured in `settings.json` under the `mcpServers` key.
- Same MCP protocol as Claude Code; different config location.
- Supports `command`, `args`, `env` for stdio transport.
- Supports `url`, `headers` for HTTP/SSE transport.
- Additional Gemini-specific fields: `cwd`, `timeout`, `trust`, `includeTools`, `excludeTools`.
- Example:
```json
{
"mcpServers": {
"context7": {
"url": "https://mcp.context7.com/mcp"
},
"playwright": {
"command": "npx",
"args": ["-y", "@anthropic/mcp-playwright"]
}
}
}
```
## Hooks
- Gemini supports hooks: `BeforeTool`, `AfterTool`, `SessionStart`, etc.
- Hooks use a different format from Claude Code hooks (matchers-based).
- Not converted by the plugin converter — a warning is emitted.
## Extensions
- Extensions are distributable packages for Gemini CLI.
- They extend functionality with custom tools, hooks, and commands.
- Not used for plugin conversion (different purpose from Claude Code plugins).
## Settings.json structure
```json
{
"model": "gemini-2.5-pro",
"mcpServers": { ... },
"tools": {
"sandbox": true
}
}
```
- Only the `mcpServers` key is written during plugin conversion.
- Other settings (model, tools, sandbox) are user-specific and out of scope.