mirror of
https://github.com/Fission-AI/OpenSpec.git
synced 2026-10-04 14:38:54 +08:00
Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
0a0b35433f |
@@ -0,0 +1,19 @@
|
||||
## Why
|
||||
Gemini CLI now supports project-scoped custom slash commands that live under `.gemini/commands`. Teams using OpenSpec with Gemini CLI must currently hand-write these TOML files to stay aligned with the proposal/apply/archive workflow, creating drift and inconsistent instructions. Extending OpenSpec's automation keeps Gemini CLI users at parity with Claude, Cursor, and OpenCode.
|
||||
|
||||
## Research Findings
|
||||
- Gemini CLI discovers user and project commands from `~/.gemini/commands/` and `<project>/.gemini/commands/`, with project commands winning on name conflicts. Commands are named from their relative path (e.g., `openspec/proposal.toml` → `/openspec:proposal`).
|
||||
- Each command definition is a TOML file that must provide a `prompt` string and can optionally include a `description`. Multiline prompts use triple quotes and safely support argument injection via `{{args}}` as well as shell execution blocks (`!{...}`) that trigger confirmations.
|
||||
- Gemini CLI loads these definitions through `FileCommandLoader`, which scans both command directories, parses TOML via Zod, and adapts them into executable slash commands at runtime.
|
||||
|
||||
## What Changes
|
||||
- Treat Gemini CLI as a first-class slash command target during `openspec init`, generating `.gemini/commands/openspec/proposal.toml`, `apply.toml`, and `archive.toml` populated from shared templates wrapped with OpenSpec markers.
|
||||
- Refresh existing Gemini CLI command files during `openspec update`, updating only the marker-managed prompt content when the files already exist.
|
||||
- Add a Gemini CLI option to the AI tool selection UI and to the slash command registry so users can configure or refresh it alongside other assistants.
|
||||
- Provide Vitest coverage that mirrors existing slash command tests for creation and update flows, ensuring the TOML scaffolding integrates cleanly with FileCommandLoader expectations.
|
||||
- Document the Gemini CLI slash command behavior in the relevant specs so downstream automation and teams understand the new capability.
|
||||
|
||||
## Impact
|
||||
- Affected specs: `cli-init`, `cli-update`
|
||||
- Affected code (planned): slash command configurators/registry, CLI init & update flows, template management, AI tool configuration prompts
|
||||
- Affected tests: `test/core/init.test.ts`, `test/core/update.test.ts` (new cases for Gemini CLI)
|
||||
@@ -0,0 +1,9 @@
|
||||
## MODIFIED Requirements
|
||||
### Requirement: Slash Command Configuration
|
||||
The init command SHALL generate slash command files for supported editors using shared templates.
|
||||
|
||||
#### Scenario: Generating slash commands for Gemini CLI
|
||||
- **WHEN** the user selects Gemini CLI during initialization
|
||||
- **THEN** create `.gemini/commands/openspec/proposal.toml`, `.gemini/commands/openspec/apply.toml`, and `.gemini/commands/openspec/archive.toml`
|
||||
- **AND** populate each file from shared templates so command text matches other tools
|
||||
- **AND** ensure each TOML file contains OpenSpec-managed markers around the prompt so future updates can refresh the body safely
|
||||
@@ -0,0 +1,8 @@
|
||||
## MODIFIED Requirements
|
||||
### Requirement: Slash Command Updates
|
||||
The update command SHALL refresh existing slash command files for configured tools without creating new ones.
|
||||
|
||||
#### Scenario: Updating slash commands for Gemini CLI
|
||||
- **WHEN** `.gemini/commands/openspec/` contains `proposal.toml`, `apply.toml`, and `archive.toml`
|
||||
- **THEN** refresh each file using shared templates while preserving content outside the OpenSpec markers
|
||||
- **AND** ensure the updated prompts remain wrapped with markers to support future refreshes
|
||||
@@ -0,0 +1,20 @@
|
||||
## 1. Slash command scaffolding
|
||||
- [ ] 1.1 Add a Gemini CLI entry to the slash command registry with a `GeminiSlashCommandConfigurator` that maps `proposal`, `apply`, and `archive` to `.gemini/commands/openspec/*.toml`.
|
||||
- [ ] 1.2 Reuse existing slash command templates for the prompt bodies and ensure they are wrapped by OpenSpec markers inside the TOML `prompt` string.
|
||||
- [ ] 1.3 Define any Gemini-specific metadata (e.g., `description` values) that should live alongside the prompts to improve `/help` readability.
|
||||
|
||||
## 2. CLI init integration
|
||||
- [ ] 2.1 Extend the AI tool selection options to list Gemini CLI as supporting OpenSpec slash commands, including already-configured detection and success messaging.
|
||||
- [ ] 2.2 Ensure `openspec init` writes the Gemini CLI TOML files when the tool is selected, creating parent directories as needed.
|
||||
|
||||
## 3. CLI update integration
|
||||
- [ ] 3.1 Update the slash command refresh flow so `openspec update` rewrites Gemini CLI TOML prompts only when the files already exist.
|
||||
- [ ] 3.2 Extend logging to report Gemini slash command updates alongside other tools.
|
||||
|
||||
## 4. Tests
|
||||
- [ ] 4.1 Add Vitest coverage under `test/core/init.test.ts` that verifies the Gemini CLI TOML files are generated with the expected prompts and markers.
|
||||
- [ ] 4.2 Add Vitest coverage under `test/core/update.test.ts` that confirms existing Gemini TOML files get refreshed while preserving content outside the markers.
|
||||
|
||||
## 5. Documentation & polish
|
||||
- [ ] 5.1 Update README (or other user-facing docs) to mention Gemini CLI slash command support and how the generated files map to `/openspec:*` commands.
|
||||
- [ ] 5.2 Document any Gemini-specific limitations or follow-up work (e.g., handling of folder trust) if discovered during implementation.
|
||||
Reference in New Issue
Block a user