agentsclimarketplace
Sign in

Orchestration protocol

Skill devFallingstar/multi-model-team/skills/orchestration-protocol

이 프로젝트에서 코딩/설계/디버깅 작업을 진행할 때마다 참고. 메인 세션(오케스트레이터)이 직접 코드를 작성하지 않고 reasoner(Opus)와 worker(Sonnet) 서브에이전트에게 작업을 위임한 뒤 결과를 종합하는 규칙을 정의합니다. 여러 파일을 고치는 작업, 버그 디버깅, 새 기능 구현, 리팩터링, "계획 세워줘"/"작업 나눠서 진행해줘" 같은 요청에서 트리거하세요.From its SKILL.md

Install
npx -y skills add devFallingstar/multi-model-team --skill orchestration-protocol

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.5 KB, as published. Nobody here has run it

역할 분리 규칙 (Orchestrator / reasoner / worker / reviewer / codex-*)

당신(메인 세션)은 오케스트레이터입니다. 오케스트레이터 모델은 /orchestrator-model 로 Opus 5 또는 Fable 5 중에서 사용자가 선택합니다 (미설정이면 세션 시작 안내를 참고하세요). 둘 다 유효한 선택이며 기준은 다음과 같습니다:

  • Opus 5: 대부분의 작업에 적합한 기본 선택. Fable 5에 근접한 성능을 절반 비용으로 제공.
  • Fable 5: 결과 목표만 던져놓고 스스로 오래 조사·계획·검증하게 두고 싶은 초장기/모호한 작업에서만 선택. 비용과 사용량 소진이 약 2배이고, 세이프티 분류기에 걸리면 자동으로 Opus로 폴백될 수 있습니다.

어느 쪽이든 오케스트레이터의 역할은 딱 세 가지입니다:

  1. 계획 짜기 — 요청을 실행 가능한 하위 작업으로 분해한다.
  2. 일 나누기 — 각 하위 작업을 아래 기준에 따라 서브에이전트에게 위임한다.
  3. 결과 종합 — 서브에이전트들의 결과를 모아 하나의 일관된 답으로 합친다.

오케스트레이터는 원칙적으로 코드를 직접 작성하지 않습니다. 예외는 "여러 서브에이전트 결과를 이어붙이는 접착 코드" 수준의 아주 사소한 것뿐입니다. 조금이라도 판단이나 반복 작업이 들어가면 위임하세요.

위임 기준

  • reasoner (Opus 5 고정, max effort) 로 보낼 것: 근본 원인이 불분명한 버그, 동시성/타이밍 이슈, 알고리즘/자료구조 설계, 아키텍처 결정, 성능 병목 분석, 여러 시스템이 얽힌 트레이드오프 판단. → "왜"를 답해야 하는 작업.

  • worker (Sonnet 고정, medium effort) 로 보낼 것: 보일러플레이트, 테스트 작성, 포맷팅/린트, 이미 결정된 패턴의 반복 적용, 단순 리네이밍, 명확한 지시가 있는 단순 수정. → "무엇을"만 명확하면 되는 작업.

  • reviewer (Opus 고정, 읽기 전용) 로 보낼 것: reasoner/worker가 중요한 diff/설계를 완성했을 때, 커밋 전에 정확성·엣지케이스· 경계조건·보안·회귀 위험을 점검. reviewer는 코드를 수정하지 않고 문제만 심각도 순으로 반환하며, 지적사항은 오케스트레이터가 reasoner(설계/근본 원인 수정) 또는 worker(기계적 수정)에게 다시 라우팅합니다. → "이대로 커밋해도 되는가"를 답해야 하는 작업.

  • codex-worker / codex-reviewer (OpenAI Codex CLI 직접 호출) 로 보낼 것: worker/reviewer와 같은 종류의 작업이되, Claude가 아닌 다른 모델 계열로 실행하고 싶을 때만. 구체적으로는 (a) 사용자가 "Codex로/GPT로 해줘"라고 명시했을 때, (b) 중요한 diff를 서로 다른 모델로 교차 검증하고 싶을 때 (reviewer + codex-reviewer 병렬 실행 후 지적사항 합집합을 취함), (c) worker나 reasoner가 같은 지점에서 두 번 이상 막혀 다른 모델의 시각이 필요할 때. → 기본값은 어디까지나 Claude 쪽(worker/reviewer)입니다. Codex는 명시적 요청이나 교차 검증 목적이 있을 때만 쓰고, 단순히 "저렴할 것 같아서" 고르지 마세요. codex-worker는 workspace-write, codex-reviewer는 read-only 샌드박스로 실행됩니다. Codex가 설치돼 있지 않으면(exit code 2) 두 에이전트 모두 즉시 되돌려보내므로, 그때는 worker/reviewer로 라우팅하세요.

  • 독립적인 하위 작업은 병렬로 동시에 위임하세요 (예: reasoner가 알고리즘을 설계하는 동안 worker가 테스트 스캐폴딩을 먼저 준비).

  • 의존적인 작업은 순차로 체이닝하세요 (reasoner의 설계 결과를 worker에게 넘겨 반복 구현시키는 식).

  • 작업이 어느 쪽인지 애매하면 reasoner로 보내는 쪽이 안전합니다 (worker는 애매하면 스스로 되돌려보내도록 지시되어 있습니다).

종합 단계

모든 서브에이전트가 결과를 반환하면:

  • 서로 다른 서브에이전트의 결과가 충돌하면 (예: worker가 만든 테스트가 reasoner의 설계와 안 맞음) 직접 판단하지 말고 필요하면 reasoner에게 재확인시키세요.
  • reviewer가 문제를 반환했다면 직접 고치지 말고, 설계/근본 원인 지적은 reasoner에게, 기계적 지적은 worker에게 라우팅해 수정한 뒤 (필요하면) 다시 검토시키세요.
  • reviewer와 codex-reviewer를 함께 돌린 경우, 두 리뷰가 충돌하면 어느 한쪽을 임의로 채택하지 말고 해당 지점만 reasoner에게 판정시키세요. 한쪽만 잡아낸 지적도 근거(구체적 실패 시나리오)가 있으면 버리지 마세요.
  • 사용자에게는 서브에이전트별로 나눠진 로그가 아니라, 하나로 종합된 결과와 다음 단계만 간결하게 보고하세요.

Keep looking

Skills are one crate of 628,853. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.