Geoffrey Huntley's AI autonomous development methodology + critical absorption of Superpowers.
What was absorbed (from Superpowers)
- ✅ Two-stage review: spec compliance → code quality (previously: mother checked directly without review)
- ✅ Verification first: before declaring "complete", always confirm evidence of test execution (previously: trusted the worker's self-report)
- ✅ Systematic debugging: after 3 failures, reconsider the architecture (previously: infinite retries)
- ✅ Enforce YAGNI: do not implement anything not in the spec (previously: implicit)
- ✅ Red Flags list: make anti-patterns explicit
What was not absorbed (critique)
- ❌ Strict enforcement of TDD: excessive for HTML5 games/single-file tools. Our main output is single HTML games/tools — TDD actually slows things down. Apply selectively only to complex projects (Rust/Godot).
- ❌ Git Worktrees: unnecessary in the OpenClaw environment. Subagents already isolate context.
- ❌ Separately spawning a Code Review subagent: costs too much. The mother performs the two-stage review directly.
- ❌ Brainstorming 200-300 word chunks: we go from Master instruction → immediate execution. Socratic questioning is unnecessary.
- ❌ Claude Code plugin dependency: works natively with OpenClaw.
Core principles
- 1 task 1 cycle — split small to stay in the smart zone
- 3-tier agent structure — main → mother → worker
- Files are memory — state is recorded on disk
- Backpressure — quality gate via tests/lint
- 🆕 Verification first (Evidence Before Claims) — "complete" only with evidence
- 🆕 3회 룰 — same problem fails 3 times → reconsider the architecture (no more patching)
- 🆕 Enforce YAGNI — do not implement anything not in the spec. "It would be nice to have" = do not implement
Agent structure
┌─────────────────────────────────────────────┐
│ 메인 에이전트 (Main) │
│ • 사용자와 대화 │
│ • Ralph Loop 마더 spawn │
│ • 전체 조율 및 의사결정 │
└──────────────────┬──────────────────────────┘
│ spawn (label: ralph-mother)
▼
┌─────────────────────────────────────────────┐
│ 마더 에이전트 (Mother) │
│ • specs/ 폴더 생성 및 관리 │
│ • IMPLEMENTATION_PLAN.md 생성/업데이트 │
│ • 워커 서브에이전트 spawn │
│ • 🆕 2단계 리뷰 수행 (스펙 준수 → 품질) │
│ • 진행 상황 메인에게 보고 │
└──────────────────┬──────────────────────────┘
│ spawn (label: ralph-worker-N)
▼
┌─────────────────────────────────────────────┐
│ 워커 에이전트 (Worker) │
│ • 단일 태스크 구현 │
│ • 🆕 자체 검증 실행 (테스트/curl/브라우저) │
│ • 🆕 검증 증거 포함하여 보고 │
│ • 결과 마더에게 보고 │
└─────────────────────────────────────────────┘
Workflow
Main agent role
When the user requests implementation/development:
- Identify and clarify requirements
- Spawn the Ralph Loop mother subagent
- Receive mother reports and relay progress to the user
- Make decisions and adjust direction as needed
Mother agent role
With the requirements received at spawn:
Phase 1: Requirement definition
specs/
├── feature-a.md
├── feature-b.md
└── ...
- Write a spec document for each feature
- 1 topic = 1 file (must be explainable in one sentence without and)
Phase 2: Planning
# IMPLEMENTATION_PLAN.md
## TODO
- [ ] 태스크 1 (예상 2-5분)
- [ ] 태스크 2 (예상 2-5분)
## DONE
- [x] 완료된 태스크 ✅ 스펙준수 ✅ 품질
- Analyze the gap between specs vs current code
- Priority-sorted task list
- 🆕 Task size: 2-5 minute units. Split if larger.
Phase 3: Building (repeat)
1. IMPLEMENTATION_PLAN.md 읽기
2. 가장 중요한 태스크 선택
3. 워커 서브에이전트 spawn (해당 태스크 + 관련 스펙 전문 전달)
4. 워커 완료 보고 수신
5. 🆕 2단계 리뷰:
a) 스펙 준수 검증 — 워커 결과물 vs 스펙 비교
- 누락된 요구사항 있나?
- 스펙에 없는 것을 추가했나? (YAGNI 위반)
b) 품질 검증 — 코드 품질, 에러 핸들링, 엣지 케이스
6. 🆕 검증 증거 확인 — "테스트 통과" 주장에 실제 출력이 있나?
7. 리뷰 통과 → 플랜 업데이트 + 커밋
리뷰 실패 → 워커에게 수정 지시 (같은 서브에이전트)
8. 다음 태스크로 반복 또는 완료 보고
Worker agent role
Single task assigned by the Mother:
- Analyze specs and related code
- Implement
- 🆕 Run verification and collect evidence:
- If there are tests → run them and capture output
- If it's a web app → verify for real with curl/browser
- If it's a CLI → run it and capture the result
- Report the result to the Mother (success/failure + evidence)
🆕 Systematic debugging protocol
When a bug/error/unexpected behavior occurs:
Phase 1: Investigate the root cause (required before attempting a fix)
- Read the error message completely (including the stack trace)
- Check reproducibility
- Check recent changes (git diff)
- Trace the data flow
Phase 2: Form a hypothesis and test it minimally
- Single hypothesis: "X is the root cause, because Y"
- Verify the hypothesis with the minimal change
- Change only one thing at a time
Phase 3: 3회 룰
- 3 failed fixes for the same problem → stop immediately
- Likely an architecture/design problem
- Report to the Mother → the Mother escalates to the Master
- Never attempt a 4th patch
🆕 Red Flags (anti-patterns — stop immediately)
| 🚫 Red Flag | ✅ Correct behavior |
|---|---|
| "It'll probably work" | Judge by the result after running verification |
| "Just fix this one thing" (3rd time) | Re-review the architecture |
| Declaring "done" without tests | Attach verification evidence |
| Adding features not in the spec | YAGNI — implement only the spec |
| Multiple fixes at once | One at a time |
| Trusting only the worker's report | Check the evidence directly |
| "Test later" | Verify now or mark as incomplete |
Application by project scale
| Scale | TDD | 2-stage review | 3-tier structure |
|---|---|---|---|
| Single HTML game/tool | ❌ Unnecessary | ✅ The Mother does it quickly | ⚠️ Mother only (workers can be omitted) |
| Multi-file project | ⚠️ Core logic only | ✅ Required | ✅ Required |
| Rust/WASM/Godot | ✅ Required | ✅ Required | ✅ Required |
Sub-agent spawn example
Main → Mother:
label: ralph-mother
task: "[요구사항 요약] 구현. specs/ 작성 → IMPLEMENTATION_PLAN.md → 워커로 구현 → 2단계 리뷰 → 완료 시 보고"
Mother → Worker:
label: ralph-worker-1
task: "태스크: [구체적 태스크]. 스펙: [전문 텍스트]. 구현 후 검증 실행, 증거 포함 결과 보고."
Context management
- Main: Keep context minimal (focus on the user conversation)
- Mother: Track only the overall plan and progress
- Worker: Focus on a single task only (40-60% smart zone)
- 🆕 Pass full spec to worker — eliminate file reading overhead (Superpowers pattern)
Detailed guide
For complex projects, see references/workflow.md .