팀 스킬
Claude Code의 암시적 에이전트 팀을 사용하여 공유 작업 목록에서 작업하는 N개의 조정된 에이전트를 생성합니다. Claude Code 2.1.178+는 기본 TeamCreate/TeamDelete를 제거했습니다. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1을 설정하면 각 세션에 하나의 암시적 팀이 있으며, 동료는 Agent/Task 도구를 사용하여 고유한 name 값으로 직접 생성됩니다. 이 스킬은 문서화된 경우(omc team / /omc-teams) OMC의 레거시 tmux/CLI 워커 오케스트레이션을 계속 지원합니다.
swarm 호환성 별칭은 #1131에서 제거되었습니다.
사용법
/oh-my-claudecode:team N:agent-type "작업 설명"
/oh-my-claudecode:team "작업 설명"
/oh-my-claudecode:team ralph "작업 설명"
매개변수
- N - 동료 에이전트 수 (1-20). 선택 사항. 기본값은 작업 분해에 따른 자동 크기 조정입니다.
- agent-type -
team-exec단계에 생성할 OMC 에이전트 (예: executor, debugger, designer, codex, gemini, antigravity). 선택 사항. 기본값은 단계 인식 라우팅입니다. Codex CLI 워커를 생성하려면codex, Gemini CLI 워커를 생성하려면gemini(엔터프라이즈/API-키 등급), Antigravity CLI (agy) 워커를 생성하려면antigravity(Google의 Gemini CLI 후속; 각 CLI 설치 필요)를 사용하세요. 아래 단계 에이전트 라우팅을 참조하세요. - task - 동료 간에 분해 및 분배할 상위 수준 작업
- ralph - 선택적 수정자. 있는 경우 팀 파이프라인을 Ralph의 지속성 루프(실패 시 재시도, 완료 전 아키텍트 검증)로 래핑합니다. 아래 팀 + Ralph 구성 참조.
예시
/team 5:executor "프로젝트 전체의 모든 TypeScript 오류 수정"
/team 3:debugger "src/의 빌드 오류 수정"
/team 4:designer "모든 페이지 구성 요소에 반응형 레이아웃 구현"
/team "인증 모듈을 보안 검토와 함께 리팩터링"
/team ralph "사용자 관리를 위한 완전한 REST API 구축"
# Codex CLI 워커 사용 시 (필요: npm install -g @openai/codex)
/team 2:codex "아키텍처 검토 및 개선 제안"
# Gemini CLI 워커 사용 시 (필요: npm install -g @google/gemini-cli)
/team 2:gemini "UI 구성 요소 재설계"
# Antigravity CLI 워커 사용 시 (필요: https://antigravity.google에 따라 설치)
/team 2:antigravity "UI 구성 요소 재설계"
# 혼합: 백엔드 분석에는 Codex, 프론트엔드에는 Gemini/Antigravity (/oh-my-claudecode:ask로 작업별 위임)
아키텍처
사용자: "/team 3:executor 모든 TypeScript 오류 수정"
|
v
[팀 오케스트레이터 (리드)]
|
+-- 세션의 암시적 Claude Code 팀 사용
| -> TeamCreate 호출 없음; 리드는 현재 세션 유지
|
+-- 작업을 분석 및 하위 작업으로 분해
| -> explore/architect가 하위 작업 목록 생성
|
+-- 구현 계획에서 작업 목록 항목 생성
| -> TODO/작업 항목 #1, #2, #3 (종속성 포함)
|
+-- 작업 목록 항목 업데이트 (소유자 사전 할당)
| -> 작업 #1 소유자=worker-1, 등.
|
+-- Task(name="worker-1") x 3
| -> 팀에 동료 생성
|
+-- 모니터링 루프
| <- 동료 메시지 (활성 팀 표면을 통해 자동 전달)
| -> 진행 상황 검토를 위한 작업 목록/TodoWrite
| -> 차단 해제/조정을 위해 활성 팀 표면을 통해 동료에게 메시지 전송
|
+-- 완료
-> 활성 팀 표면을 통해 각 동료에게 종료 요청
<- 동료의 종료 확인
-> OMC 팀 상태 지우기 (TeamDelete 호출 없음)
-> rm .omc/state/team-state.json
네이티브 Claude Code 팀 모델 (2.1.178+):
- 이 스킬은 ~/.claude/teams/<name>/ 디렉토리를 생성하지 않습니다.
- TeamCreate/TeamDelete 호출을 사용할 수 없습니다.
- `team_name`은 네이티브 Claude Code에서 무시되는 레거시 메타데이터로만 허용됩니다. 라우팅에 의존하지 마십시오.
- Agent/Task를 통해 `name="worker-N"`으로 직접 동료를 생성하십시오.
목표 워크플로우 관계
Team은 병렬, 단계별 실행을 위한 OMC 권한입니다. 비결정적 경고 처리 대신 결정적 충돌 정책 refuse, adopt_existing, artifact_only를 사용하십시오. 작업이 Claude Code /goal, Ralph 또는 아티팩트 전용 Ultragoal을 언급하는 경우, 리더가 명시적으로 인계하지 않는 한 Team을 기본 루프 권한으로 유지하십시오. /goal은 문서화된 네이티브 Claude Code 인계 대상 또는 리드 세션의 가시적 증거로만 사용하고, /goal 평가자가 독립적으로 명령을 실행하거나, 파일을 읽거나, team-verify/team-fix를 대체한다고 주장하지 마십시오. 아티팩트 전용 Ultragoal 참조는 워커 실행 자체가 아닌 지속적인 목표 원장/체크포인트/증거 아티팩트로 취급되어야 합니다.
단계별 파이프라인 (표준 팀 런타임)
팀 실행은 다음 단계별 파이프라인을 따릅니다:
team-plan -> team-prd -> team-exec -> team-verify -> team-fix (루프)
단계 에이전트 라우팅
각 파이프라인 단계는 실행자만이 아닌 전문화된 에이전트를 사용합니다. 리드는 단계 및 작업 특성에 따라 에이전트를 선택합니다.
| 단계 | 필수 에이전트 | 선택적 에이전트 | 선택 기준 |
|---|---|---|---|
| team-plan | explore (haiku), planner (opus) | analyst (opus), architect (opus) | 요구 사항이 불명확한 경우 analyst 사용. 시스템 경계가 복잡한 경우 architect 사용. |
| team-prd | analyst (opus) | critic (opus) | 범위에 이의를 제기하려면 critic 사용. |
| team-exec | executor (sonnet) | executor (opus), debugger (sonnet), designer (sonnet), writer (haiku), test-engineer (sonnet) | 에이전트를 하위 작업 유형에 일치시키십시오. 복잡한 자율 작업에는 executor (model=opus), UI에는 designer, 컴파일 문제에는 debugger, 문서에는 writer, 테스트 생성에는 test-engineer를 사용하십시오. |
| team-verify | verifier (sonnet) | test-engineer (sonnet), security-reviewer (sonnet), code-reviewer (opus) | 항상 verifier를 실행하십시오. 인증/암호화 변경에는 security-reviewer를 추가하십시오. 20개 이상의 파일 또는 아키텍처 변경에는 code-reviewer를 추가하십시오. code-reviewer는 스타일/서식 검사도 포함합니다. |
| team-fix | executor (sonnet) | debugger (sonnet), executor (opus) | 유형/빌드 오류 및 회귀 격리에는 debugger를 사용하십시오. 복잡한 다중 파일 수정에는 executor (model=opus)를 사용하십시오. |
라우팅 규칙:
- 리드가 단계별로 에이전트를 선택하며 사용자가 선택하지 않습니다. 사용자의
N:agent-type매개변수는team-exec단계 워커 유형만 재정의합니다. 다른 모든 단계는 단계에 적합한 전문가를 사용합니다. - 전문가 에이전트는 실행자 에이전트를 보완합니다. 분석/검토는 architect/critic Claude 에이전트로, UI 작업은 designer 에이전트로 라우팅하십시오. Tmux CLI 워커는 일회성이며 팀 통신에 참여하지 않습니다.
- 비용 모드는 모델 등급에 영향을 줍니다. 다운그레이드 시:
opus에이전트를sonnet으로,sonnet을haiku로 (품질이 허용되는 경우).team-verify는 항상 최소sonnet을 사용합니다. - 위험 수준에 따라 검토가 강화됩니다. 보안에 민감하거나 20개 이상의 파일 변경 사항은
team-verify에security-reviewer+code-reviewer(opus)를 포함해야 합니다.
단계 진입/종료 기준
- team-plan
- 진입: 팀 호출이 구문 분석되고 오케스트레이션이 시작됩니다.
- 에이전트:
explore가 코드베이스를 스캔하고,planner가 작업 그래프를 생성하며, 복잡한 작업의 경우 선택적으로analyst/architect를 사용합니다. - 종료: 분해가 완료되고 실행 가능한 작업 그래프가 준비됩니다.
- team-prd
- 진입: 범위가 모호하거나 승인 기준이 누락되었습니다.
- 에이전트:
analyst가 요구 사항을 추출하고, 선택적으로critic을 사용합니다. - 종료: 승인 기준과 경계가 명시적입니다.
- team-exec
- 진입: 작업 목록 할당 및 워커 생성이 완료되었습니다.
- 에이전트: 하위 작업 유형별로 적절한 전문가 유형의 워커가 생성됩니다 (라우팅 테이블 참조).
- 종료: 실행 작업이 현재 패스의 최종 상태에 도달합니다.
- team-verify
- 진입: 실행 패스가 완료됩니다.
- 에이전트:
verifier+ 작업에 적합한 검토자 (라우팅 테이블 참조). - 종료 (통과): 필요한 후속 조치 없이 검증 게이트를 통과합니다.
- 종료 (실패): 수정 작업이 생성되고 제어가
team-fix로 이동합니다.
- team-fix
- 진입: 검증에서 결함/회귀/불완전 기준을 발견했습니다.
- 에이전트: 결함 유형에 따라
executor/debugger. - 종료: 수정이 완료되고 흐름이
team-exec로 돌아간 다음team-verify로 이동합니다.
검증/수정 루프 및 중지 조건
다음 조건 중 하나가 충족될 때까지 team-exec -> team-verify -> team-fix를 계속합니다:
- 검증이 통과되고 필요한 수정 작업이 남아 있지 않거나,
- 작업이 증거와 함께 명시적인 최종 차단/실패 결과에 도달합니다.
team-fix는 최대 시도 횟수로 제한됩니다. 수정 시도가 구성된 한도를 초과하면 최종 failed 상태로 전환됩니다 (무한 루프 방지).
단계 인계 규칙
단계 간 전환 시 중요한 컨텍스트(결정, 기각된 대안, 식별된 위험)는 리드의 대화 기록에만 존재합니다. 리드의 컨텍스트가 압축되거나 에이전트가 다시 시작되면 이 지식은 손실됩니다.
완료되는 각 단계는 전환 전에 인계 문서를 생성해야 합니다.
리드는 인계 문서를 .omc/handoffs/<stage-name>.md에 작성합니다.
인계 형식
## 인계: <현재-단계> → <다음-단계>
- **결정됨**: [이 단계에서 내려진 주요 결정]
- **기각됨**: [고려되었지만 기각된 대안과 그 이유]
- **위험**: [다음 단계를 위해 식별된 위험]
- **파일**: [생성 또는 수정된 주요 파일]
- **남은 작업**: [다음 단계가 처리해야 할 항목]
인계 규칙
- 리드는 다음 단계의 에이전트를 생성하기 전에 이전 인계를 읽습니다. 인계 내용은 다음 단계의 에이전트 생성 프롬프트에 포함되어 에이전트가 전체 컨텍스트로 시작할 수 있도록 합니다.
- 인계는 누적됩니다. 검증 단계는 모든 이전 인계(plan → prd → exec)를 읽어 전체 결정 이력을 확인할 수 있습니다.
- 팀 취소 시 인계는 세션 재개를 위해
.omc/handoffs/에 유지됩니다. 네이티브 Claude Code 팀 정리에서 삭제되지 않습니다. Claude Code 2.1.178+에는TeamDelete호출이 없습니다. - 인계는 간결합니다. 최대 10-20줄. 결정과 근거를 캡처하며 전체 사양은 아닙니다 (사양은 DESIGN.md와 같은 전달 파일에 있습니다).
예시
## 인계: team-plan → team-exec
- **결정됨**: 3개의 서비스(auth, api, worker)를 사용한 마이크로서비스 아키텍처. 지속성은 PostgreSQL. 인증 토큰은 JWT.
- **기각됨**: 모놀리스 (확장성 문제), MongoDB (팀 전문성은 SQL), 세션 쿠키 (API 우선 설계).
- **위험**: Worker 서비스에는 작업 대기열을 위한 Redis 필요 — 아직 프로비저닝되지 않음. Auth 서비스에는 초기 설계에 속도 제한 없음.
- **파일**: DESIGN.md, TEST_STRATEGY.md
- **남은 작업**: 데이터베이스 마이그레이션 스크립트, CI/CD 파이프라인 구성, Redis 프로비저닝.
재개 및 취소 의미
- 재개: 단계별 상태 + 실시간 작업 상태를 사용하여 마지막 비최종 단계부터 다시 시작합니다.
.omc/handoffs/를 읽어 단계 전환 컨텍스트를 복구합니다. - 취소:
/oh-my-claudecode:cancel은 동료 종료를 요청하고, 응답을 기다린 후(최선의 노력), 단계를cancelled(active=false)로 표시하고, 취소 메타데이터를 캡처한 다음 팀 리소스를 삭제하고 정책에 따라 팀 상태를 지우거나 유지합니다..omc/handoffs/의 인계 파일은 잠재적인 재개를 위해 보존됩니다. - 최종 상태는
complete,failed,cancelled입니다.
Windows psmux tmux 호환 게이트
네이티브 Windows에서는 /team에 WSL이 필요하거나 tmux를 사용할 수 없다고 사용자에게 알리기 전에 실제 tmux 호환 바이너리를 확인하십시오. 네이티브 psmux는 tmux 호환 명령(종종 tmux / tmux.cmd)을 설치하며 지원되는 팀 멀티플렉서입니다.
Windows에서 차단하거나 대체하기 전에:
tmux -V(또는where tmux후tmux -V와 같은 플랫폼 등가물)을 확인하십시오.- psmux 기반
tmux -V가 성공하면 tmux를 사용 가능한 것으로 간주하십시오. - psmux/tmux를 사용할 수 있으면 정상적인 팀 흐름을 계속하고 WSL 필요 안내를 출력하지 마십시오.
- tmux 호환 바이너리를 사용할 수 없는 경우에만 사용자에게 네이티브 Windows 지원을 위해 psmux를 설치하거나 대안으로 WSL2를 사용하도록 안내하십시오.
워크플로우
단계 1: 입력 구문 분석
- N (에이전트 수) 추출, 1-20 유효성 검사
- agent-type 추출, 알려진 OMC 하위 에이전트에 매핑되는지 확인
- task 설명 추출
단계 2: 분석 및 분해
explore 또는 architect (MCP 또는 에이전트를 통해)를 사용하여 코드베이스를 분석하고 작업을 N개의 하위 작업으로 분해합니다:
- 각 하위 작업은 충돌을 방지하기 위해 파일 범위 또는 모듈 범위여야 합니다.
- 하위 작업은 독립적이거나 명확한 종속성 순서가 있어야 합니다.
- 각 하위 작업 n