Modding claude-mem

<span className="text-emerald-500"> When SDD Meets TDD: Completing the Testing Puzzle for Spec-Driven Development</span>

What is SDD (Spec-Driven Development)

Spec-Driven Development is one of the most important emerging practices in AI-assisted software engineering in 2025. Its core philosophy is: the specification is the primary artifact of software development, and code is merely output generated from the spec.

The standard SDD lifecycle:

• spec-init — Initialize the feature specification
• spec-requirements — Produce structured requirements documents (typically in EARS format)
• spec-design — Architecture design documents, including system structure diagrams
• spec-tasks — Break down the design into implementation tasks with dependencies
• spec-impl — AI Agent generates code from the specification

SDD solves a real problem: it transforms AI from "useful autocomplete" into a "traceable development partner." Every line of AI-generated code can be traced back to a versioned specification document, which has significant implications for auditing, compliance, and team collaboration.

However, after researching multiple SDD frameworks (cc-sdd, OpenSpec, Kiro) and authoritative analyses (ThoughtWorks, Martin Fowler), we discovered a common gap: testing is not defined as an independent phase in SDD's standard workflow. Testing is implicitly embedded within the implementation phase, lacking systematic test specifications, test execution strategies, and test quality gates. ThoughtWorks also acknowledged in their analysis: "We still need highly deterministic CI/CD practices to ensure software quality" — implying that SDD itself does not fully address quality assurance.

<span className="text-accent">What is Our make-plan + do Combo</span>

We extended the make-plan and do Skills in claude-mem, with the goal of filling in SDD's missing testing dimension while preserving the spec-driven spirit.

make-plan workflow:

• Phase -1A Requirements Clarity Check — If requirements are vague, automatically guide the user into a brainstorming session or ask them to provide more details
• Phase -1B Risk Assessment — Automatically determine the execution mode based on five dimensions: data sensitivity, impact scope, reversibility, complexity, and existing test coverage
• Phase 0 Documentation Discovery — Search for and read relevant documentation and APIs
• Phase 0.5 Test Infrastructure Discovery — Discover the project's testing framework, naming conventions, and toolchain
• Each Implementation Phase — Includes both implementation specs and test specs, with test cases defined in GIVEN/WHEN/THEN format
• Test Plan Consolidation — Produce a complete test matrix, including cross-phase integration tests and acceptance scenarios

do splits into three execution modes based on risk assessment results:

• LIGHT mode (low risk) — Implement then test module by module, lightest workflow
• STANDARD mode (medium risk) — Phase-by-phase TDD, write tests before implementation, independent Test Agent performs verification
• FULL mode (high risk) — Complete parallel TDD workflow, including dependency analysis, background parallel testing, test-tracker.md tracking file, and manual review gates

<span className="text-sky-500">Key Differences Between the Two</span>

SDD has a complete "from requirements to code" workflow, but testing is implicit. We have a <span className="text-rose-500">complete "from spec to test to verification" workflow</span>.

Differences at the spec level:

• SDD produces requirements.md, design.md, tasks.md — focused on "what to build" and "how to build it"
• Our make-plan mandates a Test Specification in every implementation phase — in addition to defining "what to build," it also defines "how to prove it's correct"
• SDD has no test infrastructure discovery step; our Phase 0.5 automatically detects the project's testing framework and conventions

Differences at the execution level:

• SDD's spec-impl has the Agent generate code directly from specs, with testing handled as a byproduct of implementation
• Our do separates implementation and testing into two independent roles: the Implementation Agent is responsible for writing code and test files, while the Test Agent is responsible for running tests and writing failure diagnostics
• <span className="text-rose-500">The Test Agent is strictly read-only — it only runs tests, records results, and analyzes failure causes, never modifying any source code</span>. This ensures <span className="text-rose-500">cognitive isolation</span> between the Agent that writes code and the Agent that verifies it

Differences in failure handling:

• SDD does not define a standard workflow for handling test failures
• In our workflow, the Test Agent records complete diagnostics for every failed test: which file and line the error is on, why it failed, and suggested fixes. All failures are aggregated and presented for manual review, where humans decide the fix strategy before a dedicated Fix Agent repairs them one by one

Differences in tracking and artifacts:

• SDD's artifacts are specification documents and code
• We additionally produce test-tracker.md (recording the state changes of each test case across phases) and test-report.md (final test report, including compliance matrix and fix history). These documents are committed alongside the code, serving as traceable quality evidence

<span className="text-amber-500">Conclusion: Making Testing a First-Class Citizen on a Spec-Driven Foundation</span>

SDD established a structured pipeline from requirements to code, enabling every line of AI-generated code to be traced back to a versioned specification. Our architecture embraces this core philosophy and builds upon it by elevating testing from an implicit step to an independent first-class process — test specs are produced in parallel with implementation specs, an independent read-only Test Agent performs verification, and persistent tracking records document the lifecycle of every test case.

SDD guarantees that "code can be traced back to specs." We further guarantee that "code behavior conforms to specs."

<span className="text-rose-500">But we must be honest — these additional guarantees come at a cost</span>. SDD's workflow is clear and concise — five steps, linear progression, easy for AI Agents to execute correctly. Our workflow adds risk assessment, test infrastructure discovery, TDD cycles, role separation, background parallel testing, and manual review gates, making the overall complexity significantly higher. A more thorough but harder-to-execute-correctly workflow is not necessarily better than a simple but stable one.

This is also why we designed the risk-adaptive mode. During the planning phase, the system automatically assesses the risk level based on five dimensions — data sensitivity, impact scope, reversibility, complexity, and existing test coverage — then selects the corresponding execution intensity:

• LIGHT mode (low risk) — Close to SDD's original simplicity. Generate tests after implementing each module, run once, report results. No additional role separation, no tracking files. Suitable for internal tools, prototypes, one-off scripts
• STANDARD mode (medium risk) — Phase-by-phase TDD. Write tests from specs first, then write implementation, with an independent read-only Test Agent performing verification. Failures are escalated for human decision. No background parallel testing, no tracking files. Suitable for general feature development, non-critical APIs
• FULL mode (high risk) — Complete workflow. After dependency analysis, tests for independent tasks run in parallel in the background, test-tracker.md records the complete lifecycle of each test case, all failures are aggregated and pass through a manual review gate, Fix Agent repairs them one by one, and finally test-report.md is produced as quality evidence. Suitable for core APIs, data processing pipelines, authentication systems, and payment-related features

Low-risk tasks use the lightest workflow; only high-risk scenarios activate the full mechanism, avoiding sacrificing all efficiency for the sake of quality. Users can also override the system's judgment at any time — if the system determines LIGHT but you believe it should be FULL, your choice always takes priority.