Spectra: a desktop app and CLI that keep coding agents inside a spec workflow

The problem Spectra targets: agent output with no paper trail

A coding agent can produce a working change and leave behind almost nothing you can inspect later. The diff exists, but the reasoning, the requirements it was supposed to satisfy, and the tasks it decided not to do are gone once the session ends. Spectra's answer is to move that material into a spec directory the agent maintains through skills, and to put a desktop app on top so a human can browse it. The README describes the app as letting you "browse specs, track progress, and archive completed work" so you are not "manually managing spec directories, YAML configs, and Markdown files." The audience is therefore developers who already run an agent in a terminal or editor and want the surrounding paperwork generated rather than typed. It is not a tool for people who have not adopted an agent yet, because every change proposal in the workflow originates from a skill invocation.

How the pieces fit: skills write, the app reads, the CLI parks and initialises

Spectra ships as three channels. The desktop app is a viewer and editor for specs and change proposals. The CLI, published to npm as @kaochenlong/spxa and invoked as spxa, sets up the workflow with spxa init and handles the park mechanism. The skills are prompts installed into whichever coding agent you use, and they are what actually create and modify files. The naming is deliberate and easy to get wrong: the README states plainly that "the command is spxa, not spectra," because the desktop app installs a separate spectra command and the two channels "update separately." Inside a change, task progress is not stored in a database. It is parsed from Markdown checklists, so a line reading - [ ] or - [x] is the state. Archiving a completed change merges its spec changes into the main specs, which is the point at which a proposal stops being a proposal.

The skill list is the real product surface

Spectra's skills are grouped by stage, and the grouping is the most informative part of the README. Planning has /spectra-discuss, which the table says clarifies requirements and compares approaches "before proposing; no code changes," and /spectra-propose, which creates the full change proposal with proposal, specs, design and tasks. Implementation has /spectra-apply and /spectra-ingest, the latter for folding shifted requirements from a plan or conversation back into an existing change. The quality gate is where the set gets unusually dense: /spectra-verify checks code against the change's specs, tasks and design before archiving; /spectra-review does code review and, per the README, "reports only, never edits files"; /spectra-analyze looks for contradictions and gaps across the four document types; /spectra-audit runs a security audit on changed code; /spectra-drift detects divergence between a change and the current codebase; /spectra-debug insists on reproducing first and finding a root cause from evidence. Finish is /spectra-archive and /spectra-commit, the latter committing "only the files that belong to a change." The split between /spectra-review (read-only) and /spectra-apply (writes) is a sensible boundary, and worth preserving if you adapt the prompts. Note the invocation syntax differs: Codex uses a dollar sign, so $spectra-apply rather than /spectra-apply. The README adds that /spectra-verify and /spectra-analyze can be invoked directly in Claude Code, Codex and GitHub Copilot.

Getting it running: two independent install paths

On macOS the desktop app comes from Homebrew as a cask: brew install --cask spectra-app. The CLI is separate and does not require the app at all. The README gives npm install -g @kaochenlong/spxa followed by spxa init, and states that Node.js 22.14 or newer is required. If you want the workflow and the agent skills without a GUI, that is the path. One detail matters for anyone working in a restricted network: native binaries for macOS, Linux and Windows "are installed as exact-version optional dependencies; nothing is downloaded during installation or at run time." That removes a class of postinstall surprises, but it also means the platform matrix is baked into the package rather than resolved at install time, so a platform outside the matrix fails at install rather than degrading. For the park mechanism the commands are spectra park <name> and spectra unpark <name>, which the README describes as temporarily parking in-progress changes "without polluting the Git working tree." Direct downloads are also offered for macOS on Apple Silicon and Intel as .dmg, and Windows x64 as .exe.

Parallel tasks, compact mode, and what the README leaves unsaid

Two features deserve scrutiny. The first is parallel task execution. /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, falling back to sequential execution when subagents are unavailable. The README says this is "enabled by default with no setup" and that older [P] markers are still recognised. The dependency graph is therefore expressed in the task list itself, which means a mis-annotated task is a concurrency bug rather than a slow build. The second is Compact Mode, bound to Command-D, a floating panel for monitoring progress while coding, with Command-T opening memos. On limitations, the README is quiet in places that matter. It does not document rollback for an archive operation, so if merging a change's specs into the main specs produces something you dislike, the documented recovery path is your version control, not the app. It does not describe what happens when two changes touch the same spec. The park mechanism's storage location is not stated, only its effect on the working tree. None of these are disqualifying, but they are the questions to answer before you rely on archiving as a routine step.

Where Spectra is the wrong tool, and what to compare it against

Spectra is a poor fit when the change is smaller than the paperwork. A one-line fix still travels through propose, apply and verify if you follow the workflow as written, and the README's own framing, a tool shaped around one developer's "daily development rhythm," is a hint that the cadence is opinionated rather than universal. It is also a poor fit if your team cannot install agent skills, since the desktop app alone gives you a viewer for documents that nothing is generating. The obvious alternative is OpenSpec, which the README names as the inspiration and describes Spectra's history against: Spectra "started as a GUI frontend for OpenSpec," and the author rewrote the workflow because OpenSpec's "didn't quite match my own development habits." The concrete difference is the shape of the deliverable. OpenSpec is the upstream workflow; Spectra is a reimplementation of it with simplified commands, a desktop app for browsing and archiving, a park mechanism for shelving in-progress changes, and a wider skill set that includes security audit and drift detection. Choosing between them is largely a question of whether you want a GUI and the extra quality-gate skills, or prefer to stay on the original workflow. There is no migration tooling mentioned in the README, so the move is manual either way.

Maintenance, licensing, and the cost of keeping up

The repository is not archived, and the last push was on 2026-09-13, the same day as the most recent release tag, v3.0.0, dated 2026-09-11. Earlier releases, v2.3.1 and v2.3.0, landed in May 2026, so the release cadence over the visible window is roughly quarterly with a larger jump at the 3.0 boundary. That version number is the upgrade cost in miniature: a major bump across a tool whose skills are installed into your agent means re-checking that your prompts and task annotations still match. The [P] marker compatibility note suggests the project does try to keep older task lists working, which lowers but does not eliminate that cost. On licensing, the repository declares NOASSERTION rather than an SPDX identifier, so the terms are not machine-readable from the metadata alone, and the README defers to npm/spxa for "the supported platform matrix, what has actually been verified on each platform, and licensing." Read that directory before shipping Spectra inside a commercial product. The two install channels also age independently, so a Homebrew cask update and an npm update are separate operations with separate version numbers, and the CLI's Node.js 22.14 floor is a constraint on any build image you bake it into.

Editorial conclusion

Adopt Spectra if your coding agent already writes more code than you can review from memory and you want proposals, tasks and verification to be files you can open. Skip it if you work solo on short-lived branches where a proposal document costs more than the change itself. Before committing, verify two things yourself: the licence terms, which the repository does not state under an SPDX identifier, and the platform matrix in npm/spxa, which the README points to rather than reproducing.

Official sources

1. Issues
2. kaochenlong/spectra-app on GitHub
3. README
4. Releases