# Agent Team Composer

> 메타 프롬프트 가이드북을 기반으로 작업에 적합한 서비스·모델·역할을 선택하고 에이전트 팀의 작업 명세와 실행 순서를 구성한다. 서비스 조합, 멀티 모델 협업, 에이전트 팀 자동 구성 요청에 사용한다. 실행까지 요청하면 실제 연결된 도구로 수행한다. 단일 모델용 프롬프트 변환만 요청하면 meta-prompt를 사용한다.

- Skill: `2000silpeed/agent-team-composer` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add 2000silpeed/agent-team-composer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/2000silpeed/agent-team-composer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: 2000silpeed (https://skillmd.com/u/2000silpeed)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/2000silpeed/agent-team-composer

---


# Agent Team Composer

요청 → 환경 확인 → 작업 분해 → 서비스·역할 배정 → meta-prompt 컴파일 → 실행·통합·검증.

사용자의 목표를 만족하는 **가장 작은 실행 가능한 팀**을 구성한다. 역할은 책임, 서비스는 실행 경로, 모델은 추론·생성 엔진이다. 세 가지를 구분하며 서비스 수를 늘리는 것 자체를 목표로 삼지 않는다.

## 목표와 실행 범위

요청과 세션에서 결과물, 완료 기준, 필수 서비스, 비용·기한·데이터 제약을 수집한다. “기획/조합/프롬프트만”이면 `plan`, “만들어/구현/실행까지”이면 `execute`. 이 스킬 자체를 만드는 요청은 스킬 구현이지 예시 서비스의 실행 허가가 아니다.

필수 정보만 한 번에 질문하고 독립적으로 가능한 준비를 진행한다. 기본 우선순위는 결과물 적합성 → 실행 가능성 → 적은 조율 비용이다. 사용자가 속도·비용·품질을 지정하면 따른다. 예산 미지정을 무제한 외부 과금 허가로 해석하지 않는다.

## 실행 환경과 기반 스킬

가용 도구·스킬 목록을 먼저 확인하고 필요한 도구만 검색한다. 설치된 스킬이나 모델 가이드북만으로 실행 가능하다고 판단하지 않는다. 서비스 관측과 배정은 [references/routing.md](references/routing.md)를 따른다.

`meta-prompt`는 다음 순서로 찾는다.

1. 세션 스킬 목록의 `meta-prompt` 위치.
2. 이 스킬의 실제 디렉터리 기준 `../../SKILL.md`가 `name: meta-prompt`이고 `../../guidebooks/registry.yaml`이 존재하면 저장소 내 기반 스킬.
3. 환경에서 제공한 스킬 루트의 `meta-prompt/SKILL.md`.

발견한 `SKILL.md`와 `guidebooks/registry.yaml`을 읽는다. 중복 복사본을 만들지 않는다. 기반 스킬이 없으면 작업 분해·서비스 가용성 확인까지만 수행하고, 프롬프트 컴파일과 의존 작업은 보류한 채 누락 위치를 보고한다. 기반 스킬이 있는 상태에서 **개별 모델 가이드만 없는 경우**에는 `_generic`을 사용한다.

현재 세션의 서비스·모델은 환경에서 확인한다. 카드가 특정 호스트나 기본 모델을 가정해도 현재 런타임 정보를 우선한다. 카드 검증일은 서비스 연결 증거나 오늘의 가격·성능 증거가 아니다.

## 작업과 팀 구성

먼저 결과물 단위로 작업을 나누고 선행 결과가 필요한 작업을 연결한다. 그 후 역할을 배정한다. 오케스트레이터는 현재 주 에이전트이며 불필요하게 별도 팀장 에이전트를 생성하지 않는다.

- 독립적으로 진행할 수 있고 조율 비용보다 이득이 큰 작업만 병렬 배정한다. 순차 작업과 작은 작업은 현재 에이전트가 맡을 수 있다.
- 서브에이전트는 독립적인 경계가 있는 작업에 사용한다. 같은 파일을 수정하면 파일 소유권을 나누거나 지원되는 격리 환경을 사용한다.
- 팀 규모는 실제 동시 실행 한도와 독립 작업 수로 제한한다. 역할 수와 동시에 실행할 에이전트 수를 구분한다.
- 사용자가 지정한 서비스·모델은 고정 제약이다. 사용할 수 없으면 다른 서비스로 조용히 교체하지 않는다. 선택 사항인 후보는 이유를 남기고 가용 후보로 바꿀 수 있다.
- 별도 검증 역할은 오류 비용이나 통합 복잡도가 정당화할 때 추가한다. 모든 요청에 기획자·실행자·리뷰어 3명을 강제하지 않는다.

후보 선택은 routing 문서를 따른다. 우열을 입증하지 못한 경우 “현재 조건의 권장 조합”으로 표현하고 벤치마크 최적해처럼 말하지 않는다.

## 역할별 meta-prompt 컴파일

각 작업의 실제 실행 대상에 대해 모델 index → 해당 `when`의 카드만 로드한다. 같은 카드는 한 번만 읽고 재사용한다. 플랫폼 아래의 생성 모델이 확인되면 플랫폼 규칙과 모델 규칙을 함께 적용한다.

컴파일 입력은 목표, 필요한 컨텍스트, 제약, 완료 기준이다. 출력에는 다음을 담는다.

- 단일 책임, 입력 산출물과 선행 작업 ID, 출력 경로·형식.
- 사용 가능한 도구·쓰기 범위, 검증 방법, 실패 시 보고할 정보.
- 실제 서비스·모델, 적용 가이드북·카드 경로, 검증 상태, 일반 규칙으로 보충한 부분.

컴파일 중에는 meta-prompt의 **프롬프트 산출물 모드**를 사용한다. 컴파일 자체가 서비스 실행을 재귀적으로 시작하지 않게 한다. 팀 실행과 비용 처리는 아래 단계가 담당한다. 사용자에게 없는 의도를 추가하거나 불필요한 장문 역할극을 넣지 않는다.

## 명세 전달 또는 실행

작은 계획은 응답 안에, 여러 작업·인계가 있으면 작업 디렉터리의 충돌하지 않는 폴더에 [assets/team-plan.template.yaml](assets/team-plan.template.yaml)을 채워 저장한다. 파일을 만들 권한이 없는 환경에서는 같은 내용을 응답으로 전달한다. 기존 사용자 파일은 덮어쓰지 않는다.

역할·서비스·선후 관계·선택 이유를 짧게 알린다. `plan`이면 팀 명세와 바로 사용할 프롬프트를 전달하고 종료한다. `execute`이면 계획 승인 질문을 추가하지 말고 허가된 작업을 계속한다.

실제 배정·인계·재시도는 [references/execution.md](references/execution.md)를 따른다. 연결 안 된 서비스는 `manual-handoff` 또는 `blocked`로 표시한다. 전달할 프롬프트가 있다는 사실을 실행 성공으로 보고하지 않는다.

## 결과 통합과 학습

완료 기준과 실제 결과를 대조하고, 결과물 위치·수행한 검증·남은 의존성을 보고한다. 실행하지 않은 계획에는 완료 상태를 부여하지 않는다.

조합을 개선할 때는 관측한 품질·실행 시간·비용·수정 횟수를 근거로 쓴다. 미관측 값은 `unknown`. 단일 사례를 서비스 전체의 성능 순위로 일반화하지 않는다. 비교 실행은 요청과 비용 범위가 허용하는 경우에만 한다.

스킬 수정 시 행동 점검에는 [references/evaluation.md](references/evaluation.md)를 사용한다.