2000silpeed Agent Team Composer
요청 → 환경 확인 → 작업 분해 → 서비스·역할 배정 → meta-prompt 컴파일 → 실행·통합·검증.
사용자의 목표를 만족하는 가장 작은 실행 가능한 팀을 구성한다. 역할은 책임, 서비스는 실행 경로, 모델은 추론·생성 엔진이다. 세 가지를 구분하며 서비스 수를 늘리는 것 자체를 목표로 삼지 않는다.
목표와 실행 범위
요청과 세션에서 결과물, 완료 기준, 필수 서비스, 비용·기한·데이터 제약을 수집한다. “기획/조합/프롬프트만”이면 plan, “만들어/구현/실행까지”이면 execute. 이 스킬 자체를 만드는 요청은 스킬 구현이지 예시 서비스의 실행 허가가 아니다.
필수 정보만 한 번에 질문하고 독립적으로 가능한 준비를 진행한다. 기본 우선순위는 결과물 적합성 → 실행 가능성 → 적은 조율 비용이다. 사용자가 속도·비용·품질을 지정하면 따른다. 예산 미지정을 무제한 외부 과금 허가로 해석하지 않는다.
실행 환경과 기반 스킬
가용 도구·스킬 목록을 먼저 확인하고 필요한 도구만 검색한다. 설치된 스킬이나 모델 가이드북만으로 실행 가능하다고 판단하지 않는다. 서비스 관측과 배정은 references/routing.md를 따른다.
meta-prompt는 다음 순서로 찾는다.
- 세션 스킬 목록의
meta-prompt위치. - 이 스킬의 실제 디렉터리 기준
../../SKILL.md가name: meta-prompt이고../../guidebooks/registry.yaml이 존재하면 저장소 내 기반 스킬. - 환경에서 제공한 스킬 루트의
meta-prompt/SKILL.md.
발견한 SKILL.md와 guidebooks/registry.yaml을 읽는다. 중복 복사본을 만들지 않는다. 기반 스킬이 없으면 작업 분해·서비스 가용성 확인까지만 수행하고, 프롬프트 컴파일과 의존 작업은 보류한 채 누락 위치를 보고한다. 기반 스킬이 있는 상태에서 개별 모델 가이드만 없는 경우에는 _generic을 사용한다.
현재 세션의 서비스·모델은 환경에서 확인한다. 카드가 특정 호스트나 기본 모델을 가정해도 현재 런타임 정보를 우선한다. 카드 검증일은 서비스 연결 증거나 오늘의 가격·성능 증거가 아니다.
작업과 팀 구성
먼저 결과물 단위로 작업을 나누고 선행 결과가 필요한 작업을 연결한다. 그 후 역할을 배정한다. 오케스트레이터는 현재 주 에이전트이며 불필요하게 별도 팀장 에이전트를 생성하지 않는다.
- 독립적으로 진행할 수 있고 조율 비용보다 이득이 큰 작업만 병렬 배정한다. 순차 작업과 작은 작업은 현재 에이전트가 맡을 수 있다.
- 서브에이전트는 독립적인 경계가 있는 작업에 사용한다. 같은 파일을 수정하면 파일 소유권을 나누거나 지원되는 격리 환경을 사용한다.
- 팀 규모는 실제 동시 실행 한도와 독립 작업 수로 제한한다. 역할 수와 동시에 실행할 에이전트 수를 구분한다.
- 사용자가 지정한 서비스·모델은 고정 제약이다. 사용할 수 없으면 다른 서비스로 조용히 교체하지 않는다. 선택 사항인 후보는 이유를 남기고 가용 후보로 바꿀 수 있다.
- 별도 검증 역할은 오류 비용이나 통합 복잡도가 정당화할 때 추가한다. 모든 요청에 기획자·실행자·리뷰어 3명을 강제하지 않는다.
후보 선택은 routing 문서를 따른다. 우열을 입증하지 못한 경우 “현재 조건의 권장 조합”으로 표현하고 벤치마크 최적해처럼 말하지 않는다.
역할별 meta-prompt 컴파일
각 작업의 실제 실행 대상에 대해 모델 index → 해당 when의 카드만 로드한다. 같은 카드는 한 번만 읽고 재사용한다. 플랫폼 아래의 생성 모델이 확인되면 플랫폼 규칙과 모델 규칙을 함께 적용한다.
컴파일 입력은 목표, 필요한 컨텍스트, 제약, 완료 기준이다. 출력에는 다음을 담는다.
- 단일 책임, 입력 산출물과 선행 작업 ID, 출력 경로·형식.
- 사용 가능한 도구·쓰기 범위, 검증 방법, 실패 시 보고할 정보.
- 실제 서비스·모델, 적용 가이드북·카드 경로, 검증 상태, 일반 규칙으로 보충한 부분.
컴파일 중에는 meta-prompt의 프롬프트 산출물 모드를 사용한다. 컴파일 자체가 서비스 실행을 재귀적으로 시작하지 않게 한다. 팀 실행과 비용 처리는 아래 단계가 담당한다. 사용자에게 없는 의도를 추가하거나 불필요한 장문 역할극을 넣지 않는다.
명세 전달 또는 실행
작은 계획은 응답 안에, 여러 작업·인계가 있으면 작업 디렉터리의 충돌하지 않는 폴더에 assets/team-plan.template.yaml을 채워 저장한다. 파일을 만들 권한이 없는 환경에서는 같은 내용을 응답으로 전달한다. 기존 사용자 파일은 덮어쓰지 않는다.
역할·서비스·선후 관계·선택 이유를 짧게 알린다. plan이면 팀 명세와 바로 사용할 프롬프트를 전달하고 종료한다. execute이면 계획 승인 질문을 추가하지 말고 허가된 작업을 계속한다.
실제 배정·인계·재시도는 references/execution.md를 따른다. 연결 안 된 서비스는 manual-handoff 또는 blocked로 표시한다. 전달할 프롬프트가 있다는 사실을 실행 성공으로 보고하지 않는다.
결과 통합과 학습
완료 기준과 실제 결과를 대조하고, 결과물 위치·수행한 검증·남은 의존성을 보고한다. 실행하지 않은 계획에는 완료 상태를 부여하지 않는다.
조합을 개선할 때는 관측한 품질·실행 시간·비용·수정 횟수를 근거로 쓴다. 미관측 값은 unknown. 단일 사례를 서비스 전체의 성능 순위로 일반화하지 않는다. 비교 실행은 요청과 비용 범위가 허용하는 경우에만 한다.
스킬 수정 시 행동 점검에는 references/evaluation.md를 사용한다.