Skip to content
/

cc-spec-driven

cc-spec-driven · mkhrdev/cc-spec-driven · ★ 27 · last commit 2026-01-26

Tracks specification changes as CRs through a draft→confirm→RC→archive lifecycle with LLM-evaluated hooks that enforce checklist completion and bidirectional dependency graph integrity.

Best whenSkill describes how to do it; Hook ensures can only do it this way — the Stop hook uses LLM reasoning to block completion if workflow steps are missing.
Skip ifSkipping _deps.yaml rebuild after /dd-done, Modifying confirmed CRs without resetting to draft
vs seeds
spec-kitin using lifecycle hooks for command enforcement, but uniquely implements hooks as LLM-evaluated prompts rather than she…
Primitive shape 15 total
Commands 12 Hooks 3
00

Summary

cc-spec-driven — Summary

cc-spec-driven (v0.2.0) is a Claude Code plugin that implements a change-request-centric spec-driven workflow with engineering-level hook enforcement. Its central innovation is using three hooks (SessionStart, PostToolUse, Stop) as a compliance engine: hooks detect when spec workflow operations are incomplete and either inject warning messages or block Claude from stopping. The workflow is built around Change Requests (CRs) — uniquely identifiable units of specification work — that flow through a lifecycle (draft → confirmed → RC preview → done/archive) tracked in a layered YAML/Markdown document system. The plugin ships 12 /dd-* slash commands, 3 hooks with LLM-evaluated prompt hooks (not shell hooks), and a full bidirectional dependency graph (_deps.yaml) that auto-updates on feature document changes. Compared to seeds, cc-spec-driven is architecturally closest to spec-kit in its hook-per-command enforcement model, but goes further by using LLM-evaluated prompt hooks (where the hook itself is an AI prompt that decides whether to block) rather than shell scripts — a unique pattern in the corpus.

01

Overview

cc-spec-driven — Overview

Origin

Created by ibarapascal (GitHub: mkhrdev). Published as a Claude Code plugin at v0.2.0 (January 2026). 27 stars, 1 contributor. Supports English and Chinese (README has both versions).

Philosophy

The framework is built on a "Document-First" approach with change-driven enrichment:

"Change-Driven — No need to write all docs upfront, enrich incrementally with changes" "AI-Assisted — Natural language input, AI organizes into unified format" "Documents as Truth — Confirmed documents are the sole basis for development and testing" "Rough to Fine — Describe module overview first, refine features on demand"

The most distinctive philosophical statement is on hook enforcement:

"Skill describes 'how to do it', Hook ensures 'can only do it this way'." "As long as state progression depends on file writes, the workflow is engineered to be locked down."

This is the clearest articulation of the "hooks as enforcement mechanism" philosophy across all analyzed frameworks.

Core Differentiator: LLM-Evaluated Hooks

Unlike most hook implementations (which run shell scripts), cc-spec-driven's hooks are LLM-evaluated prompts: the hook sends a structured prompt to Claude asking it to analyze the file operation and decide whether to proceed. The Stop hook can return {"decision": "block"} to prevent Claude from stopping until checklist items are complete.

Change Request (CR) System

Every spec change is tracked as a CR with a unique ID (CR-001, CR-002, etc.). CRs flow through: draft → confirmed → RC preview → done/archive. This provides full change traceability throughout the spec lifecycle.

02

Architecture

cc-spec-driven — Architecture

Distribution

  • Type: Claude Code plugin
  • Install: claude plugins:install mkhrdev/cc-spec-driven
  • Update: claude plugins:update cc-spec-driven
  • Language: Markdown (commands) + JSON (hooks)
  • Version analyzed: 0.2.0

Installation

claude plugins:install mkhrdev/cc-spec-driven

After installation, type /dd- in Claude Code to see all available commands.

Plugin Manifest (plugin.json)

{
  "name": "cc-spec-driven",
  "version": "0.2.0",
  "description": "Spec-Driven Document-First Development Framework",
  "author": {"name": "ibarapascal"},
  "commands": "./.claude-plugin/commands",
  "hooks": "./.claude-plugin/hooks/hooks.json"
}

Directory Tree (plugin source)

.claude-plugin/
├── plugin.json          # Plugin manifest
├── commands/            # 12 slash command files
│   ├── _base.md         # Shared base template
│   ├── dd-init.md
│   ├── dd-update.md
│   ├── dd-confirm.md
│   ├── dd-done.md
│   ├── dd-status.md
│   ├── dd-drop.md
│   ├── dd-check.md
│   ├── dd-rebase.md
│   ├── dd-spec-dev.md
│   ├── dd-spec-test.md
│   └── dd-test-case.md
└── hooks/
    └── hooks.json       # 3 hooks: SessionStart, PostToolUse, Stop

Product Directory Tree (at runtime)

{product}/
├── project.yaml                   # Product config (next_cr_id, etc.)
├── glossary.yaml                  # Glossary
├── overview.md                    # Product overview
├── features/
│   ├── _deps.yaml                 # Bidirectional dependency graph
│   ├── {feature}.md               # Business requirements (formal)
│   ├── {feature}.rc-{id}.md       # Business requirements (CR preview)
│   ├── {feature}.tech.md          # Technical consensus (formal)
│   └── {feature}.tech.rc-{id}.md
├── changes/
│   ├── _index.yaml                # Change index
│   ├── CR-{id}.md                 # In-progress CRs
│   ├── archive/
│   └── dropped/
├── specs/
│   ├── _index.yaml
│   ├── CR-{id}.dev.md             # Dev spec
│   ├── CR-{id}.test.md            # Test spec
│   └── ...
└── cases/
    ├── _index.yaml
    ├── blessed/                   # Reusable test cases
    └── CR-{id}/

Required Runtime

None beyond Claude Code.

03

Components

cc-spec-driven — Components

Commands (12 slash commands)

Core Commands

Command Purpose
/dd-init Initialize product directory structure
/dd-update Create or modify a Change Request (natural language → CR)
/dd-confirm Confirm CR, generate RC preview documents
/dd-done Merge RC to official docs, rebuild _deps.yaml
/dd-status View current CR status
/dd-drop Abandon a CR and clean up RC/spec files

Auxiliary Commands

Command Purpose
/dd-check Consistency check across documents
/dd-rebase Handle branch conflicts
/dd-spec-dev Generate development spec from confirmed CR
/dd-spec-test Generate test spec from confirmed CR
/dd-test-case Generate Maestro test cases

Plus _base.md — shared base prompt template.

Hooks (3 hooks, all LLM-evaluated prompt type)

Event Purpose
SessionStart Check if current directory has project.yaml; warn if not
PostToolUse (matcher: Write|Edit) Analyze written file path; inject workflow rule reminders based on path pattern (CR files, RC files, archive operations, etc.)
Stop Validate checklist completeness for current operation; return {"decision": "block"} if steps incomplete

Critical detail: These hooks do NOT run shell scripts. They inject prompt text that Claude evaluates using AI reasoning to decide what to do. The Stop hook can block Claude from finishing.

Skills

None.

Subagents

None.

MCP Servers

None.

Scripts

None.

Templates

Per-feature documents created by commands:

  • {feature}.md — business requirements
  • {feature}.tech.md — technical consensus
  • CR-{id}.dev.md — development spec
  • CR-{id}.test.md — test spec
  • CR-{id}/*.yaml — Maestro test cases

State Files

  • project.yaml — product config with next_cr_id
  • features/_deps.yaml — bidirectional dependency graph
  • changes/_index.yaml — CR index
  • specs/_index.yaml — spec index
  • cases/_index.yaml — test case index
05

Prompts

cc-spec-driven — Prompts

Prompt 1: PostToolUse Hook — File Operation Enforcement

Source: .claude-plugin/hooks/hooks.json

Technique: LLM-evaluated prompt hook — the hook sends a structured analysis prompt to Claude, which evaluates the file operation and returns a JSON decision with an optional systemMessage.

{
  "matcher": "Write|Edit",
  "hooks": [{
    "type": "prompt",
    "prompt": [
      "You are a spec-driven workflow guardian. Analyze the completed file operation and enforce subsequent steps.",
      "",
      "**File just written**: $TOOL_INPUT",
      "**Operation result**: $TOOL_RESULT",
      "",
      "## Path Validity Check (Priority)",
      "First check if the written file path is within the spec framework's managed scope.",
      "Valid paths should contain one of these structures: features/, changes/, specs/, cases/, project.yaml, glossary.yaml, overview.md",
      "",
      "## Enforcement Rules",
      "Based on file path patterns, output corresponding systemMessage reminder:",
      "",
      "### 4. CR Moved to archive/ (`changes/archive/CR-*.md`)",
      "→ You are completing /dd-done. This is the most critical step, must:",
      "   - **Rebuild features/_deps.yaml**",
      "   - Delete all RC files",
      "   - Update changes/_index.yaml (status→done)",
      "   - Archive specs and cases",
      "   - Check referenced_by, promote cases to blessed/",
      "",
      "## Output Format",
      "Return JSON: { \"continue\": true, \"systemMessage\": \"Matched rule reminder, empty if no match\" }"
    ],
    "timeout": 30
  }]
}

Notable technique: The hook is itself a prompt to Claude — the AI evaluates its own file operations and injects workflow rule reminders into its own context. This is "LLM enforces LLM" — unprecedented in the seed frameworks.


Prompt 2: Stop Hook — Checklist Validation

Source: .claude-plugin/hooks/hooks.json

Technique: LLM-evaluated blocking gate — the hook presents a checklist to Claude and asks it to decide whether to approve or block the Stop event.

{
  "matcher": "*",
  "hooks": [{
    "type": "prompt",
    "prompt": [
      "You are a spec-driven workflow completion validator. Before Claude stops, verify if the operation is complete.",
      "",
      "## Check Items",
      "### /dd-done (Most Critical)",
      "- [ ] RC files have been merged and deleted",
      "- [ ] **features/_deps.yaml has been rebuilt**",
      "- [ ] CR has been moved to archive/",
      "- [ ] changes/_index.yaml status = done",
      "- [ ] specs and cases have been archived",
      "",
      "## Output Format",
      "Return JSON: { \"decision\": \"approve|block\", \"reason\": \"...\", \"systemMessage\": \"...\" }",
      "",
      "## Judgment Rules",
      "- /dd-* operation detected but steps incomplete → block",
      "- No /dd-* operation or all complete → approve",
      "- Uncertain → approve (don't block non-framework operations)"
    ],
    "timeout": 30
  }]
}

Notable technique: The Stop hook uses "decision": "block" to prevent Claude from completing — a verifiable completion gate enforced by LLM reasoning, not shell logic.


Prompt 3: SessionStart Hook — Environment Check

Source: .claude-plugin/hooks/hooks.json

Technique: Proactive context validation — checks for project.yaml existence at session start and warns if not found.

The hook instructs Claude to output a warning message if project.yaml doesn't exist, directing users to run /dd-init. Silently passes if the product directory is valid.

09

Uniqueness

cc-spec-driven — Uniqueness & Positioning

differs_from_seeds

cc-spec-driven is closest to spec-kit in using hooks to enforce command lifecycle compliance, but diverges fundamentally in how those hooks work: spec-kit's hooks are shell scripts (18 hooks, 2 per command), while cc-spec-driven uses 3 LLM-evaluated prompt hooks that ask Claude itself to reason about compliance and return JSON decisions. The Stop hook that can return {"decision": "block"} to prevent completion is unique across all 11 seeds. The Change Request (CR) system with bidirectional _deps.yaml dependency tracking goes well beyond any seed's state management — only taskmaster-ai has comparable structured state, but taskmaster's state is task-execution state, not spec-change traceability state. No seed framework generates Maestro test cases from specs.

Positioning

cc-spec-driven occupies the "spec change management with engineering-level enforcement" niche. It's appropriate for teams managing complex products where requirement changes need full traceability from CR ID through RC preview to merged docs to test cases, with automated dependency scope checking.

Distinctive Opinions

  1. "Hooks ensure 'can only do it this way'" — the clearest articulation of hooks-as-enforcement in the batch.
  2. LLM-evaluated prompt hooks — the AI evaluates its own file operations via hooks, creating a self-policing workflow where the enforcement layer uses the same intelligence as the agent.
  3. Bidirectional dependency graphfeatures/_deps.yaml tracks both what a feature depends on and what depends on it, enabling proactive impact analysis.

Observable Failure Modes

  1. Single-tool only: Claude Code plugin with no multi-runtime support.
  2. LLM-evaluated hooks can be fooled: Since hooks use AI reasoning rather than deterministic logic, a confused Claude might incorrectly approve or block.
  3. High complexity: The CR/RC/dep graph system is the most complex state model in this batch — high learning curve.
  4. 1 contributor: Maintenance risk.

Explicit Antipatterns

Not listed explicitly, but the hook enforcement system implies:

  • Skipping features/_deps.yaml rebuild after /dd-done
  • Modifying confirmed CRs without resetting to draft status
  • Leaving orphan RC files after dropping a CR

Cross-References

No explicit seed citations. The CR lifecycle pattern resembles change management systems (JIRA-style change tracking applied to spec documents).

04

Workflow

cc-spec-driven — Workflow

CR Lifecycle

draft → confirmed → RC preview generated → done/archive
             ↓
          dropped

Phases

Phase Command Artifact
1. Initialize /dd-init project.yaml, glossary.yaml, overview.md, features/, changes/, specs/, cases/
2. Create CR /dd-update "description" changes/CR-{id}.md + changes/_index.yaml
3. Confirm CR /dd-confirm CR-{id} features/{feature}.rc-{id}.md (RC preview), features/{feature}.tech.rc-{id}.md
4. Merge RC /dd-done CR-{id} features/{feature}.md + features/{feature}.tech.md updated; features/_deps.yaml rebuilt
5. Generate specs /dd-spec-dev, /dd-spec-test specs/CR-{id}.dev.md, specs/CR-{id}.test.md
6. Generate tests /dd-test-case cases/CR-{id}/*.yaml (Maestro)

Approval Gates

Gate Type
Human confirmation before merging RC preview (dd-confirm → dd-done) file-review
Stop hook blocks Claude if checklist incomplete automated (LLM-evaluated)
Dependency scope protection warning if affected features missed automated (LLM-evaluated)

Hook Enforcement

The Stop hook validates a checklist before allowing Claude to stop:

For /dd-done (most critical):

  • RC files have been merged and deleted
  • features/_deps.yaml has been rebuilt
  • CR moved to archive/
  • changes/_index.yaml status = done
  • specs and cases archived
  • test cases promoted to blessed/ if applicable

If any step is incomplete, the hook returns {"decision": "block", "reason": "..."}.

Spec Format

Markdown. Feature documents ({feature}.md) are business requirements. Technical documents ({feature}.tech.md) are technical consensus. Change records (CR-{id}.md) are delta descriptions.

Context Loading Strategy

Layered loading (0-3 levels) to optimize token usage:

  • Always load: project.yaml, glossary.yaml, overview.md
  • On-demand: Only frontmatter and content of relevant features

Parallel Work Support

Git branches with independent CRs per branch, no parallel bottlenecks. /dd-rebase handles merging.

06

Memory Context

cc-spec-driven — Memory & Context

State Storage

YAML and Markdown files in the product directory:

File Purpose
project.yaml Product config (next_cr_id, settings)
glossary.yaml Domain glossary
overview.md Product overview
features/_deps.yaml Bidirectional dependency graph (auto-rebuilt by /dd-done)
changes/_index.yaml CR index (all CRs, statuses)
specs/_index.yaml Spec index
cases/_index.yaml Test case index
cases/blessed/ Reusable test cases

Memory Type

File-based (YAML + Markdown hybrid).

Persistence Scope

Project-level.

Context Loading Strategy

Layered loading to optimize token usage:

  • Level 0 (Always): project.yaml, glossary.yaml, overview.md
  • Level 1 (On-demand): changes/_index.yaml frontmatter
  • Level 2 (On-demand): Relevant feature document frontmatter
  • Level 3 (On-demand): Full feature document content

Bidirectional Dependency Graph

features/_deps.yaml tracks:

  • deps: which features I depend on
  • affects: which features depend on me (auto-computed)

This enables dependency scope protection: the PostToolUse hook detects when a confirmed CR modifies a feature, checks _deps.yaml, and warns if affected downstream features were not also addressed.

Cross-Session Handoff

The CR lifecycle state in changes/_index.yaml provides full session resumption. The SessionStart hook validates the environment on each new session.

Test Case Reuse (blessed Mechanism)

Verified test cases are promoted to cases/blessed/ for reuse. runFlow references allow test cases to auto-include reusable cases from dependency features. CR-id naming enables multiple versions to coexist.

Compaction

Not explicitly handled, but the layered loading strategy minimizes context usage.

07

Orchestration

cc-spec-driven — Orchestration

Multi-Agent

No. Single agent sequential workflow.

Orchestration Pattern

Sequential. CR lifecycle progresses one step at a time.

Isolation Mechanism

None (for single-branch work). Parallel work uses Git branches with independent CRs.

Multi-Model

No.

Execution Mode

Interactive loop. User drives each phase with /dd-* commands.

Auto-Validators (Hook-Enforced)

The 3 LLM-evaluated hooks provide auto-validation:

  1. SessionStart: Validates product directory
  2. PostToolUse: Validates each file write against workflow rules, injects reminders
  3. Stop: Validates checklist completeness, blocks Claude if steps are missing

These are the most sophisticated auto-validators in this batch — they use LLM reasoning, not shell scripts.

Prompt Chaining

Yes. CR creation → RC preview → merge to official docs is a sequential chain where each step's output feeds the next.

Git Automation

None automatic. The /dd-rebase command assists with manual branch conflict resolution.

Crash Recovery

Yes — CR lifecycle state in _index.yaml files provides full resumption. The SessionStart hook validates environment on each new session.

08

Ui Cli Surface

cc-spec-driven — UI & CLI Surface

Dedicated CLI Binary

Exists: No

Local UI

Exists: No

IDE Integration

Claude Code plugin only. Install via claude plugins:install mkhrdev/cc-spec-driven.

Observability

  • changes/_index.yaml — CR status ledger (all CRs visible)
  • specs/_index.yaml — spec status ledger
  • cases/_index.yaml — test case status ledger
  • Hook warnings injected into Claude's context in real-time

The index YAML files serve as lightweight observability artifacts.

Related frameworks

same archetype · same primary tool · same memory type

DevTeam: Claude Code Multi-Agent Dev System
Trellis ★ 8.5k

Team-scale AI coding harness: shared specs auto-injected via hooks into sub-agents across 14 AI tools, with per-developer…

Atmosphere ★ 3.8k

JVM framework for building production-grade governed AI agents with streaming transports, HITL approvals, Cedar/Rego policy…

Superpowers ★ 207k

Enforces spec-first, TDD, and subagent-reviewed development as mandatory automatic workflows rather than optional practices.

Claude-Flow / Ruflo ★ 55k

Eliminates single-agent context limits and sequential bottlenecks by orchestrating fault-tolerant swarms of specialized AI agents…

BMAD-METHOD ★ 48k

Provides a full agile delivery lifecycle with named expert-persona AI collaborators that elicit the human's best thinking rather…