SDC: A Spec-Driven Development Plugin for Claude Code — Say Goodbye to 'Vibe Coding' with Structured Workflows

SDC (Spec-Driven Claude) is a Spec-Driven Development (SDD) plugin tailored for Claude Code. It enforces the 'write specifications first, then code' workflow via professional proxies and slash commands such as /sdc.clarify, architect, tdd, backend/frontend, addressing the common 'vibe coding' issue in AI programming—where code appears correct but fails to meet actual requirements.

When using AI programming assistants like Claude Code, many developers have encountered this dilemma: you describe a feature requirement, the AI quickly generates code that looks reasonable, has correct syntax, and even runs—but its actual behavior deviates from expectations.

This phenomenon is called 'Vibe Coding': the AI-generated output seems correct on the surface but lacks an accurate understanding of the real intent. The root cause is that requirement descriptions are often vague, and AI tends to generate code that is 'statistically most likely correct' rather than 'truly correct'.

Spec-Driven Development (SDD) was created to solve this problem. It requires writing complete, detailed specifications before any code—clearly defining all interfaces, types, acceptance criteria, and business rules. Only after the specifications are approved does implementation begin.

SDC (Spec-Driven Claude) deeply integrates this concept into Claude Code, enforcing the SDD workflow through structured processes and specialized proxies.

In SDD, specifications define a complete contract:

• API Contracts: Endpoints, status codes, request/response structures
• Type Definitions: TypeScript interfaces (or equivalents) for frontend use
• DTO/Schema: Input validation for backend
• Acceptance Criteria: Verifiable behavior that defines 'done'
• Business Rules: Logic not obvious from the contract alone

Backend and frontend teams read the same specifications independently and reach consistent results. No misalignment, no rewrites.

SDD isn't suitable for all scenarios:

• SDD Appropriate: Feature development introducing new behavior
• Direct Implementation: Bug fixes, minor visual adjustments, slight refactoring

Understanding this boundary is crucial for using SDC efficiently.

SDC installs four global slash commands into Claude Code to form a complete workflow:

Participants: You + Claude

This is the starting point of the entire workflow. You describe the feature, and Claude asks targeted questions to eliminate ambiguity and assess whether the scope fits into a single specification or should be split.

Key Outputs:

• Clear requirement description
• Scope boundary definition
• Recommendation on whether splitting is needed

Participants: architect proxy (using opus model)

The architect proxy is responsible for writing complete specification documents, stored in the docs/specs/ directory. It presents a specification summary and waits for your explicit approval before proceeding.

This is a critical control point for SDD: No implementation work begins until the specification is approved.

Participants: tdd proxy (using sonnet model)

Write tests based on acceptance criteria—before the implementation exists. The tests will fail, which is expected. The test-first approach ensures:

• Acceptance criteria are verifiable
• Implementation has a clear goal
• Regression tests are in place