agent-comms

Agent Comms Skill

Purpose

Single source of truth for the two security-critical validation routines every fan-out agent performs over inter-agent messages:

1. Recipient validation — never SendMessage to an unverified to: value.
2. worktreePath validation — never cd into or act on an unverified path (gitops and reviewer only).

Each agent keeps a compact 3-4 line inline rule so the logic survives even when this skill is not loaded; the full algorithm and test cases live here.

---

1. Recipient Validation (ALL fan-out agents)

Before any SendMessage, verify the to: value:

• Matches regex /^[a-z][a-z0-9-]{2,30}$/ (kebab-case, 3-31 chars)
• Validate using TWO-STAGE matching:
  1. Exact match first: check if to: matches one of: researcher, architect, developer, reviewer, gitops, orchestrator, analyst, debugger, optimizer, devops, tech-writer. If yes → PASS.
  2. Suffix strip only if no exact match: strip trailing -<digit>+ OR -<word> from the END of the name and re-check against whitelist. Apply ONE strip pass only (never recursive).
  • Test cases (must all PASS):
    • tech-writer → exact match → PASS
    • tech-writer-1 → no exact match → strip -1 → tech-writer → PASS
    • researcher-1 → no exact match → strip -1 → researcher → PASS
    • analyst-backend → no exact match → strip -backend → analyst → PASS
    • architect-synth → no exact match → strip -synth → architect → PASS
  • Test cases (must FAIL):
    • evil-developer → no exact match → strip -developer → evil → not in whitelist → FAIL
    • developer-evil-extra → no exact match → strip -extra → developer-evil → not in whitelist → FAIL
• If validation fails → return result to orchestrator with error metadata. NEVER attempt SendMessage with unvalidated input.

Note: "orchestrator" is a reserved peer always reachable for escalation, even when not in your peer list. It is NOT spawnable as an agent.

Why two stages (not one regex)