Delegate (위임)은(는) 무엇을 하나요?
오케스트레이터의 컨텍스트는 세션 전체에 걸쳐 지속되는 하나의 창입니다. 오케스트레이터가 읽는 모든 파일과 보유한 모든 명령 출력은 판단 예산을 소모합니다. 하위 에이전트는 작업마다 새로운 창을 얻으므로, 오케스트레이터는 라우팅, 완료 조건 정의, 판단을 수행하고, 에이전트는 읽기, 실행, 쓰기를 담당합니다.
두 가지 역할
모든 위임 프롬프트는 Your ROLE_TYPE is sub-agent.로 시작합니다. 이 줄은 재귀 방지 표시입니다: 이 스킬을 상속받은 하위 에이전트는 더 이상 작업을 분해해서는 안 됩니다. 프롬프트가 그렇게 시작했다면 여기서 멈추고 references/sub-agent-contract.md를 따르십시오. 그렇지 않다면 당신은 위임자(delegator)이며 이 파일의 나머지 부분이 적용됩니다.
적용 시점
파일을 변경하거나, 원인을 조사하거나, 사실을 수집하거나, 버그를 수정하거나, 작업을 리뷰하는 모든 요청 — 규모와 관계없이 — 그리고 소스 코드를 직접 읽거나 진단을 직접 실행하려는 순간에 적용됩니다. "단 두 줄뿐인데" 하는 경우도 위임 대상입니다. 유일한 예외는 이번 턴에 직접 편집한 단일 파일로 범위가 제한된 확인 작업입니다.
또한 작업이 진행 중인 경우에도 적용됩니다: 하위 에이전트의 보고서 판단(Adjudicate 참조), 단계 재위임, 또는 사용자가 지목한 패턴 인스턴스 일반화(패턴 확장 참조).
답변이 이미 컨텍스트에 있고 파일 변경이 필요 없는 경우에는 인라인으로 답변하십시오.
분해(Decompose)
요청을 여러 단계로 분할하십시오. 실제 작업을 생성하는 단계만 유지하고, 불필요한 단계는 추가하지 마십시오.
| 단계 | 산출물 |
|---|---|
| read (읽기) | 작업이 의존하는 자료를 찾고 읽음 |
| gather (수집) | 외부 사실: 문서, 기존 사례, 현재 시스템 상태 |
| process (처리) | 분석 및 선택한 접근 방식 |
| verify (검증) | 실제 코드와 환경에 대해 접근 방식 확인 |
| write (쓰기) | 변경 사항 |
| validate (검사) | 린트, 타입 검사, 빌드 결과 |
| test (테스트) | 테스트 실행 및 변경 사항을 다루는 새 테스트 |
| report (보고) | 변경된 내용과 증거 |
| review (리뷰) | 결과에 대한 독립적인 비판 |
일부 형태는 반복되며 별도의 처리가 있습니다:
- 버그 수정 → references/fix-cycle.md: 변경 전에 재현.
- 여러 대상에 동일한 편집 → 하나의
process위임이 변경 사항을 결정; N개의 일반(generic) 위임이 적용; 하나의review위임이 확인. parallel-work 참조.
위임(Dispatch)
- 단계당 하나의 위임. 하나의 단계가 N개의 대상으로 확장될 수 있지만(N개의 위임, 동일 단계), 다른 단계와 혼합되지 않습니다.
- 독립적인 위임은 한 번에 함께 보내 동시에 실행되도록 하십시오. 하나가 다른 결과를 소비해야 하거나, 분리 없이 두 위임이 동일한 파일을 쓰는 경우에만 직렬화하십시오.
read/gather/process의 결과는 파일에 저장하고, 컨텍스트에 저장하지 마십시오. 경로를 다음 단계에 전달하고, 내용은 전달하지 마십시오.
에이전트 선택
에이전트의 이름이 아니라 작업이 요구하는 바에 따라 분류하십시오:
- 전문가(Specialist) — 작업의 도메인과 설명이 일치하는 모든 에이전트. 관찰 사항, 성공 기준, 컨텍스트를 받습니다. 구현 단계는 절대 받지 않습니다.
- 일반(Generic) —
general-purpose(또는 이에 상응하는 도구) 및Explore. 정해진 구현을 받습니다: 정확한 편집, 정확한 파일, 정확한 검증.Explore는 정확히 일치하는 검색에만 사용합니다. - 리뷰어(Reviewer) —
review단계의 경우, 작성자와 다른 에이전트를 선택하고, 해당 도메인의 리뷰어 또는 감사자 유형 에이전트를 선호합니다.
적합한 전문가가 없으면, 정해진 작업과 함께 일반(generic)을 위임하십시오.
두 프롬프트 모두 동일한 두 줄로 시작합니다. 다음 템플릿 중 하나의 첫 줄에 그대로 복사하십시오: Your ROLE_TYPE is sub-agent. Follow the sub-agent contract at <references/sub-agent-contract.md의 절대 경로>.
프롬프트 — 전문가 모드
PHASE: <단계 이름 중 하나>
TASK: <한 문장>
OBSERVATIONS:
- <컨텍스트에 이미 있는 사실: 사용자 진술, 이전 STATUS 보고서, 오류 내용 그대로, 알고 있는 file:line>
DEFINITION OF SUCCESS:
- <측정 가능한 결과>
- <수락 기준>
- <검증 방법 — 명령어와 예상 결과, 또는 확인할 리뷰어>
DELIVERY:
- 한 줄보다 긴 내용은 .tmp/scratch/reports/<YYYYMMDD>-<slug>.md에 쓰고 경로를 반환합니다.
CONTEXT:
- Location: <찾을 위치>
- Scope: <경계>
- Constraints: <사용자가 요구한 요구사항; 따라야 할 기존 패턴>
- Commands: <프로젝트의 validate/test를 위한 품질 게이트, 또는 "이 프로젝트가 정의한 게이트를 찾으십시오">
ECOSYSTEM CONTEXT: (섹션이 비어 있으면 생략)
- <에이전트가 읽을 수 없는 세션 사실: 인증된 CLI, 리뷰 중인 PR, 동일한 파일에서 작업 중인 다른 에이전트>
YOUR TASK:
<아래 표의 해당 단계 행을 그대로>
YOUR TASK를 위한 단계별 행:
| 단계 | 행 |
|---|---|
| read | 이 작업이 의존하는 자료를 찾아 읽으십시오. 정확한 경로와 인용된 내용을 전달 파일에 쓰십시오. 나중 단계에서 필요한 세부 사항을 요약하여 생략하지 마십시오. 아무것도 편집하지 마십시오. |
| gather | CONTEXT에 명명된 외부 사실을 수집하십시오. 각 사실을 출처와 함께 전달 파일에 기록하십시오. 아무것도 편집하지 마십시오. |
| process | OBSERVATIONS의 경로에 있는 자료를 분석하십시오. 접근 방식을 선택하고, 그 이유와 대안이 배제된 이유를 기록하십시오. 아무것도 편집하지 마십시오. |
| verify | 선택한 접근 방식을 CONTEXT의 실제 코드 및 환경에 대해 확인하십시오. 유효한 부분과 실패한 부분을 기록하십시오. 아무것도 구현하지 마십시오. |
| write | DEFINITION OF SUCCESS에 명시된 변경을 수행하십시오. CONTEXT Scope 내의 파일만 수정하십시오. |
| validate | CONTEXT Commands의 명령어를 실행하거나, 이 프로젝트의 린트/타입/빌드 게이트를 찾아 실행한 명령어를 명시하십시오. 정확한 출력, 통과 및 실패를 보고하십시오. 침묵하는 실패는 실패입니다. |
| test | CONTEXT Commands의 테스트 호출을 실행하거나, 이를 찾아 실행한 명령어를 명시하십시오. 변경 사항을 다루는 테스트를 추가하십시오. 정확한 출력을 보고하십시오. |
| report | 변경된 내용과 그 증거(파일, 명령어, 출력)를 명시하십시오. 증거가 뒷받침하지 않는 주장은 하지 마십시오. |
| review | OBSERVATIONS의 경로에 있는 결과를 DEFINITION OF SUCCESS에 대해 비판하십시오. 차이, 모순, 뒷받침되지 않는 주장을 보고하십시오. 아무것도 수정하지 마십시오. |
작성 규칙:
- 컨텍스트에 이미 있는 내용으로 채울 수 없는 섹션은 생략하고, 임의로 만들지 마십시오. 빈 OBSERVATIONS 또는 ECOSYSTEM CONTEXT는 유효한 상태입니다. 추측은 허용되지 않습니다.
- OBSERVATIONS는 통과 전용입니다: 컨텍스트에 이미 있는 내용만 포함하십시오. 이를 채우기 위해 읽기, grep, 명령어 실행은 사전 수집(pre-gathering)에 해당하며, 에이전트가 새 창으로 수행합니다.
- 관찰 사항을 사실로 기술하십시오("exit code 1", "오류 내용은: …"). 가설을 가지고 있다면 레이블을 붙이십시오:
Hypothesis to verify: …. - Constraints는 결과와 경계이며, 절대 단계가 아닙니다. Commands에 프로젝트 자체 게이트를 명명하는 것은 제약(constraint)이지 단계(step)가 아닙니다.
- 에이전트가 상속받는 내용(저장소 규칙, 툴체인, "자유롭게 탐색", "사용 가능한 스킬 사용")은 언급하지 마십시오. 이는 프로젝트의 에이전트 지침에 포함됩니다. 에이전트가 스킬을 로드해야 하고 스스로 로드하지 않을 경우에만 스킬 이름을 명시하십시오.
- 경로: 에이전트가 자신의 작업 디렉토리에서 해석하는 대로 작성하십시오. 저장소 내부에서는 상대 경로로, 심볼릭 링크를 통해 접근하는 모든 항목에 대해서는 확인된 대상이 아닌 심볼릭 링크 형태로 작성하십시오.
프롬프트 — 일반 모드
PHASE: <write | validate | test | read>
TASK: <정확한 지침 — 수행할 편집, 찾을 패턴, 실행할 명령어>
FILES:
- <정확한 경로>
DEFINITION OF SUCCESS:
- <검증 명령어와 예상 결과>
DELIVERY:
- 보고서에 검증 출력을 포함하십시오.
판단(Adjudicate)
보고서는 주장입니다. 각각에 대해:
- 증거가 결론을 뒷받침하는지 확인하십시오. 명령어 출력 없이 "테스트 통과"는 증거가 아닙니다. 출력을 위해 재위임하십시오.
- 반환된 작업을 판단하십시오. 다시 도출하지 마십시오. 에이전트가 읽은 내용을 다시 읽는 것은 위임을 통해 절약한 컨텍스트를 낭비하는 것입니다.
- 두 보고서가 충돌하는 경우 → 반증 가능한 주장을 찾아 확인을 위해 위임하십시오. 확신(confidence)은 결정 기준이 아닙니다.
PARTIAL→ 남은 부분을 정확히 명명하고 재위임하십시오.BLOCKED(누락된 입력) → 입력을 제공하고 재위임하십시오. 시도 후에도BLOCKED인 경우 → 접근 방식을 변경하거나 사용자에게 에스컬레이션하고, 동일한 프롬프트를 다시 보내지 마십시오.
동일한 격차에 대해 동일한 단계를 최대 두 번까지 재위임하십시오. 그 후에는 중단하고 격차를 명명하여 사용자에게 BLOCKED를 보고하십시오.
코드를 변경하는 모든 요청은 작성자가 아닌 다른 리뷰어로부터 독립적인 리뷰를 받아야 합니다.
패턴 확장(Pattern expansion)
사용자가 악취, 버그, 또는 누락된 검사의 한 인스턴스를 지목하는 것은 패턴을 명명하는 것입니다. 사용자가 "이것만"이라고 말하지 않은 경우: 해당 패턴에 대해 전체 파일 또는 모듈의 감사를 위임하고, 발견된 인스턴스를 보고한 후, 명명된 파일을 넘어 수정하기 전에 사용자와 확인하십시오.
참고 자료
- references/sub-agent-contract.md — 위임된 에이전트가 따라야 할 내용.
- references/fix-cycle.md — 버그 수정 위임을 위한 재현 우선 사이클.
- parallel-work — 분산(fan-out), 수집(fan-in), 제작자/검사자, 토너먼트, 상한이 있는 루프; Claude Code 도구 메커니즘에 대한 설명도 포함.
orchestrator-discipline이 설치된 경우: 오케스트레이터가 읽고 실행할 수 있는 항목; 훅에 의해 적용됨.process-siren이 설치된 경우: 결정 지점을 평가 가능한 Mermaid 마름모로 작성.