team-orchestrator

Files (1)

• SKILL.md

SKILL.md (first lines)

## Overview

team-orchestrator 스킬은 `/orchestrate` 커맨드의 핵심 엔진으로,
Agent Teams를 구성하고 작업을 분배하며 결과를 집계하는 오케스트레이션 로직을 정의한다.

## 전제조건

Agent Teams 전제조건(환경변수 설정)은 `reference/agents-teams-ref.md` 참조.

---

## Team Composition

### 팀 크기 결정

최대 팀원 수: Lead 1 + Teammates 3 (총 4명)

| 작업 규모 | 팀원 수 | 구성 |
|-----------|---------|------|
| 소 (파일 1-3개) | 1-2명 | 구현1 (+테스트1) |
| 중 (파일 4-8개) | 2-3명 | 구현1-2 + 테스트1 |
| 대 (파일 9개 이상) | 3명 | 구현2 + 테스트1 또는 패턴별 분리 |

### 역할 템플릿

**풀스택 기능 구현:**
| 역할 | subagent_type | 담당 |
|------|--------------|------|
| Frontend Dev | general-purpose | UI 구현, 컴포넌트 |
| Backend Dev | general-purpose | API, DB, 로직 |
| QA Engineer | general-purpose | 테스트, E2E |

**리팩토링:**
| 역할 | subagent_type | 담당 |
|------|--------------|------|
| Analyzer | Explore | 코드 분석/계획 |
| Implementer | general-purpose | 리팩토링 실행 |
| Verifier | general-purpose | 테스트/검증 |

**버그 조사:**
| 역할 | subagent_type | 담당 |
|------|--------------|------|
| Investigator 1 | Explore | 코드 분석 |
| Investigator 2 | Explore | 로그/환경 분석 |
| Fixer | general-purpose | 수정 구현 |

---

## Task Distribution

### 파일 소유권 분리 (CRITICAL)

같은 파일을 2명이 편집하면 덮어쓰기가 발생한다.
반드시 팀원별로 파일 소유권을 분리한다.

```
파일 소유권 결정 로직:
  1. 변경 예상 파일 목록 생성
  2. 파일별 모듈/도메인 분류
  3. 도메인 단위로 팀원 배정
  4. 공유 파일(types, config)은 한 팀원에게 독점 배정
```

### 작업 분해 규칙

팀원당 5-6개 Task를 배정한다.

| Task 크기 | 판단 기준 | 설명 |
|-----------|----------|------|
| 너무 작음 | 조율 오버헤드 > 이점 | 하나로 합치기 |
| 적절함 | 명확한 결과물이 있는 자체 포함 단위 | 함수, 테스트 파일, 검토 |
| 너무 큼 | 체크인 없이 오래 작동 | 더 작게 분할 |

### 의존성 관리

```
의존성 그래프 생성:
  Task A (types 정의) → Task B (API 구현) → Task C (UI 연동)

  선행 Task가 완료되어야 후행 Task 시작 가능
  순환 의존성 감지 시 경고
```

TaskCreate에서 `addBlockedBy` 필드로 의존성을 설정한다.

---

## Context Inheritance (CRITICAL)

팀원은 프로젝트 컨텍스트(CLAUDE.md, MCP servers, skills)를 자동 로드하지만,
**리더의 대화 기록은 상속하지 않는다.**

따라서 팀원 생성 프롬프트에 반드시 다음을 포함해야 한다:
- 작업 목적과 배경
- 관련 파일 경로
- 기대하는 결과물
- 주의사항/제약사항

```
# 좋은 예시
"Review the authentication module at src/auth/ for security vulnerabilities.
Focus on token handling, session management, and input validation.
The app uses JWT tokens stored in httpOnly cookies."

# 나쁜 예시
"보안 검토 해줘"  ← 팀원은 리더가 논의한 맥락을 모름
```

CLAUDE.md는 정상 작동: 팀원들은 작업 디렉토리에서 CLAUDE.md를 자동으로 읽는다.

---

## Plan Approval Mode

위험하거나 복잡한 작업에서 팀원이 구현 전 계획 승인을 받도록 할 수 있다:

```
Spawn an architect teammate to refactor the auth module.
Require plan approval before they make any changes.

From sangrokjung/claude-forge, MIT.

More from sangrokjung/claude-forge