Plan Orchestrate
계획 문서를 /orchestrate custom에 연결하여 각 단계별로 즉시 복사하여 붙여넣을 수 있는 호출 명령어를 생성합니다. 이 스킬은 생성 전용이며 /orchestrate를 직접 실행하지 않습니다. 사용자는 준비가 되면 각 줄을 붙여넣습니다.
활성화 시기
- 사용자가 다단계 계획 문서(PRD, RFC, 구현 계획)를 가지고 있으며
/orchestrate를 통해 실행하려고 할 때 - 사용자가 "이 계획을 orchestrate 해줘", "각 단계별로 orchestrate 프롬프트를 줘", "이 계획에 대한 체인을 구성해줘"라고 말할 때
- 단계별 계획이 존재하지만 사용자가 단계별로 에이전트를 수동으로 선택하고 싶지 않을 때
건너뛸 때:
- 작업이 단일 임시 단계인 경우 →
/orchestrate custom을 직접 호출합니다. - 계획을 읽을 수 없거나 비어 있는 경우. 명시적인 번호 매기기가 없다는 것만으로 건너뛰지 않습니다. 아래 "명확한 단계 없음" 에지 케이스를 참조하세요.
입력
<plan-doc-path> [--lang=python|typescript|go|rust|cpp|java|kotlin|flutter|auto] [--scope=all|step:<n>|range:<a>-<b>] [--dry-run]
<plan-doc-path>— 필수; 상대 또는 절대 경로 (@docs/...허용)--lang— 리뷰어 언어 변형; 기본값은auto(프로젝트에서 감지)--scope— 출력 단계 제한; 기본값은all--dry-run— 분해 및 체인 근거만 출력; 최종 프롬프트는 출력하지 않음
권위 있는 /orchestrate 형식 (이탈 금지)
{ORCH_CMD} custom "<agent1>,<agent2>,...,<agentN>" "<task description>"
여기서 {ORCH_CMD}는 0단계에서 결정됩니다(아래 참조). 출력에서 명령 문자열은 항상 하나의 구체적인 형식을 사용합니다 — 둘 다 사용하거나 플레이스홀더를 사용하지 않습니다.
custom은 순차적 체인입니다. 각 에이전트의 HANDOFF가 다음 에이전트로 전달됩니다.- 쉼표로 구분된 에이전트 목록. 공백 없음이 선호되며, 하나의 공백은 허용됩니다.
--mode/--gate/--agents=...플래그는 존재하지 않습니다 — 절대 만들지 마십시오.- 에이전트 이름은 이 스킬의 카탈로그에서 가져옵니다. 작업 설명에 포함된 쌍따옴표는
\"로 이스케이프 처리됩니다.
ECC 설치 형태 및 네임스페이싱
두 가지 설치 형태에 따라 슬래시 명령어와 모든 에이전트 이름의 접두사가 결정됩니다. 두 가지는 동기화되어야 합니다 — 출력당 하나의 형태만 사용하고 절대 혼합하지 마십시오:
<claude-home>은 Claude Code 홈 디렉토리를 나타냅니다: macOS/Linux에서는 ~/.claude, Windows에서는 %USERPROFILE%\.claude입니다. 호스트 플랫폼이 사용자 홈 디렉토리를 확인하는 방식으로 확인합니다(~를 하드코딩하지 마십시오).
| 형태 | 감지 | {ORCH_CMD} | 에이전트 이름 형식 |
|---|---|---|---|
| 플러그인 설치 (2.0.0+) | <claude-home>/plugins/marketplaces/ecc/ 존재 | /ecc:orchestrate | ecc:<name> |
| 레거시 기본 설치 | 위 항목 없음; <claude-home>/agents/ 아래 에이전트 파일 존재 | /orchestrate | <name> |
이것이 중요한 이유: 플러그인 설치에서 에이전트는 ecc:tdd-guide로 등록됩니다. 기본 이름은 퍼지 매칭을 강제하며, 병렬 호출 시 간헐적으로 실패합니다. 레거시에서는 접두사가 붙은 형태가 등록되지 않아 바로 실패합니다.
사용 가능한 에이전트 카탈로그 (이 목록에서 선택해야 함)
일반:
planner— 요구사항 재진술, 위험 분해, 단계 계획architect— 아키텍처, 시스템 설계, 리팩터 제안tdd-guide— 테스트 작성 → 구현 → 80%+ 커버리지code-reviewer— 일반 코드 리뷰security-reviewer— 보안 감사, OWASP, 비밀 누출refactor-cleaner— 데드 코드, 중복, knip-class 정리doc-updater— 문서, 코드맵, READMEdocs-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 모드 + 언어 감지
-
<plan-doc-path>를 읽습니다. 없거나 비어 있으면 보고하고 중단합니다. -
ECC 설치 형태를 한 번 감지하고
ECC_MODE에 고정합니다. 알고리즘 (순서대로 실행, 첫 번째 일치에서 중단):<claude-home>/plugins/marketplaces/ecc/가 존재하면ECC_MODE=plugin.- 그렇지 않고
<claude-home>/agents/가 존재하고 최소 하나의 ECC 에이전트 파일(예:tdd-guide.md,code-reviewer.md)을 포함하면ECC_MODE=legacy. - 그렇지 않으면
ECC_MODE=legacy로 기본 설정하고 출력 상단에 한 줄 경고를 표시:> Warning: could not detect ECC install; defaulting to legacy form. If you use the plugin install, edit the prefixes manually. - 두 표시가 모두 존재하는 경우(혼합 설치),
plugin이 우선합니다 — 플러그인 네임스페이스만 퍼지 매칭 없이 에이전트 이름을 확인할 수 있습니다.
이 시점부터 모든 출력 줄은 슬래시 명령어와 모든 에이전트 이름에 일치하는 접두사를 사용합니다. 동일한 출력에 두 형태를 절대 혼합하지 마십시오.
-
--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은 센티넬입니다 — 에이전트 이름이 아닙니다. 2단계 규칙 4와 5에서 체인 구성 시code-reviewer/build-error-resolver로 변환됩니다.
- 프로브 마커:
-
PyTorch 서브 프로필 감지:
lang=python이고pyproject.toml/requirements.txt/uv.lock중 하나가torch에 대한 의존성을 선언하면pytorch=true를 설정합니다. 이는build체인 선택에만 영향을 미칩니다(아래 2단계 규칙); 리뷰어는python-reviewer로 유지됩니다. -
계획에 선언된 에이전트 이름 정규화: 계획 텍스트가 플러그인 접두사가 붙은 형태(예:
ecc:tdd-guide)로 에이전트를 참조하는 경우, 체인을 검증하거나 구성하기 전에 접두사를 제거하여 기본 카탈로그 이름을 얻습니다. 다시 접두사를 붙이는 것은ECC_MODE에 따라 출력 시에만 이루어집니다(4단계). 미리 접두사가 붙은 이름이 체인 구성으로 유입되지 마십시오 — 플러그인 모드에서 이중 접두사가 발생합니다.
1단계 — 단계 분해
우선 순위에 따라 "단위 단계" 식별:
- 명시적 번호:
## Step N/### Phase N/## N. .../ 최상위 순서 목록. - 테이블의 "Step" 열.
- 동사로 시작하는 제목이 있는
---로 구분된 블록. - 그렇지 않으면 각 H2를 하나의 단계로 처리.
각 단계별로 id(1부터 시작), title(80자 이하), intent(1–3문장), tags를 추출합니다.
2단계 — 태깅 및 체인 선택
의도별로 태깅 (다중 태그 허용; 체인은 기본 + 누적된 보조 태그로 구성):
아래 트리거 단어는 대소문자를 구분하지 않고 일치시킵니다. 다국어 계획은 의미가 나열된 영어 트리거 단어와 일치하는 한 모든 언어의 단어 어간을 일치시켜 지원됩니다.
| 태그 | 트리거 단어 | 기본 체인 |
|---|---|---|
design | architecture, design, choose, evaluate, RFC | planner,architect |
plan | plan, breakdown, milestone | planner |
impl | implement, build, add, create, port | tdd-guide,<lang>-reviewer |
test | test, coverage, e2e, integration | tdd-guide,e2e-runner |
refactor | refactor, cleanup, dedupe, split | architect,refactor-cleaner,<lang>-reviewer |
migration | migrate, upgrade, rewrite, port | architect,tdd-guide,<lang>-reviewer |
db | schema, migration, index, SQL, Postgres, alembic, sqlmodel | database-reviewer,<lang>-reviewer |
security | encrypt, auth, secret, OWASP, PII | security-reviewer,<lang>-reviewer |
build | build, compile, lint failure, CI | <lang>-build-resolver (build-error-resolver로 폴백) |
docs | docs, readme, codemap, changelog | doc-updater |
lookup | lookup, reference, API usage | docs-lookup |
review | review, audit, verify | <lang>-reviewer,code-reviewer |
loop | loop, autonomous, watchdog | loop-operator |
체인 구성 규칙:
- 기본 태그 선택: 단계가 여러 태그와 일치하면 테이블 순서에서 첫 번째(테이블 상단 = 가장 높은 우선순위)가 기본 태그이고 나머지는 보조 태그입니다. 아래 구성 규칙 2와 3은 특정 다중 태그 조합을 명시적으로 처리합니다. 그렇지 않으면 태그 테이블 순서대로 보조 체인을 추가합니다.
impl+security→tdd-guide,<lang>-reviewer,security-reviewer.impl+db→tdd-guide,database-reviewer,<lang>-reviewer.- 결과 체인에서 중복 제거 (첫 번째 발생 유지). 예:
review+lang=unknown은 규칙 5 이후code-reviewer,code-reviewer가 됩니다. 중복 제거로code-reviewer로 축소됩니다. <lang>-reviewer는lang=unknown일 때code-reviewer로 확인됩니다.<lang>-build-resolver는lang=unknown일 때build-error-resolver로 확인됩니다. 특수 사례: 0단계에서pytorch=true가 설정된 경우,<lang>에 관계없이build체인에pytorch-build-resolver를 사용합니다.python-build-resolver는 없습니다.--lang=python이고pytorch=true가 아니면build-error-resolver로 확인됩니다.- 태그가 없는 단계: 트리거 단어가 일치하지 않으면 체인을
code-reviewer로 설정하고 "Chain rationale" 아래에no tag matched; default review-only chain을 작성합니다. - 중복 제거 후 체인 길이는 ≤ 4여야 합니다. 초과하면 가장 약한 태그(
lookup및docs먼저)를 드롭합니다. impl체인에planner와architect를 함께 배치하지 마십시오(토큰 낭비).design단계에서만 함께 배치합니다.impl,refactor또는migration으로 태그된 단계는 리뷰어 클래스 에이전트(<lang>-reviewer,code-reviewer,security-reviewer또는database-reviewer중 하나)로 끝납니다. 가장 도메인 특화된 리뷰어가 꼬리 위치를 차지합니다(예: 규칙 2의impl+security는security-reviewer로 끝나고, 규칙 3의impl+db는<lang>-reviewer로 끝납니다.database-reviewer가 체인 초반에 마이그레이션을 게이트하기 때문입니다).test및build단계는 각각 자체 검증기(e2e-runner및 빌드 해결사)에 의해 게이트되며 추가 리뷰어가 필요하지 않습니다.
3단계 — 작업 설명 압축
각 출력 <task description>은 다음을 충족해야 합니다:
- 자체 포함되어야 함 (첫 번째 에이전트가 계획 문서를 열 필요가 없음).
[Plan: <path>#step-<id>]로 시작.- 1–3개의 검증 가능한 수락 기준을 포함.
- 계획이 이 단계에 대해 선언한 경우에만 범위 가드(
Out of scope: ...)를 포함합니다. 그대로 상속합니다. 계획에 범위 외 문장이 없으면 절을 완전히 생략합니다 — 만들지 마십시오. - 200–600자; 한 줄; 포함된
"는\"로 이스케이프 처리; 리터럴 개행 없음.
4단계 — 출력
ECC_MODE에 의해 결정된 형식을 사용하여 마크다운을 출력합니다. 출력은 전체에 걸쳐 하나의 형식을 사용합니다 — 모든 {ORCH_CMD}와 모든 에이전트 이름은 0단계의 일치하는 접두사로 렌더링됩니다. 두 형식을 모두 출력하지 마십시오. 렌더링된 출력에 "이것은 플러그인 형식입니다" / "접두사를 제거하십시오"와 같은 지침을 포함하지 마십시오.
구체적인 렌더링 규칙:
{ORCH_CMD}=plugin에서는/ecc:orchestrate,legacy에서는/orchestrate.{AGENT(name)}=plugin에서는ecc:<name>,legacy에서는<name>.- 개요 테이블 "Chain" 열은 동일한
{AGENT(name)}렌더링을 사용합니다. - 단계별 bash 블록에는 실행 가능한 명령어만 포함됩니다.
# plugin form또는# legacy form주석 없음 — 형식은 암시적이며 전체 출력에서 균일합니다.
출력 구조:
# Plan-Orchestrate 결과
**계획**: `<path>`
**언어**: `<detected-or-given>`
**ECC 모드**: `<plugin | legacy>`
**단계 수**: <N>
**범위**: <all | step:n | range:a-b>
## 단계 개요
| # | 제목 | 태그 | 체인 |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |
---
## 단계 1 — <title>
**의도**: <1–3문장>
**태그**: <a, b>
**체인 근거**: <이 체인이 선택된 이유; 어떤 에이전트가 루프를 종료하는지>
```bash
{ORCH_CMD} custom "{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}" "[Plan: docs/foo.md#step-1] <압축된 작업 설명>; Acceptance: <1–3개 항목>; Out of scope: <…>"
```
위의
{ORCH_CMD}및{AGENT(...)}표기법은 이 스킬이 런타임에 수행하는 대체를 설명합니다. 실제로 출력되는 마크다운에는 확인된 문자열이 포함되며 플레이스홀더는 포함되지 않습니다.
모든 단계의 명령어를 순서대로 집계한 마지막 "일괄 실행" 블록을 추가하여 사용자가 한 번에 모두 붙여넣을 수 있도록 합니다. 개요 전용 모드에서는 배치 블록을 건너뜁니다 (아래 "대규모 계획" 에지 케이스 참조): 개요 테이블만 출력할 때는 단계별 명령어를 집계할 항목이 없습니다.
5단계 — 자체 점검 (출력 전 실행)
- 모든 체인의 모든 에이전트가 카탈로그에서 왔는지 확인 (계획에 나타난
ecc:접두사 제거 후; 0단계 5단계 참조). - 확인된
{ORCH_CMD}와 모든 확인된{AGENT(...)}가 동일한 형식(plugin또는legacy)을 사용하는지 확인 — 하나의 출력에서 혼합되지 않음. - 렌더링된 출력에
# plugin form/# legacy form주석 및 "접두사를 제거하십시오" 지침이 없는지 확인. - 발명된
--mode/--gate/--agents=...필드가 없는지 확인. - 각 작업 설명이 한 줄, 쌍따옴표로 묶이고, 포함된
"가 이스케이프 처리되었는지 확인. - 각 작업 설명이
[Plan: <path>#step-<id>]로 시작하고 Acceptance (1–3개 항목)를 포함하는지 확인.Out of scope:절은 계획에서 상속된 경우에만 존재. - 2단계 중복 제거 후 체인에 중복 에이전트가 없는지 확인.
- 체인 길이 ≤ 4.
-
impl/refactor/migration으로 태그된 단계가 리뷰어 클래스 에이전트로 끝나는지 확인.