오케스트레이터 파이프라인 (공유 엔진)
orch-* 스킬은 얇은 래퍼입니다. 이들은 어떤 작업도 재구현하지 않습니다. 요청을 분류하고, 이 파이프라인의 어느 단계를 실행할지 선택한 후, 각 단계를 기존 ECC 에이전트 또는 명령어에 위임합니다. 이 파일이 바로 그 파이프라인입니다.
이 엔진을 직접 호출하지 말고 오퍼레이션 스킬(
orch-add-feature,orch-fix-defect, ...)을 호출하세요. 이 파일은 이들이 참조하는 레퍼런스입니다.
사용 시기
orch-*오퍼레이션 스킬이 실행될 때마다 간접적으로 로드됩니다.- 계열에 새로운 오퍼레이션을 추가하거나 공유 단계, 게이트, 에이전트 맵을 조정할 때만 직접 읽습니다.
오퍼레이션 계열
| 스킬 | 오퍼레이션 | 트리거 | 첫 번째 동작 |
|---|---|---|---|
orch-add-feature | feature | 기능이 아직 존재하지 않음 | 새로운 슬라이스 연구 + 계획 |
orch-change-feature | tweak | 작동하지만 원하는 동작이 다름 | 기존 동작 및 해당 테스트 수정 |
orch-fix-defect | fix | 깨짐; 동작이 잘못됨 | 실패하는 테스트로 재현 후 수정 |
orch-refine-code | refactor | 동작은 유지, 구조 개선 | 테스트를 통과한 상태로 구조 변경 |
orch-build-mvp | mvp | 디자인/스펙 문서에서 부트스트랩 | 문서 읽어들이기 → 수직 슬라이스 |
이 래퍼들은 기존 ECC 명령어를 대체하지 않고 구성합니다:
/feature-dev,/plan,/code-review,/build-fix,/refactor-clean,/gan-build, 그리고tdd-workflow스킬. orch-* 계열은 공유 크기 분류기와 두 개의 게이트를 그 위에 추가하여 하나의 포괄 체계가 다섯 가지 오퍼레이션을 일관되게 처리합니다.
단계 0 — 크기 분류 (적정 규모화)
의례(ceremony)는 블래스트 반경(blast radius)에 비례합니다. 세 가지 신호로 요청을 점수화하고, 어떤 신호든 가장 높은 등급을 취한 후 한 줄로 결과를 표시하여 사용자가 재정의할 수 있도록 합니다:
| 등급 | 수정 파일 | 새 의존성/계약 | 설계 모호성 | 실행 단계 |
|---|---|---|---|---|
| trivial | 1개 파일, 몇 줄 | 없음 | 없음 — 변경이 명확함 | 4 → 5 → 6 |
| small | 1개 파일 / 1개 함수 | 없음 | 코드를 읽으면 명확함 | (1 경량) → 4 → 5 → 6 |
| standard | 2–5개 파일 | 새 내부 모듈 가능성 | 하나의 실제 선택 필요 | 1 → 2 → 4 → 5 → 6 |
| large | 다수 / 교차 관심사 | 새 외부 의존성, 공개 API, 또는 스펙 문서 | 여러 미해결 질문 | 1 → 2 → (3) → 4 → 5 → 6 |
단계 0(인테이크)은 항상 실행되며 위 마스크 열에서 생략됩니다. 동점자 해소 규칙: 보안 트리거(아래 참조)나 공개 API/계약을 건드리는 것은 파일 수와 관계없이 최소 standard입니다.
단계들
각 단계는 위임합니다 — 작업을 인라인으로 수행하지 않습니다.
- 0. 인테이크 — 요청을 다시 진술합니다.
orch-build-mvp의 경우, 스펙/설계 문서를 읽고 범위, 확정된 결정, 기능 목록을 추출합니다. - 1. 연구 및 재사용 —
rules/common/development-workflow.md에 따라:gh search repos/gh search code, 그 다음 Context7 / 벤더 문서, 그 다음 패키지 레지스트리, 그 다음 Exa. 완전히 새로운 코드보다는 입증된 구현을 채택하는 것을 선호합니다. - 2. 계획 —
planner에이전트(또는 구조적 결정의 경우architect/code-architect)에 위임합니다. 얇은 수직 슬라이스 순서로 정렬된task_list를 출력합니다. → 게이트 1. - 3. 스캐폴드 —
orch-build-mvp전용: 첫 번째 종단간 슬라이스를 구축합니다. - 4. 구현 (TDD) —
tdd-guide에이전트(또는tdd-workflow스킬)를 통해 각 작업을 진행합니다: 레드 → 그린 → 리팩터. 오퍼레이션의 첫 번째 동작 규칙을 따릅니다. - 5. 리뷰 —
code-reviewer에이전트 //code-review. 보안 트리거(아래)를 건드리는 diff가 있을 때마다security-reviewer를 추가합니다. - 6. 커밋 — conventional commits (
feat:/fix:/refactor:/ ...), 논리적 청크당 하나씩. → 게이트 2.
두 게이트
이 계열은 게이트형이며 자율적이지 않습니다:
- 게이트 1 — 계획 후.
task_list를 제시합니다. 사용자가 승인할 때까지 구현 코드를 작성하지 않습니다. - 게이트 2 — 커밋 전. diff 요약과 제안된 메시지를 제시합니다. 사용자가 확인할 때까지 커밋하지 않습니다.
게이트 사이의 모든 것은 중단 없이 진행됩니다.
에이전트 / 명령어 맵
| 단계 | 기본 | 폴백 / 에스컬레이션 |
|---|---|---|
| 인테이크 / 이해 | code-explorer | 조정, 수정, 또는 리팩토링 전에 기존 경로 추적 |
| 계획 | planner | 구조적 호출의 경우 architect, code-architect |
| 구현 | tdd-guide (또는 tdd-workflow 스킬) | 빌드 실패 시 build-error-resolver / /build-fix |
| 리뷰 | code-reviewer / /code-review | 언어 리뷰어 (python-reviewer, typescript-reviewer, ...) |
| 보안 | security-reviewer | — |
| MVP 내부 루프 | /gan-build "<요약>" --skip-planner | gan-generator → gan-evaluator 구동; --max-iterations / --pass-threshold 조정 |
리포지토리에 맞는 언어 리뷰어를 선택하세요 (리포지토리 자체의 CLAUDE.md 참조).
보안 리뷰 트리거
diff가 다음 중 하나라도 건드리면 security-reviewer를 포함하세요: 인증 또는 권한 부여, 사용자 입력 처리, 데이터베이스 쿼리, 파일 시스템 경로, 외부 API 호출, 암호화, 또는 비밀/자격 증명. (rules/common/security.md에 따름.)
핸드오프 산출물
파이프라인은 숨겨진 상태를 전달하지 않습니다 — 계획 문서가 핸드오프 그 자체입니다:
task_list(계획에서) 구현 루프를 구동합니다.- 더 큰 작업은
rules/common/development-workflow.md에 따라 리포지토리의docs/아래에 PRD / 아키텍처 / 시스템 설계를 출력할 수도 있습니다. - 리뷰 결과(CRITICAL / HIGH)는 게이트 2 전에 해결되어야 합니다.
검증
- 크기 등급이 명시되었고 작업과 일치했는지
- 게이트 1(계획)과 게이트 2(커밋)가 모두 존중되었는지
- 보안 트리거가 건드려진 경우에만
security-reviewer가 실행되었는지 - 커밋이 conventional하고 하나의 논리적 변경으로 범위가 지정되었는지
- 새롭거나 변경된 동작에 테스트가 있으며,
rules/common/testing.md에 따라 적용 범위가 80% 이상인지