오케스트레이터 파이프라인 (공유 엔진)은(는) 무엇을 하나요?
orch-* 스킬은 얇은 래퍼입니다. 어떤 작업도 직접 재구현하지 않고, 요청을 분류하여 이 파이프라인의 어떤 단계를 실행할지 선택한 후 각 단계를 기존 ECC 에이전트 또는 명령어에 위임합니다. 이 파일이 바로 그 파이프라인입니다.
이 엔진을 직접 호출하지 말고 작업 스킬(
orch-add-feature,orch-fix-defect, …)을 호출하세요. 이 파일은 작업 스킬이 참조하는 레퍼런스입니다.
사용 시기
orch-*작업 스킬이 실행될 때 간접적으로 로드됩니다.- 새 작업을 스킬군에 추가하거나 공유 단계, 게이트, 에이전트 맵을 조정할 때만 직접 읽습니다.
작업군
| 스킬 | 작업 | 트리거 | 첫 번째 단계 |
|---|---|---|---|
orch-add-feature | 기능 추가 | 기능이 아직 존재하지 않음 | 새 기능 조사 + 계획 수립 |
orch-change-feature | 변경 | 동작은 하지만 원하는 동작과 다름 | 기존 동작 및 테스트 수정 |
orch-fix-defect | 수정 | 동작이 잘못됨 | 실패하는 테스트로 재현 후 수정 |
orch-refine-code | 리팩토링 | 동작 유지, 구조 개선 | 테스트 통과 유지하며 구조 변경 |
orch-build-mvp | MVP | 설계/명세 문서로부터 부트스트랩 | 문서 분석 → 수직 슬라이스 |
이 래퍼들은 기존 ECC 명령어를 대체하지 않고 조합합니다:
/feature-dev,/plan,/code-review,/build-fix,/refactor-clean,/gan-build및tdd-workflow스킬.orch-*군은 이 위에 공유 크기 분류기와 두 개의 게이트를 추가하여, 하나의 프레임워크가 다섯 가지 작업을 일관되게 처리합니다.
0단계 — 크기 분류 (적정 규모 결정)
절차의 규모는 변경의 영향 범위에 비례합니다. 세 가지 신호를 기준으로 요청을 점수화하고, 가장 높은 등급을 선택하여 한 줄로 결과를 표시합니다. 사용자가 재정의할 수 있습니다.
| 등급 | 수정 파일 수 | 새 종속성/계약 | 설계 모호성 | 실행 단계 |
|---|---|---|---|---|
| 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단계(Intake)는 항상 실행되며 위 표에서 생략되었습니다. 동점자 해소 규칙: 보안 트리거(아래 참조) 또는 공개 API/계약을 건드리는 것은 파일 수와 관계없이 최소 standard 등급입니다.
단계
각 단계는 위임합니다 — 작업을 직접 수행하지 않습니다.
- 0. Intake (접수) — 요청을 재진술합니다.
orch-build-mvp의 경우 명세/설계 문서를 읽고 범위, 확정된 결정, 기능 목록을 추출합니다. - 1. Research & Reuse (조사 및 재사용) —
rules/common/development-workflow.md에 따라:gh search repos/gh search code, Context7 / 공급업체 문서, 패키지 레지스트리, Exa 순서로 검색합니다. 완전히 새로운 코드보다는 검증된 구현을 채택하는 것을 선호합니다. - 2. Plan (계획 수립) —
planner에이전트(또는 구조적 결정에는architect/code-architect)에 위임합니다. 얇은 수직 슬라이스 순서로 정렬된task_list를 출력합니다. → 게이트 1. - 3. Scaffold (스캐폴드) —
orch-build-mvp전용: 첫 번째 종단 간 슬라이스를 구축합니다. - 4. Implement (TDD 구현) — 각 작업을
tdd-guide에이전트(또는tdd-workflow스킬)를 통해 진행합니다: red → green → refactor. 작업의 첫 번째 단계 규칙을 따릅니다. - 5. Review (검토) —
code-reviewer에이전트 //code-review. 변경 사항이 보안 트리거(아래)를 건드릴 때마다security-reviewer를 추가합니다. - 6. Commit (커밋) — 관례적 커밋(
feat:/fix:/refactor:/ …), 논리적 청크당 하나씩. → 게이트 2.
두 개의 게이트
이 스킬군은 완전 자율이 아닌, 게이트형입니다:
- 게이트 1 — 계획 수립 후.
task_list를 제시합니다. 사용자가 승인할 때까지 구현 코드를 작성하지 않습니다. - 게이트 2 — 커밋 전. 변경 요약과 제안된 커밋 메시지를 제시합니다. 사용자가 확인할 때까지 커밋하지 않습니다.
게이트 사이의 모든 작업은 중단 없이 진행됩니다.
에이전트 / 명령어 맵
| 단계 | 기본 | 대체 / 에스컬레이션 |
|---|---|---|
| Intake / 이해 | 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 참조).
보안 검토 트리거
변경 사항이 다음 중 하나에 닿을 때 security-reviewer를 호출: 인증 또는 권한 부여, 사용자 입력 처리, 데이터베이스 쿼리, 파일 시스템 경로, 외부 API 호출, 암호화, 비밀/자격 증명. (rules/common/security.md에 따름)
인계 결과물
파이프라인은 숨겨진 상태를 유지하지 않습니다 — 계획 문서가 곧 인계 결과물입니다:
task_list(계획 수립에서 생성)가 구현 루프를 구동합니다.- 더 큰 작업은 저장소의
docs/아래에rules/common/development-workflow.md에 따라 PRD / 아키텍처 / 시스템 설계를 생성할 수도 있습니다. - 검토 결과(CRITICAL / HIGH)는 게이트 2 이전에 해결되어야 합니다.
검증 사항
- 크기 등급이 명시되었고 작업과 일치하는가?
- 게이트 1(계획)과 게이트 2(커밋)가 모두 준수되었는가?
- 보안 트리거가 닿은 경우에만
security-reviewer가 실행되었는가? - 커밋이 관례적이며 하나의 논리적 변경에 범위가 한정되었는가?
- 새로 추가되거나 변경된 동작에 대한 테스트가 있으며,
rules/common/testing.md에 따라 적용 범위 ≥ 80%인가?