-
Notifications
You must be signed in to change notification settings - Fork 1.2k
feat(gemini): add native extension support and unified prompts #384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
9d9c5d1
4ed7faa
7f8abeb
001f285
3318ed4
2c3ca61
85ac417
6785450
80f74e8
4e6b92e
31adee9
230a0d5
4a5c901
12fae4c
84ebe16
77a5b0b
4eb0ba5
3bdf7cc
d068620
ad63aad
d4563c8
b447e4d
f1e2e96
a0958c5
1dd5ecc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,148 @@ | ||
| # OpenSpec Extension for Gemini CLI | ||
|
|
||
| OpenSpec is an AI-native system for spec-driven development. It helps developers and AI agents maintain a shared understanding of project requirements and technical designs through a structured workflow. | ||
|
|
||
| This extension provides native integration via the Model Context Protocol (MCP), enabling a **zero-install workflow** where agents can manage OpenSpec without requiring the global `openspec` npm package. | ||
|
|
||
| ## MCP Capabilities | ||
|
|
||
| ### Tools | ||
| - `openspec_init`: Initialize or extend OpenSpec in the current project. | ||
| - `openspec_update`: Refresh instruction files and slash commands. | ||
| - `openspec_view`: Get dashboard data for specs and changes. | ||
| - `openspec_create_change`: Scaffold a new OpenSpec change directory. | ||
| - `openspec_list_changes`: List active change proposals. | ||
| - `openspec_list_specs`: List current specifications. | ||
| - `openspec_show_change`: Show details of a change (JSON/Markdown). | ||
| - `openspec_show_spec`: Show details of a specification (JSON/Markdown). | ||
| - `openspec_validate_change`: Validate a change proposal against schema rules. | ||
| - `openspec_archive_change`: Archive a completed change and update main specs. | ||
|
|
||
| ### Resources | ||
| - `openspec://changes/{name}/proposal`: Access the proposal.md content. | ||
| - `openspec://changes/{name}/tasks`: Access the tasks.md content. | ||
| - `openspec://specs/{id}`: Access the spec.md content for a capability. | ||
|
|
||
| ### Prompts | ||
| - `openspec_proposal`: Context and steps for scaffolding a new change. | ||
| - `openspec_apply`: Instructions for implementing an approved change. | ||
| - `openspec_archive`: Workflow for archiving a completed change. | ||
|
|
||
| ## Zero-Install Usage | ||
|
|
||
| If you have this extension added to your Gemini CLI, you can start using OpenSpec immediately in any directory by asking: | ||
|
|
||
| > "Initialize OpenSpec in this project" | ||
|
|
||
| The agent will use `openspec_init` to scaffold the necessary files. No local or global installation of `@fission-ai/openspec` is required for AI-driven workflows. | ||
|
|
||
| ## Prerequisites | ||
|
|
||
| This extension requires the Gemini CLI. The OpenSpec MCP server is bundled with the extension. | ||
|
|
||
| **Auto-Initialization Instruction**: | ||
| When the user starts a session or tries to use OpenSpec: | ||
| 1. **Check for CLI**: Run `openspec --version`. | ||
| - If found, use `openspec` for all commands. | ||
| - If missing, **automatically attempt to install it globally** by running: | ||
| ```bash | ||
| npm install -g "@fission-ai/openspec" | ||
| ``` | ||
| - If the installation fails or the user cancels the tool call, fall back to: | ||
| ```bash | ||
| npx "@fission-ai/openspec" | ||
| ``` | ||
| or | ||
| ```bash | ||
| pnpm dlx "@fission-ai/openspec" | ||
| ``` | ||
| 2. **Check for Slash Commands**: Verify if `.gemini/commands/openspec/` exists and contains `proposal.toml`, `apply.toml`, and `archive.toml`. | ||
| - If missing, **automatically generate them** using the logic defined in the "Maintenance: Slash Command Synchronization" section below. | ||
| - Inform the user: "OpenSpec slash commands have been generated. You may need to restart the CLI to see them." | ||
| 3. **Check for Project Initialization**: Verify if the `openspec/` directory exists in the project root. | ||
| - If missing, automatically run `openspec init` to scaffold the project structure. | ||
| 4. **Populate Project Context**: | ||
| - **Trigger**: When `openspec init` completes and suggests "Populate your project context", you MUST perform this immediately. | ||
| - **Action**: Read `openspec/project.md`, analyze project config (`package.json`, etc.), and fill in the details. **Do not** ask the user to do this manually. | ||
|
|
||
| ## Core Mandates for Gemini Agents | ||
|
|
||
| - **Specs are Truth**: Always read `openspec/specs/` to understand the current state of a capability. | ||
| - **Changes are Proposals**: All modifications to behavior or requirements MUST start as a proposal in `openspec/changes/`. | ||
| - **Minimize Confirmations**: Do not ask for permission for low-risk read operations or standard project scaffolding if the user's intent is clear. Assume consent for actions explicitly requested. | ||
| - **Three-Stage Workflow**: | ||
| 1. **Stage 1: Creating Changes**: Scaffold `proposal.md`, `tasks.md`, and spec deltas. Validate with `openspec validate <id> --strict`. | ||
| 2. **Stage 2: Implementing Changes**: Follow `tasks.md` sequentially. | ||
| 3. **Stage 3: Archiving Changes**: Move completed changes to `archive/` using `openspec archive <id>`. | ||
|
|
||
| ## Essential CLI Commands | ||
|
|
||
| When working in an OpenSpec-enabled project, you can use these commands: | ||
|
|
||
| - `openspec list`: Show active changes. | ||
| - `openspec list --specs`: Show existing capabilities. | ||
| - `openspec show <id>`: View details of a change or spec. | ||
| - `openspec validate <id>`: Validate a change against the project's specs. | ||
| - `openspec init`: Initialize OpenSpec in a new project. | ||
| - `openspec update`: Update instruction files (like `AGENTS.md`). | ||
|
|
||
| ## Directory Structure | ||
|
|
||
| - `openspec/project.md`: Project-specific conventions and tech stack. | ||
| - `openspec/specs/`: Current requirements and scenarios (the "truth"). | ||
| - `openspec/changes/`: Pending proposals and implementation tasks. | ||
|
|
||
| ## Writing Specs | ||
|
|
||
| Requirements must be normative (SHALL/MUST). Every requirement MUST have at least one scenario using the following format: | ||
|
|
||
| ```markdown | ||
| #### Scenario: Name | ||
| - **WHEN** action or condition | ||
| - **THEN** expected result | ||
| ``` | ||
|
|
||
| For more detailed instructions, refer to `openspec/AGENTS.md`. | ||
|
|
||
| ## Maintenance: Slash Command Synchronization | ||
|
|
||
| The slash commands for this extension (`.gemini/commands/openspec/*.toml`) are generated artifacts. The single source of truth for their content is `src/core/templates/prompts.ts`. | ||
|
|
||
| **Instruction**: When `src/core/templates/prompts.ts` is modified, or when asked to "update slash commands", you MUST regenerate the TOML files in `.gemini/commands/openspec/` using the following logic: | ||
|
|
||
| 1. **Read** `src/core/templates/prompts.ts` to extract the exported constants. | ||
| 2. **Construct** the prompt body for each command by joining the relevant constants with `\n\n`: | ||
| - **proposal**: `PROPOSAL_GUARDRAILS` + `PROPOSAL_STEPS` + `PROPOSAL_REFERENCES` | ||
| - **apply**: `BASE_GUARDRAILS` + `APPLY_STEPS` + `APPLY_REFERENCES` | ||
| - **archive**: `BASE_GUARDRAILS` + `ARCHIVE_STEPS` + `ARCHIVE_REFERENCES` | ||
| 3. **Generate** the TOML files with the following structure (preserving the `<!-- OPENSPEC:START -->` markers inside the prompt string): | ||
|
|
||
| **File**: `.gemini/commands/openspec/proposal.toml` | ||
| ```toml | ||
| description = "Scaffold a new OpenSpec change and validate strictly." | ||
| prompt = """ | ||
| <!-- OPENSPEC:START --> | ||
| {PROPOSAL_BODY} | ||
| <!-- OPENSPEC:END --> | ||
| """ | ||
| ``` | ||
|
|
||
| **File**: `.gemini/commands/openspec/apply.toml` | ||
| ```toml | ||
| description = "Implement an approved OpenSpec change and keep tasks in sync." | ||
| prompt = """ | ||
| <!-- OPENSPEC:START --> | ||
| {APPLY_BODY} | ||
| <!-- OPENSPEC:END --> | ||
| """ | ||
| ``` | ||
|
|
||
| **File**: `.gemini/commands/openspec/archive.toml` | ||
| ```toml | ||
| description = "Archive a deployed OpenSpec change and update specs." | ||
| prompt = """ | ||
| <!-- OPENSPEC:START --> | ||
| {ARCHIVE_BODY} | ||
| <!-- OPENSPEC:END --> | ||
| """ | ||
| ``` |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| { | ||
| "name": "openspec", | ||
| "version": "0.18.0", | ||
| "contextFileName": "GEMINI.md", | ||
| "mcpServers": { | ||
| "openspec": { | ||
| "command": "node", | ||
| "args": [ | ||
| "bin/openspec.js", | ||
| "serve" | ||
| ] | ||
| } | ||
| } | ||
| } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| # Add Gemini CLI Extension Support | ||
|
|
||
| ## Goal | ||
| Transform the OpenSpec repository into a valid Gemini CLI extension to enhance the development experience for users employing the Gemini CLI. | ||
|
|
||
| ## Motivation | ||
| Integrating with Gemini CLI allows us to provide deep, project-specific context and potentially custom tools directly to the AI agent. This "eases the integration path" by making the agent "OpenSpec-aware" out of the box when this extension is installed or linked. | ||
|
|
||
| ## Proposed Solution | ||
| 1. **Extension Manifest**: Create a `gemini-extension.json` file in the project root. This file defines the extension metadata and points to the context file. | ||
| 2. **Context File**: Create a `GEMINI.md` file in the project root. This file will contain high-level instructions, architectural overviews, and usage guides for OpenSpec, tailored for the Gemini agent. It should reference or inline key parts of `AGENTS.md` and `openspec/project.md`. | ||
| 3. **Unified Prompts**: Extract core slash command prompts into a shared `src/core/templates/prompts.ts` file. This ensures that all agent integrations (Claude, Cursor, Gemini, etc.) use the same underlying instructions. | ||
| 4. **Native Slash Commands**: Create native Gemini CLI slash command files (`.toml`) in `.gemini/commands/openspec/` that consume the unified prompts. This allows users to trigger OpenSpec workflows directly via `/openspec:proposal`, etc. | ||
|
|
||
| ## Benefits | ||
| - **Contextual Awareness**: Gemini CLI will automatically understand OpenSpec commands (`openspec init`, `openspec change`, etc.) and conventions without manual prompting. | ||
| - **Standardization**: Ensures that the AI assistant follows the project's specific coding and contribution guidelines. | ||
| - **Extensibility**: Lay the groundwork for future MCP server integrations (e.g., tools to automatically validate specs or scaffold changes). |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| ## ADDED Requirements | ||
| ### Requirement: Slash Command Safety | ||
| All generated slash command templates SHALL include safety guardrails. | ||
|
|
||
| #### Scenario: CLI Availability Check | ||
| - **WHEN** generating slash commands for any tool | ||
| - **THEN** the template SHALL include an instruction to verify the `openspec` CLI is installed and available in the environment | ||
| - **AND** guide the user to install it via `npm install -g @fission-ai/openspec` if missing |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| - [x] Create `gemini-extension.json` in the project root @file:gemini-extension.json | ||
| - [x] Create `GEMINI.md` in the project root with OpenSpec context @file:GEMINI.md | ||
| - [x] Extract slash command prompts to a shared location for unified usage across agents | ||
| - [x] Configure `GEMINI.md` to auto-generate slash commands from shared prompts | ||
| - [x] Document CLI installation prerequisites in `GEMINI.md` and shared prompts | ||
| - [x] Add maintenance instructions to `GEMINI.md` for syncing slash commands from `prompts.ts` | ||
| - [x] Update `README.md` with Gemini CLI Extension installation and benefits | ||
| - [x] Verify the extension can be linked locally using `gemini extensions link .` (Manual verification) |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,29 @@ | ||
| # Proposal: Add MCP Server Support | ||
|
|
||
| ## Context | ||
| Currently, OpenSpec integrates with AI agents via CLI commands and static configuration files (slash commands). While effective, this requires manual setup for some agents and lacks the rich interactivity offered by the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/). | ||
|
|
||
| ## Goal | ||
| Implement a native MCP server within the OpenSpec CLI using modern tools (e.g., `fastmcp` or `@modelcontextprotocol/sdk`). This will: | ||
| 1. Allow any MCP-compliant agent (Claude Desktop, Gemini CLI, etc.) to discover and use OpenSpec tools and resources without custom configuration files. | ||
| 2. Enable the Gemini CLI extension to be a thin wrapper around this native MCP server. | ||
| 3. Align the project structure with modern standards by moving `openspec/` to `.openspec/` during initialization. | ||
|
Comment on lines
+6
to
+10
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🛠️ Refactor suggestion | 🟠 Major Simplify Why section to 1–2 concise sentences. The current "Goal" section (lines 6–10) is too detailed for the "Why" section. Condense it to 1–2 sentences that directly answer "Why is this change needed?" The implementation details belong in "What Changes." Per coding guidelines, the "Why" section should provide 1–2 sentences of motivation only. 🤖 Prompt for AI Agents |
||
|
|
||
| ## Migration Path | ||
| To support existing users, the CLI will include an automatic migration flow: | ||
| - **Detection**: `openspec init` (or a dedicated `openspec migrate` command) will detect legacy `openspec/` directories. | ||
| - **Auto-rename**: Prompt the user to rename `openspec/` to `.openspec/`. | ||
| - **Instruction Refresh**: Automatically run `openspec update` after the rename to ensure all assistant instructions point to the new location. | ||
| - **Backward Compatibility**: The CLI will continue to look for `openspec/` if `.openspec/` is missing, but will issue a deprecation warning. | ||
|
|
||
| ## Solution | ||
| 1. **Add `openspec serve` command**: Starts the MCP server over stdio. | ||
| 2. **Use Modern MCP Tools**: Leverage libraries like `fastmcp` or the official SDK to simplify server implementation and type safety. | ||
| 3. **Expose Tools**: Convert existing CLI commands (`list`, `show`, `validate`, `archive`) into MCP tools. | ||
| 4. **Expose Resources**: Provide direct read access to specs and changes via `openspec://` URIs. | ||
| 5. **Expose Prompts**: Serve the standard proposal/apply/archive prompts via `prompts/list`. | ||
| 6. **Migrate Directory**: Update `init` to scaffold in `.openspec/` instead of `openspec/`. | ||
| 7. **Gemini Extension**: Create the `gemini-extension.json` manifest to register this MCP server capability. | ||
| 8. **CI Validation**: Add a CI check to ensure `gemini-extension.json` version stays in sync with `package.json`. | ||
|
|
||
|
Comment on lines
+1
to
+28
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🛠️ Refactor suggestion | 🟠 Major Restructure proposal to follow required format: Why, What Changes, Impact. Per coding guidelines, proposals must include three explicit sections:
The current structure uses "Context," "Goal," "Migration Path," and "Solution," which mix these concerns. Restructuring will improve clarity and align with project conventions. Breaking changes (e.g., moving 📋 Proposed restructuring-# Proposal: Add MCP Server Support
-
-## Context
-Currently, OpenSpec integrates with AI agents via CLI commands and static configuration files (slash commands). While effective, this requires manual setup for some agents and lacks the rich interactivity offered by the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/).
-
-## Goal
-Implement a native MCP server within the OpenSpec CLI using modern tools (e.g., `fastmcp` or `@modelcontextprotocol/sdk`). This will:
-1. Allow any MCP-compliant agent (Claude Desktop, Gemini CLI, etc.) to discover and use OpenSpec tools and resources without custom configuration files.
-2. Enable the Gemini CLI extension to be a thin wrapper around this native MCP server.
-3. Align the project structure with modern standards by moving `openspec/` to `.openspec/` during initialization.
+# Proposal: Add MCP Server Support
+
+## Why
+OpenSpec currently integrates with AI agents via static CLI commands and configuration files, which lacks the rich interactivity offered by the Model Context Protocol (MCP), an open protocol that enables seamless integration between LLM applications and external data sources and tools. Implementing a native MCP server will simplify integration for multiple agents (Claude Desktop, Gemini CLI, etc.) and modernize the project structure.
+
+## What Changes
-## Migration Path
-To support existing users, the CLI will include an automatic migration flow:
-- **Detection**: `openspec init` (or a dedicated `openspec migrate` command) will detect legacy `openspec/` directories.
-- **Auto-rename**: Prompt the user to rename `openspec/` to `.openspec/`.
-- **Instruction Refresh**: Automatically run `openspec update` after the rename to ensure all assistant instructions point to the new location.
-- **Backward Compatibility**: The CLI will continue to look for `openspec/` if `.openspec/` is missing, but will issue a deprecation warning.
+- ⚠️ **BREAKING**: Move project initialization from `openspec/` to `.openspec/` (hidden directory).
+- **Detection & Migration**: `openspec init` will detect legacy `openspec/` directories and prompt to migrate; automatic rename and instruction refresh included.
+- **Backward Compatibility**: CLI will fall back to `openspec/` if `.openspec/` missing, with deprecation warning.
+- **Add `openspec serve` command**: Starts the MCP server over stdio using modern tooling (fastmcp or @modelcontextprotocol/sdk).
+- **Expose MCP Tools**: Convert CLI commands (`list`, `show`, `validate`, `archive`) to MCP tools.
+- **Expose MCP Resources**: Provide read access to specs and changes via `openspec://` URIs.
+- **Expose MCP Prompts**: Serve proposal/apply/archive prompts via `prompts/list`.
+- **Gemini Extension Integration**: Create `gemini-extension.json` manifest to register MCP server.
+- **CI Validation**: Add check to sync `gemini-extension.json` version with `package.json`.
+
+## Impact
+- **Affected Specs**: `cli-init` (directory structure), `cli-spec` (serve command), `mcp-server` (tools/resources/prompts), `ci-sync` (version validation).
+- **Affected Code**: `src/core/config.ts`, `src/core/init.ts`, `src/mcp/*` (new modules), `src/commands/serve.ts` (new command), `.github/workflows/ci.yml`, `gemini-extension.json`.
-## Solution
-1. **Add `openspec serve` command**: Starts the MCP server over stdio.
-2. **Use Modern MCP Tools**: Leverage libraries like `fastmcp` or the official SDK to simplify server implementation and type safety.
-3. **Expose Tools**: Convert existing CLI commands (`list`, `show`, `validate`, `archive`) into MCP tools.
-4. **Expose Resources**: Provide direct read access to specs and changes via `openspec://` URIs.
-5. **Expose Prompts**: Serve the standard proposal/apply/archive prompts via `prompts/list`.
-6. **Migrate Directory**: Update `init` to scaffold in `.openspec/` instead of `openspec/`.
-7. **Gemini Extension**: Create the `gemini-extension.json` manifest to register this MCP server capability.
-8. **CI Validation**: Add a CI check to ensure `gemini-extension.json` version stays in sync with `package.json`.
-
-This "modernizes" the integration, making it cleaner, more robust, and easier to maintain.🧰 Tools🪛 LanguageTool[style] ~24-~24: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym. (ENGLISH_WORD_REPEAT_BEGINNING_RULE) 🤖 Prompt for AI Agents |
||
| This "modernizes" the integration, making it cleaner, more robust, and easier to maintain. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| # Delta for ci-sync | ||
|
|
||
| ## ADDED Requirements | ||
| ### Requirement: Extension Version Synchronization | ||
| The system SHALL ensure that the version in `gemini-extension.json` matches the version in `package.json` during the CI process. | ||
|
|
||
| #### Scenario: Version mismatch in CI | ||
| - **GIVEN** `package.json` has version `0.18.0` | ||
| - **AND** `gemini-extension.json` has version `0.17.0` | ||
| - **WHEN** the CI pipeline runs | ||
| - **THEN** the version check step SHALL fail | ||
| - **AND** report the mismatch to the logs | ||
|
|
||
| #### Scenario: Version match in CI | ||
| - **GIVEN** both files have version `0.18.0` | ||
| - **WHEN** the CI pipeline runs | ||
| - **THEN** the version check step SHALL pass |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,29 @@ | ||
| # Delta for cli-init | ||
|
|
||
| ## MODIFIED Requirements | ||
| ### Requirement: Directory Creation | ||
| The command SHALL create the complete OpenSpec directory structure in a hidden directory `.openspec/` to reduce clutter. | ||
|
|
||
| #### Scenario: Creating OpenSpec structure | ||
| - **WHEN** `openspec init` is executed | ||
| - **THEN** create the following directory structure: | ||
| ``` | ||
| .openspec/ | ||
| ├── project.md | ||
| ├── AGENTS.md | ||
| ├── specs/ | ||
| └── changes/ | ||
| └── archive/ | ||
| ``` | ||
|
|
||
| ## ADDED Requirements | ||
| ### Requirement: Legacy Migration | ||
| The `init` command SHALL detect legacy `openspec/` directories and offer to migrate them to `.openspec/`. | ||
|
|
||
| #### Scenario: Migrating legacy directory | ||
| - **GIVEN** a project with an existing `openspec/` directory | ||
| - **AND** no `.openspec/` directory exists | ||
| - **WHEN** executing `openspec init` | ||
| - **THEN** prompt the user: "Detected legacy 'openspec/' directory. Would you like to migrate it to '.openspec/'?" | ||
| - **AND** if confirmed, rename the directory | ||
| - **AND** update all managed AI instructions to point to the new location |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,10 @@ | ||
| # Delta for cli-spec | ||
|
|
||
| ## ADDED Requirements | ||
| ### Requirement: Serve Command | ||
| The system SHALL provide a `serve` command to start the Model Context Protocol (MCP) server. | ||
|
|
||
| #### Scenario: Start MCP Server | ||
| - **WHEN** executing `openspec serve` | ||
| - **THEN** start the MCP server using stdio transport | ||
| - **AND** keep the process alive to handle requests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
Repository: Fission-AI/OpenSpec
Length of output: 5647
🏁 Script executed:
Repository: Fission-AI/OpenSpec
Length of output: 2332
🏁 Script executed:
Repository: Fission-AI/OpenSpec
Length of output: 7731
Address conflicting documentation and critical version compatibility gaps.
The extension section contains several issues that need resolution:
"Zero Configuration" contradicts explicit requirements (lines 167 vs 171): The benefits claim "Zero Configuration," but line 171 explicitly requires the OpenSpec CLI installed globally. Either remove "Zero Configuration" or clarify that it applies only to slash command setup, not CLI installation.
"Auto-Maintenance" lacks explanation (line 169): This term is unexplained. The related documentation in
GEMINI.mddescribes automatic CLI version checking, slash command generation, and command definition synchronization from source files—but the README provides no clarity or reference to this context. Add a brief explanation or link to the detailed auto-initialization logic.Missing version compatibility guidance: The CI infrastructure (scripts and specs) enforces strict version synchronization between
gemini-extension.jsonandpackage.json. However, the README provides zero guidance on this critical operational concern:Additionally, the current repository state shows a version mismatch (
package.json: 0.19.0vsgemini-extension.json: 0.18.0), which contradicts the documented CI requirement that these must always match. This needs to be resolved and documented.Installation command format not verified: Confirm that
gemini extensions install https://github.com/Fission-AI/OpenSpecis the correct format for Gemini CLI extension installation.🤖 Prompt for AI Agents