lev-os TDD Workflow
Write tests first, code second.
1. The TDD Cycle
🔴 RED → Write failing test
↓
🟢 GREEN → Write minimal code to pass
↓
🔵 REFACTOR → Improve code quality
↓
Repeat...
2. The Three Laws of TDD
- Write production code only to make a failing test pass
- Write only enough test to demonstrate failure
- Write only enough code to make the test pass
3. RED Phase Principles
What to Write
| Focus | Example |
|---|---|
| Behavior | "should add two numbers" |
| Edge cases | "should handle empty input" |
| Error states | "should throw for invalid data" |
RED Phase Rules
- Test must fail first
- Test name describes expected behavior
- One assertion per test (ideally)
4. GREEN Phase Principles
Minimum Code
| Principle | Meaning |
|---|---|
| YAGNI | You Aren't Gonna Need It |
| Simplest thing | Write the minimum to pass |
| No optimization | Just make it work |
GREEN Phase Rules
- Don't write unneeded code
- Don't optimize yet
- Pass the test, nothing more
5. REFACTOR Phase Principles
What to Improve
| Area | Action |
|---|---|
| Duplication | Extract common code |
| Naming | Make intent clear |
| Structure | Improve organization |
| Complexity | Simplify logic |
REFACTOR Rules
- All tests must stay green
- Small incremental changes
- Commit after each refactor
6. AAA Pattern
Every test follows:
| Step | Purpose |
|---|---|
| Arrange | Set up test data |
| Act | Execute code under test |
| Assert | Verify expected outcome |
7. When to Use TDD
| Scenario | TDD Value |
|---|---|
| New feature | High |
| Bug fix | High (write test first) |
| Complex logic | High |
| Exploratory | Low (spike, then TDD) |
| UI layout | Low |
8. Test Prioritization
| Priority | Test Type |
|---|---|
| 1 | Happy path |
| 2 | Error cases |
| 3 | Edge cases |
| 4 | Performance |
9. Anti-Patterns
| ❌ Don't | ✅ Do |
|---|---|
| Skip the RED phase | Watch test fail first |
| Write tests after | Write tests before |
| Over-engineer initial | Keep it simple |
| Multiple asserts | One behavior per test |
| Test implementation | Test behavior |
10. AI-Augmented TDD
Multi-Agent Pattern
| Agent | Role |
|---|---|
| Agent A | Write failing tests (RED) |
| Agent B | Implement to pass (GREEN) |
| Agent C | Optimize (REFACTOR) |
Remember: The test is the specification. If you can't write a test, you don't understand the requirement.
Technique Map
- Role definition - Clarifies operating scope and prevents ambiguous execution.
- Context enrichment - Captures required inputs before actions.
- Output structuring - Standardizes deliverables for consistent reuse.
- Step-by-step workflow - Reduces errors by making execution order explicit.
- Edge-case handling - Documents safe fallbacks when assumptions fail.
Technique Notes
These techniques improve reliability by making intent, inputs, outputs, and fallback paths explicit. Keep this section concise and additive so existing domain guidance remains primary.
Prompt Architect Overlay
Role Definition
You are the prompt-architect-enhanced specialist for tdd-workflow, responsible for deterministic execution of this skill's guidance while preserving existing workflow and constraints.
Input Contract
- Required: clear user intent and relevant context for this skill.
- Preferred: repository/project constraints, existing artifacts, and success criteria.
- If context is missing, ask focused questions before proceeding.
Output Contract
- Provide structured, actionable outputs aligned to this skill's existing format.
- Include assumptions and next steps when appropriate.
- Preserve compatibility with existing sections and related skills.
Edge Cases & Fallbacks
- If prerequisites are missing, provide a minimal safe path and request missing inputs.
- If scope is ambiguous, narrow to the highest-confidence sub-task.
- If a requested action conflicts with existing constraints, explain and offer compliant alternatives.