FAQ
Official OSpec FAQ
These answers cover the official package, the recommended 3-step workflow, and how optional plugins fit into OSpec.
Getting Started
Start here if you need the official package name, command, installation check, or the next page to open.
What is OSpec?
OSpec is a document-driven workflow for AI-assisted development. It helps teams initialize a repository, work through explicit changes, and keep delivery structured without turning the workflow into a long command checklist.
How do I install OSpec?
Install the official CLI package @clawplays/ospec-cli with npm, then run the ospec command. The install page and npm package are the official references for installation.
What is the official package and command?
The official package is @clawplays/ospec-cli and the official command is ospec. Those are the names that should appear in installation docs, snippets, and automation.
What should I run after installation?
Run ospec --help or ospec --version to verify the installation. That confirms the command is available before you initialize or update a project.
Where should I read after the install command is working?
Read Docs for the 4-step workflow, use FAQ for common questions, and open Prompt Guide when you want example phrasing.
Is the website the only place I should read?
No. The website is a quick guide. Use the repository docs and npm package page when you need the full reference details.
Workflow
Keep OSpec simple: initialize once, move one requirement through one change, then archive it after acceptance.
What is the recommended OSpec workflow?
Most teams only need three steps: initialize the project, create and advance one explicit change, then archive the accepted change after deployment and validation are complete.
What does ospec init do?
ospec init prepares the repository for real work. It sets up the collaboration shell, baseline project docs, and the structure needed so the first real requirement can move forward cleanly.
Does ospec init create the first change automatically?
No. Initialize the project first, then create one explicit change for the real task.
When should I create a new change?
Create a new change when you have one clear requirement, bug fix, documentation update, or refactor to deliver. Each change should stay focused so the work remains easy to inspect and continue.
Should one change include multiple unrelated features?
No. Keep one explicit requirement or one tightly related delivery unit per change. That keeps proposal, tasks, state, verification, and review easier to inspect and less likely to drift.
Why doesn't a finished feature archive automatically?
If Stitch is enabled and the change includes UI work, OSpec stops before archive so a person can review the result first. After that review, archive it manually. If Stitch is not enabled, archive behavior follows the project setup, and some projects can close out and archive automatically.
Plugins
These answers cover the optional plugin layer for UI review and automated checks.
How do Stitch and Checkpoint fit into OSpec?
Stitch supports page design review and preview collaboration. Checkpoint supports automated checks around important product flows. They extend OSpec, but they are not required for the basic 3-step workflow.
Do I need plugins to use OSpec?
No. The core workflow works without plugins. Stitch and Checkpoint are optional capabilities that extend the document-driven workflow for design review and automated verification.
When is a plugin worth adding?
Add a plugin when it solves a real repeatable need, such as UI preview review or browser-based verification. Do not add plugins just to make the workflow look more feature-rich.