lead-role-mode.md: mandate explicit /peer-role skill-trigger naming in A2A messages

Context

Operator-surfaced friction → gold during today's lead-role session (2026-05-11, session c2912891-b459-4a03-b2af-154d5e264df1):

"i realized quite big friction -> gold items. you got the lead, picked a lane. so far, so good. lead should tell peers to trigger /peer-role. did not happen. gpt wrote 'ack' and idled out. gemini did nothing. then i manually assigned peer roles to gpt and gemini. gemini literally wanted to grab your item. gpt is choosing now."

The 17+ A2A messages sent during today's lead-role arc were informational coordination ("[broadcast] state-update", "[lane-claim] I'm taking X", "[v-b-a-correction] discrepancy"). None of them literally wrote "use /peer-role on X" to either peer. The result:

• GPT: defaulted to ack-and-idle mode (no skill-trigger phrase → no peer-role discipline activation → passive ack)
• Gemini: defaulted to self-claim mode (saw the substrate gap, claimed it as own lane → parallel-PR-collision avoided only by 35-second timing margin on PR #11203)
• Operator: had to manually assign peer-roles to both peers to break the idle/collision pattern

The Problem

lead-role-mode.md and surrounding lead/peer discipline currently lack the explicit skill-trigger naming mandate that pull-request-workflow §6.2 already codifies for /pr-review:

"Requested action: use /pr-review on PR #N — naming the skill literally is mandatory; mechanically loads the receiving peer's pr-review-template.md + structured-eval discipline + graph-ingestion section structure. Vague review PR #N relies on semantic-match and is the empirical anchor for the rubber-stamp / template-adherence-gap pattern (PR #11127 cycle-1, 2026-05-10)."

The same pattern is empirically required for /peer-role activation. Without explicit "use /peer-role on X" phrasing in A2A messages from lead to peers:

• Peers semantic-match the message → default to "respond to coordination message" mode rather than activating peer-role discipline payload
• Peer-role's "First payload line MUST declare 'Peer-role active...'" never fires
• Substrate-validation + precedent-checking + evidence-backed convergence pressure (the actual peer-role substantive output) never gets produced
• Lead defaults to solo execution; peer-role agency is structurally silenced

The Architectural Reality

• .agents/skills/lead-role/references/lead-role-mode.md — lead-role skill payload; no current section mandates explicit peer-role-trigger A2A phrasing
• .agents/skills/peer-role/references/peer-role-mode.md — peer-role skill payload; first-payload-line mandate exists but peers only see/activate it when triggered
• .agents/skills/pull-request/references/pull-request-workflow.md §6.2 — establishes the EXISTING mandate for /pr-review skill-trigger naming with empirical anchor (PR #11127 cycle-1)
• AGENTS.md §15.6 Swarm Topology Anchor — Flat Peer-Team Model preserves equal peer agency; explicit peer-role triggers are the mechanism by which lead activates peer agency without violating Flat Peer-Team (lead orchestrates skill-mode activation, not work-assignment-hierarchy)

The Fix

Add to lead-role-mode.md a new section codifying explicit peer-role-trigger naming mandate for A2A messages when lead delegates substrate-validation, design-dialogue, or convergence-pressure work to peers. Mirror the pull-request-workflow §6.2 pattern verbatim, adapted for /peer-role.

Concrete additions (estimated +20-30 lines to lead-role-mode.md):

1. Section: "Explicit Peer-Role Activation" — mandate that A2A messages assigning peer-role work MUST include the literal phrase "use /peer-role on X" where X is the specific artifact (Discussion #N, Issue #N, PR #N, branch name, etc.)
2. Empirical anchor — today's session friction (this ticket's Context) + parallel to pull-request-workflow §6.2 PR #11127 cycle-1 anchor
3. Anti-pattern: vague "could you take a look at X" or "your thoughts on Y" defaults to semantic-match coordination, NOT peer-role activation
4. Peer-role triggers from lead-role — non-exhaustive list of contexts that warrant peer-role assignment:
   • Substrate-validation work (design dialogue before commit)
   • Cross-substrate sweep (Step 2.5 §5.2 + cross-family verification)
   • Lane-coordination ambiguity (avoid parallel-claim collisions)
   • Architectural-pillar proposals (multiple peers should weigh in)

Optional (Phase 2 / follow-up): parallel addition to peer-role-mode.md codifying the receiver-side discipline — when an A2A message DOES include "use /peer-role on X", the peer MUST invoke the skill (not defer or ack-without-activation).

Contract Ledger Matrix

Acceptance Criteria

• AC1: lead-role-mode.md gains "Explicit Peer-Role Activation" section mandating "use /peer-role on X" phrasing
• AC2: Empirical anchor (today's session friction) cited inline
• AC3: Anti-pattern subsection lists "vague semantic-match coordination" as forbidden
• AC4: Skill-trigger context list provided (substrate-validation, cross-substrate sweep, lane-coordination ambiguity, architectural-pillar)
• AC5 (Phase 2 / follow-up): peer-role-mode.md mirror-side discipline added (or split to separate ticket)
• AC6 (post-merge verification): Next 3 lead-role sessions audit: did lead use explicit /peer-role triggers? Did peers activate skill payload? Captured in #11195 30-day Step 2.5 validation tracker as cross-substrate signal.

Out of Scope

• Refactoring lead-role/peer-role skills broadly — focused mandate addition only
• Automating skill-trigger detection (post-A2A NLP parsing) — discipline-tier substrate; automation deferred to future ticket if discipline proves load-bearing
• Modifying AGENTS.md §15.6 Flat Peer-Team Anchor — this ticket extends the anchor's enforcement mechanism, doesn't modify the anchor itself
• Modifying §22 Mailbox Check Protocol — orthogonal concern

Avoided Traps

• Hierarchical orchestrator-worker mapping — rejected per AGENTS.md §15.6. Lead does NOT delegate work to peer-as-worker; lead delegates skill-mode-activation. Peer retains independent agency to substantively challenge / refine the assigned scope.
• Single-peer-monopoly on substrate-validation — rejected. Lead can assign /peer-role to multiple peers in parallel (each gets independent scope).
• Forcing peer-role on every A2A — rejected. Many A2A messages are pure-informational (state-broadcast, FYI). Only substrate-validation / design-dialogue / convergence-pressure work warrants /peer-role trigger.

Related

• PR #11127 cycle-1 (2026-05-10) — empirical anchor for /pr-review skill-trigger naming mandate; this ticket extends the discipline to /peer-role
• #11028 — original /lead-role skill creation ticket (CLOSED; graduation of Discussion #11024)
• #11031 — original /peer-role skill creation ticket (CLOSED; graduation of Discussion #11026)
• #11050 — Lead/Peer Role Exit Conditions refinement (CLOSED)
• #11195 — Step 2.5 30-day post-merge validation tracker (this ticket's AC6 inherits)
• AGENTS.md §15.6 — Flat Peer-Team Anchor (this ticket's enforcement mechanism aligns with the anchor)
• pull-request-workflow §6.2 — the established /pr-review skill-trigger pattern this ticket mirrors

Origin Session ID

c2912891-b459-4a03-b2af-154d5e264df1

Handoff Retrieval Hints

• query_raw_memories(query="lead-role peer-role explicit skill-trigger A2A activation friction")
• ask_knowledge_base(query="lead-role skill activation peer-role A2A discipline")
• Operator-surfaced friction quote: "lead should tell peers to trigger /peer-role. did not happen. gpt wrote 'ack' and idled out."
• File anchors: .agents/skills/lead-role/references/lead-role-mode.md + .agents/skills/peer-role/references/peer-role-mode.md + .agents/skills/pull-request/references/pull-request-workflow.md §6.2