The Team Loop
두 개의 협력 팀 또는 에이전트가 하나의 저장소에서 작업할 때 이 스킬을 사용하세요. Team A와 Team B는 설정된 이름으로 바꾸세요. 오너(Owner)는 사람이며, 우선순위, 병합, 배포, 동결(freeze), 정책 결정에 대한 권한을 가집니다.
온보딩: 5분 설정
- 이 스킬을 대상 저장소에 복사하고 활성 에이전트 도구에 맞는 어댑터를 설치합니다.
templates/team-loop.yml을.team-loop.yml로 복사하고 팀 이름과gate_command를 설정합니다.scripts/setup-labels.sh --repo OWNER/REPO를 실행합니다.- 오너가 고정된 조정 이슈(coordination issue) 하나와
ready레이블이 지정된 이슈 하나를 생성합니다. - 각 팀은 이 파일을 읽고, 최대 한 개의 항목을 클레임하며, 설정된 상태 헤더를 사용합니다.
역할
- 오너(Owner): 준비된 작업을 생성하거나 승격합니다. 직접
Owner:결정을 자신의 말로 게시합니다. 범위와 UTC 종료 시간이 명시된 서면 위임(mandate)을 제외하고 병합 및 배포를 승인합니다. - Team A / Team B: 빌드, 테스트, 리뷰, 클레임, 인계, 보고를 수행합니다. 가능한 경우 별도의 GitHub ID를 사용합니다.
- 리뷰어(Reviewer) (선택 사항): 새로운 컨텍스트로 리뷰를 수행합니다. 설정된 위험 경로 또는 카테고리에 대해 필수로 지정할 수 있습니다.
루프 상태
backlog -> ready -> in-progress -> blocked 또는 needs-owner -> 구현 PR -> ready-for-owner -> 병합됨 -> deployed.
backlog는 클레임할 수 없습니다. 오너 승격을 위해 매주 낮은 심각도의 백로그 작업을 일괄 처리합니다.ready는 구현, 테스트 및 PR 생성을 승인합니다. 병합 또는 배포를 절대 승인하지 않습니다.- 이슈를 닫을 때는
in-progress,ready,blocked,needs-owner와 같은 오래된 상태 레이블을 제거하세요.
클레임 프로토콜
- 행동하기 직전에 레이블을 다시 읽으세요.
in-progress,blocked또는ready가 아닌 작업은 클레임하지 마세요. scripts/claim.sh --repo OWNER/REPO --issue N --team "Team A" --plan "short plan"을 실행합니다.- 이 스크립트는
in-progress와 팀 레이블을 추가하고, 클레임을 게시한 후 상태를 다시 확인합니다. 경쟁에서 지면 백오프(back off)합니다. - 진행 중인 작업(WIP)을 팀당
wip_limit이하로 유지하세요. 다른 항목을 클레임하기 전에 완료, 인계 또는 명시적으로 차단하세요. team:any의 경우, 가장 먼저 유효한 클레임 댓글이 이깁니다. 다른 팀은 물러납니다. 중복 구현으로 동점을 해결하지 마세요.
댓글 및 커뮤니케이션
모든 팀 댓글의 첫 번째 줄은 다음과 같이 시작합니다:
Status: <state> | Team: <configured team> | <short context>
계획이 포함된 클레임, 리뷰 결과, 게이트 결과, 인계, 질문, 오너 대상 에스컬레이션, 동의 또는 릴리스 보고서만 게시하세요. 시작됨, 대기 중, 아직 기다리는 중, 재무장 또는 기타 의례적인 댓글은 게시하지 마세요. 일반 댓글은 다섯 줄 이내로 유지하고, 증거는 PR 설명이나 접힌 세부 정보(collapsed details)에 배치하세요.
오너만 Owner: 결정을 작성합니다. 팀은 직접적인 오너 댓글에 링크를 걸거나 요청해야 하며, 절대 권위를 가장하여 전달하지 마세요.
레이블 및 라우팅
reference/labels.md의 레이블을 사용하세요. 할당되지 않은 ready 이슈는 설정에 달리 명시되지 않는 한 기본적으로 Team A에 할당됩니다. team:any는 어느 팀이든 클레임할 수 있도록 합니다. 유휴 상태일 때는 다음 순서로 다른 팀을 도우세요: 요청된 리뷰, 트린 준비 또는 리베이스, 그 다음 주간 백로그 배치. 오너의 요청 없이 무제한 버그 수정 작업을 수행하지 마세요.
리뷰, 트레인, 게이트, 인증서
-
각 PR은 가볍고 집중된 검사를 실행하고, 위험 수준에 따라 필요한 리뷰 등급을 받습니다.
-
리뷰어는 완료된 PR에
ready-for-owner레이블을 지정합니다. -
트레인 러너(train runner)는 해당 시점에 사용 가능한 리뷰된 PR을 수집합니다. 다음을 실행합니다:
scripts/train.sh --repo OWNER/REPO --name train-YYYYMMDD-N PR_NUMBER... -
train.sh는 포함된 모든 PR에train-running을 추가하고, 기준(base)과 헤드(head)를 기록하며, 충돌 화면(clash screen)을 수행하고, 임시 병합 결과를 구성한 후gate.sh를 한 번 호출합니다. -
gate.sh는 인증서를git rev-parse HEAD^{tree}에 키잉(key)합니다.--force를 사용하지 않는 한, 일치하는 기존 인증서는 성공적인 증거입니다. -
기준 또는 PR 헤드가 변경되거나 화면/게이트가 실패하면 트레인은 무효입니다. 문제가 되는 PR을 제거하거나 분할한 후 트레인을 재구축하세요.
train-running이 트레인을 보유하는 동안 관련 없는 작업을 병합하지 마세요. -
직접 오너 승인 또는 활성 위임 후,
train.sh를--merge --owner-authorization "Owner: ..."와 함께 다시 실행하여 기록된 PR 헤드를 순서대로 병합합니다. 기준 또는 헤드가 변경되면 거부하며, 각 병합 후 보호된 브랜치의 트리를 확인합니다.
배포, 동결, 보류, 일시 중지
- 오너가 기록된 예외를 제공하지 않는 한, 설정된 보호 브랜치만 일치하는 트리 인증서와 함께 배포하세요.
- 릴리스에 대해 하나의 배포 보고서를 생성하세요. 배송된 PR 및 이슈에
deployed레이블을 지정하고, 보고서를 복제하지 않고 하나의 보고서에 연결하세요. freeze는 새로운 병합 및 배포를 중지합니다. 레이블 읽기 실패는 되돌릴 수 없는 작업에 대해 동결된 것으로 간주하세요.- 트레인 보류(train hold)는 트레인이 종료될 때까지 해당 트레인 외부의 병합을 차단합니다.
- 일시 중지 시, 클레임, 트레인, 병합 및 배포를 중지하세요. 오너는 재개가 허용된 항목을 명명하는 재시작 목록을 게시합니다. 재시작 전에 레이블, PR 헤드, 기준 및 인증서를 다시 확인하세요.
에스컬레이션 및 위임
제품, 보안, 법률, 릴리스 또는 모호한 소유권 결정이 작업을 차단할 때 needs-owner를 사용하세요. 관찰된 동작, 옵션, 권장 사항 및 마감일(있는 경우)을 명시하세요. 독립적인 작업을 계속하세요.
위임은 정확한 범위와 UTC 만료 시간을 명시해야 합니다. 예:
Owner: Team A may merge and deploy reviewed documentation PRs 41 and 42 until 2026-05-01T18:00:00Z.
해당 범위를 벗어나거나 만료 후의 모든 작업은 새로운 직접 결정이 필요합니다.
회고
최소한 주 1회 scripts/scorecard.sh를 실행하고 reference/metrics.md의 정의를 논의하세요. 측정 가능한 병목 현상을 한 번에 하나씩 개선하세요. 병합된 PR당 게이트 실행, 클레임 지연 시간, 사이클 타임, 대기열 순 변경, 평균 배치 크기, 인증된 비율 및 변경 실패율을 검토하세요.
표준적인 번호 규칙은 reference/rules.md를, 상태 게시 전 템플릿은 reference/comment-templates.md를 읽으세요.