moai-workflow-ddd

Refactor legacy code through an ANALYZE-PRESERVE-IMPROVE cycle with characterization tests.

Updated Aug 29, 2026
One-click install
npx skills add https://github.com/Seung-zedd/secure-file-upload --skill moai-workflow-ddd-seung-zedd
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: moai-workflow-ddd
Source: https://github.com/Seung-zedd/secure-file-upload/tree/main/.claude/skills/moai-workflow-ddd
Command: npx skills add https://github.com/Seung-zedd/secure-file-upload --skill moai-workflow-ddd-seung-zedd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Refactoring legacy code without breaking existing behavior is risky when test coverage is thin. This Skill provides a structured Domain-Driven Development workflow that captures current behavior with characterization tests before making any structural change, so refactoring never silently alters what the code does. ## Core Features & Use Cases - ANALYZE Phase: Identify domain boundaries, coupling and cohesion metrics, and problematic structural patterns using AST-grep analysis. - PRESERVE Phase: Create characterization tests and behavior snapshots that document what the code actually does, building a verified safety net. - IMPROVE Phase: Apply incremental refactorings (extract method, extract class, move method, rename) with continuous test validation after every change. - Use Case: When modernizing a production module with few tests, run the DDD cycle to map callers, lock in current behavior with characterization tests, then restructure the code step by step while the test suite confirms nothing changed. ## Quick Start Ask the AI to refactor a legacy module using the DDD workflow, starting with an analysis of its callers and characterization tests before any code changes.

Frequently Asked Questions about moai-workflow-ddd

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor legacy code without breaking existing behavior?▼

Use the ANALYZE-PRESERVE-IMPROVE cycle: first map callers and coupling, then write characterization tests that capture current behavior, then make small incremental changes running the full test suite after each step. Revert immediately if any test fails.

What is the difference between DDD and TDD workflows?▼

TDD uses a RED-GREEN-REFACTOR cycle to create new functionality from specification tests. DDD uses ANALYZE-PRESERVE-IMPROVE to restructure existing code without changing behavior, relying on characterization tests that document what the code currently does.

What are characterization tests and when should I write them?▼

Characterization tests capture the actual current behavior of code, including surprising or incorrect outputs, without assuming correctness. Write them before refactoring any code path that lacks coverage, so regressions are detected during restructuring.

Can DDD be used for greenfield projects?▼

Yes, with an adapted cycle: ANALYZE becomes requirements analysis, PRESERVE defines intended behavior through specification tests, and IMPROVE implements code to satisfy those tests. This makes DDD a superset that includes TDD's test-first approach.

When should I not use the DDD workflow?▼

Do not use DDD when the goal is to change behavior rather than preserve it. For new behavior, modify the SPEC first or use TDD. DDD is specifically for behavior-preserving structural improvement of existing code.

What should I do when tests fail after a refactoring step?▼

Revert immediately to the last known good state, analyze which tests failed and why, and check whether the transformation unintentionally changed behavior. Then retry with smaller transformation steps and re-run the full suite.