# Spectra: a desktop app and CLI for spec-driven development with coding agents > Spectra wraps spec-driven development in a desktop app, an npm CLI, and a set of agent skills. It suits teams already running Claude Code, Codex, or Cursor against Markdown specs, and not those who want a hosted service or an Android client. **kaochenlong/spectra-app** — Spec-driven development for coding agents — a desktop app, a CLI, and skills for Codex, Claude Code, Cursor, Copilot, Antigravity and Junie - Repository: https://github.com/kaochenlong/spectra-app - Stars: 747 · Forks: 33 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-13 · Updated: 2026-09-13 · Language: en - Canonical page: https://hysenlabs.com/projects/kaochenlong-spectra-app ## The problem Spectra solves for agent-driven spec workflows Spec-driven development asks you to write down what a change should do before an agent writes the code. In practice that means a directory of Markdown specs, a proposal for each change, a task checklist, and a design note, all kept in sync with the repository. The bookkeeping is the part that breaks down. Directories drift, checklists go stale, and nobody notices a contradiction between a proposal and a spec until the code is already merged. Spectra targets that bookkeeping. It is a desktop app for browsing and editing specs and change proposals, a CLI published to npm as @kaochenlong/spxa, and a set of skills that a coding agent invokes to propose changes, write specs, and carry out tasks. The README states the goal plainly: no more manually managing spec directories, YAML configs, and Markdown files. The audience is a developer who already runs an agent against a repository and wants the spec layer to be visible rather than implicit. The project was inspired by OpenSpec and began as a GUI frontend for it; the README says the author rewrote the workflow because OpenSpec's flow did not match his habits. That history matters, because it means Spectra is an opinionated fork of a workflow, not a neutral viewer. ## How the app, CLI and agent skills fit together The architecture has three parts that share the same files on disk. The coding agent runs the skills: /spectra-discuss to clarify requirements, /spectra-propose to create a change proposal covering proposal, specs, design and tasks, /spectra-apply to implement tasks, and /spectra-archive to merge a finished change back into the main specs. Quality-gate skills sit between those stages: /spectra-verify checks code against the change's specs, tasks and design before archiving, /spectra-review reports on an implementation without editing files, /spectra-analyze hunts for contradictions across proposal, design, specs and tasks, /spectra-audit performs a security audit of changed code, /spectra-drift detects divergence between a change and the codebase, and /spectra-debug reproduces a problem before looking for a root cause. The desktop app reads the same Markdown. It parses task progress from checklist syntax, so a line written as an unchecked or checked box becomes a progress indicator, and it archives completed changes with one click. Compact Mode, bound to the keyboard shortcut the README gives, puts a floating panel over your editor for monitoring progress while you code, with a separate shortcut for memos. The CLI covers the pieces that do not need a window, including a park mechanism: spectra park and spectra unpark set an in-progress change aside without polluting the Git working tree. Parallel execution is the most interesting mechanism. /spectra-propose records dependencies between tasks using an [after: ...] annotation, and /spectra-apply hands tasks whose prerequisites are complete to the agent's subagents to run in parallel. When subagents are not available it falls back to running them one by one. The README says this is enabled by default with no setup, and that [P] markers in older task lists are still recognized. The design is honest about its dependency: parallelism is only as good as the dependency annotations the proposing agent wrote. ## Installing Spectra and running a first change On macOS the desktop app installs through Homebrew as a cask. The README gives this command: ```bash brew install --cask spectra-app ``` If you only want the spec workflow and the agent skills, the CLI is a separate npm package and does not require the desktop app. The README states it requires Node.js 22.14 or newer: ```bash npm install -g @kaochenlong/spxa spxa init ``` One detail that trips people up: the command is spxa, not spectra. The desktop app installs a binary named spectra, and the README describes the two as independent channels that update separately. Native binaries for macOS, Linux and Windows arrive as exact-version optional dependencies, so nothing is downloaded during installation or at run time. After init, the workflow starts inside your coding agent rather than the terminal. In Claude Code, Cursor, Copilot, Antigravity or Junie you invoke the skills with a slash: ```text /spectra-propose ``` Codex uses a dollar sign instead, for example $spectra-apply. The README notes that /spectra-verify and /spectra-analyze can be invoked directly in Claude Code, Codex and GitHub Copilot. What you should see after /spectra-propose is a new change directory containing a proposal, specs, a design note and a task checklist; the app then displays that change and parses its checklist into progress. ## Where Spectra gets in the way The desktop build targets macOS on Apple Silicon and Intel as .dmg files, and Windows x64 as .exe. There is no Linux desktop package in the platform table, even though the CLI ships native binaries for Linux. If your team is on Linux workstations, you get the CLI and the skills but not the app, which removes the visual tracking that is the project's main pitch. The skills are also not portable across agents in the same form. Codex requires $ instead of /, and the README only claims direct invocation of /spectra-verify and /spectra-analyze for Claude Code, Codex and GitHub Copilot. For Cursor, Antigravity and Junie the documentation lists the skills without stating which can be called directly, so treat that as unverified. The heavier constraint is philosophical. Spectra assumes you accept its change model: a proposal, specs, a design, a task list, and an archive step that merges spec changes back. If your team writes specs differently, or does not want an archive step at all, the app has nothing to show you. The README's own account of why the author forked away from OpenSpec is a warning that this workflow encodes one person's habits. The park mechanism, for instance, exists because the author wanted to set work aside without touching the working tree, which is a preference, not a universal need. ## Spectra compared with OpenSpec The README names OpenSpec as the inspiration and says Spectra started as a GUI frontend for it before the workflow was rewritten. That is the honest comparison point, and the difference is one of scope rather than of spec format. OpenSpec is the upstream workflow. Spectra keeps the idea of specs and change proposals but adds a desktop application for browsing and archiving them, a compact monitoring panel, and a larger set of agent skills organized into plan, implement, quality-gate and finish stages. It also adds mechanisms OpenSpec does not appear to have: the park and unpark CLI commands, dependency annotations with [after: ...] and parallel task execution through subagents, and one-click archiving. The trade-off runs the other way too. Spectra is a single-maintainer project that diverged from its upstream, so improvements to the original workflow do not automatically arrive here, and the README's account of the fork makes clear the author is optimizing for his own development rhythm. If you want the workflow with the widest set of users and documentation behind it, the upstream project is the safer bet. If you want a visual layer and the extra skills, Spectra is the one that has them. ## Maintenance, licensing and upgrade cost The repository is not archived, and the last push was on 2026-09-13. Release v3.0.0 was published on 2026-09-11, following v2.3.1 in May 2026 and v2.3.0 earlier that month. The gap between the May releases and the September major version suggests a substantial rewrite or feature addition landed in v3.0.0, so anyone on v2.x should read CHANGELOG.md before upgrading rather than assuming a drop-in change. Upgrade cost has a specific wrinkle here: the desktop app and the CLI are independent channels that update separately, per the README. Installing a new desktop release does not move the npm CLI, and vice versa. Teams that pin one and not the other can end up with a version skew between the app that reads the spec directories and the CLI that initializes them. The licence is the open question. The repository metadata reports NOASSERTION, which means GitHub could not match the LICENSE file to a known licence template. The README points to npm/spxa for licensing details on the CLI side. Before adopting this in a commercial setting, read the LICENSE file directly; its terms are not stated anywhere in the repository documentation, and I am not going to guess at them. ## Conclusion Adopt Spectra if your team already writes specs as Markdown and drives Claude Code, Codex, Cursor, Copilot, Antigravity or Junie against them, and you want a visual layer over the same files. Skip it if you need a hosted service, a mobile client, or an official support contract; the repository is a single-maintainer project and the README does not document a support channel beyond GitHub Issues. Verify two things before committing: that the npm package installs on your platform by checking the platform matrix in npm/spxa, and that your agent of choice supports the slash-command invocation Spectra's skills expect, since Codex requires $ instead of /. ## FAQ ### What is the Spectra app? Spectra is a Spec-Driven Development tool made of a desktop app, a CLI and skills for coding agents. The app lets you browse specs, track progress and archive completed work, while your coding agent uses the skills to propose changes, write specs and carry out tasks. ### Does Spectra have an app? Yes. Spectra ships a desktop app for macOS as .dmg files for Apple Silicon and Intel, and for Windows x64 as an .exe. The CLI is a separate npm package, @kaochenlong/spxa, and can be used without the desktop app. ### What is spectra used for? It manages spec documents for spec-driven development: viewing and editing specs and change proposals, parsing task progress from Markdown checklists, and archiving completed changes. Coding agents use its skills to propose changes, implement tasks and run quality checks. ## Sources - [Issues](https://github.com/kaochenlong/spectra-app/issues) - [kaochenlong/spectra-app on GitHub](https://github.com/kaochenlong/spectra-app) - [README](https://github.com/kaochenlong/spectra-app/blob/main/README.md) - [Releases](https://github.com/kaochenlong/spectra-app/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kaochenlong-spectra-app