Spec-driven development that adapts to your stack, your team, and your workflow.
SpecOps brings structured spec-driven development to your AI coding assistant — with domain-specific templates for infrastructure, data pipelines, and SDKs, and a built-in team review workflow for shared codebases. Works with Claude Code, Cursor, OpenAI Codex, and GitHub Copilot.
Infrastructure specs include Rollback Steps and Resource Definitions. Data pipeline specs include Data Contracts and Backfill Strategy. Library specs flag Breaking Changes per task. Backend and fullstack use clean defaults — no unnecessary ceremony.
Draft a spec, get section-by-section feedback from teammates, revise, and only implement once minApprovals is met. Git identity detection, configurable approval thresholds, and an implementation gate that blocks unapproved specs from proceeding.
curl | bash. No Python, no uv, no package manager setup. SpecOps installs as a skill file your AI coding assistant reads — there is no runtime to maintain.
Convention strings and custom templates are sanitized against prompt injection. Secrets use placeholders, PII uses synthetic data, all config fields enforce strict schema validation, and path traversal is rejected at the boundary.
Small features get lean specs. The agent actively avoids premature abstractions, one-use configurations, and speculative future-proofing. Over-engineering patterns are flagged as red flags during spec creation.
# One-line install (detects your AI coding tools automatically)
bash <(curl -fsSL https://raw.githubusercontent.com/sanmak/specops/main/scripts/remote-install.sh)Non-interactive install:
curl -fsSL https://raw.githubusercontent.com/sanmak/specops/main/scripts/remote-install.sh | bash -s -- --platform claude --scope user
curl -fsSL https://raw.githubusercontent.com/sanmak/specops/main/scripts/remote-install.sh | bash -s -- --platform cursor
curl -fsSL https://raw.githubusercontent.com/sanmak/specops/main/scripts/remote-install.sh | bash -s -- --platform codex
curl -fsSL https://raw.githubusercontent.com/sanmak/specops/main/scripts/remote-install.sh | bash -s -- --platform copilotClone and run locally:
git clone https://github.com/sanmak/specops.git && cd specops && bash setup.shPlatform-specific guides:
Claude Code:
/specops Add user authentication with OAuth
/specops view auth-feature
/specops list
Cursor / Codex / Copilot:
Use specops to add user authentication with OAuth
View the auth-feature spec
List all specops specs
One command triggers a 4-phase workflow: understand your codebase, generate a structured spec, implement it, and verify the result.
For teams, SpecOps adds a structured review cycle between spec creation and implementation. Engineers review specs collaboratively, provide section-by-section feedback, and approve before coding begins. See TEAM_GUIDE.md for the full team workflow.
| Platform | Status | Trigger |
|---|---|---|
| Claude Code | Supported | /specops [description], /specops view, /specops list |
| Cursor | Supported | Use specops to [description], View the ... spec, List all specops specs |
| OpenAI Codex | Supported | Use specops to [description], View the ... spec, List all specops specs |
| GitHub Copilot | Supported | Use specops to [description], View the ... spec, List all specops specs |
| Windsurf | Planned | — |
| Continue.dev | Planned | — |
SpecOps and Spec Kit share the same core philosophy: specs before code. We think Spec Kit is excellent — and we're building on the same principles with a different focus.
Choose Spec Kit if you want the broadest agent support (18+) and are exploring SDD as an individual or small team.
Choose SpecOps if you're a team shipping to production and need specs that match your project type, structured review before implementation, and security-hardened spec processing.
| Capability | SpecOps | GitHub Spec Kit |
|---|---|---|
| Supported platforms | Claude Code, Cursor, OpenAI Codex, GitHub Copilot | 18+ agents |
| Installation | Single curl | bash, no dependencies |
Python 3.11+ and uv |
| Team review workflow | Built-in (draft → review → revise → approve → gate) | Not available |
| Configurable approval thresholds | Yes — minApprovals in config |
Not available |
| Vertical-aware templates | 7 project types (infra, data, library, builder, etc.) | Generic templates |
| Infrastructure specs | Rollback steps, topology, resource definitions | Generic |
| Data pipeline specs | Data contracts, backfill strategy, pipeline SLAs | Generic |
| Library/SDK specs | Breaking change flags, public API surface | Generic |
| Simplicity guardrails | Built-in anti-over-engineering checks | Not available |
| Security hardening | Prompt injection defense, schema validation, path containment | Not documented |
| Monorepo support | Per-module config overrides | Not documented |
| Platform breadth | 4 platforms | 18+ platforms |
| Research workflow | Planned | Yes |
| EARS-style requirements | Planned | Yes |
Create .specops.json in your project root. Configuration is optional — SpecOps uses sensible defaults.
{
"specsDir": ".specops",
"team": {
"conventions": ["Use TypeScript", "Write tests for business logic"],
"reviewRequired": true,
"specReview": { "enabled": true, "minApprovals": 2 }
},
"implementation": {
"autoCommit": false,
"createPR": true,
"testing": "auto"
}
}See examples/ for minimal, standard, and full configurations. Full schema reference in REFERENCE.md.
SpecOps is the only spec-driven development tool with domain-specific templates. It adapts spec structure, vocabulary, and required sections based on your project type. Set explicitly in .specops.json or let SpecOps auto-detect from your codebase.
| Vertical | Adaptation |
|---|---|
| Backend | Default templates (API endpoints, services, data models) |
| Frontend | State management, components, UI patterns |
| Full Stack | Handles both frontend and backend layers |
| Infrastructure | Resource definitions, topology, IaC |
| Data Engineering | Pipeline stages, data flow, contracts |
| Library/SDK | Public API surface, developer use cases |
| Builder | Product modules, ship plans, cross-domain tasks |
Backend / Full Stack — Use for API services, microservices, or full-stack web apps. Default templates apply unchanged; specs use standard "User Stories", "Component Design", and "API Changes" vocabulary. See example: user-authentication.
Frontend — Use when the project is purely client-side (React, Vue, etc.) consuming existing APIs. Adapts design.md: "Data Model Changes" becomes "State Management"; "API Changes" is skipped when only consuming. See example: dark-mode-toggle.
Infrastructure — Use for Terraform, Kubernetes, CloudFormation, or other IaC projects. Heavy adaptation: "User Stories" become "Infrastructure Requirements" (As an operator/SRE...), "Components" become "Resources", tasks gain "Validation Steps" and "Rollback Steps". See example: k8s-autoscaling.
Data Engineering — Use for ETL pipelines, data warehouses, or streaming systems. Heavy adaptation: "User Stories" become "Data Requirements", "Components" become "Pipeline Stages", adds "Data Quality Requirements" and "Volume & Velocity" sections. See example: user-activity-pipeline.
Library/SDK — Use for reusable packages, SDKs, or shared libraries. Medium adaptation: "User Stories" become "Developer Use Cases" (As a developer...), "Components" become "Modules", adds "API Design Principles", "Compatibility Requirements", and "Breaking Change" flags per task. See example: date-utils-library.
Builder — Use when you are a solo builder or small team shipping a product end-to-end across multiple domains (frontend, backend, infra, data). Heaviest adaptation: "User Stories" become "Product Requirements" (framed around product outcomes), "Components" become "Product Modules", adds mandatory "Scope Boundary" section, tasks tagged with "Domain" and "Ship Blocking" flags. Includes an explicit simplicity guardrail to keep specs lean despite broad scope. See example: task-management-saas.
Both verticals handle work that spans frontend and backend, but they serve different mindsets:
| Full Stack | Builder | |
|---|---|---|
| Scope | Frontend + backend code | Frontend + backend + infra + data + DevOps + anything the product needs |
| Perspective | Implementation layers — "what code goes where" | Product outcomes — "what ships and when" |
| Templates | Default, unchanged — standard User Stories, Component Design, API Changes | Product-centric — Product Requirements, Product Modules, Integration Points, Ship Plan |
| Task structure | Standard tasks grouped by implementation order | Tasks tagged by Domain (frontend, backend, infra, data) with Ship Blocking flags |
| Scope control | Standard spec sections | Mandatory Scope Boundary section (v1 vs. deferred) to prevent scope creep |
| Best for | Adding a feature to an existing app where infra and deployment are already handled | Building a new product from scratch where you own everything from UI to deployment |
Rule of thumb: If someone else handles your infrastructure, CI/CD, and deployment — use Full Stack. If you are the infrastructure, CI/CD, and deployment — use Builder.
Three layers, strict separation:
core/— Platform-agnostic workflow, templates, and safety rules (single source of truth)generator/— Builds platform-specific outputs from core + platform adaptersplatforms/— Generated instruction files per platform (checked into git, no build step for users)
See STRUCTURE.md for the full repository layout.
SpecOps follows a core design principle: prefer the simplest solution that meets requirements.
- Specs scale to the task — a small feature does not generate a full rollout plan
- No speculative complexity — no premature abstractions, no "future-proofing"
- Use what exists — prefer existing project patterns over inventing new ones
Red flags the agent actively avoids: abstractions used only once, error handling for impossible scenarios, configuration for unchanging values, designing for hypothetical futures.
Specs are prompts — they can contain user-supplied content that reaches the agent context. SpecOps treats spec inputs with the same security discipline as any prompt surface.
- Convention strings and custom templates are sanitized against prompt injection
- Secrets use placeholders, PII uses synthetic data
- All schema fields have validation constraints (
maxLength,maxItems,additionalProperties: false) - Paths are contained — rejects absolute paths and
../traversal - Security audited with no high-confidence vulnerabilities found (full report)
For vulnerability reporting, see SECURITY.md.
Contributions welcome. See CONTRIBUTING.md for guidelines.