メニュー
Domain-Driven Development workflow specialist using ANALYZE-PRESERVE-IMPROVE cycle for behavior-preserving code transformation. Use when refactoring legacy code or reducing technical debt safely.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/modu-ai/claude --skill moai-workflow-dddコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Higgsfield MCP 기반 AI 영상을 자연어 요청 한 줄로 생성합니다. 모델·파라미터를 하드코딩하지 않고 라이브 카탈로그(models_explore)를 조회해 호출하므로, 카탈로그가 바뀌어도 드리프트 없이 동작합니다. 다음과 같은 요청 시 사용하세요: - "Higgsfield 영상 만들어줘" - "Veo로 영상" - "Kling으로 영상" - "Seedance로 다이내믹 영상" - "Cinema Studio로 시네마틱 영상" - "Marketing Studio UGC 광고 영상" - "AI 영상 생성" Veo·Kling·Seedance·Cinema Studio·Marketing Studio·Wan·Gemini Omni·Grok 등 계열의 프롬프트 크래프트는 references/prompt-craft/*.md에 출처와 함께 큐레이션돼 있고(계열마다 규칙이 다름 — 범용 공식 없음), 실제 파라미터(모델 id·해상도·비율·길이·비용)는 런타임에 라이브 조회합니다.
Higgsfield MCP 이미지·영상 생성의 공유 코어. media-higgsfield-image / media-higgsfield-video가 로드하는 SSOT(single source of truth)로, 호출 스키마·라이브 카탈로그 조회 프로토콜·공통 크래프트 규칙(R1–R5)·인터뷰 슬롯·잡 수명주기를 정의합니다. 다음과 같은 상황에서 로드됩니다: - media-higgsfield-image 또는 media-higgsfield-video가 호출 계약을 참조할 때 - Higgsfield 모델의 파라미터를 하드코딩하지 않고 런타임 조회해야 할 때 - namespace(mcp__higgsfield__ vs mcp__claude_ai_higgsfield__)를 런타임 해석해야 할 때 이 스킬은 단독 실행 스킬이 아니라 두 소비 스킬이 참조하는 공유 코어입니다.
Higgsfield MCP 기반 AI 이미지를 자연어 요청 한 줄로 생성합니다. 모델·파라미터를 하드코딩하지 않고 라이브 카탈로그(models_explore)를 조회해 호출하므로, 카탈로그가 바뀌어도 드리프트 없이 동작합니다. 다음과 같은 요청 시 사용하세요: - "Higgsfield로 이미지 만들어 줘" - "Soul로 인물 이미지" - "Nano Banana Pro로 카드뉴스 이미지" - "AI 이미지 생성해줘" - "시네마틱 키 비주얼 만들어줘" - "캐릭터 일관성 있는 시리즈 이미지" - "DTC 광고 이미지(Marketing Studio)" Soul·Nano Banana·GPT Image·Seedream·FLUX·Recraft·Marketing Studio 등 계열의 프롬프트 크래프트는 references/prompt-craft/*.md에 출처와 함께 큐레이션돼 있고, 실제 파라미터(모델 id·해상도·비율·비용)는 런타임에 라이브 조회합니다. 프롬프트만 필요하면 moai-coworker의 *-prompt 스킬을 사용하세요.
SOC 職業分類に基づく
SKILL.md を表示中
| name | moai-workflow-ddd |
| description | Domain-Driven Development workflow specialist using ANALYZE-PRESERVE-IMPROVE cycle for behavior-preserving code transformation. Use when refactoring legacy code or reducing technical debt safely. |
| license | Apache-2.0 |
| compatibility | Designed for Claude Code |
| allowed-tools | Read, Write, Edit, Bash(git:*), Bash(pytest:*), Bash(ruff:*), Bash(npm:*), Bash(npx:*), Bash(node:*), Bash(uv:*), Bash(make:*), Bash(cargo:*), Bash(go:*), Bash(mix:*), Bash(bundle:*), Grep, Glob, mcp__context7__resolve-library-id, mcp__context7__get-library-docs |
| user-invocable | false |
| metadata | {"version":"1.0.0","category":"workflow","status":"active","updated":"2026-01-16","modularized":"true","tags":"workflow, refactoring, ddd, domain-driven, behavior-preservation, ast-grep, characterization-tests","author":"MoAI-ADK Team","related-skills":"moai-tool-ast-grep, moai-workflow-testing, moai-foundation-quality"} |
[NOTE] This workflow is selected based on .moai/config/sections/quality.yaml:
constitution:
development_mode: ddd # or tdd
When to use this workflow:
development_mode: ddd → Use DDD (this workflow)development_mode: tdd → Use TDD instead (moai-workflow-tdd)Key distinction:
Domain-Driven Development provides a systematic approach for refactoring existing codebases where behavior preservation is paramount. Unlike TDD which creates new functionality, DDD improves structure without changing behavior.
Core Cycle - ANALYZE-PRESERVE-IMPROVE:
When to Use DDD:
When NOT to Use DDD:
Greenfield Project Adaptation:
For new projects without existing code, DDD adapts its cycle:
This makes DDD a superset of TDD - it includes TDD's test-first approach while also supporting refactoring scenarios.
TDD Approach (for new features):
DDD Approach (for refactoring):
The golden rule of DDD is that observable behavior must remain identical before and after refactoring. This means:
The analyze phase focuses on understanding the current codebase structure and identifying refactoring opportunities.
Identify logical boundaries in the codebase by examining:
Use AST-grep to analyze structural patterns. For Python, search for import patterns to understand module dependencies. For class hierarchies, analyze inheritance relationships and method distributions.
Evaluate code quality metrics:
Low cohesion and high coupling indicate refactoring candidates.
Use AST-grep to identify problematic patterns:
Create analysis reports documenting:
The preserve phase establishes safety nets before making any changes.
Characterization tests capture existing behavior without assumptions about correctness. The goal is to document what the code actually does, not what it should do.
Steps for creating characterization tests:
Characterization test naming convention: testcharacterize[component]_[scenario]
For complex outputs, use snapshot testing to capture current behavior:
Snapshot files serve as behavior contracts during refactoring.
Before proceeding to improvement phase, verify:
Run mutation testing if available to verify test effectiveness.
The improve phase makes structural changes while continuously validating behavior preservation.
Never make large changes at once. Follow this pattern:
Extract Method: When a code block can be named and isolated. Use AST-grep to identify candidates by searching for repeated code blocks or long methods.
Extract Class: When a class has multiple responsibilities. Move related methods and fields to a new class while maintaining the original API through delegation.
Move Method: When a method uses data from another class more than its own. Relocate while preserving all call sites.
Inline Refactoring: When indirection adds complexity without benefit. Replace delegation with direct implementation.
Rename Refactoring: When names do not reflect current understanding. Update all references atomically using AST-grep rewrite.
Use AST-grep for safe, semantic-aware transformations:
For method extraction, create a rule that identifies the code pattern and rewrites to the extracted form.
For API migration, create a rule that matches old API calls and rewrites to new API format.
For deprecation handling, create rules that identify deprecated patterns and suggest modern alternatives.
After each transformation:
When executing DDD through moai:2-run in DDD mode:
Step 1 - Initial Assessment:
Step 2 - Analyze Phase Execution:
Step 3 - Preserve Phase Execution:
Step 4 - Improve Phase Execution:
Step 5 - Validation and Completion:
For complex refactoring requiring multiple iterations:
Behavior Preservation (Required):
Structure Improvement (Goals):
Apply TRUST 5 framework with DDD focus:
DDD relies heavily on AST-grep for:
Load moai-tool-ast-grep for detailed pattern syntax and rule creation.
DDD complements testing workflow:
DDD outputs feed into quality assessment:
Tests Fail After Transformation:
Characterization Tests Are Flaky:
Performance Degradation:
When DDD session encounters issues:
Version: 1.0.0 Status: Active Last Updated: 2026-01-16
| Rationalization | Reality |
|---|---|
| "This legacy code is obviously broken, I will just rewrite it" | The broken-looking code may encode production behavior callers depend on. ANALYZE first, rewrite with tests. |
| "Characterization tests are just busywork" | They are the safety net that lets you refactor without fear. Without them, refactor equals rewrite. |
| "I understand this module well enough to skip ANALYZE" | Understanding is not verification. ANALYZE forces you to name assumptions and confront callers. |
| "This function has no tests because it has no behavior worth testing" | If it has callers, it has contract. The contract is the thing to characterize. |
| "I will preserve behavior by being careful" | Carefulness is not a mechanism. Tests are the only mechanism that catches regressions. |
| "This refactor is too small to need DDD" | Small refactors cause silent regressions exactly because people skip the safety net. |
Chesterton's Fence: Do not remove or replace code whose purpose you cannot explain. ANALYZE phase exists specifically to uncover the reasoning behind code that looks wrong.