• — 필수; 상대 경로 또는 절대 경로(@docs/... 허용).
• --lang — 검토 대상 언어 변형; 기본값은 auto (프로젝트에서 감지됨)입니다.
• --scope — 출력되는 단계를 제한합니다; 기본값은 all입니다.
• --dry-run — 분해 및 체인 근거만 출력하고, 최종 프롬프트는 출력하지 않습니다.

권위 있는 /orchestrate 형식 (이로부터 벗어나지 마십시오)

{ORCH_CMD} custom ",,...," ""

여기서 {ORCH_CMD}는 0단계에서 결정됩니다(아래 참조). 출력된 명령 문자열은 항상 하나의 구체적인 형태를 사용해야 하며, 두 가지 형태를 혼용하거나 자리 표시자를 사용해서는 안 됩니다.

• custom은 순차적인 체인이며, 각 에이전트의 HANDOFF가 다음 에이전트로 전달됩니다.
• 쉼표로 구분된 에이전트 목록입니다. 공백은 사용하지 않는 것이 좋으나, 한 개의 공백은 허용됩니다.
• --mode / --gate / --agents=... 플래그는 존재하지 않으므로 절대 임의로 생성하지 마십시오.
• 에이전트 이름은 이 스킬의 카탈로그에서 가져옵니다. 작업 설명에 포함된 쌍따옴표는 \"로 이스케이프 처리됩니다.

ECC 설치 형식 및 네임스페이스

두 가지 설치 형식이 슬래시 명령어 와 모든 에이전트 이름의 접두사를 결정합니다. 이 두 형식은 반드시 일치해야 하며, 출력마다 하나의 형식만 사용해야 하고 절대로 혼합해서는 안 됩니다:

~ Claude Code 홈 디렉터리를 ~/.claude (macOS/Linux) 또는 %USERPROFILE%\.claude (Windows)로 표기합니다. 호스트 플랫폼에서 사용자 홈 디렉터리를 해결하는 방식에 따라 이를 처리하십시오( ~를 하드코딩하지 마십시오).

이 문제가 중요한 이유: 플러그인 설치 방식에서는 에이전트가 everything-claude-code:tdd-guide로 등록됩니다. 접미사 없는 이름은 모호한 일치(fuzzy matching)를 유발하며, 이는 병렬 호출 시 간헐적으로 실패합니다. 레거시 방식에서는 접두사가 붙은 형태가 등록되지 않아 아예 실패합니다.

사용 가능한 에이전트 목록 (이 중에서 선택해야 함)

일반:

• planner — 요구사항 재진술, 위험 분해, 단계별 계획 수립
• architect — 아키텍처, 시스템 설계, 리팩토링 제안
• tdd-guide — 테스트 작성 → 구현 → 80% 이상의 커버리지 달성
• 코드 검토자 — 일반적인 코드 검토
• 보안 검토자 — 보안 감사, OWASP, 기밀 정보 유출
• 리팩토링 정리 담당자 — 사멸 코드, 중복 코드, knip 클래스 정리
• 문서 업데이트 담당자 — 문서, 코드맵, README
• docs-lookup — 타사 라이브러리 API 조회 (Context7)
• e2e-runner — 종단 간 테스트 오케스트레이션
• database-reviewer — PostgreSQL 스키마, 마이그레이션, 성능
• harness-optimizer — 로컬 에이전트 하네스 구성
• loop-operator — 장시간 실행되는 자율 루프
• chief-of-staff — 다중 채널 분류 (계획 단계에는 거의 적합하지 않음)

빌드 오류 해결기:

• build-error-resolver (일반) / cpp-build-resolver / go-build-resolver / java-build-resolver / kotlin-build-resolver / rust-build-resolver / pytorch-build-resolver

코드 검토자:

• python-reviewer / typescript-reviewer / go-reviewer / rust-reviewer / cpp-reviewer / java-reviewer / kotlin-reviewer / flutter-reviewer

에이전트 이름에 오타가 있으면 /orchestrate가 실패합니다. 출력하기 전에 이 목록과 대조하여 확인하십시오.

작동 원리

0단계 — ECC 모드 및 언어 감지

1. 읽기 . 누락되었거나 비어 있으면 보고하고 중단합니다.

2. ECC 설치 양식을 한 번 감지한 후 ECC_MODE로 고정합니다. 알고리즘 (순서대로 실행하며, 첫 번째 일치 항목에서 중단):

   1. /plugins/marketplaces/everything-claude-code/가 존재하면 → ECC_MODE=plugin.
   2. 그렇지 않은 경우, /agents/가 존재하고 적어도 하나의 ECC 에이전트 파일(예: tdd-guide.md, code-reviewer.md)을 포함하는 경우 → ECC_MODE=legacy.
   3. 그렇지 않은 경우 → 기본적으로 ECC_MODE=legacy로 설정하고 출력 상단에 한 줄의 경고를 표시합니다: > 경고: ECC 설치를 감지할 수 없음; 기본적으로 레거시 형식으로 설정됩니다. 플러그인 설치를 사용하는 경우 접두사를 수동으로 편집하십시오.
   4. 두 마커가 모두 존재하는 경우(혼합 설치), 플러그인이 우선합니다. 즉, 플러그인 네임스페이스만이 퍼지 매칭 없이 에이전트 이름을 해결합니다.

   이 시점부터 출력되는 모든 줄은 슬래시 명령 과 모든 에이전트 이름에 일치하는 접두사를 사용합니다. 동일한 출력에 두 형식을 모두 출력해서는 안 됩니다.

3. --lang을 해결합니다. 'auto'인 경우, 다중 언어 감지 기능을 실행합니다:

   • 탐지 마커: pyproject.toml / uv.lock / requirements.txt → python; package.json → typescript; go.mod → go; Cargo.toml → rust; CMakeLists.txt 또는 최상위 *.cpp → cpp; pom.xml / build.gradle (Java) → java; build.gradle.kts 또는 최상위 Kotlin → kotlin; pubspec.yaml → flutter.
   • 다중 언어 동점 처리: 일치하는 마커가 두 개 이상인 경우, 소스 파일 수가 가장 많은 언어를 선택합니다( git ls-files를 통해 집계하며, vendor/, node_modules/, dist/, build/, .venv/, 생성된 파일 및 명백한 테스트 피처는 제외). 동점인 경우나 어떤 언어도 소스 파일의 60%를 초과하지 않는 경우, lang=unknown으로 설정합니다.
   • 일치하는 마커가 없는 경우 → lang=unknown으로 설정합니다.
   • lang=unknown은 센티넬(sentinel)이며, 에이전트 이름이 아닙니다. 2단계 규칙 4와 5는 체인 구성 시점에 이를 코드 검토자(code-reviewer) 또는 빌드 오류 해결자(build-error-resolver) 로 변환합니다.

4. PyTorch 하위 프로필 감지: lang=python이고 pyproject.toml / requirements.txt / uv.lock 중 어느 하나라도 torch에 대한 의존성을 선언하면 pytorch=true로 설정합니다. 이는 빌드 체인 선택(아래 2단계 규칙)에만 영향을 미치며, 검토자는 python-reviewer로 유지됩니다.

5. 계획에 선언된 모든 에이전트 이름을 정규화: 계획 텍스트에서 에이전트를 플러그인 접두사가 붙은 형태(예: everything-claude-code:tdd-guide)로 참조하는 경우, 체인을 검증하거나 구성하기 전에 접두사를 제거하여 기본 카탈로그 이름을 얻습니다. 접두사 재부여는 ECC_MODE에 따라 출력 시점(4단계)에만 수행됩니다. 접두사가 미리 부여된 이름이 체인 구성 단계로 유입되지 않도록 하십시오. 그렇지 않으면 플러그인 모드에서 접두사가 중복 적용될 수 있습니다.

1단계 — 단계 분해

우선순위 순서대로 “단계 단위”를 식별합니다:

1. 명시적인 번호 매기기: ## 단계 N / ### 단계 N / ## N. ... / 최상위 순서 목록.
2. 표의 “단계(Step)” 열.
3. ----로 구분된 블록과 동사 중심의 제목.
4. 그렇지 않은 경우 각 H2를 하나의 단계로 취급합니다.

단계별로 ID (1부터 시작), 제목 (80자 이하), 의도 (1~3문장), 태그를 추출합니다.

2단계 — 태그 지정 및 체인 선정

의도에 따라 태그 지정(다중 태그 허용; 1차 태그 + 중첩된 2차 태그로 체인 구성):

아래의 트리거 단어는 대소문자를 구분하지 않고 일치시킵니다. 다국어 계획은 의미가 나열된 영어 트리거 단어와 일치하는 한, 어떤 언어의 어간과도 일치시켜 지원됩니다.

체인 구성 규칙:

1. 주 태그 선택: 한 단계가 여러 태그와 일치할 경우, 테이블 순서상 첫 번째 태그 (테이블 상단 = 최우선순위)가 주 태그가 되며, 나머지는 보조 태그가 됩니다. 아래의 구성 규칙 2와 3은 특정 다중 태그 조합을 명시적으로 처리하며, 그 외의 경우에는 태그 테이블 순서대로 보조 체인을 추가합니다.
2. impl + security → tdd-guide,-reviewer, security-reviewer.
3. impl + db → tdd-guide,database-reviewer,-reviewer.
4. 결과 체인에서 중복을제거합니다 (첫 번째 발생 항목은 유지). 예: review + lang=unknown은 규칙 5 적용 후 code-reviewer,code-reviewer가 되지만, 중복 제거를 통해 code-reviewer로 통합됩니다.
5. -reviewer는 lang=unknown일 때 code-reviewer 로 해결됩니다.
6. - build -resolver는 lang=unknown일 때 build-error-resolver 로 해결됩니다. 특수한 경우: Phase 0에서 pytorch=true로 설정된 경우, . python-build-resolver는 존재하지 않으며, pytorch=true가 설정되지 않은 상태에서 --lang=python을 지정하면 build-error-resolver로 해결됩니다.
7. 태그가 없는 단계: 일치하는 트리거 단어가 없으면 체인을 code-reviewer로 설정하고 '일치하는 태그 없음'이라고 기록합니다 . "체인 근거" 항목에는 기본적으로 review-only 체인이 표시됩니다.
8. 중복 제거 후 체인 길이는 4 이하여야 합니다. 이를 초과할 경우 가장 약한 태그(검색 및 문서 태그부터 우선)를 제거합니다.
9. 임플레멘테이션 체인에서는 플래너와 아키텍트를 짝지우지 마십시오(토큰 낭비). 디자인 단계에서만 짝지우십시오.
10. impl, refactor 또는 migration 태그가 지정된 단계는 reviewer-class 에이전트( -reviewer, code-reviewer, security-reviewer 또는 database-reviewer 중 하나)로 끝납니다. 해당 도메인에 가장 특화된 검토자가 마지막 위치를 차지합니다(예: 규칙 2의 impl+security는 security-reviewer로 끝나고, 규칙 3의 impl+db는 -reviewer로 끝납니다. database-reviewer가 체인의 앞부분에서 이미 마이그레이션을 게이트 처리했기 때문입니다). 테스트 및 빌드 단계는 각각의 유효성 검사기(각각e2e-runner 및 빌드 해결기)에 의해 제어되며, 추가 검토자가 필요하지 않습니다.

3단계 — 작업 설명 압축

발생된 각 는 다음 조건을 충족해야 합니다:

• 자립적이어야 합니다(첫 번째 에이전트가 계획 문서를 열어둘 필요가 없음).
• [Plan: #step-]로 시작해야 합니다.
• 검증 가능한 1~3개의 수용 기준을 포함해야 합니다.
• 계획에서 해당 단계에 대한 범위 제한(범위 외: ...) 을 명시한 경우에만 이를 포함해야 합니다. 그대로 그대로 상속받아야 합니다. 계획에 범위 외 문구가 없는 경우, 해당 절을 완전히 생략해야 하며 — 임의로 만들어서는 안 됩니다.
• 200~600자, 한 줄로 작성하십시오. "는 \"로 이스케이프 처리하고, 리터럴 줄바꿈은 사용하지 마십시오.

4단계 — 출력

ECC_MODE에 의해 결정된 형식을 사용하여 마크다운을 출력하십시오. 출력은 전체적으로 하나의 형식을 사용해야 합니다. 모든 {ORCH_CMD} 와 모든 에이전트 이름은 0단계에서 지정된 일치하는 접두사와 함께 렌더링됩니다. 두 가지 형식을 모두 출력해서는 안 되며, 렌더링된 출력에 “이것은 플러그인 형식입니다” / “접두사를 제거하세요”와 같은 지침을 포함해서는 안 됩니다.

구체적인 렌더링 규칙:

• {ORCH_CMD} = 플러그인 환경에서는 /everything-claude-code:orchestrate, 레거시 환경에서는 /orchestrate.
• {AGENT(name)} = 플러그인 환경에서는 everything-claude-code:, 레거시 환경에서는.
• 개요 표의 "Chain" 열은 동일한 {AGENT(name)} 렌더링을 사용합니다.
• 단계별 bash 블록에는 실행 가능한 명령만 포함됩니다. # plugin 형식이나 # legacy 형식 주석은 없습니다. 형식은 암시적이며 전체 출력에서 일관되게 적용됩니다.

출력 구조:

# Plan-Orchestrate 결과

**계획**: ``
**언어**: ``
**ECC 모드**: ``
**단계**: 
**범위**: 

## 단계 개요

| # | 제목 | 태그 | 체인 |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |

---

## 1단계 —