Plan Orchestrate (계획 오케스트레이트)
계획 문서와 /orchestrate custom 명령어를 연결하여, 각 단계별로 바로 붙여넣을 수 있는 호출을 생성합니다. 이 스킬은 생성만 수행하며, 실제로 /orchestrate를 실행하지 않습니다. 사용자는 각 줄을 준비가 되었을 때 붙여넣습니다.
활성화 시기
- 사용자가 다단계 계획 문서(PRD, RFC, 구현 계획)를 가지고 있고, 이를
/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>" "<작업 설명>"
여기서 {ORCH_CMD}는 Phase 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 스타일 정리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가 실패합니다. 생성하기 전에 이 목록과 교차 확인하십시오.
작동 방식
Phase 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로 기본 설정하고 출력 맨 위에 한 줄 경고를 생성합니다:> 경고: ECC 설치를 감지할 수 없습니다; 레거시 형태로 기본 설정합니다. 플러그인 설치를 사용하는 경우 접두사를 수동으로 편집하십시오. - 두 마커가 모두 존재하는 경우(혼합 설치),
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은 센티넬입니다 — 에이전트 이름이 아닙니다. Phase 2 규칙 4와 5가 체인 구성 시code-reviewer/build-error-resolver로 변환합니다.
- 프로브 마커:
-
PyTorch 서브 프로필을 감지합니다:
lang=python이고pyproject.toml/requirements.txt/uv.lock중 하나가torch에 대한 종속성을 선언하면pytorch=true로 설정합니다. 이는build체인 선택에만 영향을 미칩니다(아래 Phase 2 규칙); 리뷰어는python-reviewer로 유지됩니다. -
계획에 선언된 에이전트 이름을 정규화합니다: 계획 텍스트가 에이전트를 플러그인 접두사 형태(예:
ecc:tdd-guide)로 참조하는 경우, 체인을 검증하거나 구성하기 전에 접두사를 제거하여 베어 카탈로그 이름을 얻습니다. 다시 접두사 추가는ECC_MODE(Phase 4)에 따라 출력 시간에만 발생합니다. 미리 접두사가 붙은 이름이 체인 구성에 흘러들어가지 않도록 하십시오 — 플러그인 모드에서 이중 접두사가 발생할 수 있습니다.
Phase 1 — 단계 분해
우선 순위 순서로 "단계 단위"를 식별합니다:
- 명시적 번호 매기기:
## Step N/### Phase N/## N. .../ 최상위 순서 목록. - 테이블의 "Step" 열.
---로 구분된 블록과 동사로 시작하는 제목.- 그렇지 않으면 각 H2를 하나의 단계로 간주합니다.
단계별로 id (1부터 시작), title (80자 이하), intent (1–3 문장), tags를 추출합니다.
Phase 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 (fallback to 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로 확인됩니다. 특별한 경우: Phase 0이pytorch=true로 설정한 경우,<lang>에 관계없이build체인에pytorch-build-resolver를 사용합니다.python-build-resolver는 없습니다;--lang=python과pytorch=true가 아니면build-error-resolver로 확인됩니다.- 태그 없음 단계: 트리거 단어가 일치하지 않으면 체인을
code-reviewer로 설정하고 "Chain rationale" 아래에일치하는 태그 없음; 기본 리뷰 전용 체인을 작성합니다. - 중복 제거 후 체인 길이 ≤ 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및 빌드 해결사 각각)에 의해 게이트되며 추가 리뷰어가 필요하지 않습니다.
Phase 3 — 작업 설명 압축
각 생성된 <task description>은 다음을 충족해야 합니다:
- 자체 포함되어야 함 (첫 번째 에이전트가 계획 문서를 열어둘 필요 없음).
[Plan: <path>#step-<id>]로 시작해야 함.- 1-3개의 검증 가능한 수락 기준 포함.
- 계획이 이 단계에 대해 선언한 경우에만 범위 보호장치(
Out of scope: ...)를 포함. 그대로 상속. 계획에 범위 외부 문장이 없으면 절을 완전히 생략 — 임의로 만들지 마십시오. - 200–600자; 한 줄; 포함된
"는\"로 이스케이프; 리터럴 개행 없음.
Phase 4 — 출력
ECC_MODE에 의해 결정된 형태를 사용하여 Markdown을 생성합니다. 출력은 전체적으로 하나의 형태를 사용합니다 — 모든 {ORCH_CMD}와 모든 에이전트 이름은 Phase 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 Result (계획 오케스트레이션 결과)
**Plan**: `<path>`
**Lang**: `<detected-or-given>`
**ECC mode**: `<plugin | legacy>`
**Steps**: <N>
**Scope**: <all | step:n | range:a-b>
## Steps overview (단계 개요)
| # | Title (제목) | Tags (태그) | Chain (체인) |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |
---
## Step 1 — <title>
**Intent (의도)**: <1–3 문장>
**Tags (태그)**: <a, b>
**Chain rationale (체인 근거)**: <이 체인이 선택된 이유; 어떤 에이전트가 루프를 종료하는지>
```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(...)}표기법은 이 스킬이 런타임에 수행하는 대체를 설명합니다. 실제 생성된 Markdown에는 확인된 문자열이 포함되며, 자리 표시자는 포함되지 않습니다.
모든 단계의 명령을 순서대로 집계한 최종 "Batch execution (일괄 실행)" 블록을 추가하여 사용자가 한 번에 모두 붙여넣을 수 있도록 합니다. 개요 전용 모드에서는 Batch 블록을 건너뜁니다 (아래 "Large plan" 에지 케이스 참조): 개요 테이블만 생성되는 경우, 집계할 단계별 명령이 없습니다.
Phase 5 — 자체 점검 (생성하기 전에 실행)
- 모든 체인의 모든 에이전트가 카탈로그에서 가져왔는지 확인 (계획에 나타난
ecc:접두사 제거 후; Phase 0 단계 5 참조). - 확인된
{ORCH_CMD}및 확인된 모든{AGENT(...)}가 동일한 형태(plugin또는legacy)를 사용하는지 확인 — 하나의 출력에서 혼합되지 않음. - 생성된 출력에
# plugin form/# legacy form주석 및 "접두사 제거" 지침이 남아 있지 않은지 확인. - 임의로 만든
--mode/--gate/--agents=...필드가 없는지 확인. - 각 작업 설명이 한 줄, 큰따옴표, 포함된
"가 이스케이프되었는지 확인. - 각 작업 설명이
[Plan: <path>#step-<id>]로 시작하고 수락 기준(1–3 항목)을 포함하는지 확인.Out of scope:절은 계획에서 상속된 경우에만 존재. - Phase 2 중복 제거 후 체인에 중복 에이전트가 없는지 확인.
- 체인 길이 ≤ 4.
-
impl/refactor/migration으로 태그된 단계가 리뷰어 클래스 에이전트(<lang>-reviewer,code-reviewer,security-reviewer,database-reviewer중 하나)로 끝나는지 확인.