Spec-kit vs OpenSpec vs Conduct

When we built Conduct, we were already fans of specification-driven development. We’d been using spec-kit for greenfield projects and loved its simplicity. We’d experimented with OpenSpec’s delta format for tracking changes. But we kept running into the same problems: our team used different AI agents, we needed to link specs to Linear, and our project hierarchies were getting unwieldy.

So we built Conduct to solve those problems. But that doesn’t make the other tools obsolete—spec-kit and OpenSpec each excel in their own domains. Here’s how we think about the differences and when you might choose one over the other.

TL;DR Comparison

What is Specification-Driven Development?

Traditional development: Code is king, specs are scaffolding we discard.

Spec-driven development: Specifications are executable, directly generating implementations.

This shift is critical for AI-assisted development. Without specs, AI coding assistants:

• Generate code from vague prompts
• Miss requirements
• Add unwanted features
• Lack context on existing systems

With specs, AI has:

• Clear requirements to implement
• Structured context
• Defined success criteria
• Audit trail of changes

spec-kit: The Pioneer

GitHub’s spec-kit introduced spec-driven development to the mainstream.

What It Does Well

• ✅ Simplicity: Single specs/ folder, easy to understand
• ✅ 0→1 Projects: Excellent for greenfield development
• ✅ GitHub Integration: Built by GitHub, works great with GitHub Copilot
• ✅ Clear Methodology: Strong philosophy and getting-started guide

Limitations

• ❌ Flat Structure: All specs in one folder, hard to organize large projects
• ❌ No Versioning: Manual tracking of spec changes
• ❌ No Issue Tracker Integration: Can’t link specs to tickets
• ❌ Evolving Features: Less structure for modifying existing features

Best Use Case

You’re starting a new project from scratch.

Example Structure

specs/
├── authentication.md
├── dashboard.md
├── api-endpoints.md
└── database-schema.md

OpenSpec: The Lightweight Framework

OpenSpec is a lightweight, spec-driven framework that emphasizes evolution over time.

What It Does Well

• ✅ Delta Format: Structured “patches” showing how specs change
• ✅ Two-Folder Model: Separates current truth (specs/) from proposed updates (changes/)
• ✅ Feature Grouping: Related specs, tasks, and designs in one folder
• ✅ Native AI Support: Custom slash commands for Cursor, Claude, Windsurf, etc.
• ✅ No Dependencies: No API keys or MCP protocol required
• ✅ Open Source: Completely free and self-hosted

Limitations

• ❌ Complex Structure: Two-folder model can be confusing initially
• ❌ Manual Organization: No automatic versioning or hierarchy enforcement
• ❌ Scattered Updates: Multi-spec features can spread across folders
• ❌ No Issue Tracker Integration: Can’t link to GitHub/Jira/Linear
• ❌ CLI Only: No orchestration beyond spec management

Best Use Case

You’re evolving existing features and need structured change tracking across multiple specs.

Example Structure

openspec/
├── specs/
│   ├── auth.md (current truth)
│   └── dashboard.md (current truth)
└── changes/
    ├── add-oauth/
    │   ├── delta-auth.md (ADDED/MODIFIED/REMOVED sections)
    │   └── delta-dashboard.md
    └── improve-performance/
        └── delta-api.md

Delta Format Example

## ADDED Requirements

### Requirement: OAuth2 Integration
SHALL support OAuth2 authentication

#### Scenario: Google Login
GIVEN user clicks "Login with Google"
WHEN authorization succeeds
THEN user is logged in

## MODIFIED Requirements

### Requirement: Session Management
SHALL maintain sessions for 7 days (updated from 24 hours)

## REMOVED Requirements

### Requirement: Basic Auth
Deprecated in favor of OAuth2

Conduct: What We Built and Why

We built Conduct as both a spec management CLI and a multi-agent orchestration platform (desktop app coming soon). Our goal was to address the gaps we experienced with existing tools while preserving what made spec-driven development great in the first place.

What It Does Well

• ✅ Multi-Agent Support: Works with 6+ AI coding tools (Cursor, Claude, Warp, Factory, OpenCode, GitHub Copilot, Gemini)
• ✅ Automatic Versioning: Specs automatically versioned (v0 → v1 → v2) when changes are made
• ✅ Persistent Memory: libSQL database (local or remote) remembers all work
• ✅ Infinite Nesting: Organize features hierarchically to any depth
• ✅ Issue Tracker Integration: Link specs to GitHub, Jira, Linear, GitLab, Azure DevOps - Useful for AI agents when creating PRs
• ✅ Agent-Agnostic: Team members can use different AI tools with same specs (AGENTS.md, CLAUDE.md, WARP.md, GEMINI.md)
• ✅ JSON Schema Support: IDE autocomplete and validation for config files
• ✅ Desktop App (Coming Soon): Orchestrate multiple agents from one interface
• ✅ Audit Trail: Old spec versions preserved for history

Limitations

• ❌ More Complex: Richer feature set means steeper learning curve
• ❌ Desktop App Not Ready: Multi-agent orchestration still in development
• ❌ Newer: Less battle-tested than spec-kit

Best Use Case

You work with multiple AI agents, need hierarchical organization, and want issue tracker integration.

Example Structure

conduct/
├── spec.v0.md (root spec)
├── AGENTS.md (AI agent instructions)
├── track.json (version & config tracking)
├── features/
│   ├── authentication/
│   │   ├── spec.v2.md (current version)
│   │   ├── spec.v1.md (previous version)
│   │   ├── spec.v0.md (original)
│   │   ├── features/
│   │   │   ├── oauth/
│   │   │   │   └── spec.v0.md
│   │   │   └── two-factor/
│   │   │       └── spec.v0.md
│   │   └── changes/
│   │       ├── add-oauth.spec.md
│   │       └── add-2fa.spec.md
│   └── dashboard/
│       ├── spec.v1.md
│       └── changes/
│           └── improve-performance.spec.md
└── changes/
    └── update-dependencies.spec.md

Automatic Versioning Flow

1. Create feature:
   conduct init
   /feature Authentication system
   → creates: features/authentication/spec.v0.md

2. Make change via AI agent:
   /change Add OAuth2 support
   → creates: features/authentication/changes/add-oauth.spec.md
   → creates: features/authentication/spec.v1.md
   → preserves: features/authentication/spec.v0.md

3. Another change:
   /change Add two-factor auth
   → creates: features/authentication/changes/add-2fa.spec.md
   → creates: features/authentication/spec.v2.md
   → preserves: spec.v0.md and spec.v1.md

Key Differences

Structure Philosophy

spec-kit: Flat - all specs in one folder OpenSpec: Dual - current state + proposed changes Conduct: Hierarchical - nested features with automatic versioning

Versioning Approach

spec-kit: Manual version management OpenSpec: Delta patches show changes Conduct: Automatic version increments (v0 → v1 → v2)

AI Agent Support

spec-kit: Primarily GitHub Copilot OpenSpec: Native integration with 10+ agents Conduct: Universal support with agent-specific commands for 6+ agents

Organization

spec-kit: Best for small, flat projects OpenSpec: Groups related changes in folders Conduct: Infinitely nested feature hierarchies

Issue Tracking

spec-kit: None OpenSpec: None Conduct: GitHub, Jira, Linear, GitLab, Azure DevOps

Head-to-Head Scenarios

Scenario 1: Starting a New Project

Winner: spec-kit

Simple, clear, and gets you coding fast. Perfect for 0→1.

uv tool install specify-cli --from specify-cli
specify init
# Start writing specs in specs/ folder

Scenario 2: Evolving an Existing Feature

Winner: OpenSpec

Delta format clearly shows what changed, added, and removed.

npm install -g @fission-ai/openspec@latest
openspec init
# Create change deltas in openspec/changes/

Scenario 3: Large Multi-Agent Team

Winner: Conduct

Different team members use different AI agents, all working from same specs.

npm install -g conduct-cli
conduct init
# Select: Cursor, Claude, Warp
# Team members use their preferred agent

Scenario 4: Linking Specs to Tickets

Winner: Conduct

Only Conduct integrates with issue trackers.

conduct init
conduct config tracker add
# Select: GitHub or Linear
# Specs automatically link to tickets
# AI agents can reference issue context

Scenario 5: Complex Feature Hierarchies

Winner: Conduct

Authentication → OAuth → Google + GitHub nested infinitely.

features/authentication/features/oauth/features/google/spec.v0.md

Scenario 6: Quick Prototyping

Winner: spec-kit

Minimal overhead, just write markdown and start coding.

Migration Paths

From spec-kit to OpenSpec

1. Create openspec/specs/ and move files from specs/
2. Future changes go in openspec/changes/ as deltas
3. Use OpenSpec CLI for structured evolution

From spec-kit to Conduct

1. Run conduct init
2. Move each spec to conduct/features/{feature-name}/spec.v0.md
3. Use AI agent commands for future features/changes

From OpenSpec to Conduct

1. Run conduct init
2. Move files from openspec/specs/ to conduct/features/*/spec.v0.md
3. Convert deltas to Conduct change specs
4. Let Conduct auto-version from there

From Conduct to Others

Export current spec versions to flat structure for spec-kit or dual structure for OpenSpec.

Which Should You Choose?

Choose spec-kit if:

• You’re starting a greenfield project
• Your team primarily uses GitHub Copilot
• You want the simplest possible setup
• You don’t need versioning or issue tracking

Choose OpenSpec if:

• You’re evolving existing features
• You need structured change tracking
• You want native support for many AI agents
• You prefer deltas over versioned files
• You need a lightweight, no-dependencies solution

Choose Conduct if:

• Your team uses multiple AI coding tools (Cursor, Claude, Warp, Gemini, etc.)
• You need persistent memory across all work (libSQL database)
• You need automatic versioning (v0 → v1 → v2)
• You want hierarchical feature organization
• You need issue tracker integration (GitHub, Jira, Linear, GitLab, Azure)
• You want JSON schema support for config validation
• You want a desktop app for multi-agent orchestration (coming soon)
• You need audit trails with preserved history

The Future We’re All Building Toward

Whether you use spec-kit, OpenSpec, or Conduct, we’re all working toward the same future:

Specifications become first-class citizens, not afterthoughts.

AI coding assistants work best with:

1. Clear requirements (specs provide this)
2. Structured context (hierarchies and deltas)
3. Predictable outcomes (executable specifications)
4. Audit trails (versioning and history)

We built Conduct because we needed these capabilities in a specific way, but the question isn’t whether to use spec-driven development—it’s which tool fits your workflow best.

Try Them All

Each tool is open source and easy to try:

spec-kit:

uv tool install specify-cli --from specify-cli
specify init

OpenSpec:

npm install -g @fission-ai/openspec@latest
openspec init

Conduct:

curl -fsSL https://git.conduct.run/install.sh | bash
# or: npm install -g conduct-cli
conduct init

Our Take

We’re grateful to GitHub for pioneering spec-driven development with spec-kit’s simple, effective approach. We learned from OpenSpec’s delta-based evolution and broad AI agent support. And we built Conduct to add multi-agent orchestration, automatic versioning, and issue tracking because those were the problems we needed solved.

There’s no wrong choice—each tool matches different workflows and project complexities. We built Conduct for teams that need what we needed. If your needs are different, spec-kit or OpenSpec might be the better fit.

The real win is adopting spec-driven development in any form. Your AI coding assistants will work better, and we all benefit from that.

Resources

• spec-kit: github.com/github/spec-kit
• OpenSpec: openspec.dev | github.com/Fission-AI/OpenSpec
• Conduct: conduct.run | github.com/21nOrg/conduct | Documentation

Have questions or want to share your experience? Join the conversation on GitHub or reach out to the respective project communities.