Team Assemble

Team Assemble

작업을 분석하여 전문가 팀을 동적으로 구성하고 TeamCreate 기반으로 즉시 실행하는 스킬.

When to Use

• 독립적인 하위 작업 2개 이상으로 분해 가능한 복잡한 태스크
• 리서치 + 구현 + 검증처럼 역할 분리가 명확한 작업
• 병렬 실행으로 시간을 절약할 수 있는 작업

사용하지 말 것: 단일 파일 수정, 간단한 질문, 순차적으로만 가능한 작업

Workflow

digraph team_assemble {
  rankdir=TB;
  "사용자 입력" [shape=doublecircle];
  "Phase 1:\n작업 분석 & 팀 설계" [shape=box];
  "사용자 승인?" [shape=diamond];
  "Phase 2:\nTeamCreate & TaskCreate" [shape=box];
  "Phase 3:\nTeammate 실행" [shape=box];
  "Phase 4:\n결과 종합 & 정리" [shape=box];
  "완료" [shape=doublecircle];

  "사용자 입력" -> "Phase 1:\n작업 분석 & 팀 설계";
  "Phase 1:\n작업 분석 & 팀 설계" -> "사용자 승인?";
  "사용자 승인?" -> "Phase 1:\n작업 분석 & 팀 설계" [label="수정"];
  "사용자 승인?" -> "Phase 2:\nTeamCreate & TaskCreate" [label="승인"];
  "Phase 2:\nTeamCreate & TaskCreate" -> "Phase 3:\nTeammate 실행";
  "Phase 3:\nTeammate 실행" -> "Phase 4:\n결과 종합 & 정리";
  "Phase 4:\n결과 종합 & 정리" -> "완료";
}

---

Phase 1: 작업 분석 & 팀 설계

작업을 분석하여 다음을 결정:

1. 역할 분해 — 독립적인 하위 작업으로 분해하고 전문가 역할 부여 2. 모델 선택 — 역할별 최적 모델 배정 3. 의존성 그래프 — 선행 관계 결정

역할-모델 매핑

경계 역할 판단: "새로운 판단을 내려야 하는가?" → opus. "주어진 기준대로 실행하는가?" → sonnet.

팀 구성 제안

AskUserQuestion으로 반드시 승인을 받은 후 진행:

팀 구성 제안: {team-name}

| # | 역할 | 모델 | 담당 작업 | 의존성 |
|---|------|------|----------|--------|
| 1 | role-name | opus | 작업 설명 | - |
| 2 | role-name | sonnet | 작업 설명 | #1 |

Options: "좋아요, 실행해주세요" / "역할 수정이 필요해요"

"역할 수정" 선택 시 구체적으로 뭘 바꿀지 질문. 2회 이상 수정 요청 시 자유 텍스트 입력으로 전환.

---

Phase 2: 팀 생성 & 태스크 분배

승인 후 순서대로 실행:

TeamCreate(team_name: "{keyword}-team", description: "작업 설명")

team_name 규칙: 작업 핵심 키워드 + -team (예: migration-team, research-team)

각 역할별 TaskCreate 호출 후 TaskUpdate로 blockedBy 의존성 설정:

TaskCreate(subject: "#1 {역할}: {작업 요약}", description: "상세 설명", activeForm: "{작업} 진행 중")
TaskUpdate(taskId: "2", addBlockedBy: ["1"])

---

Phase 3: Teammate 실행

핵심 메커니즘: Task 도구는 foreground(기본)에서 blocking — teammate가 끝날 때까지 대기하고 결과 텍스트를 반환. 이 반환값이 teammate의 작업 결과.

병렬 실행

blockedBy가 없는 태스크들을 단일 메시지에서 동시에 Task 호출:

Task(name: "analyst", team_name: "...", subagent_type: "general-purpose", model: "opus", prompt: "...", mode: "bypassPermissions")
Task(name: "collector", team_name: "...", subagent_type: "general-purpose", model: "sonnet", prompt: "...", mode: "bypassPermissions")
// 두 Task 완료 후 각각의 결과 텍스트 수신

순차 실행 (의존성)

선행 Task의 반환값을 다음 teammate 프롬프트에 삽입:

Task(name: "writer", prompt: "선행 작업 결과:\n{result_1}\n\n이 결과를 바탕으로...")

Teammate 프롬프트 필수 요소

1. 맥락 — 전체 프로젝트와 이 작업의 관계 2. 구체적 목표 — 정확히 무엇을 달성해야 하는지 3. 제약조건 — 하지 말아야 할 것, 변경 범위 제한 4. 출력 형식 — 결과물 형태 (텍스트/파일/테이블) 5. 팀 정보 — team_name, task ID → TaskUpdate 완료 표시 지시

상세 프롬프트 템플릿은 `references/prompt-templates.md` 참조.

---

Phase 4: 결과 종합 & 정리

결과 수집

모든 teammate 결과를 종합하여 사용자에게 보고:

## 팀 실행 결과: {team-name}
### 1. {역할}: {작업}  →  {결과 요약}
### 최종 산출물
- {파일 경로 또는 결과물 목록}

팀 정리

foreground Task 완료 후 teammate는 idle 상태. 정리 순서:

SendMessage(type: "shutdown_request", recipient: "{name}", content: "작업 완료")
TeamDelete()  // 모든 teammate 종료 확인 후

shutdown_request에 응답 없으면 이미 종료된 것 — 무시하고 TeamDelete 진행.

---

Common Mistakes

Quick Reference

Phase 1: 분석 → AskUserQuestion (팀 구성 승인)
Phase 2: TeamCreate → TaskCreate × N → TaskUpdate (의존성)
Phase 3: Task × N (병렬) → 결과 전달 → Task × N (후속)
Phase 4: 결과 종합 → shutdown_request × N → TeamDelete

Additional Resources

Reference Files

• `references/examples.md` — DB 마이그레이션, 경쟁사 분석, 풀스택 구현 등 3개 worked example (전체 Phase 1~3 흐름)
• `references/prompt-templates.md` — 역할별 teammate 프롬프트 템플릿 (analyst, implementer, validator) 및 작성 팁

Team Assemble - Worked Examples

Example 1: DB 마이그레이션

사용자 입력: "팀 구성해서 Supabase에서 PostgreSQL로 마이그레이션 해줘"

Phase 1 제안

팀 구성 제안: migration-team

| # | 역할 | 모델 | 담당 작업 | 의존성 |
|---|------|------|----------|--------|
| 1 | schema-analyst | opus | Supabase 현재 스키마, RLS 정책, 함수 분석 | - |
| 2 | migration-planner | opus | 마이그레이션 전략 수립 (순서, 위험요소, 롤백) | #1 |
| 3 | schema-writer | sonnet | PostgreSQL DDL 스크립트 작성 | #2 |
| 4 | data-migrator | sonnet | 데이터 이전 스크립트 (pg_dump/restore) | #2 |
| 5 | validator | sonnet | 데이터 무결성 검증 쿼리 작성 | #3, #4 |

Phase 2 도구 호출

TeamCreate(team_name: "migration-team", description: "Supabase → PostgreSQL 마이그레이션")

TaskCreate(subject: "#1 schema-analyst: Supabase 스키마 분석", ...)
TaskCreate(subject: "#2 migration-planner: 마이그레이션 전략 수립", ...)
TaskCreate(subject: "#3 schema-writer: DDL 스크립트 작성", ...)
TaskCreate(subject: "#4 data-migrator: 데이터 이전 스크립트", ...)
TaskCreate(subject: "#5 validator: 무결성 검증", ...)

TaskUpdate(taskId: "2", addBlockedBy: ["1"])
TaskUpdate(taskId: "3", addBlockedBy: ["2"])
TaskUpdate(taskId: "4", addBlockedBy: ["2"])
TaskUpdate(taskId: "5", addBlockedBy: ["3", "4"])

Phase 3 실행 순서

1. Round 1 (병렬 없음 — #1만 독립): Task(schema-analyst, opus) 2. Round 2 (#2는 #1 결과 필요): Task(migration-planner, opus, 선행결과 포함) 3. Round 3 (병렬 — #3, #4 독립): Task(schema-writer, sonnet) + Task(data-migrator, sonnet) 동시 4. Round 4 (#5는 #3+#4 필요): Task(validator, sonnet, 선행결과 포함)

---

Example 2: 경쟁사 분석 리포트

사용자 입력: "전문가 팀으로 AI 코딩 도구 경쟁사 분석 리포트 만들어줘"

Phase 1 제안

팀 구성 제안: competitor-analysis-team

| # | 역할 | 모델 | 담당 작업 | 의존성 |
|---|------|------|----------|--------|
| 1 | market-researcher | opus | 주요 경쟁사 식별 및 시장 동향 조사 | - |
| 2 | product-analyst | opus | 각 제품 기능/가격/차별점 비교 분석 | - |
| 3 | tech-reviewer | sonnet | 기술 스택, 아키텍처 비교 | - |
| 4 | report-writer | sonnet | 조사 결과 종합 리포트 작성 | #1, #2, #3 |

Phase 3 실행 순서

1. Round 1 (병렬 — #1, #2, #3 모두 독립): 3개 Task 동시 호출 2. Round 2 (#4는 모든 결과 필요): Task(report-writer, sonnet, 3개 결과 포함)

---

Example 3: 풀스택 기능 구현

사용자 입력: "팀으로 해줘 — 사용자 인증 시스템 구현"

Phase 1 제안

팀 구성 제안: auth-team

| # | 역할 | 모델 | 담당 작업 | 의존성 |
|---|------|------|----------|--------|
| 1 | architect | opus | 인증 아키텍처 설계 (JWT/세션, OAuth) | - |
| 2 | backend-dev | sonnet | API 엔드포인트 구현 (login, register, refresh) | #1 |
| 3 | frontend-dev | sonnet | 로그인/회원가입 UI 구현 | #1 |
| 4 | test-writer | sonnet | E2E 테스트 작성 | #2, #3 |

Phase 3 실행 순서

1. Round 1: Task(architect, opus) 2. Round 2 (병렬 — #2, #3 독립): Task(backend-dev, sonnet) + Task(frontend-dev, sonnet) 동시 3. Round 3: Task(test-writer, sonnet, 선행결과 포함)

Teammate Prompt Templates

기본 구조

모든 teammate 프롬프트는 5개 섹션으로 구성:

## 맥락
{프로젝트 배경과 이 작업이 전체에서 차지하는 위치}

## 목표
{구체적으로 무엇을 달성해야 하는지}

## 제약조건
- {하지 말아야 할 것}
- {변경하면 안 되는 파일/범위}
- {따라야 할 규칙}

## 출력 형식
{결과물의 형태 — 텍스트 요약, 파일 생성, 코드 등}

## 팀 정보
- team_name: {team-name}
- task_id: {task-id}
- 작업 완료 시 TaskUpdate(taskId: "{task-id}", status: "completed") 호출

역할별 프롬프트 예시

Analyst (분석가)

## 맥락
Supabase 기반 프로젝트를 셀프호스팅 PostgreSQL로 마이그레이션하는 작업의 첫 단계.
프로젝트 루트: /Users/bong/team-attention/deep-thought

## 목표
현재 Supabase 스키마를 분석하고 문서화:
1. 모든 테이블, 컬럼, 타입, 관계 (FK)
2. RLS 정책 목록
3. Supabase 전용 기능 (auth, storage, realtime) 의존성
4. Edge Functions 목록

## 제약조건
- 코드를 수정하지 말 것 — 분석만 수행
- Supabase 대시보드 접근 불가, 로컬 파일만 분석

## 출력 형식
마크다운 문서로 반환:
- 테이블별 스키마 요약 테이블
- Supabase 전용 의존성 목록
- 마이그레이션 시 주의사항

## 팀 정보
- team_name: migration-team
- task_id: 1
- 완료 시 TaskUpdate(taskId: "1", status: "completed")

Implementer (구현자)

## 맥락
인증 아키텍처가 설계 완료됨. JWT + refresh token 방식.
프레임워크: Next.js 14 (App Router), Prisma ORM.

선행 작업 결과:
{architect_result}

## 목표
설계를 기반으로 백엔드 API 구현:
1. POST /api/auth/register — 회원가입
2. POST /api/auth/login — 로그인 (JWT 발급)
3. POST /api/auth/refresh — 토큰 갱신
4. POST /api/auth/logout — 로그아웃
5. Prisma 스키마에 User 모델 추가

## 제약조건
- src/app/api/auth/ 디렉토리에만 파일 생성
- 기존 코드 수정 금지
- 비밀번호는 bcrypt로 해싱
- 환경변수: JWT_SECRET, REFRESH_SECRET

## 출력 형식
생성한 파일 경로 목록과 각 엔드포인트의 요청/응답 형식 요약.

## 팀 정보
- team_name: auth-team
- task_id: 2
- 완료 시 TaskUpdate(taskId: "2", status: "completed")

Validator (검증자)

## 맥락
DB 마이그레이션의 모든 단계가 완료됨. DDL 적용 및 데이터 이전 완료.

선행 작업 결과:
- DDL: {schema_writer_result}
- 데이터 이전: {data_migrator_result}

## 목표
마이그레이션 무결성을 검증:
1. 레코드 수 비교 (원본 vs 이전)
2. FK 관계 무결성 확인
3. 누락 데이터 탐지
4. 인덱스 및 제약조건 확인

## 제약조건
- 읽기 전용 쿼리만 사용 (SELECT, COUNT)
- 데이터 수정 금지

## 출력 형식
검증 결과 테이블:
| 검증 항목 | 상태 | 상세 |
PASS/FAIL 표시와 실패 시 원인.

## 팀 정보
- team_name: migration-team
- task_id: 5
- 완료 시 TaskUpdate(taskId: "5", status: "completed")

프롬프트 작성 팁

• 구체적: "코드 분석해줘" 대신 "src/lib/auth.ts의 인증 로직을 분석하고 보안 취약점을 식별"
• 제한된 범위: 변경 가능한 파일/디렉토리를 명시적으로 지정
• 출력 형식 고정: 자유 형식이 아닌 구조화된 형식 요구 (테이블, 체크리스트 등)
• 선행 결과 포함: 의존 작업 시 이전 결과를 프롬프트 본문에 직접 삽입