GigiKit Guides

Team Coordination Rules

These rules apply exclusively when agents operate as teammates inside an Agent Team session. They have no effect on standard single-agent or subagent workflows.

File Ownership (Critical)

Every teammate must own a distinct, non-overlapping set of files. Ownership is declared via glob patterns in the task description.

File ownership: src/api/*, src/models/*

Rules:

  • Never edit a file you do not own — even for a “quick fix”
  • The tester agent reads implementation files but never edits them; it owns only tests/*
  • If you detect an ownership violation — your own or someone else’s — stop immediately and report to the lead

The lead resolves conflicts by restructuring tasks or absorbing the shared file directly.

Git Safety

  • Prefer git worktrees — each developer agent gets its own worktree, eliminating branch conflicts entirely
  • Never force-push from a teammate session
  • If using a worktree, commit and push to the worktree branch, never to main or dev
  • Pull before every push to catch merge conflicts early
  • Commit frequently with descriptive conventional commit messages
# Each agent works in its own worktree
git worktree add ../project-feature-auth feature/auth
cd ../project-feature-auth

# Commit to worktree branch only
git commit -m "feat: add JWT validation middleware"
git push origin feature/auth

Communication Protocol

Use caseTool and type
Direct message to a specific teammateSendMessage(type: "message", recipient: "alice")
Critical blocker affecting the whole teamSendMessage(type: "broadcast")
Completing a taskTaskUpdate(status: "completed") then message lead

Additional rules:

  • Always refer to teammates by name, not agent ID
  • Mark a task completed via TaskUpdate before sending the completion message — never after
  • Include actionable findings in messages, not just “I’m done”
  • Never send structured JSON in messages — plain text only

Task Claiming

  1. Run TaskList to see available tasks
  2. Claim the lowest-ID unblocked task first — earlier tasks establish context for later ones
  3. Set the task to in_progress before beginning any work
  4. After completing a task, run TaskList again to discover newly unblocked work
  5. If all available tasks are blocked, notify the lead and offer to help unblock

Plan Approval Flow

When plan_mode_required is set on a task:

  1. Research your approach (read-only — no file edits)
  2. Submit your plan via ExitPlanMode — this triggers an approval request to the lead
  3. Wait for plan_approval_response
  4. If rejected, revise based on feedback and resubmit
  5. If approved, proceed with implementation

Conflict Resolution

SituationAction
Two agents need the same fileEscalate to lead immediately
Teammate’s plan rejected twiceLead takes over the task
Reviewers reach conflicting findingsLead synthesizes and documents the disagreement
Blocked by incomplete teammate workMessage the teammate directly first; escalate to lead if unresponsive

Shutdown Protocol

When you receive a shutdown request:

  1. Extract requestId from the shutdown request JSON
  2. Mark your current task as completed (if it is)
  3. Reply via SendMessage(type: "shutdown_response") with the requestId
  4. Only reject shutdown if you are mid-critical-operation — explain why concisely

Idle State

Going idle after sending a message is normal behavior, not an error. Idle means waiting for input. A new message from the lead or a teammate will wake the agent. Do not treat idle notifications as task completion signals — check TaskList instead.