The proposal makes vague requests reviewable before coding
Before an agent implements dark mode, OpenSpec asks it to write down what the switch should do. The README's example specifies a system-preference default and a user choice that survives later visits. Those are decisions you can challenge before implementation. A change folder holds a proposal, requirement files, a technical design, and a task checklist. You review the Markdown, then ask the assistant to work through it.
OpenSpec uses this process in its own repository, which our checkout measured at roughly 137,810 source lines. That gives you real specifications to inspect beyond the introductory example. For an existing application, the attraction is keeping agreed behavior beside the code in Git. The cost is maintaining another set of files. I'd use it for a feature whose edge cases need discussion, and skip the proposal for a spelling correction.
What happened when we ran it
Our run installed OpenSpec's 242 pnpm packages in 13 seconds, using 94 MB on disk, and the build succeeded in 11 seconds. We cloned commit 9111a76 on October 12, 2026, into a fresh Debian sandbox with 3 CPUs and 8 GB of RAM, using image lab-node:22. The container was unprivileged and had no secrets. Both steps completed without a reported failure.
Vitest passed all 6,404 tests with 0 failures in 207 seconds. The checkout contained 1,287 files and occupied 10.1 MB before installation. Our scan found workspace packages, a tests directory, and 3 CI workflow files, with no Dockerfile. This is evidence that the repository installs, builds, and passes its automated checks in that environment. The run didn't measure whether an assistant follows a specification correctly or whether the workflow reduces rework.
The CLI sets up instructions that run inside your coding assistant
The documented consumer route requires Node.js 20.19.0 or newer: install @fission-ai/openspec globally, then run openspec init inside your project. The initializer generates instructions for the coding tools you select. OpenSpec's command-location guide explains a practical trap: openspec commands belong in the terminal, while /opsx:propose belongs in your assistant's chat. Claude Code receives command files and skills. Other integrations use their own invocation syntax.
Our 94 MB installed environment covers the repository setup we measured, so budget separately for your chosen assistant and its model access. OpenSpec's documented initialization doesn't ask for a service credential of its own. Package upgrades also need a second action: run openspec update inside each project to regenerate its agent guidance. Otherwise, the CLI can change while the instructions your assistant reads remain old. The README also recommends clearing the assistant's context before implementation.
Strict validation can accept a scenario without an expected outcome
Issue 2078, opened October 13, reports that a requirement containing only an AND step passes strict validation and archives successfully. The example lacks both a triggering condition and an expected result. This is a user report, separate from our sandbox findings. A pull request proposing warnings for missing WHEN/GIVEN or THEN steps remained open when checked. Teams seeking an automatic specification-quality check should treat that gap as a reason to wait.
Passing 6,404 tests doesn't establish that generated requirements say anything useful. Read each scenario as a developer who must implement it: what happens, under which conditions, and what result proves completion? Release v1.14.1 adds a warning for requirement text over 500 characters, which strict mode treats as failure. That's a check on the document's form. It cannot decide whether the dark-mode requirement handles an existing saved preference correctly. A person still has to ask that question.
Shared stores still require machine-level registration
Stores move the planning tree into a separate Git repository, allowing application repositories to reference shared requirements. The stores guide labels the feature beta and warns that commands, flags, and file formats may change. It also says OpenSpec doesn't clone, synchronize, or push stores automatically. Each teammate clones the planning repository and registers its local path. That can suit a platform team already comfortable reviewing requirements through Git.
Our no-secrets sandbox and 207-second test run don't establish that your cross-repository setup works. Issue 1950 describes the machine-level registry's duplicate-checkout limit and manual registration requirement. Its proposed project-scoped discovery implementation remained an open pull request on October 13. If developers use parallel clones or worktrees, reproduce that arrangement before adopting stores. For a stable planning system across repositories, this is a substantial reservation even though the single-repository setup passed.
October maintenance is active, and telemetry needs an explicit choice
The repository's last push was October 12, 2026. GitHub listed 71,798 stars and 197 open issues and PRs when checked October 13, with store and validation discussions updated that day. Release v1.14.1 shipped October 6 with fixes for custom-schema verification and archive error reporting. Those dates support calling the project actively maintained. MIT licensing permits ordinary commercial adoption, while anonymous command-name and version telemetry is enabled by default. The README documents OPENSPEC_TELEMETRY=0 and DO_NOT_TRACK=1 as opt-outs.
OpenSpec combines active maintenance with 3 CI workflow files and a clean sandbox result, but choose it for the review habit. Spec Kit suits teams wanting its constitution and explicit specification-to-convergence sequence. Superpowers puts more emphasis on agent skills for implementation discipline and code review. For OpenSpec, try one feature that previously caused disagreement. Ask a teammate to implement from its scenarios without reading the original chat. If they still need the chat to understand expected behavior, revise the specification before asking the agent to code.