명령과 스킬 라우팅
Chorus 플러그인은 AI-DLC 파이프라인의 각 단계마다 명령 하나씩을 추가합니다. 이 페이지는 그 명령들의 참고 문서입니다. 각 명령을 언제 실행하는지, 그 API 키에 어떤 권한이 필요한지, 그리고 무엇을 산출하는지를 다룹니다. 파이프라인 자체는 다시 설명하지 않습니다. 그에 대해서는 AI-DLC 워크플로와 아래에 링크한 각 단계 가이드를 읽으세요.
Hermes에서는 skill_view("chorus:idea"), skill_view("chorus:develop"), skill_view("chorus:yolo")로 네임스페이스 스킬을 불러옵니다. 모든 단계와 세 종류의 리뷰어가 포함됩니다. Claude 슬래시 명령이 아니며 모든 Chorus UI 동작을 게이트웨이에서 실행한다는 뜻도 아닙니다.
런타임마다 호출 방식이 다르다
섹션 제목: “런타임마다 호출 방식이 다르다”Claude Code는 이 명령들을 chorus 네임스페이스 아래의 슬래시 명령으로 노출합니다. Codex는 같은 스킬을
$ 접두사로 노출합니다. 동작은 동일하며, 명령을 입력하는 방식만 다릅니다.
# Claude Code — /chorus: 슬래시 명령/chorus/chorus:idea/chorus:proposal/chorus:develop/chorus:review/chorus:quick-dev/chorus:yolo
# Codex — $ 접두사 스킬 이름$chorus$idea$proposal$develop$review$quick-dev$yolo이 페이지의 명령은 모두 Claude Code 형식(/chorus:develop)으로 표기합니다. Codex에서는 $ 형식
($develop)으로 바꿔 읽으세요. 나머지 런타임(OpenClaw, Kiro, Pi)도 같은 스킬을 탑재합니다. 런타임별
호출 참고 사항은 에이전트 플랫폼 아래의 각 페이지를 참고하세요.
/chorus — 라우팅과 설정
섹션 제목: “/chorus — 라우팅과 설정”/chorus # Claude Code$chorus # Codex- 트리거: 세션을 시작할 때, 또는 어떤 단계 명령을 써야 할지 확신이 서지 않을 때 실행합니다. 개요이자 라우터 입구입니다.
- 필요한 권한: 연결된 플러그인과 API 키. 특정 권한은 필요 없습니다.
- 산출물: 워크플로 상태를 바꾸지 않습니다. 플랫폼 개요, 키의 역할과 유효 권한을 알려 주고, 아래의 적절한 단계 명령으로 안내합니다.
단계 명령
섹션 제목: “단계 명령”한눈에 보기:
| 명령 | 필요한 권한 | 산출물 |
|---|---|---|
/chorus:idea | idea:write(요구사항 구체화 해결에는 idea:admin) | 요구사항 구체화를 해결해 계획할 준비가 된, 가져간 아이디어 |
/chorus:proposal | proposal:write + document:write | 제출된 제안 — 문서 초안 + 작업 DAG(draft → pending) |
/chorus:develop | task:write | 작업 보고와 자체 점검한 수락 기준을 갖추고 to_verify까지 진행된 작업 |
/chorus:review | proposal:admin + task:admin | 승인된 제안(초안이 실제 문서와 작업으로 생성)과 검증된 작업(→ done) |
/chorus:quick-dev | task:write(자체 검증에는 task:admin) | 독립 작업 또는 제안에 붙은 작업을 to_verify / done까지 진행 |
/chorus:yolo | 관리자 프리셋 키(모든 리소스의 write + proposal:admin + task:admin) | 프롬프트에서 시작해 아이디어 하나를 완료까지 진행하고 완료 보고서를 작성 |
/chorus:idea — 구상
섹션 제목: “/chorus:idea — 구상”/chorus:idea # Claude Code$idea # Codex- 트리거: 요구사항으로 다듬을 미처리 아이디어가 있을 때. 먼저 가져간 뒤 구조화된 요구사항 구체화 라운드를 실행합니다.
- 필요한 권한: 가져가기와 요구사항 구체화 실행에는
idea:write. 요구사항 구체화의 해결(커밋 게이트)에는 추가로idea:admin이 필요하며, PM 프리셋 키는 이 단계를 관리자 프리셋 키에 넘겨야 합니다. - 산출물: 요구사항 구체화 라운드에 답하고 해결까지 마친, 가져간 아이디어 —
/chorus:proposal로 넘어갈 준비가 된 상태입니다. 아이디어 기록를 참고하세요.
/chorus:proposal — 계획
섹션 제목: “/chorus:proposal — 계획”/chorus:proposal # Claude Code$proposal # Codex- 트리거: 어떤 아이디어의 요구사항 구체화가 해결되어 작업을 계획할 준비가 되었을 때.
- 필요한 권한: 제안 컨테이너, 작업 초안, 의존성 에지에는
proposal:write. PRD, 기술 설계, 명세 초안에는document:write. - 산출물: 문서 초안과 작업 초안 의존성 그래프를 담고, 검증을 거쳐 검토에 제출된 제안(
draft→pending). 제출 시, 훅이 메인 에이전트에게 제안 검토자 생성을 촉구합니다. 자동화 동작을 참고하세요.
/chorus:develop — 개발
섹션 제목: “/chorus:develop — 개발”/chorus:develop # Claude Code$develop # Codex- 트리거: 승인된 작업이 있고, 그중 하나를 구현할 준비가 되었을 때. 사람이 Chorus에서 어떤 아이디어의 개발을
시작하면(
start_development요청), 에이전트는 그 아이디어의 남은 작업 전부를 의존성 순서로 처리합니다. - 필요한 권한: 가져가기, 작업 보고, 수락 기준 자체 점검, 제출에는
task:write. - 산출물:
claim → in_progress → to_verify를 거친 작업. 작업 보고와 자체 점검한 수락 기준을 갖춥니다. 제출 시, 훅이 메인 에이전트에게 작업 검토자 생성을 촉구합니다. 작업 실행를 참고하세요.
/chorus:review — 검토와 거버넌스
섹션 제목: “/chorus:review — 검토와 거버넌스”/chorus:review # Claude Code$review # Codex- 트리거: 제안이
pending이거나 작업이to_verify에 있고, 사람을 대신하는 관리자 역할로 그것들을 처리하고 있을 때. - 필요한 권한: 제안 승인이나 종료에는
proposal:admin, 작업 검증·재오픈·종료와 수락 기준 표시에는task:admin. 완전한 관리자 프리셋 키는 둘 다에 더해 아이디어와 문서를 종료하는 거버넌스 권한도 갖습니다. - 산출물: 승인된 제안(그 문서 초안과 작업 초안이 실제 문서와 작업으로 생성)과 검증된 작업(
to_verify→done), 또는 피드백과 함께 거부·재오픈된 항목. 제안 검토와 검증과 완료를 참고하세요.
/chorus:quick-dev — 직접 작업
섹션 제목: “/chorus:quick-dev — 직접 작업”/chorus:quick-dev # Claude Code$quick-dev # Codex- 트리거: 작고 잘 이해된 작업(버그 수정, 핫픽스, 후속 패치)이라 완전한 아이디어 → 제안 과정이 과할 때.
- 필요한 권한: 작업 생성, 가져가기, 실행에는
task:write. 결과의 자체 검증에는 명시적인task:admin이 필요하며, 그것이 없으면 에이전트는 증거를 게시하고 검증을 사람에게 넘깁니다. - 산출물: 독립 작업(또는
proposalUuid로 기존 제안에 붙은 작업)을to_verify까지, 키가task:admin을 가진 경우done까지 진행합니다.
/chorus:yolo — 완전 자동 파이프라인
섹션 제목: “/chorus:yolo — 완전 자동 파이프라인”/chorus:yolo <prompt> # Claude Code$yolo <prompt> # Codex/chorus:yolo <prompt> --project <project-uuid>- 트리거: 자연어 프롬프트에서 시작해 무인으로 파이프라인 전체를 돌리고 싶을 때. Chorus에서 보낸
yolo_requested요청은 기존 아이디어를 그 아이디어가 있는 단계에서부터 이어서 실행합니다. - 필요한 권한: 관리자 프리셋 API 키 — 모든 리소스의 write에 더해
proposal:admin과task:admin(구체적으로idea:write,proposal:write+proposal:admin,task:write+task:admin, 그리고project:write). 권한이 하나라도 빠지면 스킬은 시작 단계에서 중단합니다. - 산출물: 완전한 한 바퀴 — (지정되지 않았다면) 프로젝트, 아이디어, 자체 요구사항 구체화, 제안, 웨이브 기반 작업 실행, 검토 루프, 관리자 검증, 그리고 필수 완료 보고서. 사람의 명시적 승인 없이는 절대 PR을 병합하거나 푸시하지 않습니다.
에이전트용
섹션 제목: “에이전트용”- 트리거: 라우팅과 역할 확인에는
/chorus($chorus). 각 단계 명령은 해당 단계에 도달했을 때, 또는 사람이 Chorus에서 시작했을 때 실행됩니다 —start_development는 아이디어의 남은 작업 전부에 대해/chorus:develop을 이어서 실행하고,yolo_requested는 아이디어의 현재 단계에서/chorus:yolo를 이어서 실행합니다. - 제약:
- 도구의 가시성은 키의 권한 집합을 따르지만, 핸들러 가드는 여전히 적용됩니다 — 예를 들어
task:write를 가지고 있어도 작업의 담당자만chorus_submit_for_verify를 호출할 수 있습니다. /chorus:yolo는 관리자 프리셋 키를 요구하며, 필요한 권한이 하나라도 빠지면 중단합니다./chorus:quick-dev는 명시적인task:admin이 있을 때만 자체 검증하고, 그렇지 않으면 사람에게 넘깁니다.- Codex에서는 같은 스킬을
$접두사로 호출합니다. 검토와 자동화 기능은 런타임마다 다릅니다. 자동화 동작을 참고하세요. /chorus:yolo에서도 사람의 명시적 승인 없이는 절대 PR을 병합하거나 푸시하지 않습니다.
- 도구의 가시성은 키의 권한 집합을 따르지만, 핸들러 가드는 여전히 적용됩니다 — 예를 들어