Help us improve
Share bugs, ideas, or general feedback.
Cross-validates agent team outputs against shared mental models, detects drift and mismatches, and performs backup for blocked or overloaded team members.
npx claudepluginhub tobyilee/team-bigfive --plugin team-bigfiveHow this skill is triggered — by the user, by Claude, or both
Slash command
/team-bigfive:mutual-monitoringThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Team Big Five의 2번(상호 성과 모니터링)·3번(백업 행동) 구성요소. 팀원들이 서로의 작업을 관찰해 실수를 잡고, 막힌 팀원의 일을 대신 수행한다. `performance-monitor` 에이전트가 전담하되, 모든 `contributor`도 자기 인접 산출물을 부분적으로 모니터링한다.
Orchestrates agent teams using Team Big Five theory (leadership, mutual monitoring, backup, adaptability, team orientation) for collaborative tasks. Uses shared mental models and explicit protocols for high performance.
Automatically analyzes task complexity to decide Subagent vs Agent Teams for parallel code reviews, collaborative debugging, and cross-layer frontend/backend/testing development.
Implements PACT agent teams protocol for task claiming, teachback verification, inter-agent messaging with SendMessage, blocker reporting, and work handoffs.
Share bugs, ideas, or general feedback.
Team Big Five의 2번(상호 성과 모니터링)·3번(백업 행동) 구성요소. 팀원들이 서로의 작업을 관찰해 실수를 잡고, 막힌 팀원의 일을 대신 수행한다. performance-monitor 에이전트가 전담하되, 모든 contributor도 자기 인접 산출물을 부분적으로 모니터링한다.
혼자 일하는 에이전트는 자기 오류를 못 본다. 특히 경계면 — 팀원 A의 출력이 팀원 B의 입력이 되는 지점 — 에서 각자는 "내 쪽은 맞다"고 믿지만 둘이 안 맞는다. 상호 모니터링은 이 경계면을 교차로 비교해 숨은 버그를 드러낸다. 백업은 한 팀원의 정체가 팀 전체를 멈추지 않게 한다.
코드 과제에서 "두 산출물이 markdown 상으로 정합해 보임"은 "동작함"이 아니다. 경계면 텍스트 대조 전에 반드시 실행 검증을 먼저 한다:
execution: {build, typecheck, test, lint} pass/fail + 출력 꼬리를 인용한다.산문 과제(리서치·문서·창작·마케팅)에는 실행할 스크립트가 없다 → Part 1의 정독 대조로 직행.
산출물이 생성되었는지 확인하는 것은 검증이 아니다. 의존 관계로 연결된 두 산출물을 함께 읽고, SMM의 해당 계약(스키마 또는 스타일/사실/연속성)을 기준으로 대조한다.
나쁨: "contributor-api가 users.json 만들었음 → OK"
좋음: "users.json의 필드 {id,name} ↔ contributor-ui가 기대하는 {id,name,email}
→ email 누락. SMM 인터페이스 위반. DRIFT 플래그."
나쁨(산문): "ch.4 초고 존재 → OK"
좋음(산문): "ch.1은 주인공을 외동으로, ch.4는 여동생 등장 → SMM canon 위반. DRIFT."
계약은 과제마다 다르므로 무엇을 대조하는지도 다르다:
코드/설계 : I/O shape, 타입, 계약 위반, 빌드/테스트(Part 0)
리서치/분석: 주장↔출처 정합(사실 원장), 인용 정확성, 분석 단위 일관, 무근거 주장
문서/보고서: 섹션 간 용어 일관, 중복·공백, 주장-근거 연결, 독자 적합
창작 : 보이스 드리프트, 타임라인/세계관 모순(canon 위반), 플롯 홀, POV·시제 일탈, 복선 회수
마케팅 : 핵심 메시지 일관, 브랜드 보이스, 채널별 톤, CTA·클레임 일관
또한 SMM §9의 명시된 위험 가정을 능동적으로 감시한다 — 그 가정이 깨질 조짐이 보이면 DRIFT 전이라도 리더에 알린다(사전 적응).
전체 완성 후 1회가 아니라, 각 모듈/Phase 완료 직후 즉시 검증한다. 늦게 잡은 경계면 버그는 그 위에 쌓인 작업까지 무효화한다.
| 판정 | 의미 | 후속 |
|---|---|---|
| OK | SMM 기준 정합 (+ 코드면 실행 통과) | 통과 |
| DRIFT | 산출물이 SMM/인접 산출물과 불일치, 또는 빌드/테스트 실패 | 해당 팀원에 폐쇄 루프 플래그 + 수정 요청 |
| BLOCKED | 산출물 누락/깨짐/의존 미충족 | 백업 행동 트리거 (Part 2) |
소프트 제약(SMM §6에서 [soft])의 위반은 차단 DRIFT가 아니라 **권고(FYI)**로 — 드래프트 단계에서는 보이스·플롯 탐색을 막지 않는다. 차단 DRIFT는 [hard] 제약(계약·canon·사실·빌드)에만.
_workspace/monitor/round_{N}_report.md)## {대상 팀원 / 경계면}
- 판정: OK | DRIFT | BLOCKED
- 실행(코드): build/typecheck/test/lint = pass/fail (+출력 꼬리)
- 근거: {어느 파일 어느 부분} ↔ {SMM 어느 기준 / 어느 인접 산출물}
- 권고: {구체적 수정 방향}
검증 강도는 경계면의 신뢰 등급(SMM §4)에 비례한다 — 결과 영향 큰 경계면은 매 라운드 재검증, 가벼운 건 한 번만. 검증 강도를 팀원 의심이 아니라 경계면 결과 비용으로 정한다. 검증은 계약 버전에 묶이므로, 의존 계약이 갱신되면 하위 "검증됨"은 무효 → 재검증. 모든 것을 매번 재검증하면 신뢰가 무너지고 비용이 폭발한다. 신뢰하되, 비싼 경계면은 본다.
에이전트 팀에서 팀원은 매 턴 종료 후 정상적으로 idle이 된다. idle 자체는 실패가 아니다. **정체(stall)**는 다르게 정의한다:
정체 = 해당 task가 여전히
in_progress/미claim 상태이고, 리더의 점검 주기 N회(예: 2회)에 걸쳐TaskUpdate변화가 없음. (단순히 idle 알림이 온 것 ≠ 정체)
이 구분이 없으면 건강한 idle 팀원에게 백업을 발동해 중복 작업이 생기거나, 진짜 데드락을 놓친다.
1. monitor가 정체/과부하/실패를 감지 → 리더에게 폐쇄 루프로 보고
2. 리더가 판단:
- 유휴 팀원 있음 → 그 팀원에게 작업 재할당 (TaskUpdate owner)
- 작업이 크면 → 분할하여 여러 팀원에 분산
- 대체 불가 → 부분 결과 보존 후 사용자에 보고
3. 백업 팀원은 SMM을 읽고 원 담당자의 진행분(부분 산출물)을 이어받는다
4. 원 담당자가 복귀하면 SMM 결정 로그로 인수인계 상태를 공유
백업은 무한 재시도가 아니다. 같은 작업이 2회 실패하면 구조적 문제(SMM 결함, 작업 정의 오류)를 의심하고 리더가 재계획(Adaptability)을 검토한다.
Big Five의 전제는 팀 성과가 측정 가능하다는 것이다. monitor는 종료 전 _workspace/monitor/scorecard.md를 작성해 팀워크 품질을 계량한다:
## 팀 스코어카드
- DRIFT 건수 (경계면별):
- 재발 DRIFT (2회+):
- BLOCKED / 백업 발동 횟수:
- 적응 체크포인트 발동 횟수:
- OK까지 라운드 수:
- 완료 기준(rubric) 충족: {N}/{전체}
- 실행 게이트(코드): build/test/lint 최종 상태
이 스코어카드는 Phase 5 디브리핑(AAR)의 원자료가 되고, 하네스 진화의 학습 신호가 된다 — 좋은 실행과 나쁜 실행을 구분하는 유일한 근거다.