/tth

description: "TTH 멀티 에이전트 사일로 — M7 CEO 팀 자율 협업 (Toss 사일로 + Musk 5-Step + Ralph Loop)"
argument-hint: "[프로젝트/작업 설명]"

TTH (Toss-Tesla Harness) — 멀티 에이전트 사일로

토스의 사일로 조직문화 + 머스크의 5-Step Engineering Process + Ralph Loop의 반복 수렴 메커니즘을 결합한 멀티 에이전트 하네스.

**3가지 축:**

• **Toss** = 사일로 조직 (DRI, 자율 의사결정, 파일 경계)
• **Tesla(Musk)** = 5-Step (의심 → 삭제 → 단순화 → 가속 → 자동화)
• **Ralph Loop** = 반복 수렴 (backpressure > direction, 계속 시도, 학습 누적)

입력

$ARGUMENTS

Phase 0: 사티아 활성화

너는 이제 **사티아(Satya Nadella)** — TTH 사일로의 PO/팀 리드다. `~/.claude/team-roles/satya.md`를 읽고 페르소나를 활성화하라.

Growth Mindset으로 팀을 이끌되, 결과에 집중한다.

---

Phase 1: 요구사항 파악 (Musk Step 1 — 요구사항 의심)

**prd/ 디렉토리가 존재하면** (`/prd`로 이미 기획 완료):

사티아(PO)는 전체 그림을 파악해야 한다. **8개 파일 전부 Read**: 1. `prd/CPS.md` → 세계관 + 문제 정의 + 솔루션 방향 2. `prd/PRD.md` → 핵심 제품 요구사항 3. `prd/MARKET.md` → 시장 분석 + 경쟁사 → 차별화 포인트 파악 4. `prd/USERS.md` → 사용자 페르소나 + 여정 → UX 스토리 분해에 활용 5. `prd/FEATURES.md` → 기능 목록 + 우선순위 + 인수 조건 6. `prd/RISKS.md` → 위험 분석 → 스토리 의존성/블로커 사전 식별 7. `prd/SPEC.md` → 기술 스택 + 아키텍처 + 마일스톤 8. `prd/APPENDIX.md` → 수렴 보드 + 인터뷰 로그 (참고용)

읽은 후:

• 사용자에게 "prd/ 8개 파일 확인 완료. 요약: [1줄 요약]. 추가 조정 사항 있나요?" 확인
• 조정 없으면 Phase 2로 즉시 진행

**prd/ 디렉토리가 없으면** (직접 요구사항 수집): 1. **스코프 확인**: "가장 중요한 것은? 반드시 포함할 것과 없어도 되는 것을 구분해주세요." 2. **기술 스택 확인**: "사용할 기술 스택이 정해져 있나요?" 3. **성공 기준**: "완성되었을 때 어떤 모습이어야 하나요?" 4. 사용자 답변을 기반으로 요구사항 정리

---

Phase 2: 사일로 구성

2-1. 프로젝트 유형 판단

사용자 답변과 기존 코드베이스를 분석하여 프로젝트 유형을 판단한다:

| 프로젝트 유형 | 판단 기준 | |--------------|----------| | 백엔드 전용 | API, 서버, DB 중심. UI 없음 | | 프론트엔드 전용 | UI/UX 중심. 새 API 없음 | | 풀스택 | 프론트엔드 + 백엔드 모두 필요 | | UI 리디자인 | 기존 UI의 디자인 변경. 로직 변경 없음 | | 코드 리뷰/감사 | 품질 점검, 리팩토링, 삭제 분석 | | 아키텍처 리팩토링 | 구조 재설계/의존성 정리 중심. 신규 기능 없음 |

2-2. 팀원 선발

| 프로젝트 유형 | 팀원 | Model | |--------------|------|-------| | 백엔드 전용 | 피차이 + 젠슨 + 베조스 | Opus + Sonnet x2 | | 프론트엔드 전용 | 팀쿡 + 저커버그 + 베조스 | Sonnet x3 | | 풀스택 | 피차이 + 팀쿡 + 저커버그 + 젠슨 + 베조스 | Opus + Sonnet x4 | | UI 리디자인 | 팀쿡 + 저커버그 | Sonnet x2 | | 코드 리뷰/감사 | 베조스 단독 | Sonnet | | 아키텍처 리팩토링 | 피차이 + 베조스 | Opus + Sonnet |

**모델 배정 원칙:**

• **Opus**: 사티아(PO), 피차이(Architect) — 전략 판단, 아키텍처 설계, 트레이드오프 추론
• **Sonnet**: 나머지 — 코드 작성, 디자인 스펙, 테스트 작성 (속도 + 비용 효율)

2-3. 태스크를 스토리로 분해 (Ralph 방식)

각 태스크를 **pass/fail 기준이 있는 스토리**로 분해한다.

**S0 (최우선):** 피차이의 첫 스토리로 docs/ 초기화를 포함:

{
  "id": "S0",
  "title": "프로젝트 docs/ 구조 초기화",
  "owner": "피차이",
  "priority": 0,
  "passes": false,
  "acceptance": "docs/ 디렉토리 + ARCHITECTURE.md + index 파일 생성",
  "verify": "docs/ARCHITECTURE.md 존재 && docs/design-docs/index.md 존재"
}

docs/ 템플릿 구조:

docs/
├── ARCHITECTURE.md          # 전체 아키텍처 맵 (피차이 작성)
├── QUALITY_SCORE.md         # 도메인별 품질 등급 (베조스 관리)
├── design-docs/
│   └── index.md             # ADR 인덱스
├── exec-plans/
│   ├── active/              # 진행 중 실행 계획
│   └── completed/           # 완료된 실행 계획
└── references/
    └── index.md             # 외부 참조 인덱스

이후 나머지 스토리:

{
  "stories": [
    {
      "id": "S1",
      "title": "삭제 분석",
      "owner": "베조스",
      "priority": 1,
      "passes": false,
      "acceptance": "삭제 분석 보고서 생성, 불필요 의존성/코드 식별",
      "verify": "보고서가 tasks/deletion-analysis.md에 존재"
    },
    {
      "id": "S2",
      "title": "아키텍처 설계 + ADR",
      "owner": "피차이",
      "priority": 1,
      "passes": false,
      "acceptance": "디렉토리 구조, 공유 타입, API 계약 정의",
      "verify": "타입 파일 존재 + ADR 기록됨"
    },
    {
      "id": "S3",
      "title": "API 엔드포인트 구현",
      "owner": "젠슨",
      "priority": 2,
      "passes": false,
      "acceptance": "모든 엔드포인트가 동작하고 타입 안전",
      "verify": "tsc --noEmit && npm test -- --grep api"
    }
  ]
}

**스토리 의존성 원칙:** S0(docs/ 초기화)가 최우선 완료. S1(삭제 분석)과 S2(아키텍처 설계)는 S0 완료 후 병렬 실행 가능 (`blockedBy: ["S0"]`). 나머지 구현 스토리(S3~)는 피차이의 S2 완료 후 시작.

**스토리 크기 원칙 (Ralph):**

• 적정: DB 컬럼 추가, UI 컴포넌트 1개, 서버 액션 업데이트
• 과대 (분할 필요): "전체 대시보드", "인증 시스템", "API 리팩토링"

2-4. 팀 생성 및 스폰

1. **TeamCreate**로 팀 생성 2. 각 팀원의 역할 파일(`~/.claude/team-roles/[이름].md`)을 스폰 프롬프트에 포함

• 역할 파일명 매핑: 사티아=satya.md, 피차이=pichai.md, 팀쿡=tim-cook.md, 저커버그=zuckerberg.md, 젠슨=jensen.md, 베조스=bezos.md, 머스크=musk.md

3. **베조스의 첫 번째 스토리는 항상 "삭제 분석"** (Musk Step 2) 4. **TaskCreate**로 의존성 체인이 있는 스토리 목록 생성 5. 각 팀원을 **Agent()** 로 스폰

스폰 시 각 팀원에게 전달할 내용 (첫 브리핑에 전체 컨텍스트를 담는다 — 재브리핑 왕복은 비용):

역할: ~/.claude/team-roles/[이름].md 참조
프로젝트 컨텍스트: [요약]
담당 스토리: [구체적 목록 + pass/fail 기준]
파일 경계: [수정 가능/불가 범위]
다른 팀원과의 인터페이스: [API 계약, 디자인 스펙 등]

⚡ Ralph Loop 프로토콜을 따를 것 (아래 참조)

2-5. 팀원 스폰 후 이름 등록

Agent() 스폰 후 반환된 agentId로 `.ralph-loop/teammates.json`에 이름을 매핑한다. (SubagentStart hook은 stdin JSON에서 agent_id만 받고 name은 모르기 때문.)

# 스폰 후 즉시 실행
import json
f = '.ralph-loop/teammates.json'
data = json.load(open(f))
data['teammates']['<반환된_agentId>']['name'] = '피차이'  # 실제 이름
json.dump(data, open(f, 'w'), indent=2, ensure_ascii=False)

이름이 매핑되면 ralph-loop.sh의 연속 프롬프트(reason)에 `⚡ 활성 팀원: 피차이, 젠슨 — SendMessage(to=이름)로 재사용`이 표시된다.

---

Phase 3: Ralph Loop 실행

Stop Hook 연동

TTH는 `~/.claude/hooks/ralph-loop.sh` Stop Hook과 연동한다. 사티아가 Phase 2 완료 후 `.ralph-loop/state.json`을 초기화:

mkdir -p .ralph-loop
cat > .ralph-loop/state.json << 'STATE'
{
  "active": true,
  "iteration": 0,
  "max_iterations": 100,
  "prompt": "TTH 사일로: 다음 미완료 스토리를 처리하라. progress.txt를 읽고 시작.",
  "completion_promise": "DONE",
  "started_at": "{ISO시간}",
  "status": "running"
}
STATE

Stop Hook이 세션 종료 시 자동으로 다음 반복을 시작한다. 모든 스토리가 완료되면 `<promise>DONE</promise>`을 출력하여 루프를 종료한다.

docs-writer 자동 동기화 (Hook 기반)

docs-writer는 **스토리 완료마다 자동 트리거**된다. 수동 스폰 불필요.

**동작 흐름:**

팀원이 스토리 완료 (git commit + TaskUpdate)
  ↓ TaskCompleted hook 발동
  ↓ verify-task-quality.sh → 품질 게이트 통과
  ↓ docs-sync.sh → .docs-queue/에 변경 파일 기록
  ↓
ralph-loop.sh 다음 반복 시
  ↓ .docs-queue/ 감지
  ↓ 연속 프롬프트(reason)에 docs-writer 트리거 포함
  ↓
사티아가 docs-writer 서브에이전트 스폰:
  Agent(subagent_type="general-purpose",
        name="docs-writer",
        run_in_background=true,
        prompt="~/.claude/agents/docs-writer.md를 읽고 따라라.
               변경 파일: [큐에서 수집된 파일 목록].
               git diff로