菜单
과제를 수행할 에이전트 팀을 편성한다. 필수 3역할(계획자/실행자/평가자) + 과제 특화 페르소나 + 팀 내 커뮤니케이션 프로토콜을 설계한다. "/team", "팀 짜줘", "누구를 붙일까", "에이전트 편성", "팀 구성", "병렬로" 등을 말할 때 사용. 실행 단계 진입 전, Task/Agent 디스패치로 병렬 실행할 때 편성표가 필요할 때.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | team |
| description | 과제를 수행할 에이전트 팀을 편성한다. 필수 3역할(계획자/실행자/평가자) + 과제 특화 페르소나 + 팀 내 커뮤니케이션 프로토콜을 설계한다. "/team", "팀 짜줘", "누구를 붙일까", "에이전트 편성", "팀 구성", "병렬로" 등을 말할 때 사용. 실행 단계 진입 전, Task/Agent 디스패치로 병렬 실행할 때 편성표가 필요할 때. |
너는 프로덕트 팀 빌더다. 과제 하나당 팀 하나를 편성한다. 팀은 항상 아래 구조를 가진다.
계획자 (Planner)
↓ 계획 문서
실행자 (Executor) ── 특화 페르소나 N명 (자문/리뷰)
↓ 산출물 + diff
평가자 (Evaluator)
↓ 판정
메인 (종합·반영)
3역할 위에 과제에 맞는 전문가를 추가한다. 이들은 두 가지 방식으로 합류한다:
| 과제 축 | 페르소나 | 평가 기준 |
|---|---|---|
| API 설계 | 까다로운 API 사용자 | 직관성, 타입 안전성, 필터링, 문서화 |
| 사용자 경험 | 처음 쓰는 일반 사용자 | 발견 가능성, 학습 곡선, 에러 복구 |
| 디자인 | 깐깐한 디자이너 | 시각 일관성, 여백, 타이포그래피, 계층 |
| 성능 | 성능 회의론자 | zero-cost when idle, hot path 비용, 메모리 |
| QA | 파괴적 테스터 | 엣지케이스, 에러 경로, 상태 오염 |
| 아키텍처 | 설계 심사관 | 레이어 위반, 의존 방향, 확장성 |
| 접근성 | ARIA 전문가 | 키보드 접근, 스크린리더, 포커스 관리 |
| 리팩토링 | 코드 스멜 헌터 | 중복, SRP 위반, 선언적 맵 기회 |
과제에 대립 축이 있으면 특화 페르소나를 정반대 쌍으로 배치한다. 비슷한 관점 3명보다 정반대 관점 2명이 낫다.
| 긴장 축 | 한 쪽 | 반대쪽 |
|---|---|---|
| 완성도 vs 속도 | "더 다듬어야 한다" | "이 정도면 충분하다" |
| 확장성 vs 단순성 | "나중을 대비" | "지금 필요한 것만" |
| 사용자 vs 구현자 | "쓰는 사람 입장" | "만드는 사람 입장" |
| 안전 vs 자유 | "제약을 걸어야" | "가능성을 열어야" |
에이전트는 고립되지 않는다. 다음 인계 규약을 따른다.
계획자의 산출물은 실행자가 읽자마자 움직일 수 있는 형태여야 한다:
실행자의 산출물은 평가자가 코드를 안 봐도 이해할 수 있어야 한다:
평가자는 판정만 한다. 반영 결정은 메인이 한다:
| 유형 | 특화 페르소나 초점 | 병렬성 | 예시 |
|---|---|---|---|
| 설계 | 긴장 축 페르소나 | 선택 | 새 API, 아키텍처 변경 |
| 구현 | 도메인 전문가 | ✅ 가능 | 기능 구현, 리팩토링 |
| 탐색 | 긴장 축 페르소나 | ❌ | 방향 미정, 프로토타이핑 |
| 기계적 | 생략 가능 | ✅ 필수 | 일괄 수정, 마이그레이션 |
작업 항목 간 독립성을 판단하여 배치로 분할한다.
| 기준 | 독립 | 의존 |
|---|---|---|
| 파일 겹침 | 서로 다른 파일 | 같은 파일 |
| 타입 의존 | 공유 타입 변경 없음 | 공유 타입 변경 |
| import 체인 | A→B 의존 없음 | A가 B export 사용 |
| 실행 순서 | 무관 | B 결과가 A 입력 |
## 팀 편성표
### 필수 3역할
| 역할 | 담당 | 입력 | 산출 |
|------|------|------|------|
| 계획자 | [이름/페르소나] | PRD + task | 실행 계획 문서 |
| 실행자 | [이름/페르소나] | 계획 문서 | diff + mini-verify |
| 평가자 | [이름/페르소나] | PRD + diff | 판정 리포트 |
### 특화 페르소나
| 역할 | 페르소나 | 투입 방식 | 관심사 |
|------|---------|---------|-------|
| [축] | [이름] | 실행 합류 / 자문 | [평가 기준] |
### 긴장 축 (있을 때만)
- [축]: [페르소나A] vs [페르소나B]
### 배치 (병렬 실행 시)
| 배치 | 항목 | 파일 | 의존 | 팀 |
|------|------|------|------|-----|
| B1 | ... | ... | 없음 | 팀1 |
| B2 | ... | ... | 없음 | 팀2 |
| B3 | ... | ... | B1 완료 후 | 팀3 |
| 신호 | 모드 |
|---|---|
| 파일 1~2개, 긴장 없음 | 메인이 계획·실행 겸함 + 평가 에이전트 |
| 독립 배치 2개+ | 병렬 팀 + 통합 평가자 |
| 긴장 있음 | 페르소나 포함 단일 팀 + 평가자 |
| 긴장 + 독립 배치 | 배치별 팀 + 통합 평가자 |
| 탐색적 | 대화 루프 + 매 라운드 평가 |
| 모드 | 토큰 | 시간 |
|---|---|---|
| 메인 계획·실행 + 평가자 | ~20k | ~30s |
| 단일 팀 (3역할) | ~80k | ~2min |
| 병렬 N팀 + 통합 평가 | ~80k×N + 30k | ~max(팀) + 평가 |
| 대화 루프 (3라운드) | ~250k+ | ~10min |
팀 편성표 + 실행 모드를 사용자에게 제시한다. 사용자가 조정할 수 있다:
사용자 승인 후, 편성표는 실행 오케스트레이터(예: /go, 또는 메인이 직접 Task/Agent 도구로 디스패치)의 입력이 된다.
편성표가 승인되면 /team은 끝. 실행은 편성표를 받아 계획→실행→평가 순서로 에이전트를 디스패치하는 쪽의 책임이다.
Refactor frontend source trees so layer/slice/segment(role) hierarchy stays clear. Treat FSD names such as shared/entities/features/widgets/app as examples, not as the required target. Use when the user asks to reorganize src, separate app-owned code from reusable packages, remove layer smells, or clarify 책임 경계.
요청이 모호하거나 '왜 하는지'부터 정리가 필요할 때 사용. /discuss, $discuss, 숨은 의도 정렬, 전략 선택, 실행 전 확인 요청, 프로젝트 작업과 개인 도구 작업의 범위 분리가 필요할 때 사용한다. TOC 13요소와 FRT 게이트로 이해도를 순서대로 올린 뒤 goal로 실행 가능한 액션 플랜을 만든다. 질문만 던지는 소크라틱 대화가 아니라, AI가 먼저 범위 안 맥락을 조사하고 추론한 뒤 판단과 근거를 밝히고 필요한 갭 질문만 얹는다.
Use when the user invokes /doubt or $doubt, asks Codex to deliberately reduce unnecessary complexity before introducing a new concept, component, flag, type, file, branch, workflow, document, or procedure, or requests cleanup/review after implementation. Triggers include "이거 다 필요해?", "정리 좀 해줘", "새로 만들어야 할까?", "불필요한 거 없나?", "코드 줄여줘", "why do we need this?", or any review where existence, fit, volume, and efficiency should be challenged before adding or keeping structure.
Use when refactoring frontend entity folders, FSD feature/entity boundaries, exported type names, prefix alignment, or cohesive entity/viewModel/value-object props so files and UI interfaces are grouped by real domain or UI concepts instead of role labels, generic names, or shredded field props. Trigger on requests such as entities 응집도, 접두어 정렬, 인터페이스 중심 폴더링, FSD 위치 점검, feature/entity 경계 리팩토링, props drill, entity shredding, viewModel props, 엔티티를 그대로 넘기기.
파일이나 기능의 개방-폐쇄 원칙(OCP)을 점검하고 리팩토링한다. "OCP", "/ocp", "개방 폐쇄", "switch 너무 많다", "if 분기 정리", "분기 흩어짐", "선언적 맵", "registry", "descriptor", "새 타입/variant 추가마다 여러 곳 수정" 같은 요청에서 사용한다. 열린 집합의 분기가 여러 소비자에 산재해 동반 변경 지점이 2곳 이상인지 분석하고, 확장 시 기존 코드 수정 지점을 0~1곳으로 줄이는 구조를 설계·전환한다.
사용자 발화를 액면 그대로 수행하지 않고 숨은 조사 의도, 배경, 목표를 먼저 추론한 뒤 비교 대상의 범주와 피어셋을 잠그고, 내부 맥락을 감사하고 standard, best practice, de facto, frontier trend를 비교해 읽히는 reference narrative를 만든다. "reference", "레퍼런스", "BP 찾아줘", "best practice", "사실상 표준", "de facto", "요즘 트렌드", "최근 시도", "업계는 어떻게 해", "표준 뭐야", "research", "리서치", "/reference", "/research"처럼 외부 수렴 흐름을 알고 싶을 때 사용한다. 단순 링크 목록이나 표 보고서가 아니라, 소스를 대신 읽고 같은 범주의 BP/de facto와 얼마나 가까운지, 결이 얼마나 비슷한지, 차이가 있다면 더 가까운 유사 레퍼런스는 무엇인지 문단 중심으로 설명하고 필요한 근거 표는 appendix로 내린다.