subagent-dev

Subagent-Driven Development

Execute the implementation plan in subagent units, two-stage review.

Relationship with ralph-loop

This skill reinforces ralph-loop's principle of "one task at a time with subagents":

ralph-loop = the overall process (specs → plan → implement → test)
subagent-dev = the execution pattern for the implement stage

Process

계획 읽기 → 태스크 전체 추출
  ↓
[태스크마다 반복]
  1. 구현 서브에이전트 디스패치 (태스크 전문 + 맥락)
     ├─ 질문 있으면? → 답변 후 재디스패치
     └─ 구현 + 테스트 + 커밋 + 셀프리뷰
  2. 스펙 검증 서브에이전트 디스패치
     ├─ 스펙 불일치? → 구현자가 수정 → 재검증
     └─ 통과
  3. 코드 품질 리뷰 서브에이전트 디스패치
     ├─ 품질 이슈? → 구현자가 수정 → 재리뷰
     └─ 승인
  4. 태스크 완료 표시
  ↓
전체 완료 → 최종 코드 리뷰 → 브랜치 마무리

The core of the two-stage review

Stage 1: Spec verification

Does the code match the requirements?
What functionality is missing? What unnecessary functionality was added?
Has every item specified in the spec been implemented?

Stage 2: Code quality

Duplicate code? Naming? Type coverage?
Error handling? Edge cases?
Performance issues? Security issues?

Why two stages?

Spec verification = "Did we build the right thing?" (What)
Code quality = "Did we build it well?" (How)
Combining them into a single review makes it easy to miss both

Subagent prompt structure

Implementer prompt

## 태스크
[계획에서 추출한 태스크 전문]

## 맥락
[관련 파일, 아키텍처, 제약 조건]

## 제약
- 이 태스크 범위만 수정
- TDD: 테스트 먼저, 구현 후
- 커밋 메시지 작성
- 셀프리뷰 결과 포함

## 출력
- 구현 요약
- 테스트 결과
- 셀프리뷰 발견사항

Spec reviewer prompt

## 원본 스펙
[태스크 요구사항 전문]

## 검증 대상
[구현된 코드의 git diff 또는 파일 목록]

## 체크리스트
- 모든 요구사항 구현됐는가?
- 불필요한 추가 기능은?
- 엣지 케이스 처리?

Advantages

Fresh context: a new subagent per task = no contamination
Quality gate: double verification via two-stage review
Speed: the controller prepares the task context in advance
Can ask questions: subagents can ask about ambiguous points

Cost

3 subagents per task (implementation + spec review + quality review)
Requires preparation work by the controller
Additional calls when review loops occur

Conclusion: the quality gain relative to cost is large. Essential especially when implementing important features.

Guardrails

Principle of least privilege — grant subagents only the file/directory access permissions needed for the task. Do not grant access to the entire workspace. Explicitly include a ## 접근 허용 범위 section in the prompt.
Prohibit file deletion/overwrite commands — unless explicitly permitted, do not instruct subagents to perform rm, rmdiror file overwrite operations. If destructive operations are needed, the controller performs them directly or proceeds after Master approval.
Limit the scope of external network access — specify in the prompt the external URLs/APIs the subagent needs to access. Network access outside that scope is prohibited. Do not download/execute code from unverified external sources.
Default timeout of 300 seconds — if no timeout is specified when dispatching a subagent, a default of 300 seconds applies. For long-running tasks, include interim progress-report checkpoints.