moai-workflow-ddd

Refactor legacy code through an ANALYZE-PRESERVE-IMPROVE cycle with behavior preservation.

Updated Jun 18, 2026
One-click install
npx skills add https://github.com/h102-log/pdfrag --skill moai-workflow-ddd-h102-log
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: moai-workflow-ddd
Source: https://github.com/h102-log/pdfrag/tree/main/.claude/skills/moai-workflow-ddd
Command: npx skills add https://github.com/h102-log/pdfrag --skill moai-workflow-ddd-h102-log

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Refactoring legacy code without breaking existing behavior is risky, especially when test coverage is thin and the codebase has high coupling. This Skill provides a structured Domain-Driven Development workflow that guarantees observable behavior stays identical while code structure improves. ## Core Features & Use Cases - ANALYZE Phase: Identify domain boundaries, compute coupling/cohesion metrics (Ca, Ce, Instability), and detect structural problems like god classes and feature envy using AST-grep pattern analysis. - PRESERVE Phase: Build characterization tests and behavior snapshots that capture what the code actually does, creating a verified safety net before any change. - IMPROVE Phase: Apply incremental refactorings (extract method, extract class, move method, rename) with continuous test validation after every small change. - Use Case: You inherit a production Python service with tangled modules and partial tests. Run the DDD cycle to map dependencies, add characterization tests for critical paths, then safely restructure the code one verified commit at a time. ## Quick Start Ask the AI to run the DDD workflow on a legacy module to analyze its structure, add characterization tests, and refactor it while preserving behavior.

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 domain boundaries and coupling, then write characterization tests that capture current behavior, and finally apply small incremental refactorings while running the full test suite after each change.

What is the difference between DDD and TDD workflows?▼

TDD uses a RED-GREEN-REFACTOR cycle to create new functionality from specification tests, while DDD uses ANALYZE-PRESERVE-IMPROVE to restructure existing code without changing behavior. DDD is a superset that also adapts to greenfield projects via specification tests.

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

Characterization tests document what code actually does rather than what it should do, capturing real outputs including surprising behavior. Write them before refactoring any code path that lacks sufficient test coverage.

When should I not use the DDD refactoring workflow?▼

Do not use DDD when behavior changes are required, since its golden rule is identical observable behavior; modify the SPEC first instead. It is also not intended for writing new tests or creating features from scratch.

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

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 commit each successful change.