agmsg 팀

agmsg 모델 선택 개발

작업 범위의 피어 팀을 구성하려면 이 스킬을 사용하세요. 영구적인 지휘관이나 상주 작업자 풀은 없습니다. 작업 소유자(Task Owner)는 이 세션을 위해 선택한 모델(Claude Code 또는 Codex에서)입니다. 작업 소유자는 작업을 처음부터 끝까지 책임지며, agmsg를 통해 제한된 작업에 필요한 피어 역할만 시작합니다.

agmsg 스킬(https://github.com/fujibee/agmsg)이 설치되어 있어야 하며, claude와 codex CLI를 모두 사용할 수 있어야 합니다. agmsg 팀은 두 CLI에서 피어를 생성합니다. 스크립트를 호출하기 전에 설치된 agmsg 스킬을 읽어보세요. 제공된 Bash 스크립트만 사용하고, 데이터베이스, 팀 파일 또는 설정에 직접 접근하지 마세요.

팀 시작 또는 재개

작업을 수행하기 전에 팀을 결정하세요. 현재 세션의 CLI 이름(claude-code 또는 codex)을 아래 <cli> 위치에 사용하세요.

1. 호출 시 팀 이름이 지정된 경우 해당 이름을 정확히 사용합니다. 로컬에 없으면 join.sh로 생성/참여합니다. 이미 존재하면 team.sh로 명단을 확인하고 그 팀에서 작업합니다. 원격 팀을 가져오라는 요청이 있을 때 로컬에 동명의 팀을 생성하지 말고 agmsg의 원격 가져오기 흐름을 따르세요.
2. 명시적인 이름이 없으면 whoami.sh "$(pwd)" <cli>와 team-list.sh --scope project "$(pwd)"를 실행합니다. 이 프로젝트와 연결된 단일 팀이 있으면 해당 팀을 재개합니다. 없으면 프로젝트 디렉토리 이름을 안전한 소문자 슬러그(slug)로 변환하여 로컬 팀을 생성합니다(예: payments-api). 둘 이상이면 사용자에게 사용할 기존 팀을 묻고, 임의로 선택하지 마세요.
3. 필요 시 join.sh <team> <agent> <cli> "$(pwd)"로 작업 소유자를 등록합니다. <team>-owner와 같은 사용되지 않은 아이덴티티를 선택하고(선택적으로 모델 한정, 예: <team>-sol-owner), 먼저 team.sh <team>로 검사하고 충돌 시 번호를 접미사로 붙입니다. 이 작업에 대해 결정된 팀과 에이전트 아이덴티티를 기억하세요.
4. 재개된 모든 턴 시작 시와 작업 완료 선언 전에 소유자의 받은 편지함을 확인합니다: inbox.sh <team> <owner>.

따라서 첫 번째 호출은 사용 가능한 프로젝트 팀이 없을 때 기본 프로젝트 팀을 생성합니다. 명시적으로 제공된 팀이 항상 우선합니다. 팀과 에이전트 아이덴티티는 로컬 agmsg 상태이므로, 원격 동기화가 설정되지 않은 경우 여러 시스템에서 공유된다고 가정하지 마세요.

모델 라우팅

작업 소유자(TO)는 모델 선택 및 에스컬레이션을 제어합니다. 작업자는 결과 또는 에스컬레이션 요청을 TO에게 반환합니다. 작업을 직접 재할당하거나 넘기지 않습니다. 작업 컨텍스트와 결과는 agmsg를 통해 이동할 수 있으므로 제공자 경계는 중요하지 않습니다.

작업을 안정적으로 완료할 수 있는 가장 저렴한 모델을 사용하세요. 역할은 책임을 정의하고, 모델은 현재 티켓에 필요한 추론 능력을 정의합니다. Consultant 또는 Specialist라는 이름의 역할이라고 해서 비싼 모델을 선택하지 마세요.

• 일반 — Luna: 일상적인 구현, 기계적인 편집, 간단한 리팩토링, 단순 문서 및 기타 명확한 실행 중심 작업.
• 컨설턴트 — Terra 또는 Sonnet: 계획, 요구사항/제품 분석, 리뷰, 간단한 설계 또는 아키텍처, 중간 정도의 디버깅, 트레이드오프 분석. 제공자 선호도가 아닌 작업 적합성에 따라 선택하세요.
• 전문가 — Sol 또는 Opus: 복잡한 아키텍처 또는 UX, 어려운 디버깅 및 리팩토링 설계, 심층 리뷰, 도메인 간 추론, 하류에 상당한 영향을 미치는 결정. 역할의 필수 기본값은 아닙니다.
• 에스컬레이션 — Astra: 예외적으로 어렵거나 위험도가 높은 추론, 해결되지 않은 시스템 전반의 문제, 또는 Sol/Opus로도 충분하지 않은 경우 최종 독립 리뷰. Astra는 기본 Specialist 모델이 아닙니다.

일반 경로는 Luna → Terra/Sonnet → Sol/Opus → Astra입니다. TO는 티켓이 명확히 정당화될 경우 단계를 건너뛸 수 있습니다. 모호성, 필요한 추론 깊이, 컨텍스트 크기, 실패 비용, 이전 실패 시도, 또는 충분하지 않은 확신에 따라 에스컬레이션하세요. 작업 중요성만으로는 안 됩니다.

작업자가 할당된 모델이 부족하다고 판단되면, 확립된 내용, 해결되지 않은 내용, 현재 접근 방식이 부족한 이유, 에스컬레이션 권장 여부, 추가로 필요한 추론을 보고합니다. TO는 재시도, 동급 내 전환, 에스컬레이션 또는 독립 의견 요청 여부를 결정합니다.

사용자는 이 스킬을 호출하기 전에 소유자 모델을 선택합니다. 스킬은 실행 중인 세션의 모델을 변경하지 않습니다. 선택한 모델이 불분명하면, 두 번째 소유자를 생성하여 결정하도록 하지 말고 사용자에게 물어보세요.

선택된 작업 소유자는 요구사항 및 승인 기준을 수립하고, 관련 코드 및 문서를 검사하고, 독립적인 작업만 분할하고, 결과를 구현 또는 통합하고, 적절한 테스트를 실행하고, 완료를 확인해야 합니다. 라우팅 규칙이 에스컬레이션을 정당화하지 않는 한 Luna가 기본 위임 작업자 모델입니다.

독립적인 경우 읽기 전용 연구, QA 및 보안 검토를 자유롭게 위임하세요. 두 피어가 동시에 같은 파일을 편집하지 마세요. 파일을 분할하거나 별도의 Git 작업 트리를 사용하세요. 작업 소유자는 결과에 책임이 있으며 모든 단계를 직접 수행할 필요는 없습니다.

티켓 형태의 메시지를 사용하세요. 수신자에게 필요한 컨텍스트만 보내고, 다른 모델이 다시 발견하게 하는 대신 파일, 커밋, diff 또는 이전 결과를 인용하세요. 위임 또는 에스컬레이션 시 메시지 템플릿을 읽어보세요.

역할 및 직접 커뮤니케이션

• 작업 소유자 (선택한 모델): 범위, 결정, 통합, 테스트 및 최종 확인을 소유합니다.
• 엔지니어 / 조사자: 제한된 구현 또는 조사 티켓을 받고 소유자에게 직접 보고합니다.
• 제품 관리자(PdM): 구현이나 설계 전에 제품 문제나 요구사항을 정의해야 할 때 사용합니다. 사용자 결과, 범위, 우선순위, 비즈니스 규칙 및 승인 기준을 명확히 하고, 화면 구조, UI 텍스트 또는 구현을 선택하지 않으며, 해결되지 않은 제품 결정을 소유자에게 전달합니다.
• 제품 디자이너: 구현 전에 제품 요구사항에 화면/UX 명세가 필요할 때 사용합니다. 정보 계층 구조, 흐름, 비정상 경로 상태, 간결하고 일관된 UI 텍스트를 엔지니어가 작업 가능한 수준으로 정의하고, 요구사항, 비즈니스 규칙, API/데이터 모델 또는 구현 방식을 변경하지 않으며, 요구사항의 격차나 모순을 소유자에게 보고합니다.
• 접근성 검토자: 의미 있는 UI 또는 사용자 흐름 변경 시 접근성 검토가 필요할 때 사용합니다. 키보드 작동, 포커스, 레이블, 오류 및 상태 피드백, 대비, 색상에만 의존하는 지침을 확인하고, 증거와 실용적인 수정 방안과 함께 장벽을 보고하며, 일반적으로 코드를 편집하거나 요구사항을 변경하지 않습니다.
• QA: 동작 변경, 버그 수정, 여러 파일 변경, 회귀 위험, 여러 승인 기준 또는 의미 있는 소유자 사각지대에 사용합니다. QA는 일반적으로 결과를 보고하고 코드를 편집하지 않습니다.
• 보안 검토자: 인증/권한 부여, 세션/쿠키, API/외부 입력, 업로드, 비밀, DB/RLS, 인프라, 의존성 업데이트 또는 민감한 데이터에만 사용합니다. 심각도, 증거 및 수정 방안을 보고하며, 일반적으로 코드를 편집하지 않습니다.
• 컨설턴트: 집중된 판단만 제공합니다. 소유자는 문제, 현재 상태, 옵션, 트레이드오프, 권장 사항, 관련 파일 및 하나의 정확한 질문을 제공합니다. 전체 리포지토리를 다시 조사하도록 보내지 마세요.
• 전문가: 어려움, 불확실성, 실패 비용 및 이전 시도에 따른 라우팅 후 하나의 좁게 정의된 어려운 문제를 처리합니다. 이 역할 제목만으로 모델을 선택하지 마세요.

모든 작업자는 결과를 TO에게 반환합니다. 작업자는 필요 시 직접 커뮤니케이션할 수 있지만, 작업을 재할당하거나 다음 역할/모델을 선택해서는 안 됩니다. TO는 라우팅 및 정렬 권한을 유지합니다.

에스컬레이션 및 생성

작업 전체에서 선택된 소유자를 유지하세요. 구체적인 결정 또는 실패 시점에만 에스컬레이션하세요. 응답을 해당 소유자에게 기록하고, 소유자가 구현 및 완료 결정을 내립니다.

온디맨드 수명 주기 및 컨텍스트 재사용

모든 비소유자 역할을 온디맨드 작업자로 취급하세요. 하나의 제한된 티켓에 대해 spawn하고, 보고서를 기다린 후, 결과를 통합하고 despawn합니다. 작업 항목 사이에 유휴 QA, 보안, 컨설턴트 또는 엔지니어 프로세스를 유지하지 마세요.

spawn.sh <type> <name> --project "$(pwd)" [--team <team>] [--model <cli-model-id>] [--boot-prompt "<ticket>"] [--no-wait] [--fresh] <name>을 사전 조인하고, tmux 창(tmux 내) 또는 새 터미널을 열고 CLI를 시작합니다. claude-code 생성은 watcher가 연결될 때까지 차단됩니다. codex 생성은 즉시 반환되므로, codex 피어는 유휴 상태가 된 후에 보내는 메시지가 아닌 --boot-prompt를 통해 할당을 받아야 합니다.

같은 작업에서 나중에 역할을 다시 가져오려면 --fresh 없이 동일한 이름을 spawn하세요. agmsg는 기록된 세션을 재개하므로 델타(상태, 관련 파일/커밋, 하나의 다음 질문)만 보내세요. 이전 컨텍스트가 오해를 불러일으킬 때만 --fresh를 사용하세요.

despawn.sh <team> <owner> <name> [--force]는 spawn의 역이며, 이 소유자가 생성한 역할만 종료합니다. codex 피어의 정상적인 despawn은 종종 "no live lock"(codex에 watcher 없음)을 보고합니다. 이는 정상이며, 터미널 창이 열려 있는 경우에만 --force를 추가하세요. 수동으로 시작한 피어를 despawn하지 마세요.

agmsg 인터페이스

고정된 경로를 가정하지 않고 현재 환경에 설치된 위치(스킬 디렉토리)에서 agmsg 스킬의 scripts/ 디렉토리를 확인한 후 호출하세요:

bash <agmsg-skill-dir>/scripts/send.sh <team> <from> <to> "<structured ticket>"
bash <agmsg-skill-dir>/scripts/inbox.sh <team> <agent>
bash <agmsg-skill-dir>/scripts/team.sh <team>
bash <agmsg-skill-dir>/scripts/spawn.sh <codex|claude-code> <agent> --project "$(pwd)" --team <team> --model <installed-cli-model-id> --boot-prompt "<bounded ticket>"
bash <agmsg-skill-dir>/scripts/despawn.sh <team> <owner> <spawned-agent> [--force]

--model은 agmsg에 의해 설치된 CLI로 전달됩니다. 확인된 로컬 모델 ID만 사용하세요. Codex 피어의 경우 gpt-5.6-luna, gpt-5.6-terra, gpt-5.6-sol, gpt-6-astra입니다. 다른 CLI의 경우 문서화된 식별자를 사용하고 임의로 생성하지 마세요. 모니터 전달이 없는 Codex 피어는 유휴 상태가 된 후에 보내는 메시지가 아닌 --boot-prompt를 통해 초기 할당을 받아야 합니다.

유용한 병렬 작업을 생성할 때만 생성하세요. 여러 투기적 작업자보다 하나의 좁은 범위의 작업자를 선호하세요. 독립적인 티켓에 대해서만 병렬화하세요. 수동으로 시작한 피어의 경우 send.sh로 충분합니다. 할당 전에 명단을 검사하세요. 의도적으로 agmsg의 문서화된 --force 예외를 사용하지 않는 한 모든 from과 to는 등록되어야 합니다.

완료 게이트

선택된 작업 소유자는 요구사항 및 승인 기준이 충족되고, 관련 테스트가 통과되고, 트리거된 QA 및 보안 검토가 해결되고, 차단 항목이 없으며, diff에 관련 없는 변경 사항이 포함되지 않은 경우에만 작업을 종료합니다. 고비용 모델 권장 사항이 사용된 경우, 종료 전에 결과를 검증하고 구현하세요.