Use cases for OpenSpec
OpenSpec is a lightweight convention layer: the same commands scale from weekend projects to multi-team repos. Here is how different situations typically use it.
Solo developer / side project
You are both author and reviewer. SDD still helps “future you” when you return after a break: the proposal and tasks rehydrate intent without rereading old chat logs. Start with one change per feature; skip heavy ceremony for trivial fixes.
Small product team (2–8 engineers)
Specs become the handoff surface between people and between models. A short proposal review in Slack or GitHub—linked to the change folder—replaces long oral explanations. Pair OpenSpec with your normal PR process: spec first, then code, then archive.
Brownfield and legacy codebases
OpenSpec does not require greenfield purity. Initialize in an existing repo, document current behavior in specs where unknown, and iterate. The design.md file is ideal for “here is how we will extend this module without breaking X.”
Enterprise and compliance-minded teams
Written proposals and scenarios support audit trails and security review. They do not replace formal threat modeling or legal sign-off, but they give reviewers a single place to read intent before implementation lands.
export OPENSPEC_TELEMETRY=0 (see site footer).
Agencies and client work
Exportable Markdown artifacts map cleanly to statements of work: clients see what was agreed before billable implementation hours stack up.