Skip to content
Closed
Show file tree
Hide file tree
Changes from 12 commits
Commits
Show all changes
25 commits
Select commit Hold shift + click to select a range
9d9c5d1
feat(gemini): add native extension support and unified prompts
StoyanD Dec 18, 2025
4ed7faa
update the gemini doc to onboard user smoothly
StoyanD Dec 21, 2025
7f8abeb
chore(openspec): archive gemini extension support change
StoyanD Dec 21, 2025
001f285
Merge branch 'main' into gemini-extension
StoyanD Dec 22, 2025
3318ed4
Merge branch 'main' into gemini-extension
StoyanD Jan 6, 2026
2c3ca61
Merge branch 'main' into gemini-extension
StoyanD Jan 9, 2026
85ac417
feat(openspec): add proposal for MCP server and .openspec migration
StoyanD Jan 9, 2026
6785450
feat: implement mcp server and directory migration
StoyanD Jan 9, 2026
80f74e8
docs: update tasks status
StoyanD Jan 9, 2026
4e6b92e
test: update init tests to expect .openspec directory
StoyanD Jan 12, 2026
31adee9
feat: complete mcp tools implementation and archive change
StoyanD Jan 12, 2026
230a0d5
separate logic into core spec
StoyanD Jan 12, 2026
4a5c901
fix(archive): handle errors gracefully and add spec update prompt
StoyanD Jan 12, 2026
12fae4c
feat(release): sync gemini-extension.json version with package.json
StoyanD Jan 12, 2026
84ebe16
docs: add MCP JSON configuration snippet to README
StoyanD Jan 12, 2026
77a5b0b
feat(mcp): refactor core logic and expand MCP server tools
StoyanD Jan 12, 2026
4eb0ba5
feat(mcp): complete MCP toolset parity
StoyanD Jan 12, 2026
3bdf7cc
docs(openspec): archive refactor-core-isolation and update add-mcp-te…
StoyanD Jan 12, 2026
d068620
feat(core): refactor change logic and add MCP tests
StoyanD Jan 12, 2026
ad63aad
fix(lint): resolve restricted imports and ts-expect-error descriptions
StoyanD Jan 12, 2026
d4563c8
fix(mcp): resolve type errors in tools.ts
StoyanD Jan 12, 2026
b447e4d
refactor(mcp): decouple SpecCommand from mcp tools
StoyanD Jan 12, 2026
f1e2e96
archiving proposal
StoyanD Jan 12, 2026
a0958c5
chore: resolve merge conflicts and preserve CLI/MCP/Core separation r…
StoyanD Jan 12, 2026
1dd5ecc
test: fix regressions in update.test.ts after merge resolution
StoyanD Jan 12, 2026
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -145,6 +145,9 @@ jobs:
- name: Lint
run: pnpm lint

- name: Check extension version sync
run: node scripts/check-extension-version.mjs

- name: Check for build artifacts
run: |
if [ ! -d "dist" ]; then
Expand Down
134 changes: 134 additions & 0 deletions GEMINI.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,134 @@
# 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).

## MCP Capabilities

### Tools
- `openspec_list_changes`: List active change proposals.
- `openspec_list_specs`: List current specifications.
- `openspec_show_change`: Show details of a change (JSON/Markdown).
- `openspec_validate_change`: Validate a change proposal against schema rules.

### 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.

## Prerequisites

This extension requires the OpenSpec CLI.

**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 -->
"""
```
18 changes: 17 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -103,7 +103,7 @@ These tools have built-in OpenSpec commands. Select the OpenSpec integration whe
| **Crush** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` (`.crush/commands/openspec/`) |
| **Cursor** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` |
| **Factory Droid** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` (`.factory/commands/`) |
| **Gemini CLI** | `/openspec:proposal`, `/openspec:apply`, `/openspec:archive` (`.gemini/commands/openspec/`) |
| **Gemini CLI** | `/openspec:proposal`, `/openspec:apply`, `/openspec:archive` (Native Extension available) |
| **GitHub Copilot** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` (`.github/prompts/`) |
| **iFlow (iflow-cli)** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` (`.iflow/commands/`) |
| **Kilo Code** | `/openspec-proposal.md`, `/openspec-apply.md`, `/openspec-archive.md` (`.kilocode/workflows/`) |
Expand All @@ -128,6 +128,22 @@ These tools automatically read workflow instructions from `openspec/AGENTS.md`.

</details>

### Gemini CLI Extension (Native)

OpenSpec is available as a native extension for the [Gemini CLI](https://geminicli.com). This provides deep contextual awareness and native slash commands without manual configuration.

**Install the extension:**
```bash
gemini extensions install https://github.com/Fission-AI/OpenSpec
```

**Benefits:**
- **Zero Configuration**: Automatically sets up `/openspec` slash commands.
- **Native Context**: Gemini becomes "OpenSpec-aware" instantly.
- **Auto-Maintenance**: The agent can self-repair its command definitions from the source of truth.

*Note: You still need the [OpenSpec CLI](#step-1-install-the-cli-globally) installed globally for the agent to perform operations.*

Comment on lines +157 to +172
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# First, let's read the actual README.md to confirm the snippet
echo "=== README.md lines 157-172 ==="
sed -n '157,172p' README.md

echo -e "\n=== Searching for Gemini CLI extension format documentation ==="
rg -n "gemini extensions install" -i

echo -e "\n=== Searching for version synchronization mentions ==="
rg -n "version.*sync|sync.*version|extension.*version" -i

echo -e "\n=== Searching for extension manifest or configuration ==="
fd -e json -e yml -e yaml "gemini.*extension|extension.*gemini" 

echo -e "\n=== Searching for geminicli.com references ==="
rg -n "geminicli.com" 

echo -e "\n=== Listing root level config files ==="
ls -la | grep -E "\.(json|yml|yaml|toml|config)"

echo -e "\n=== Searching for auto-maintenance or self-repair references ==="
rg -n "self-repair|auto-maintain|auto-update" -i

Repository: Fission-AI/OpenSpec

Length of output: 5647


🏁 Script executed:

#!/bin/bash

echo "=== gemini-extension.json content ==="
cat gemini-extension.json

echo -e "\n=== sync-extension-version.mjs script ==="
cat scripts/sync-extension-version.mjs

echo -e "\n=== check-extension-version.mjs script ==="
cat scripts/check-extension-version.mjs

echo -e "\n=== CI Sync specification ==="
cat openspec/specs/ci-sync/spec.md

echo -e "\n=== Searching for any gemini CLI documentation or setup ==="
fd "gemini" -t f | head -20

echo -e "\n=== Package.json dependencies related to gemini ==="
jq '.dependencies, .devDependencies' package.json | grep -i gemini

Repository: Fission-AI/OpenSpec

Length of output: 2332


🏁 Script executed:

#!/bin/bash

echo "=== GEMINI.md content ==="
cat GEMINI.md

echo -e "\n=== package.json version field ==="
jq '.version' package.json

echo -e "\n=== Searching for any references to extension installation or gemini CLI format ==="
rg -n "install.*extension|extensions.*install" -i

echo -e "\n=== Searching for documentation about version requirements ==="
rg -n "require.*version|version.*require|compatibility" -i README.md

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:

  1. "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.

  2. "Auto-Maintenance" lacks explanation (line 169): This term is unexplained. The related documentation in GEMINI.md describes 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.

  3. Missing version compatibility guidance: The CI infrastructure (scripts and specs) enforces strict version synchronization between gemini-extension.json and package.json. However, the README provides zero guidance on this critical operational concern:

    • What happens when extension and CLI versions drift?
    • How do users verify compatibility?
    • Are there minimum version requirements?

    Additionally, the current repository state shows a version mismatch (package.json: 0.19.0 vs gemini-extension.json: 0.18.0), which contradicts the documented CI requirement that these must always match. This needs to be resolved and documented.

  4. Installation command format not verified: Confirm that gemini extensions install https://github.com/Fission-AI/OpenSpec is the correct format for Gemini CLI extension installation.

🤖 Prompt for AI Agents
In @README.md around lines 157 - 172, Clarify the Gemini CLI Extension docs:
update the "Zero Configuration" bullet to specify it only applies to automatic
slash-command setup (not to requiring the OpenSpec CLI), expand
"Auto-Maintenance" to briefly describe/point to GEMINI.md for details about
automatic CLI version checks, slash command generation, and command sync, and
add a short compatibility section explaining that gemini-extension.json and
package.json must match (what happens if they drift, how to verify versions,
minimum supported version), fix the current repo mismatch by aligning
package.json and gemini-extension.json versions, and verify/confirm the install
command format (gemini extensions install <repo-url>) is correct before keeping
it.

### Install & Initialize

#### Prerequisites
Expand Down
14 changes: 14 additions & 0 deletions gemini-extension.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
{
"name": "openspec",
"version": "0.18.0",
"contextFileName": "GEMINI.md",
"mcpServers": {
"default": {
"command": "node",
"args": [
"bin/openspec.js",
"serve"
]
}
}
}
31 changes: 31 additions & 0 deletions openspec/changes/agent-only-mcp-workflow/proposal.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Proposal: Transition to Pure MCP-Driven Workflow

## Why
Currently, using OpenSpec with AI agents often requires the OpenSpec CLI to be installed in the environment where the agent is running. This creates adoption friction and dependency management overhead. By leveraging the Model Context Protocol (MCP), we can package all OpenSpec logic into a self-contained server that the Gemini CLI (or any MCP client) can run as a plugin. This allows agents to manage the entire OpenSpec lifecycle—from initialization to archiving—using native tools, without requiring the user to install the npm package globally or locally in their production environment.

## What Changes
1. **Architecture Principles (Core-First)**:
* **Logic Isolation**: All business logic (file I/O, parsing, validation logic) SHALL reside in `src/core/`.
* **Presentation De-coupling**: Code in `src/core/` SHALL NOT use CLI-specific libraries (`ora`, `chalk`) or direct `console.log`. It SHALL return structured data or throw errors.
* **Thin Wrappers**: `src/cli/` and `src/mcp/` SHALL be thin adapters that call `src/core/` and handle their respective output formats (terminal UI for CLI, JSON-RPC for MCP).
2. **Shared Core Implementation**:
* Refactor CLI command handlers to delegate to these isolated core functions.
3. **Full MCP Parity**:
* Implement MCP equivalents for ALL remaining CLI commands.
4. **CI and Build Stability**:
* Update CI to verify that both the CLI binary and the MCP server start correctly and share the same core logic.

## Impact
- **Architecture Cleanliness**: Enforces separation between presentation (CLI/MCP) and logic (Core).
- **Full Parity**: Ensures agents have the exact same "superpowers" as users on the command line.
- **Continuous Reliability**: CI ensures that refactoring for MCP parity never breaks the legacy CLI experience.

## Impact
- **Architecture Cleanliness**: Enforces separation between presentation (CLI/MCP) and logic (Core).
- **Flexibility**: Users can choose between CLI, MCP, or both.
- **Adoption**: Significantly lowers the barrier for entry by allowing agents to "self-initialize" via MCP.

## Impact
- **Zero-Install Adoption**: Users only need to add the Gemini extension; no separate CLI installation is required for AI-driven workflows.
- **Consistent Agent Experience**: Agents interact with a structured API (MCP) rather than parsing CLI output or managing shell command strings.
- **Future-Proofing**: Aligns OpenSpec with the emerging "plugin" architecture of modern AI coding assistants.
34 changes: 34 additions & 0 deletions openspec/changes/agent-only-mcp-workflow/specs/mcp-server/spec.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
# Delta for mcp-server

## ADDED Requirements
### Requirement: Shared Core Implementation
The MCP server and the CLI SHALL share the same underlying business logic implementation for all operations.

#### Scenario: Consistency between CLI and MCP
- **WHEN** an operation (e.g., init, list, archive) is performed via CLI
- **AND** the same operation is performed via MCP
- **THEN** both SHALL yield consistent results by calling the same core functions.

### Requirement: Project Initialization Tool
The MCP server SHALL provide a tool `openspec_init` to initialize the OpenSpec structure.

#### Scenario: Initializing project via MCP
- **WHEN** the `openspec_init` tool is called
- **THEN** execute the shared `runInit` logic
- **AND** return a structured summary of created items.

### Requirement: Change Creation Tool
The MCP server SHALL provide a tool `openspec_create_change` to scaffold a new change directory.

#### Scenario: Creating a new change via MCP
- **WHEN** the `openspec_create_change` tool is called with `name`
- **THEN** execute the shared `runCreateChange` logic
- **AND** return the paths of created files.

### Requirement: MCP-First Instructions
The MCP server SHALL provide prompts that prioritize MCP tools while maintaining CLI references as a secondary option for human readability.

#### Scenario: Guidance in MCP prompts
- **WHEN** an agent retrieves a prompt via MCP
- **THEN** the instructions SHALL explicitly list MCP tool calls as the primary action (e.g., "Use openspec_list_changes to view state")
- **AND** the instructions MAY provide the CLI equivalent for reference.
29 changes: 29 additions & 0 deletions openspec/changes/agent-only-mcp-workflow/tasks.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# Tasks: Implementation of Pure MCP-Driven Workflow

## 1. Core Logic Isolation
- [ ] 1.1 Audit `src/core/` for `ora`, `chalk`, and `console.log` usage.
- [ ] 1.2 Refactor `src/core/init.ts` to be a pure function returning initialization results.
- [ ] 1.3 Refactor `src/core/update.ts` to return update statistics instead of logging.
- [ ] 1.4 Refactor `src/core/archive.ts` to return archival reports.
- [ ] 1.5 Extract dashboard data logic from `src/core/view.ts` into a pure data provider.
- [ ] 1.6 Refactor experimental tools to follow the data-in/data-out pattern.

## 2. Interface Implementation (CLI & MCP)
- [ ] 2.1 Update CLI handlers in `src/commands/` to handle UI (spinners, colors) based on core data.
- [ ] 2.2 Implement MCP tools in `src/mcp/tools.ts` using the same core data.
- [ ] 2.3 Ensure full feature parity for all 12+ OpenSpec commands.

## 3. Build & CI Validation
- [ ] 3.1 Verify `bin/openspec.js` works as a standalone CLI after refactoring.
- [ ] 3.2 Update `.github/workflows/ci.yml` to include a check that `openspec serve` is functional (e.g., exit code 0 on help).
- [ ] 3.3 Ensure `pnpm run build` covers all new entry points.

## 4. Documentation
- [ ] 4.1 Update `src/mcp/prompts.ts` to use MCP tool names.
- [ ] 4.2 Update `GEMINI.md` and `README.md`.

## 3. Verification
- [ ] 3.1 Verify `openspec_init` works via an MCP client (e.g., Gemini CLI) in a fresh directory.
- [ ] 3.2 Verify `openspec_update` refreshes files correctly.
- [ ] 3.3 Verify `openspec_create_change` scaffolds a new change directory.
- [ ] 3.4 Ensure the CLI remains functional for users who prefer it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Duplicate section number: "3. Verification" should be "5. Verification".

There are two sections numbered "3": "3. Build & CI Validation" (line 16) and "3. Verification" (line 25). This should be section 5 to maintain sequential numbering. The task IDs (3.1, 3.2, etc.) should also be updated to 5.1, 5.2, etc.

Proposed fix
-## 3. Verification
-- [ ] 3.1 Verify `openspec_init` works via an MCP client (e.g., Gemini CLI) in a fresh directory.
-- [ ] 3.2 Verify `openspec_update` refreshes files correctly.
-- [ ] 3.3 Verify `openspec_create_change` scaffolds a new change directory.
-- [ ] 3.4 Ensure the CLI remains functional for users who prefer it.
+## 5. Verification
+- [ ] 5.1 Verify `openspec_init` works via an MCP client (e.g., Gemini CLI) in a fresh directory.
+- [ ] 5.2 Verify `openspec_update` refreshes files correctly.
+- [ ] 5.3 Verify `openspec_create_change` scaffolds a new change directory.
+- [ ] 5.4 Ensure the CLI remains functional for users who prefer it.

Based on learnings, tasks.md should contain implementation checklist with numbered sections and checkbox items.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
## 3. Verification
- [ ] 3.1 Verify `openspec_init` works via an MCP client (e.g., Gemini CLI) in a fresh directory.
- [ ] 3.2 Verify `openspec_update` refreshes files correctly.
- [ ] 3.3 Verify `openspec_create_change` scaffolds a new change directory.
- [ ] 3.4 Ensure the CLI remains functional for users who prefer it.
## 5. Verification
- [ ] 5.1 Verify `openspec_init` works via an MCP client (e.g., Gemini CLI) in a fresh directory.
- [ ] 5.2 Verify `openspec_update` refreshes files correctly.
- [ ] 5.3 Verify `openspec_create_change` scaffolds a new change directory.
- [ ] 5.4 Ensure the CLI remains functional for users who prefer it.
🤖 Prompt for AI Agents
In @openspec/changes/agent-only-mcp-workflow/tasks.md around lines 25 - 29,
Rename the duplicate "3. Verification" header to "5. Verification" and update
its checklist item IDs from 3.1–3.4 to 5.1–5.4 so numbering is sequential with
the earlier "3. Build & CI Validation"; specifically modify the header text "3.
Verification" and the four task prefixes (e.g., change "3.1 Verify
`openspec_init`..." to "5.1 Verify `openspec_init`...", and likewise for
3.2→5.2, 3.3→5.3, 3.4→5.4) to preserve a consistent numbered checklist structure
in tasks.md.

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)
29 changes: 29 additions & 0 deletions openspec/changes/archive/2026-01-12-add-mcp-server/proposal.md
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
Copy link
Contributor

Choose a reason for hiding this comment

The 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
In @openspec/changes/add-mcp-server/proposal.md around lines 6 - 10, The "Why"
section under the "Goal" heading is too detailed; replace the current multi-line
implementation-focused text with 1–2 concise sentences that state the motivation
for adding a native MCP server (e.g., enabling automatic discovery of OpenSpec
tools by MCP-compliant agents and simplifying integrations), and move all
implementation details (references to fastmcp, @modelcontextprotocol/sdk, Gemini
CLI, and the .openspec/ restructure) into the "What Changes" section so the
"Why" contains only the high-level rationale.


## 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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:

  1. Why (1–2 sentences): Concise motivation
  2. What Changes (bullet list with breaking change markers): Changes with explicit ⚠️ BREAKING or similar markers
  3. Impact (affected specs and code): Which areas are affected

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 openspec/ to .openspec/) should be explicitly marked.

📋 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.
Context: ...d changes via openspec:// URIs. 5. Expose Prompts: Serve the standard proposal/...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)

🤖 Prompt for AI Agents
In @openspec/changes/add-mcp-server/proposal.md around lines 1 - 28, Restructure
the proposal into three explicit sections: "Why" (1–2 sentences summarizing the
motivation), "What Changes" (a bulleted list of each change using explicit
markers like "⚠️ BREAKING" for breaking changes such as the openspec/ ->
.openspec/ rename), and "Impact" (list affected specs and code). Under "What
Changes" include entries for: adding the openspec serve command (MCP over
stdio), using fastmcp/@modelcontextprotocol/sdk, exposing CLI commands as MCP
tools (list, show, validate, archive), exposing openspec:// URIs and
prompts/list, changing init to scaffold .openspec/ (⚠️ BREAKING: openspec/ ->
.openspec/), creating gemini-extension.json, and adding CI validation for
gemini-extension.json vs package.json. Under "Impact" explicitly call out
affected code and artifacts: the init/migrate flow, openspec serve
implementation, prompts, gemini-extension.json manifest, migration notices, and
CI config so reviewers can find the changes.

This "modernizes" the integration, making it cleaner, more robust, and easier to maintain.
Loading