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

.agents/AGENT.md

@@ -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.*