Specification-driven development workflows for Claude Code using EARS, Gherkin, and multi-provider support.

This plugin enables specification-driven development using the GitHub Spec Kit 5-phase workflow:

Constitution → Specify → Plan → Tasks → Implement

It supports 7 specification providers:

/plugin install spec-driven-development@melodic-software

/spec-driven-development:speckit-run "User authentication with email and OAuth"

/spec-driven-development:specify "Add shopping cart functionality"

/spec-driven-development:status --all

Six unified agents provide all specification-driven development capabilities through argument-based mode selection:

Interactive authoring assistant for specifications. Pass mode as argument.

Usage: spec-author ears, spec-author gherkin, spec-author userstory

Converts specifications between formats. Pass mode as argument.

Usage: spec-converter ears, spec-converter gherkin, spec-converter kiro

Generates or refines specifications. Pass mode as argument.

Usage: spec-processor generate, spec-processor refine

Audits or validates specifications (read-only). Pass mode as argument.

Usage: spec-reviewer audit, spec-reviewer validate

Full 5-phase Spec Kit workflow orchestration. Unchanged from previous version.

ADR generation from specification context. Has auto-loaded adr-management skill.

Define project principles and constraints in .constitution.md:

/spec-driven-development:constitution --init

Generate a canonical specification from requirements:

/spec-driven-development:specify "User authentication with social login"

Output: .specs/{feature}/spec.md

Generate implementation design:

/spec-driven-development:plan .specs/auth/spec.md

Output: .specs/{feature}/design.md

Break down into implementable tasks:

/spec-driven-development:tasks .specs/auth/spec.md

Output: .specs/{feature}/tasks.md

Guide implementation with AC validation:

/spec-driven-development:implement .specs/auth/spec.md

The plugin supports all 6 EARS patterns:

Requirements are scored against INVEST criteria:

Threshold: Score 7+ to proceed

.specs/
├── {feature-name}/
│   ├── spec.md          # Canonical specification
│   ├── design.md        # Implementation design
│   ├── tasks.md         # Task breakdown
│   └── audit.md         # Last audit report
└── index.md             # Specification index

.constitution.md          # Project constitution

Enable spec-focused output formatting:

/output-style spec-output

This style:

• Emphasizes structured formats (YAML, tables, lists)
• Uses EARS syntax for requirements
• Uses Given/When/Then for acceptance criteria
• Minimizes prose, maximizes traceability

This plugin integrates with:

• schemas/canonical-spec.schema.json - Schema validation
• prompts/specify.prompt.md - Generation templates
• templates/EARS-REQUIREMENT-TEMPLATE.md - Pattern templates
• ADR-115 - Specification Provider Abstraction architecture

/spec-driven-development:userstory-author "Search products by keyword"

/spec-driven-development:ears-convert requirements.txt --to ears

/spec-driven-development:kiro-sync .specs/auth --direction export

/spec-driven-development:adr-create .specs/auth/spec.md --decision "Use JWT for session tokens"

The /spec-driven-development:adr-create command extracts architectural decisions that emerge during specification authoring. It creates ADRs in docs/adr/ linked to specific specifications (SPEC-xxx IDs).

When to use this vs enterprise-architecture:

• Use /spec-driven-development:adr-create when decisions emerge FROM specifications
• Use /ea:adr-create (enterprise-architecture plugin) for standalone architecture decisions not tied to a specific specification

Both use MADR format and can coexist in the same project.

This plugin follows Option C (Hybrid) architecture:

• Generic entry points for workflow-centric users
• Provider deep-dives for format-specific expertise
• Pure delegation to skills for domain knowledge
• Model-appropriate agents (Opus for generation, Haiku for validation)

MIT