メニュー
Test-Driven Development workflow specialist using RED-GREEN-REFACTOR cycle for test-first software development. Use when developing new features from scratch or when behavior specification drives implementation.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/modu-ai/moai-adk --skill moai-workflow-tddコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Harness learning subsystem coordinator. Produces Tier 4 auto-update proposal payloads consumed by the orchestrator (which surfaces them via AskUserQuestion) and orchestrates Apply/Rollback flows. Triggers when harness learning proposals are pending or learning lifecycle management is needed.
DEPRECATED — legacy 7-Phase meta-harness. Redirects to the v4 harness Builder (/moai:harness <natural-language request>) which replaces the static 7-Phase workflow with an orchestrator-direct 4-phase Builder (ANALYZE / PLAN / GENERATE / ACTIVATE) + a manifest-driven dynamic-workflow Runner. Retained as the redirect source for backward-compat invocation paths; the 7-Phase body below is preserved as historical reference, NOT for new harness creation.
MoAI unified orchestrator for autonomous development. Routes natural language or subcommands (plan, run, sync, project, fix, loop, mx, feedback, review, clean, codemaps, gate, e2e, harness, goal, todo) to specialized agents.
SOC 職業分類に基づく
SKILL.md を表示中
| name | moai-workflow-tdd |
| description | Test-Driven Development workflow specialist using RED-GREEN-REFACTOR cycle for test-first software development. Use when developing new features from scratch or when behavior specification drives implementation. |
| when_to_use | Use for Test-Driven Development: the RED-GREEN-REFACTOR cycle for test-first software development, new-feature implementation from scratch, and behavior-specification-driven implementation. |
| license | Apache-2.0 |
| compatibility | Designed for Claude Code |
| allowed-tools | Read, Write, Edit, Bash(pytest:*), Bash(ruff:*), Bash(npm:*), Bash(npx:*), Bash(node:*), Bash(jest:*), Bash(vitest:*), Bash(go:*), Bash(cargo:*), Bash(mix:*), Bash(uv:*), Bash(bundle:*), Bash(php:*), Bash(phpunit:*), Grep, Glob |
| user-invocable | false |
| metadata | {"version":"1.0.0","category":"workflow","status":"active","updated":"2026-02-03","modularized":"true","tags":"workflow, tdd, test-driven, red-green-refactor, test-first","author":"MoAI-ADK Team","related-skills":"moai-workflow-ddd, moai-workflow-testing, moai-foundation-quality"} |
| progressive_disclosure | {"enabled":true,"level1_tokens":100,"level2_tokens":5000} |
[NOTE] This workflow is selected based on .moai/config/sections/quality.yaml:
constitution:
development_mode: tdd # or ddd
When to use this workflow:
development_mode: tdd → Use TDD (this workflow, default)development_mode: ddd → Use DDD instead (moai-workflow-ddd)Key distinction:
Test-Driven Development provides a disciplined approach for creating new functionality where tests define the expected behavior before implementation.
Core Cycle - RED-GREEN-REFACTOR:
When to Use TDD:
When NOT to Use TDD:
TDD Approach:
DDD Approach:
The golden rule of TDD is that tests must be written before implementation code:
The RED phase focuses on defining the desired behavior through a failing test.
Before writing any implementation code:
Follow the Arrange-Act-Assert pattern:
The test must fail initially:
The GREEN phase focuses on writing minimal code to satisfy the test.
Write only enough code to make the test pass:
Run the test to confirm it passes:
The REFACTOR phase focuses on improving code quality while maintaining behavior.
With passing tests as a safety net:
After each refactoring step:
When executing TDD through manager-develop:
Step 1 - Understand Requirements:
Step 2 - RED Phase:
Step 3 - GREEN Phase:
Step 4 - REFACTOR Phase:
Step 5 - Repeat:
For features requiring multiple test cases:
Test Coverage (Required):
Code Quality (Goals):
Apply TRUST 5 framework with TDD focus:
TDD and DDD are complementary:
TDD integrates with testing workflow:
TDD outputs feed into quality assessment:
Test is Too Complex:
Implementation Grows Too Fast:
Refactoring Breaks Tests:
When TDD discipline breaks down:
Version: 1.0.0 Status: Active
| Rationalization | Reality |
|---|---|
| "I'll add tests after the implementation works" | Post-hoc tests verify what the code does, not what it should do. They miss the bugs RED phase catches. |
| "The existing tests cover this case" | Existing tests verify old behavior. New behavior needs its own failing test first. |
| "This function is too simple to test" | Simple functions accumulate complexity. The test documents expected behavior before drift. |
| "I tested it manually in the terminal" | Manual checks do not persist. Tomorrow's change breaks the contract with no signal. |
| "The test requires complex mocking" | If the test is hard to write, the code is hard to reason about. Refactor the design first. |
| "Tests slow me down" | Test-first surfaces design problems early, when they are cheapest to fix. |
| "I'll skip REFACTOR this cycle to keep moving" | Skipped refactors compound. The next cycle starts from a worse baseline. |
DAMP over DRY: In test code, prefer Descriptive And Meaningful Phrases over Don't Repeat Yourself. Duplication inside a test that makes the intent obvious is better than an abstraction that hides it.
Beyonce Rule: If you liked it, you should have put a test on it. Any behavior CI does not verify will eventually break without warning.
skip, xit, or disabled tests were added in this change[ZONE:Evolvable] [HARD] The Red Flags and Verification checklists above sit in advisory (evolvable) blocks and are consumed by no completion gate. This section promotes them into two enforced invariants that make test-first falsifiable in the completion matrix.
These two invariants close the falsifiability gap: before them, a fully-passing self-verification matrix was producible with NO RED evidence, so test-first could not be distinguished from test-after by the completion report. After them, the matrix requires the verbatim pre-GREEN RED output, so a run that skipped RED has no such output to supply and the matrix is structurally incomplete.