feat: add Opencode slash commands

AGENTS.md

@@ -1,40 +1,19 @@
-<!-- OPENSPEC:START -->
-# OpenSpec Project
+# Repository Guidelines
 
-This document provides instructions for AI coding assistants on how to use OpenSpec conventions for spec-driven development. Follow these rules precisely when working on OpenSpec-enabled projects.
+## Project Structure & Module Organization
+OpenSpec ships as a TypeScript-first CLI. Source code lives in `src`, with feature logic in `core`, interactive flows in `cli`, reusable helpers in `utils`, and command wiring in `commands`. After `pnpm run build`, deliverables land in `dist` and feed the published entry point `bin/openspec.js`. Specs and change proposals reside in `openspec/specs` and `openspec/changes`; update them whenever behavior shifts so automation stays aligned. Shared assets live in `assets`, and Vitest suites in `test` mirror the source layout for easy cross-reference.
 
-This project uses OpenSpec for spec-driven development. Specifications are the source of truth.
+## Build, Test, and Development Commands
+Run `pnpm install` to sync dependencies. `pnpm run build` compiles TypeScript to `dist` and must stay green before release. Use `pnpm run dev` for a `tsc --watch` loop and `pnpm run dev:cli` to rebuild then execute the local CLI. `pnpm test` runs the Vitest suite once, `pnpm run test:watch` keeps it hot while iterating, and `pnpm run test:coverage` verifies instrumentation thresholds. Use `pnpm run changeset` when preparing a release entry.
 
-See @openspec/AGENTS.md for detailed conventions and guidelines.
-<!-- OPENSPEC:END -->
+## Coding Style & Naming Conventions
+We follow idiomatic TypeScript with ES modules, 2-space indentation, and semicolons. Prefer named exports from index barrels and keep filenames kebab-cased (e.g., `list-command.ts`). Classes use `PascalCase`, functions and variables use `camelCase`, and constants representing flags may use `SCREAMING_SNAKE_CASE`. Keep modules small, colocate helpers under `src/utils`, and avoid new dependencies without spec-backed justification.
 
-## Complexity Management
+## Testing Guidelines
+Every behavior change needs Vitest coverage under `test`, co-located by feature (e.g., `test/core/update.test.ts`). Name suites after the module under test and lean on `vitest.setup.ts` for shared configuration. Run `pnpm test` before pushing and add regression cases for each bug fix or spec requirement.
 
-**Default to minimal solutions:**
-- Propose <100 lines of new code for features
-- Prefer single-file implementations until proven insufficient
-- Avoid frameworks, abstractions, and optimizations without clear justification
-- Choose boring, well-understood patterns over novel approaches
+## Commit & Pull Request Guidelines
+Commits follow Conventional Commits (`type(scope): subject`) and stay single-line. Reference the touched module in the scope when practical. Each PR should summarize the spec or issue it fulfills, list manual verification steps, and note updates to any `openspec/` assets. Include CLI output snippets or screenshots when the UX changes, and ensure CI and coverage checks pass before requesting review.
 
-**Question requests for complexity:**
-- Caching? → Ask for performance data and targets
-- New framework? → Suggest plain code first
-- Extra layers? → Start with the thinnest viable design
-
-**Justify complexity with data:**
-- Performance metrics showing current solution is too slow
-- Concrete scale requirements (e.g., >1000 users, >100MB data)
-- Multiple proven use cases requiring an abstraction
-
-## Package Manager
-Always use pnpm (NOT npm or yarn) for all Node.js package management:
-- Install dependencies: `pnpm install`
-- Add packages: `pnpm add [package]`
-- Run scripts: `pnpm run [script]`
-
-## Git Commits
-Use conventional commits with these rules:
-- Format: `type(scope): subject` (e.g., `fix: resolve auth error`, `feat(api): add user endpoint`)
-- Keep commit messages to ONE line only - no body or footer
-- Common types: feat, fix, docs, style, refactor, test, chore
-- Never add co-authorship lines or attribution
+## OpenSpec Workflow Tips
+Treat specs as the contract: update `openspec/project.md` or the relevant `openspec/specs/*.md` before coding, then run `pnpm run dev:cli` to validate the CLI against the revised artifacts. `openspec list --specs` confirms the catalog, and `openspec change` drafts proposals—commit these alongside code so reviewers can trace rationale to implementation.

README.md

@@ -83,13 +83,14 @@ These tools have built-in OpenSpec commands. Select the OpenSpec integration whe
 |------|----------|
 | **Claude Code** | `/openspec:proposal`, `/openspec:apply`, `/openspec:archive` |
 | **Cursor** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` |
+| **OpenCode** | `/openspec-proposal`, `/openspec-apply`, `/openspec-archive` |
 
 #### AGENTS.md Compatible
 These tools automatically read workflow instructions from `openspec/AGENTS.md`. Ask them to follow the OpenSpec workflow if they need a reminder. Learn more about the [AGENTS.md convention](https://agents.md/).
 
 | Tools |
 |-------|
-| Codex • Amp • Jules • OpenCode • Gemini CLI • GitHub Copilot • Others |
+| Codex • Amp • Jules • Gemini CLI • GitHub Copilot • Others |
 
 ### Install & Initialize
 

openspec/changes/add-slash-command-support/specs/cli-init/spec.md

@@ -13,3 +13,9 @@ The init command SHALL generate slash command files for supported editors using
 - **THEN** create `.cursor/commands/openspec-proposal.md`, `.cursor/commands/openspec-apply.md`, and `.cursor/commands/openspec-archive.md`
 - **AND** populate each file from shared templates so command text matches other tools
 - **AND** each template includes instructions for the relevant OpenSpec workflow stage
+
+#### Scenario: Generating slash commands for OpenCode
+- **WHEN** the user selects OpenCode during initialization
+- **THEN** create `.opencode/commands/openspec-proposal.md`, `.opencode/commands/openspec-apply.md`, and `.opencode/commands/openspec-archive.md`
+- **AND** populate each file from shared templates so command text matches other tools
+- **AND** each template includes instructions for the relevant OpenSpec workflow stage

openspec/changes/add-slash-command-support/specs/cli-update/spec.md

@@ -12,6 +12,11 @@ The update command SHALL refresh existing slash command files for configured too
 - **THEN** refresh each file using shared templates
 - **AND** ensure templates include instructions for the relevant workflow stage
 
+#### Scenario: Updating slash commands for OpenCode
+- **WHEN** `.opencode/commands/` contains `openspec-proposal.md`, `openspec-apply.md`, and `openspec-archive.md`
+- **THEN** refresh each file using shared templates
+- **AND** ensure templates include instructions for the relevant workflow stage
+
 #### Scenario: Missing slash command file
 - **WHEN** a tool lacks a slash command file
 - **THEN** do not create a new file during update

openspec/changes/add-slash-command-support/tasks.md

@@ -14,3 +14,7 @@
 
 ## 4. Verification
 - [x] 4.1 Add tests verifying slash command files are created and updated correctly.
+
+## 5. OpenCode Integration
+- [x] 5.1 Generate `.opencode/commands/{openspec-proposal,openspec-apply,openspec-archive}.md` during `openspec init` using shared templates.
+- [x] 5.2 Update existing `.opencode/commands/*` files during `openspec update`.

src/core/config.ts

@@ -19,5 +19,6 @@ export interface AIToolOption {
 export const AI_TOOLS: AIToolOption[] = [
   { name: 'Claude Code (✅ OpenSpec custom slash commands available)', value: 'claude', available: true, successLabel: 'Claude Code' },
   { name: 'Cursor (✅ OpenSpec custom slash commands available)', value: 'cursor', available: true, successLabel: 'Cursor' },
+  { name: 'OpenCode (✅ OpenSpec custom slash commands available)', value: 'opencode', available: true, successLabel: 'OpenCode' },
   { name: 'AGENTS.md (works with Codex, Amp, Copilot, …)', value: 'agents', available: true, successLabel: 'your AGENTS.md-compatible assistant' }
 ];

src/core/configurators/slash/opencode.ts

@@ -0,0 +1,41 @@
+import { SlashCommandConfigurator } from "./base.js";
+import { SlashCommandId } from "../../templates/index.js";
+
+const FILE_PATHS: Record<SlashCommandId, string> = {
+  proposal: ".opencode/command/openspec-proposal.md",
+  apply: ".opencode/command/openspec-apply.md",
+  archive: ".opencode/command/openspec-archive.md",
+};
+
+const FRONTMATTER: Record<SlashCommandId, string> = {
+  proposal: `---
+agent: build
+description: Scaffold a new OpenSpec change and validate strictly.
+---
+The user has requested the following change proposal. Use the openspec instructions to create their change proposal.
+<UserRequest>
+  $ARGUMENTS
+</UserRequest>
+`,
+  apply: `---
+agent: build
+description: Implement an approved OpenSpec change and keep tasks in sync.
+---`,
+  archive: `---
+agent: build
+description: Archive a deployed OpenSpec change and update specs.
+---`,
+};
+
+export class OpenCodeSlashCommandConfigurator extends SlashCommandConfigurator {
+  readonly toolId = "opencode";
+  readonly isAvailable = true;
+
+  protected getRelativePath(id: SlashCommandId): string {
+    return FILE_PATHS[id];
+  }
+
+  protected getFrontmatter(id: SlashCommandId): string | undefined {
+    return FRONTMATTER[id];
+  }
+}

src/core/configurators/slash/registry.ts

@@ -1,16 +1,19 @@
 import { SlashCommandConfigurator } from './base.js';
 import { ClaudeSlashCommandConfigurator } from './claude.js';
 import { CursorSlashCommandConfigurator } from './cursor.js';
+import { OpenCodeSlashCommandConfigurator } from './opencode.js';
 
 export class SlashCommandRegistry {
   private static configurators: Map<string, SlashCommandConfigurator> = new Map();
 
   static {
     const claude = new ClaudeSlashCommandConfigurator();
     const cursor = new CursorSlashCommandConfigurator();
+    const opencode = new OpenCodeSlashCommandConfigurator();
 
     this.configurators.set(claude.toolId, claude);
     this.configurators.set(cursor.toolId, cursor);
+    this.configurators.set(opencode.toolId, opencode);
   }
 
   static register(configurator: SlashCommandConfigurator): void {