refactor: adapt multi-agent-mux skills and agent guidelines for the Team Leader scenario

This commit is contained in:
2026-06-28 10:21:24 +09:00
parent 81474ac3f7
commit f457180777
3 changed files with 104 additions and 75 deletions
+50 -35
View File
@@ -10,21 +10,28 @@
역할군 간의 책임 및 권한을 명확히 분리하여 병목을 줄이고 작업의 완성도를 높입니다.
### 👤 Project Manager (PM / Orchestrator)
- **주요 책무**: 사용자 요구사항 접수, 상세 작업 계획 수립, 작업자 할당/지시, 전체 워크플로우 통제 및 최종 결과 보고.
### 👑 General Manager (총괄 매니저)
- **주요 책무**: 사용자와 직접 소통하여 요구사항 접수, 상세 작업 계획 수립, 팀장 에이전트 할당 및 작업 위임, 전체 워크플로우 통제 및 최종 완료 보고.
- **모호성 제거**: 사용자의 요구사항에 모호한 부분이 있다면 작업을 추측하여 진행하지 말고, 즉시 사용자에게 질문하여 명확히 해야 합니다 (`/grill-me` 슬래시 명령어 권장).
- **피드백 루프 조정**: Reviewer들의 검증 의견을 분석하여 개선 방향을 의사결정합니다. 결정하기 까다로운 기술적 난제는 Worker 및 Reviewer들의 조사를 거쳐 PM 본인의 판단을 더한 최종 보고서를 작성해 사용자에게 제시하고 프로젝트의 방향을 결정합니다.
- **자가 치유 (Hermes Fallback Fix)**: Reviewer가 지적한 결함이 아주 경미하거나 단순 오탈자/설정 누락인 경우, Worker에게 재할당하지 않고 PM이 직접 소스코드를 수정하여 전체 왕복(Round-trip) 비용을 최소화합니다.
### 🛠️ Worker (Implementation Agent)
- **주요 책무**: PM으로부터 위임받은 구체적인 비즈니스 로직 설계 및 소스코드 구현.
- **협업 및 소통**: 할당받은 업무 범위에서 구현 방향이 모호하거나 인터페이스 설계 변경이 필요한 경우 PM에게 질문하여 합의를 이룬 후 수술적(Surgical) 변경을 적용합니다.
- **계약 준수**: PM이 전달한 단일 작업 지침(Brief) 및 고유 Job ID 규약을 준수하며, 작업 시작 시 `started`, 종료 시 `completed`/`error` 이벤트를 백플레인에 발행해야 합니다.
### 👥 Team Leaders (팀장)
새롭게 생성되는 에이전트(`antigravity`, `claude`, `cline`, `hermes` 등)는 각 팀의 **팀장** 역할을 수행합니다. 총괄 매니저로부터 작업을 위임받아 개발 또는 리뷰 워크플로우를 주도합니다.
- **Developer Team Leader (개발 팀장)**:
- 총괄 매니저로부터 작업을 위임받습니다.
- **작업 분석 및 계획**: 주어진 작업을 철저히 분석하고, 작은 단위로 문제를 나누어 세부 계획을 수립합니다.
- **내부 병렬 처리**: 내부적으로 subagent를 활용해 위임받은 작업을 병렬적으로 처리할 수 있습니다.
- **리뷰 타당성 검증 및 거부**: 리뷰어가 지적한 피드백을 면밀히 검토합니다. 타당한 제안은 수렴하여 코드를 수정하지만, 타당하지 않다고 판단되는 안건은 반영하지 않고 **그 명확한 이유를 작성하여 리뷰어에게 되돌려 보냅니다**.
- **완료 신호 송신**: 모든 리뷰어들로부터 `PASS`를 획득하고 변경 사항이 검증되면, 최초 작업을 위임받았던 개발 팀장이 총괄 매니저에게 최종 작업 완료 신호를 송신합니다.
- **Reviewer Team Leader (리뷰어 팀장)**:
- 개발 팀장으로부터 리뷰 요청을 접수합니다.
- **문제 제시에 대한 이유와 개선 방향 포함**: 단순한 반려(`NOT PASS`) 통보는 금지됩니다. 이슈를 제기할 때는 **반드시 해당 문제가 발생하는 구체적인 이유와 확실한 개선 방향(코드 대안 포함)을 함께 작성**해야 합니다.
- **합의 루프**: 모든 지적 사항이 해결되고 최종 `PASS`를 발행할 때까지 리뷰 루프에 동참합니다.
### 🔍 Reviewer (Verification Agent)
- **주요 책무**: Worker가 제출한 소스코드 변경 사항(Diff)과 구현 명세를 검증하고, 보안 결함 탐지, 성능 개선안 도출 및 설계 일관성을 심사하는 조력자.
- **구체적 대안 제시**: 단순한 반려(`NOT PASS`) 통보를 금지하며, 문제를 제기할 때는 **안정적이고 검증된 구체적인 코드 대안(Alternative Code)이나 해결 방안을 반드시 함께 제시**해야 합니다.
- **교차 검증의 상호보완성**: 에이전트의 모델 특성(예: Flash 계열은 의미론적 셸 결함 포착에 강하고, Opus/Sonnet 계열은 API 서명 및 논리 회귀 분석에 강함)을 살려 병렬로 상호보완적 심사를 수행합니다.
### 🛡️ 역할 범위 준수 원칙 (Role Suitability Check)
- 모든 에이전트는 자신에게 부여된 역할에 부합하는 작업만을 수행해야 합니다. (예: 개발 팀장은 최종 PASS 여부를 결정하지 않으며, 리뷰어 팀장은 직접 프로젝트 소스코드를 작성하지 않습니다.)
- **자신의 역할에 맞지 않는 작업이 지시된 경우**, 에이전트는 반드시:
1. 해당 작업을 수행하기에 가장 적합한 에이전트 세션을 추천하여 위임을 유도하거나,
2. 프로젝트 연속성을 위해 극히 필요한 경우 직접 작업을 수행합니다.
---
@@ -59,34 +66,42 @@
sequenceDiagram
autonumber
actor User as 사용자
participant PM as Project Manager
participant W as Worker
participant R as Reviewers
participant GM as General Manager
participant DTL as Developer Team Leader
participant RTL as Reviewer Team Leaders
participant M as MQTT Backplane
User->>PM: 요구사항 전달
Note over PM: grill-me 및 계획 수립
PM->>M: Job 등록 및 Subscriber 구동
PM->>W: 작업 위임 (Job ID & Brief 전달)
W->>M: 'started' 이벤트 발행
Note over W: 코드 변경 및 구현
W->>M: 'completed' (혹은 'error') 발행
PM->>R: 병렬 리뷰 요청 (Diff 전달)
Note over R: 교차 분석 & 검증
alt 결함 발견
R->>PM: NOT PASS (대안 포함 피드백)
Note over PM: 경미한 결함은 PM이 직접 수정
PM->>W: 피드백 반영 및 재할당
User->>GM: 요구사항 전달
GM->>DTL: 작업 위임 (예: 랜딩 페이지 제작)
Note over DTL: 작업 분석, 세분화 및 subagent 병렬 구동
DTL->>M: 'started' 이벤트 발행
Note over DTL: 코드 변경 및 구현
DTL->>M: 'completed' 발행
DTL->>RTL: 리뷰 요청 (랜딩 페이지를 제작했습니다. 리뷰를 진행해주세요)
Note over RTL: 교차 분석 & 검증
alt 결함 발견 (리뷰어 피드백)
RTL->>DTL: NOT PASS / 피드백 (반드시 이유와 확실한 개선 방향 포함)
Note over DTL: DTL이 피드백의 타당성 검증
alt 타당한 피드백
Note over DTL: DTL이 수용하여 코드 수정
else 타당하지 않은 피드백
DTL->>RTL: 반론 및 거부 이유 전달 (부적절한 항목 미반영)
end
DTL->>RTL: 재리뷰 요청 (리뷰 안건 수정 완료)
else 검증 통과
R->>PM: PASS
RTL->>DTL: PASS
end
PM->>User: 최종 검증 통과 보고 & 커밋
DTL->>GM: 최종 완료 신호 송신
GM->>User: 사용자에게 작업 완료 통보
```
1. **계획 수립 및 할당**: PM은 사용자 요청을 구체화하고 의존성이 겹치지 않는 범위에서 잡을 정의합니다.
2. **작업 개시 및 통보**: PM은 구독자를 띄운 뒤 Worker 세션에 잡을 인가하며, Worker는 로직을 수행하고 단말 이벤트를 전송해 세션을 자동 종료합니다.
3. **교차 검수 반복 (Review Loop)**: PM은 작업 완료 후 변경분을 Reviewer 에이전트들에게 병렬 회람시킵니다. 리뷰어 전원이 `PASS` 의견을 낼 때까지 수정-반려 주기를 무한 반복(Loop)하여 코드 완성도를 보증합니다.
4. **릴리즈 및 정리**: 검증이 완료된 코드는 Git에 커밋하고, 임시 세션 리소스를 회수합니다.
1. **계획 수립 및 할당**: 총괄 매니저는 개발 팀장에게 작업을 인가합니다.
2. **분석 및 내부 실행**: 개발 팀장은 작업을 분석하고 세분화하여 계획을 세운 뒤 내부 subagent를 가동하여 구현을 완료합니다. 이후 `started`를 거쳐 `completed` 이벤트를 발행하고 리뷰어에게 검수를 요청합니다.
3. **이의 제기 및 정제 루프**:
- 리뷰어 팀장은 상세 피드백 시 반드시 이유와 보완 방향을 제시해야 합니다.
- 개발 팀장은 의견을 검토해 타당하면 수정하고, 타당하지 않으면 반론과 근거를 회신합니다.
- 리뷰어 전원이 `PASS`를 인가할 때까지 이 과정이 반복됩니다.
4. **최종 보고**: 개발 팀장이 총괄 매니저에게 완료 신호를 보내면 총괄 매니저가 사용자에게 완료를 알립니다.
---
@@ -123,4 +138,4 @@ TMUX 환경에서 실행되는 에이전트가 화면 스크롤 한계로 인해
---
*본 가이드는 협업 효율성과 코드 보안의 엄격한 균형을 유지하기 위한 규범입니다. 변경 사항이 필요한 경우 PM 및 Reviewer의 전원 합의를 거쳐 본 문서를 업데이트해야 합니다.*
*본 가이드는 협업 효율성과 코드 보안의 엄격한 균형을 유지하기 위한 규범입니다. 변경 사항이 필요한 경우 총괄 매니저 및 전체 팀장의 합의를 거쳐 본 문서를 업데이트해야 합니다.*
+50 -35
View File
@@ -10,21 +10,28 @@ All agents working on a new project must read this document thoroughly and compl
We clearly separate responsibilities and permissions between roles to reduce bottlenecks and enhance the quality of execution.
### 👤 Project Manager (PM / Orchestrator)
- **Core Responsibility**: Receive user requirements, establish detailed task plans, assign and instruct workers, control the overall workflow, and report final results.
### 👑 General Manager (Orchestrator)
- **Core Responsibility**: Interact directly with the user, receive high-level requirements, establish task plans, delegate tasks to Team Leaders, control the overall workflow, and report completion back to the user.
- **Ambiguity Resolution**: If a user's requirements contain ambiguous details, do not guess. Immediately ask the user for clarification (we recommend using the `/grill-me` slash command).
- **Feedback Loop Adjustment**: Analyze verification feedback from Reviewers to decide on improvement paths. For complex technical challenges, direct Workers and Reviewers to research options, add the PM's own assessment, and present a final report to the user to decide the project's direction.
- **Self-Healing (Hermes Fallback Fix)**: If a defect pointed out by a Reviewer is extremely minor or is a simple typo/configuration omission, the PM should directly fix the source code instead of reassigning it to the Worker, thereby minimizing the round-trip cost.
### 🛠️ Worker (Implementation Agent)
- **Core Responsibility**: Design business logic and implement source code as delegated by the PM.
- **Collaboration & Communication**: If the implementation path is ambiguous or interface design changes are required within the assigned scope, ask the PM for consensus before applying surgical changes.
- **Contract Adherence**: Comply with the single task instructions (Brief) and the unique Job ID convention provided by the PM. Workers must publish a `started` event when starting work, and a `completed` or `error` event to the backplane upon termination.
### 👥 Team Leaders (팀장)
Newly spawned agents (e.g., `antigravity`, `claude`, `cline`, `hermes`) act as **Team Leaders** of their respective groups. They receive delegated tasks from the General Manager and manage implementation or review workflows.
- **Developer Team Leader (개발 팀장)**:
- Receives tasks from the General Manager.
- **Task Breakdown & Planning**: Thoroughly analyzes the task, breaks it down into small units, and creates a plan.
- **Internal Parallelism**: Can run subagents in parallel internally to handle the delegated work.
- **Review Integrity & Refusal**: Thoroughly reviews feedback from Reviewers. Adopts/implements recommendations if valid. If any recommendation is judged invalid, the Developer Team Leader must **not** implement it, but instead return the refutation along with detailed reasons to the Reviewer.
- **Completion Signal**: Once all reviewers yield a `PASS` and changes are verified, the Developer Team Leader who first received the task sends a completion signal back to the General Manager.
- **Reviewer Team Leader (리뷰어 팀장)**:
- Receives review requests from the Developer Team Leader.
- **Detailed Feedback with Directions**: Simply rejecting changes (`NOT PASS`) is forbidden. Reviewers **must** specify the exact reason for the issue and provide a concrete, stable, and verified alternative direction for improvement.
- **Consensus Loop**: Engages in the review cycle until all objections are resolved and a final `PASS` is issued.
### 🔍 Reviewer (Verification Agent)
- **Core Responsibility**: Verify source code changes (Diff) and implementation specifications submitted by Workers. Reviewers act as facilitators by detecting security vulnerabilities, proposing performance improvements, and examining design consistency.
- **Provide Concrete Alternatives**: Simply rejecting changes (`NOT PASS`) is forbidden. When raising an issue, Reviewers must propose a **concrete, stable, and verified alternative code block or solution**.
- **Complementary Cross-Verification**: Leverage the unique characteristics of different agent models (e.g., Flash-class models are skilled at capturing semantic shell bugs, while Opus/Sonnet-class models excel at API signatures and logical regression analysis) to perform parallel and mutually-supportive reviews.
### 🛡️ Role Suitability Check Principle (자신의 역할 범위 수행 원칙)
- Every agent must only perform tasks suitable for its designated role (e.g., Developer Team Leaders do not issue final reviews, and Reviewer Team Leaders do not write project code).
- **If an agent receives a task that does not fit its role**, it must either:
1. Recommend the optimal agent session to delegate the task to, or
2. Perform the task directly if strictly necessary for project continuity.
---
@@ -59,34 +66,42 @@ Asynchronous communication and state management between agents are controlled vi
sequenceDiagram
autonumber
actor User as User
participant PM as Project Manager
participant W as Worker
participant R as Reviewers
participant GM as General Manager
participant DTL as Developer Team Leader
participant RTL as Reviewer Team Leaders
participant M as MQTT Backplane
User->>PM: Hand over requirements
Note over PM: Run grill-me & plan tasks
PM->>M: Register Job & start Subscriber
PM->>W: Delegate task (Provide Job ID & Brief)
W->>M: Publish 'started' event
Note over W: Modify code & implement
W->>M: Publish 'completed' (or 'error')
PM->>R: Request parallel review (Provide Diff)
Note over R: Cross-analysis & verification
alt Defect Found
R->>PM: NOT PASS (Feedback with alternatives)
Note over PM: PM directly fixes minor defects
PM->>W: Apply feedback & re-delegate
User->>GM: Hand over requirements
GM->>DTL: Delegate task (e.g., create landing page)
Note over DTL: Analyze, breakdown & spawn parallel subagents
DTL->>M: Publish 'started' event
Note over DTL: Modify code & implement
DTL->>M: Publish 'completed'
DTL->>RTL: Request review (I created landing page. Please review it)
Note over RTL: Cross-analysis & verification
alt Defect Found (Reviewer feedback)
RTL->>DTL: NOT PASS / Feedback (Must include reason & improvement direction)
Note over DTL: DTL checks validity of suggestions
alt Valid feedback
Note over DTL: DTL adopts and modifies code
else Invalid feedback
DTL->>RTL: Send refutation & reasons (Did not reflect inappropriate parts)
end
DTL->>RTL: Request review again (Modified review items)
else Verification Pass
R->>PM: PASS
RTL->>DTL: PASS
end
PM->>User: Report final pass & commit changes
DTL->>GM: Send completion signal
GM->>User: Notify task completion
```
1. **Planning and Allocation**: The PM defines requirements and outlines independent jobs to avoid conflicting dependencies.
2. **Execution and Notification**: The PM launches a subscriber, then assigns the job to a Worker session. The Worker performs the logic and sends a terminal event, automatically closing the session.
3. **Cross-Verification Iteration (Review Loop)**: Once the task is complete, the PM circulates the changes to the Reviewer agents in parallel. The modify-reject cycle repeats until all reviewers yield a `PASS`, ensuring high-quality code.
4. **Release and Cleanup**: Code that passes verification is committed to Git, and temporary session resources are reclaimed.
1. **Planning and Allocation**: The General Manager delegates the task to the Developer Team Leader.
2. **Analysis and Internal Execution**: The Developer Team Leader analyzes the task, breaks it down, plans execution, and optionally spawns parallel subagents. It publishes `started`, completes the task, and requests review from the Reviewer Team Leader.
3. **Objection & Refinement Loop**:
- The Reviewer Team Leader must provide clear reasons and improvement directions for any issues.
- The Developer Team Leader validates the feedback. Valid suggestions are implemented; invalid ones are refuted with reasons and returned to the reviewer.
- This cycle repeats until all reviewers issue a `PASS`.
4. **Completion and Report**: The Developer Team Leader sends the final completion signal to the General Manager, who notifies the user.
---
@@ -123,4 +138,4 @@ Use this checklist when deploying this agent orchestration model to a new projec
---
*This guide balances collaboration efficiency with strict code security. Any required changes must be discussed and agreed upon by the PM and all Reviewers before updating this document.*
*This guide balances collaboration efficiency with strict code security. Any required changes must be discussed and agreed upon by the General Manager and all Team Leaders before updating this document.*
@@ -252,10 +252,9 @@ Task: $current_prompt"
# Worker completed successfully, now switch to reviewer
current_role="reviewer"
current_session="$REVIEWER_SESSION"
# Build reviewer prompt based on type
if [[ "$TYPE" == "loop" ]]; then
current_prompt="Review the changes/artifacts generated for job $JOB_ID. Check if they meet the requirements. If correct, publish completed event with 'PASS'. If there are issues, publish error event with detailed feedback/nits."
current_prompt="Review the changes/artifacts generated for job $JOB_ID. Check if they meet the requirements. If correct, publish completed event with 'PASS'. If there are issues, publish error event with detailed feedback/nits. CRITICAL: When raising issues or giving a review, you MUST include the exact reason for the issue and a clear direction for improvement (문제 제시에 대한 이유와 확실한 개선 방향을 반드시 포함해야 합니다)."
elif [[ "$TYPE" == "discuss" ]]; then
current_prompt="Read draft/documents generated for job $JOB_ID. Review the feasibility and content. Write your feedback/objections. If you agree with the plan, reply with 'AGREE'."
fi
@@ -264,7 +263,7 @@ Task: $current_prompt"
echo "Reviewer did not complete successfully (status: $job_status). Terminating workflow."
break
fi
# Reviewer finished. Check if pass/agree
local success=0
if [[ "$TYPE" == "loop" ]]; then
@@ -276,7 +275,7 @@ Task: $current_prompt"
success=1
fi
fi
if [[ "$success" == "1" ]]; then
echo "Reviewer approved the work. Finalizing job as completed."
"$PY" "$SCRIPT_DIR/scripts/registry.py" --registry-dir "$REGISTRY_DIR" status --job "$JOB_ID" --set "completed"
@@ -292,7 +291,7 @@ Task: $current_prompt"
iteration=$((iteration + 1))
current_role="worker"
current_session="$AGENT_SESSION"
current_prompt="The reviewer provided the following feedback for job $JOB_ID: $feedback. Please modify the code/artifacts to address these comments."
current_prompt="The reviewer provided the following feedback for job $JOB_ID: $feedback. Please modify the code/artifacts to address these comments. CRITICAL: As the Developer Team Leader, you must thoroughly review the suggested modifications, verify their validity, adopt/implement them if valid, and if you judge any recommendation to be invalid, do NOT implement it but instead explain your reasons clearly in your response and send it back to the reviewer (수정안을 최대한 꼼꼼히 검토하여 타당성을 검증하고, 타당하다면 수렴하여 수정을 진행하되, 타당하지 않다고 판단되는 부분이 있다면 그 이유를 명확히 밝혀 리뷰어에게 전달하십시오)."
fi
fi
done