skills/peach-team-3a/SKILL.md
3-에이전트(Architect→Builder→Reviewer) 루프로 단일 기능을 설계·구현·검증하는 팀 스킬. "3a로 만들어줘", "3에이전트", "설계-구현-검토", "team-3a" 키워드로 트리거. peach-team-dev보다 가벼운 단일 기능·소규모 수정에 적합.
npx skillsauth add peachsolution/peach-harness peach-team-3aInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Architect → Builder → Reviewer → Architect 루프로 단일 기능을 완성하는 3-에이전트 팀 스킬입니다.
| 에이전트 | 역할 | 핵심 원칙 | |---------|------|----------| | Architect | 설계 계획 수립 + 최종 결정권 | BRIEF를 SendMessage로 전달 → Reviewer 판정 수용/거부 | | Builder | BRIEF 기반 코드 구현 | 범위 밖 터치 금지, 완료 후 파일 수정 금지, 자기 검토 + 검증 증거 제출 | | Reviewer | 독립 검증 + 3단계 판정 | qa-gate + 코드 리뷰 통합, 읽기전용, worktree 격리, CONDITIONAL 남용 금지 |
| | peach-team-dev | peach-team-3a | |--|-----------|--------------| | 에이전트 수 | 최대 5개 | 3개 고정 | | 적합 케이스 | 대규모 fullstack | 단일 기능, 소규모 수정 | | 판정 방식 | 통과/실패 2단계 | APPROVED / CONDITIONAL / REJECTED 3단계 | | 애매한 경우 | 무조건 재작업 | Architect가 최종 판단 |
/peach-team-3a [작업 설명]
# 옵션
# model=sonnet|opus|haiku (서브에이전트 모델 override, 기본값: sonnet)
# layer=backend|frontend|fullstack (구현 범위, 미지정 시 Architect가 판단)
cat ~/.claude/settings.json | grep -i "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS"
설정이 없거나 "1"이 아니면 즉시 중단하고 안내를 출력합니다:
⚠️ 에이전트 팀 기능이 비활성화되어 있습니다.
~/.claude/settings.json에 아래 내용을 추가한 후 Claude Code를 재시작하세요:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
작업 설명이 누락된 경우 질문합니다:
어떤 기능을 구현할까요? (예: "공지사항 목록 API 추가", "회원 상태 필드 수정")
model 옵션:
# 프로젝트 구조 파악
ls api/src/modules/ 2>/dev/null
ls front/src/modules/ 2>/dev/null
# test-data 가이드코드 존재 확인
ls api/src/modules/test-data/ 2>/dev/null
ls front/src/modules/test-data/ 2>/dev/null
# DAO 라이브러리 감지
head -5 api/src/modules/test-data/dao/test-data.dao.ts 2>/dev/null
# from 'bunqldb' → 재할당 방식
# from 'sql-template-strings' → append 방식
# Controller 프레임워크 감지
head -3 api/src/modules/test-data/controller/test-data.controller.ts 2>/dev/null
# _common 구성 감지
ls api/src/modules/_common/ 2>/dev/null
ls api/src/modules/_common/constants/ 2>/dev/null
# 스킬 references 경로 감지
BACKEND_REFS=$(find ~/.claude ~/.agents -path "*/peach-gen-backend/references" -type d 2>/dev/null | head -1)
UI_REFS=$(find ~/.claude ~/.agents -path "*/peach-gen-ui/references" -type d 2>/dev/null | head -1)
Architect
│
│ SendMessage: BRIEF 전달
▼
Builder ──────────────────────────────────┐
│ │ REJECTED → Ralph Loop
│ SendMessage: 구현 완료 + 자기 검토 │
▼ │
Reviewer (worktree 격리) │
│ │
├── APPROVED ──→ SendMessage → Architect│
├── CONDITIONAL → SendMessage → Architect│
└── REJECTED ──→ SendMessage → Builder ─┘
TeamCreate: team_name="3a-[작업축약명]-team"
TaskCreate:
1. "설계 계획 수립" (owner: architect)
2. "코드 구현" (blockedBy: Task1, owner: builder)
3. "검증 및 판정" (blockedBy: Task2, owner: reviewer)
각 역할의 전체 정의는 references/에 있습니다.
서브에이전트 생성 시 해당 파일의 전체 내용을 프롬프트에 포함합니다.
model= 옵션이 지정된 경우, model 파라미터로 전달하여 frontmatter 기본값을 override합니다.
| 역할 | 참조 파일 | 실행 환경 | |------|----------|----------| | architect | references/architect-agent.md | 일반 | | builder | references/builder-agent.md | 일반 | | reviewer | references/reviewer-agent.md | worktree 격리 |
오케스트레이터가 Architect 에이전트 생성 시 프롬프트에 포함할 컨텍스트:
[사용자 입력 그대로]api/src/modules/test-data/, front/src/modules/test-data/${BACKEND_REFS}, ${UI_REFS}references/architect-agent.md 참조Architect가 BRIEF를 SendMessage로 전달한 후 Builder를 스핀업합니다. 오케스트레이터는 Builder 에이전트 생성 시 아래를 포함합니다:
references/builder-agent.md 참조Builder가 구현 완료를 SendMessage로 보고한 후 Reviewer를 스핀업합니다. 오케스트레이터는 Reviewer 에이전트 생성 시 아래를 포함합니다:
references/reviewer-agent.md 참조Reviewer가 판정 결과를 SendMessage로 오케스트레이터에게 보고하면, 오케스트레이터가 처리합니다.
Reviewer → SendMessage → 오케스트레이터: "APPROVED" + 검증 결과
오케스트레이터 → SendMessage → Architect: 완료 보고
오케스트레이터 → /peach-qa-gate 자동 실행 (최종 증거 수집)
오케스트레이터 → 팀 정리
Reviewer → SendMessage → 오케스트레이터: "CONDITIONAL" + 조건 내용
오케스트레이터 → SendMessage → Architect: 조건 전달 + 판단 요청
Architect → SendMessage → 오케스트레이터:
"조건 수용" → 오케스트레이터 → SendMessage → Builder: 수정 지시 → Reviewer 재검증
"조건 무시" → 판단 근거 기록 후 APPROVED로 처리
규칙:
Reviewer → SendMessage → 오케스트레이터: "REJECTED" + 수정 필요 항목
오케스트레이터 → Ralph Loop 단계 판단
오케스트레이터 → SendMessage → Builder: 피드백 + 수정 지시
Builder 수정 완료 → SendMessage → 오케스트레이터 → Reviewer 재검증
REJECTED 시 단순 재시도가 아닌 구조화된 피드백 주입으로 반복합니다.
| 반복 횟수 | 단계 | 행동 |
|----------|------|------|
| 1~3회 | 자율 수정 | Reviewer 피드백만으로 Builder 수정 |
| 4회 | 가이드 재참조 | test-data 기준골격 전체 재읽기 후 수정 |
| 5~7회 | Codex 진단 | codex:codex-rescue로 실패 원인 독립 진단 + 가이드 재참조 |
| 8~10회 | 최소 수정 | Must Follow 항목만 집중, 나머지 보류 |
| 11+ | 중단 | 사용자 에스컬레이션 |
CODEX_AVAILABLE=true 시에만 투입 (settings.json에서 "codex@openai-codex": true 감지)codex:codex-rescue 투입 (3A는 소규모 루프 특성상 조기 탈출 유도)CODEX_AVAILABLE=false: Codex 없이 기존 Ralph Loop 계속 (가이드 재참조)## Ralph Loop 에스컬레이션
- 작업: [작업 설명]
- 반복: N/10회
- 단계: [현재 단계]
- 미해결: [위반 항목]
- 권장: [수동 개입 사항]
peach-team-dev 계열과 동일하게 SendMessage + TaskUpdate로 통신합니다.
Architect → 오케스트레이터 (SendMessage): BRIEF 내용
오케스트레이터 → Builder 프롬프트에 BRIEF 포함하여 스핀업
Builder → 오케스트레이터 (SendMessage): 구현 완료 + 자기 검토 + 파일 목록
오케스트레이터 → Reviewer 프롬프트에 BRIEF + 구현 보고 포함하여 스핀업
Reviewer → 오케스트레이터 (SendMessage): 판정 + 검증 결과
각 단계 완료 시 TaskUpdate로 상태를 갱신합니다:
completedcompletedcompleted / REJECTED → Builder 재작업오케스트레이터가 /peach-qa-gate를 자동 실행 → 증거 보고서 생성
SendMessage(shutdown_request) → 모든 팀원에게
TeamDelete → 팀 정리
✅ 3A 팀 작업 완료
작업: [작업 설명]
반복: [총 Reviewer 검증 횟수]회
결과:
✅ Architect: BRIEF 수립 완료
✅ Builder: 구현 완료
✅ Reviewer: APPROVED (또는 CONDITIONAL → Architect 수용)
✅ qa-gate: 증거 보고서 생성 + 완료 가능 판정
생성/수정된 파일:
[파일 목록]
다음 단계:
[실행 방법 안내]
# 단일 API 추가
/peach-team-3a 공지사항 목록 조회 API 추가
# 기존 기능 수정
/peach-team-3a 회원 상태 필드에 '정지' 값 추가 layer=backend
# UI 컴포넌트 수정
/peach-team-3a 상품 목록 페이지에 엑셀 다운로드 버튼 추가 layer=frontend
# opus 모델로 실행
/peach-team-3a 결제 상태 전이 로직 구현 model=opus
tools
기능 브랜치용 git worktree 라이프사이클을 관리하는 스킬. 생성(create) / 상태 진단(status) / PR 준비(finish) / 병합 후 정리(closeout) / 정리(cleanup) 모드를 자동 판단한다. "워크트리 만들어줘", "worktree 생성", "워크트리 정리", "워크트리 삭제", "기능 브랜치 워크트리", "워크트리 상태", "마무리", "PR 생성", "PR 머지 후 정리", "feature worktree" 키워드로 트리거. PR 전 base 비교와 안전한 동기화 필요 여부를 진단한다. 개발 완료 후 finish/closeout 모드에서는 한 번의 통합 체크포인트로 push/PR/merge/cleanup을 안전하게 진행한다.
development
Karpathy LLM Wiki 패턴 기반 지식 관리 스킬. 코드 프로젝트와 옵시디언 노트 모두 지원. Raw Source(코드·문서)를 읽어 docs/wiki/에 누적형 지식베이스를 구축·유지한다. "wiki", "위키", "ingest", "인제스트", "wiki 점검", "wiki lint", "wiki 업데이트", "문서화해줘", "아키텍처 설명해줘", "어떻게 동작해?" 키워드로 트리거. qmd 검색 도구와 연동하여 토큰 절약 + 높은 검색 정확도 제공.
development
Backend 없이 Mock 데이터 기반 프로토타입 UI를 생성·검증하는 기획 구체화 산출물 스킬. Vue 3 + TypeScript + NuxtUI v4. 별도 ui-proto 저장소(예: peach-ui-proto-backoffice)의 src/modules-task 폴더에 태스크별 화면을 누적한다. "프로토타입 만들어줘", "Mock 화면", "proto UI", "기획 화면 빠르게", "ui-proto 작업", "기획자 검토용 화면", "태스크 폴더 추가", "팀 ui-proto" 키워드로 트리거. 기획자가 직접 작업하는 화면 기획 + 현업 검토용 산출물 스킬이며, 개발용 Spec은 후속 peach-gen-spec이 생성한다. 실제 API 연동이 필요하면 peach-gen-ui를 사용한다.
development
Spec 필수 + ui-proto 보조 기준으로 E2E 환경 세팅 + 단위 시나리오 자동 분할 + 통합 suite 생성 + 실행 + 부합 검증을 한 번에 처리하는 통합 팀 스킬. "e2e 검증해줘", "통합 검증", "전체 흐름 테스트", "팀 e2e", "스펙대로 동작하는지 확인", "ui-proto와 다른지 확인", "최종 검증", "릴리스 전 검증" 키워드로 트리거. peach-e2e-setup + peach-e2e-scenario + peach-e2e-suite 3개 스킬의 패턴을 공유하고, 검증 기준은 본 프로젝트 Spec을 필수 기준으로 삼고, ui-proto는 화면/흐름 보조 기준으로 사용한다. peach-team-dev와 함께 하나의 개발-검증 납품 흐름을 이루되, 구현 컨텍스트와 검증 컨텍스트는 분리한다. 팀 실행 방식은 E2E 범위와 런타임 도구 가용성을 분석해 single-agent / role-queue / agent-team 중 선택한다. 단순 코드 동작 검증을 넘어, 기획 의도와 부합하는지 자동 검증하는 게 핵심 차별점.