OpenSpec-Zed — Summary

OpenSpec-Zed is a Rust-based Zed editor extension that registers 11 OpenSpec slash commands (/openspec propose, /openspec explore, /openspec new, etc.) in the Zed Assistant panel, providing Zed users with a native UI bridge to the OpenSpec spec-driven development workflow.

Problem it solves: The canonical OpenSpec CLI has no native IDE integration for Zed; users must switch to a terminal to run openspec commands. This extension adds slash commands to Zed's AI assistant panel so the full OpenSpec workflow can be initiated from within the editor context.

Distinctive trait: Pure Rust WASM extension — zero JavaScript, no npm dependency at runtime. The extension generates contextual AI prompts for each OpenSpec workflow step and passes them to Zed's AI assistant, but explicitly does not execute OpenSpec CLI commands itself (the user must still run those manually in a terminal).

Target audience: Rust developers and Zed editor users who prefer the OpenSpec SDD workflow but want native IDE ergonomics without leaving the editor.

Production-readiness: v0.0.1, 14 stars, last commit March 2026, GPL-3.0 license (unlike most frameworks in this batch which are MIT). One contributor. The README includes the line "I am not your maid, clean your code..." suggesting an early/personal project.

Relationship to seeds: Most similar to kiro (Archetype 5 — IDE-specific integration), but much simpler: where Kiro is a full IDE fork with proprietary hook events, OpenSpec-Zed is a thin prompt-injection adapter that requires both the Zed editor and the OpenSpec CLI pre-installed. Unlike the canonical openspec seed (which ships commands + skills across multiple AI tools), OpenSpec-Zed is single-tool (Zed only) and provides no independent prompts beyond what OpenSpec CLI already generates.

OpenSpec-Zed — Overview

Origin

Created by GitHub user uwzis (credited as "Evan Moore - Open Prem" in extension.toml). GPL-3.0 licensed — an unusual choice for an OpenSpec ecosystem tool (most are MIT). The README opens with:

"Greetings my fellow Rustaceans and sympathizers, I have a treat for you :}"

This positions it as a community contribution for the Rust/Zed developer demographic, not an officially supported OpenSpec adapter.

Philosophy

The extension's philosophy is to be a pure prompt bridge:

"Note: The extension provides AI prompts to help you with OpenSpec workflows. For actual OpenSpec CLI execution, you'll need to run the commands manually in your terminal."

This is an explicit "UI bridge, not automation" stance — the extension handles the AI conversation side (generating contextual prompts) but deliberately does not automate the CLI side.

Scope

Supports all canonical OpenSpec slash commands:

• /openspec propose — Create a new change and generate planning artifacts
• /openspec explore — Explore ideas and investigate problems
• /openspec new — Start a new change scaffold
• /openspec continue — Create the next artifact in the dependency chain
• /openspec ff — Fast-forward: create all planning artifacts at once
• /openspec verify — Validate implementation matches artifacts
• /openspec sync — Merge delta specs into main specs
• /openspec apply — Implement tasks from the active change
• /openspec archive — Archive a completed change
• /openspec bulk-archive — Archive multiple completed changes at once
• /openspec onboard — Guided tutorial through OpenSpec workflow

Key design constraint

The Zed extension API used (zed_extension_api) compiles to WASM32-WASI, limiting what the extension can execute. It cannot shell out to the OpenSpec CLI, which is why it only generates prompts. This is a technical constraint, not a philosophical choice.

OpenSpec-Zed — Architecture

Distribution

• Type: IDE extension (Zed editor)
• Language: Rust (compiled to WASM32-WASI)
• Extension ID: openspec-zed
• Schema version: 1

Install

# Clone to Zed extensions directory
git clone https://github.com/Uwzis/OpenSpec-Zed ~/.config/zed/extensions/openspec
# Restart Zed

Or install from Zed's extension marketplace by searching "OpenSpec".

Prerequisites

• Zed editor (with Assistant panel)
• Node.js 20.19.0 or higher (for OpenSpec CLI)
• npm install -g @fission-ai/openspec@latest (OpenSpec CLI, run in terminal)

Build

cargo build --target wasm32-wasi

Repository structure

OpenSpec-Zed/
├── Cargo.toml          ← Rust project manifest
├── LICENSE             ← GPL-3.0
├── README.md
├── extension.toml      ← Zed extension manifest (slash commands declared here)
└── src/
    └── lib.rs          ← ~200 lines of Rust; all slash command handlers

How it works

The extension implements zed::Extension trait in Rust:

impl zed::Extension for OpenSpecExtension {
    fn run_slash_command(
        &self,
        command: zed::SlashCommand,
        args: Vec<String>,
        _worktree: Option<&zed::Worktree>,
    ) -> Result<zed::SlashCommandOutput, String>

For each slash command, it generates a natural-language prompt string describing the OpenSpec workflow step. The prompt is returned as SlashCommandOutput text, which Zed injects into the Assistant conversation context.

Target AI tools

• Zed only (zed_extension_api)
• Cross-tool portability: single-tool (Zed-specific)

OpenSpec-Zed — Components

Slash Commands (11)

Registered in extension.toml:

Skills

Count: 0 — No SKILL.md files; the slash command handler is Rust code.

Subagents

Count: 0

Hooks

Count: 0 — Zed extensions use run_slash_command callbacks, not Claude Code lifecycle hooks.

MCP Servers

Count: 0

Scripts

Count: 0 — No bash or Python scripts.

Templates

Count: 0 — No template files; prompts are generated as Rust string literals.

Core Rust code (src/lib.rs — ~200 lines)

The entire logic is a match statement over command names. Each arm generates a prompt string:

"propose" => (
    if args_str.is_empty() {
        "I want to propose a new change. Please help me brainstorm and create
         planning artifacts for this change.".to_string()
    } else {
        format!("I want to propose a new change called '{}'. Please help me
                 create comprehensive planning artifacts...", args_str)
    },
    "OpenSpec: Propose Change",
),

Argument validation is done via a command_requires_arg() helper — commands that need a change name return an error if called without arguments.

OpenSpec-Zed — Uniqueness and Positioning

differs_from_seeds

Most analogous to kiro (Archetype 5 — IDE-specific primitives), but far simpler: Kiro is a full VS Code fork with proprietary hook events, its own spec format (EARS notation), and deep IDE-native task tracking; OpenSpec-Zed is a thin prompt-injection adapter that wraps the canonical OpenSpec CLI's command surface in Zed slash commands. Unlike spec-kit (which ships 9 real slash commands that drive actual file operations through Claude Code), OpenSpec-Zed's commands generate AI prompts only — no file I/O is performed by the extension itself. Compared to the canonical openspec seed (multi-tool, ships commands+skills), OpenSpec-Zed is single-tool (Zed-only) and relies entirely on the OpenSpec CLI for actual execution.

Positioning

• Niche: "OpenSpec for Zed users who want slash commands in the Assistant panel"
• Primary differentiator: Only framework in this batch built in Rust and targeting Zed
• Core limitation: Prompt bridge only — no execution; requires terminal for actual OpenSpec CLI commands

Observable failure modes

1. AI knowledge gap: The prompts rely on the Zed AI assistant having sufficient training knowledge of OpenSpec. If the AI doesn't know OpenSpec conventions, the prompts give it no guidance (unlike openspec-skills which embeds full templates).
2. Split workflow: Users must context-switch between Zed Assistant (for AI prompts) and terminal (for CLI execution) — the two-step process is friction-prone.
3. No validation: No mechanism to verify that what the AI generated in the conversation was actually saved to disk via the CLI.
4. Stale CLI: If the user has an older version of OpenSpec CLI than the extension expects, the commands in the prompts may not match actual CLI command names.
5. GPL-3.0 copyleft: The only GPL-3.0 framework in this batch; downstream forks must also be GPL-3.0, which may deter corporate adoption.

Explicit antipatterns

None documented.