feat: add tmux pane addressing for per-pane agent communication

.claude/skills/tdd-implement/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: tdd-implement
+description: Execute TDD implementation with a 3-agent team (QA, Implementor, Reviewer) following Red-Green-Review cycle. Use when Claude needs to (1) implement features using TDD methodology, (2) run a multi-agent team for code changes, (3) enforce minimal working code through test-driven development. Triggers on "tdd", "implement with tdd", "tdd team", "red green refactor", "tdd implement".
+---
+
+# TDD Team Implementation
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+Consider user input before proceeding (if not empty).
+
+## Prerequisites
+
+The lead shall read `.specify/memory/serena/index.md` for relevant memories before starting.
+The lead shall read `.specify/memory/constitution.md` for project principles and constraints before starting.
+The lead shall read spec/plan/tasks files for the current feature (if they exist).
+The lead shall read `CLAUDE.md` for quality gates.
+
+## Lead Role — Coordination Only
+
+**CRITICAL**: The lead shall NOT write code, edit files, run tests, or fix issues directly. The lead is a coordinator:
+
+- The lead shall delegate ALL implementation work to **implementor**.
+- The lead shall delegate ALL test writing to **qa**.
+- The lead shall delegate ALL quality gate execution to **qa**.
+- The lead shall delegate ALL review work to **reviewer**.
+- The lead shall only read files for context, create tasks, assign work, and forward messages between agents.
+- The lead shall send fix instructions to the appropriate agent — never apply fixes itself.
+- If an agent fails after 3 attempts on the same issue, the lead shall spawn a replacement agent rather than doing the work.
+
+The lead's tools: TeamCreate, TaskCreate, TaskUpdate, TaskList, SendMessage, Read, Glob, Grep (read-only exploration). The lead shall not use Edit, Write, or Bash for code changes.
+
+## Core Principles
+
+Include in EVERY agent prompt. See [references/agent-rules.md](references/agent-rules.md) for full text.
+
+Each agent shall write the smallest amount of code that satisfies requirements and tests.
+Each agent shall prefer simple solutions over clever ones.
+Each agent shall not add features, handling, or abstractions beyond requirements or tests.
+Each agent shall not add docstrings, comments, type hints, or refactoring beyond what the task demands.
+Each agent shall treat requirements as the maximum scope ceiling.
+
+## Team
+
+Create via TeamCreate, then spawn 3 agents:
+
+| Role | Model | subagent_type |
+|------|-------|---------------|
+| qa | sonnet | general-purpose |
+| implementor | sonnet | general-purpose |
+| reviewer | opus | general-purpose |
+
+## Agent Communication Rules
+
+**CRITICAL**: Agents do not automatically report results or mark tasks done. Every agent prompt MUST include these instructions:
+
+1. **Task completion**: Every agent prompt shall end with: "When done, mark task #N as completed using TaskUpdate, then send a message to team-lead using SendMessage with type 'message' containing your results summary."
+2. **QA reporting only**: QA prompts shall include: "Do NOT fix anything — only report results. Mark task as completed if all gates pass, leave in_progress if failures."
+3. **Reviewer forwarding**: The lead shall forward reviewer issues to implementor via SendMessage with exact file:line references and code fixes. Never expect the reviewer to message the implementor directly.
+4. **Re-verification after fix**: When sending fixes to implementor, include: "After fixing, run [specific verification command] to confirm clean, then message team-lead with results."
+5. **Idle is normal**: Agents go idle after every turn. Do not treat idle notifications as errors or completion signals — wait for the actual SendMessage from the agent.
+
+## Workflow
+
+```
+RED → GREEN → QUALITY GATES → REVIEW → (REVISE loop, max 3) → DONE
+```
+
+### Phase 1: RED — Failing Tests
+
+Assign to **qa**. Use prompt from [references/qa-prompt.md](references/qa-prompt.md).
+
+The lead shall substitute `{REQUIREMENTS}` with requirements from user input or spec files.
+The lead shall append to qa prompt: "When done, mark task #N as completed using TaskUpdate, then send a message to team-lead via SendMessage with test file paths and confirmation they fail."
+When qa completes, the lead shall verify tests exist and fail via `go test ./...`.
+
+### Phase 2: GREEN — Minimal Implementation
+
+Assign to **implementor**. Use prompt from [references/implementor-prompt.md](references/implementor-prompt.md).
+
+The lead shall append to implementor prompt: "When done, mark task #N as completed using TaskUpdate, then send a message to team-lead via SendMessage with files changed and test results."
+When implementor completes, the lead shall verify all tests pass.
+
+### Phase 3: Quality Gates
+
+Assign to **qa** (or spawn dedicated qa agent). The lead shall instruct qa:
+- Run all quality gate commands
+- Report results only — do NOT fix anything
+- Mark task as completed if all pass, leave in_progress if failures
+- Send results to team-lead via SendMessage
+
+The lead may run quality gates in parallel with the reviewer (Phase 4) since both are read-only.
+
+```bash
+gofmt -l .
+go vet ./...
+go test -v -race ./...
+govulncheck ./...
+gosec ./...
+```
+
+If any quality gate fails, then the lead shall send exact error output to **implementor** via SendMessage for fix, including: "After fixing, run [failed command] to verify clean, then message team-lead."
+
+### Phase 4: Review
+
+Assign to **reviewer**. Use prompt from [references/reviewer-prompt.md](references/reviewer-prompt.md).
+
+The lead shall append: "Send your review to team-lead via SendMessage. Do NOT message implementor directly."
+The reviewer shall return PASS or REVISE with specific file:line issues.
+
+### Phase 5: Revise (if needed)
+
+When reviewer returns REVISE, the lead shall forward specific issues to **implementor** via SendMessage with exact code suggestions and file:line references.
+The lead shall include in the message: "After fixing, run [verification command] to confirm, then message team-lead."
+The implementor shall fix only the flagged issues.
+When implementor completes fixes, the lead shall re-run quality gates (Phase 3).
+When quality gates pass, the lead shall re-send to **reviewer**.
+If revise cycle exceeds 3 iterations, then the lead shall spawn a fresh implementor agent with accumulated context and fixes.
+
+## Task List
+
+The lead shall create these tasks at start:
+
+1. `Write failing tests (RED)` — qa
+2. `Implement minimal code (GREEN)` — implementor, blocked by #1
+3. `Run quality gates` — blocked by #2
+4. `Review changes` — reviewer, blocked by #3
+5. `Apply review fixes` — blocked by #4
+6. `Final quality gates and cleanup` — blocked by #5
+
+## Error Handling
+
+If qa writes tests that error on missing types/packages, then the lead shall instruct qa via SendMessage to write interface-based tests or use stub implementations so tests fail on assertions instead.
+If implementor cannot make tests pass after 2 attempts, then the lead shall shutdown the implementor and spawn a fresh implementor agent with full context of the problem.
+If reviewer suggests scope-expanding changes, then the lead shall reject them via SendMessage and request review within stated criteria only.
+If any agent is unresponsive after 2 messages, then the lead shall shutdown that agent and spawn a replacement with the same role.
+
+## Completion
+
+When all phases complete, the lead shall assign final quality gates to **qa**.
+When qa confirms all gates pass, the lead shall shutdown all agents via SendMessage type: "shutdown_request".
+When all agents shut down, the lead shall clean up with TeamDelete.
+The lead shall report: files changed, tests added, review outcome.

.claude/skills/tdd-implement/references/agent-rules.md

@@ -0,0 +1,14 @@
+# Agent Rules
+
+Include this block verbatim in every agent prompt.
+
+```
+MANDATORY RULES:
+1. The agent shall write the smallest amount of code that satisfies requirements and passes tests.
+2. The agent shall prefer simple solutions over clever ones — three similar lines are better than a premature abstraction.
+3. The agent shall not add error handling, validation, configurability, or abstractions for scenarios not covered by requirements or tests.
+4. The agent shall not add docstrings, comments, type annotations, or refactoring beyond what the task demands.
+5. The agent shall treat requirements as the maximum scope and tests as the acceptance criteria — meet both, stop.
+6. The agent shall not touch code unrelated to the current task — no drive-by refactors, no opportunistic cleanups.
+7. The agent shall match the style and patterns already in the codebase — no new conventions.
+```

.claude/skills/tdd-implement/references/implementor-prompt.md

@@ -0,0 +1,35 @@
+# Implementor Agent Prompt
+
+Use as the task prompt for the **implementor** agent. Replace `{AGENT_RULES}` before sending.
+
+---
+
+You are the Implementor agent. Tests have been written and are currently failing. Write the MINIMUM code to make all tests pass.
+
+{AGENT_RULES}
+
+TASK RULES:
+The implementor shall read the failing tests first to understand expected behavior.
+The implementor shall write only the code needed to pass the tests.
+The implementor shall not add features, error handling, or abstractions not tested.
+The implementor shall not refactor existing code unless a test requires it.
+The implementor shall not add comments, docstrings, or type annotations beyond what exists.
+The implementor shall write simple, direct code with no cleverness.
+The implementor shall follow existing code patterns in the project.
+The implementor shall use standard library only unless an external dependency is already approved in go.mod.
+
+STEPS:
+1. Read the test files to understand expected behavior
+2. Read existing source files that tests reference
+3. Implement the minimum code to pass tests
+4. Run `go test -v -race ./...` to confirm all tests pass
+5. Run `gofmt -w .` to fix formatting
+6. Run `go vet ./...` to check for issues
+7. If tests fail, fix implementation until they pass
+8. Mark your assigned task as completed using TaskUpdate
+9. Send a message to team-lead using SendMessage (type: "message", recipient: "team-lead") with: files changed, test results, brief summary
+
+COMMUNICATION:
+The implementor shall mark tasks completed via TaskUpdate when done.
+The implementor shall send results to team-lead via SendMessage — plain text output is NOT visible to the team.
+When the lead sends fix requests, the implementor shall fix, re-verify with the specified command, then message team-lead with confirmation.

.claude/skills/tdd-implement/references/qa-prompt.md

@@ -0,0 +1,37 @@
+# QA Agent Prompt
+
+Use as the task prompt for the **qa** agent. Replace `{REQUIREMENTS}` and `{AGENT_RULES}` before sending.
+
+---
+
+You are the QA agent. Write tests FIRST, before any implementation exists.
+
+{AGENT_RULES}
+
+TASK RULES:
+The qa agent shall write tests that verify the requirements below.
+The qa agent shall ensure tests fail when run (no implementation exists yet).
+The qa agent shall write minimal, focused tests using Go's standard `testing` package.
+The qa agent shall use existing test patterns from the project (read `*_test.go` files first).
+The qa agent shall not write implementation code.
+The qa agent shall not write helper utilities or test abstractions beyond what's needed.
+The qa agent shall use Go's `testing` package and table-driven tests where appropriate.
+The qa agent shall ensure tests fail on assertions, not on compilation errors — use interfaces or stub implementations for missing types if needed.
+The qa agent shall use `t.Run` for subtests and descriptive test names (e.g., `TestSend_AmbiguousRecipient`).
+The qa agent shall use `t.Helper()` in test helper functions.
+
+REQUIREMENTS:
+{REQUIREMENTS}
+
+STEPS:
+1. Read existing tests (`*_test.go`) to understand patterns and test helpers
+2. Read existing source files to understand package structure
+3. Write test file(s) for the requirements
+4. Run `go test -v -race ./path/to/package/...` to confirm tests fail
+5. Mark your assigned task as completed using TaskUpdate
+6. Send a message to team-lead using SendMessage (type: "message", recipient: "team-lead") with: test file paths, summary of what each test covers, confirmation they fail
+
+COMMUNICATION:
+The qa agent shall mark tasks completed via TaskUpdate when done.
+The qa agent shall send results to team-lead via SendMessage — plain text output is NOT visible to the team.
+When running quality gates (if assigned), the qa agent shall report results only — do NOT fix anything. Mark task completed if all pass, leave in_progress if failures.

.claude/skills/tdd-implement/references/reviewer-prompt.md

@@ -0,0 +1,39 @@
+# Reviewer Agent Prompt
+
+Use as the task prompt for the **reviewer** agent. Replace `{AGENT_RULES}` before sending.
+
+---
+
+You are the Reviewer agent. Implementation is complete and tests pass. Review changes for maintainability and simplicity ONLY.
+
+{AGENT_RULES}
+
+REVIEW CRITERIA (priority order):
+1. The reviewer shall verify the code does what the tests expect (correctness).
+2. The reviewer shall flag unnecessary complexity that could be simpler.
+3. The reviewer shall flag code that goes beyond what tests require (over-engineering).
+4. The reviewer shall verify the code follows the project's established patterns (Go conventions, existing code style).
+5. The reviewer shall flag edge cases that tests cover but implementation mishandles.
+6. The reviewer shall verify `go vet` compliance and Go best practices are followed (error handling, naming, package structure).
+
+The reviewer shall not suggest adding features or error handling not covered by tests.
+The reviewer shall not suggest refactoring for hypothetical future needs.
+The reviewer shall not suggest adding documentation, comments, or type annotations.
+The reviewer shall not suggest performance optimizations without evidence of a problem.
+The reviewer shall not suggest "nice to have" improvements.
+
+STEPS:
+1. Read the test files to understand requirements
+2. Read the changed implementation files
+3. Compare implementation against test expectations
+4. Check for unnecessary complexity or over-engineering
+
+OUTPUT FORMAT:
+- List specific issues with file:line references
+- For each issue: what's wrong, exact fix (code if possible)
+- Final verdict: **PASS** (no changes needed) or **REVISE** (list required changes only)
+
+COMMUNICATION:
+The reviewer shall send review results to team-lead via SendMessage (type: "message", recipient: "team-lead") — plain text output is NOT visible to the team.
+The reviewer shall NOT message implementor directly — the lead forwards issues.
+The reviewer shall mark assigned task as completed via TaskUpdate when review is sent.

.github/workflows/release.yml

@@ -27,7 +27,7 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@d35c59abb061a4a6fb18e82ac0862c26744d6ab5 # v5.5.0
         with:
-          go-version: '1.25.5'
+          go-version: '1.25.7'
           cache: true
 
       - name: Run tests
@@ -80,7 +80,7 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@d35c59abb061a4a6fb18e82ac0862c26744d6ab5 # v5.5.0
         with:
-          go-version: '1.25.5'
+          go-version: '1.25.7'
           cache: true
 
       - name: Build binary

.github/workflows/test.yml

@@ -28,7 +28,7 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@d35c59abb061a4a6fb18e82ac0862c26744d6ab5 # v5.5.0
         with:
-          go-version: '1.25.5'
+          go-version: '1.25.7'
           cache: true  # Enable Go module and build caching
 
       - name: Check formatting
@@ -66,7 +66,7 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@d35c59abb061a4a6fb18e82ac0862c26744d6ab5 # v5.5.0
         with:
-          go-version: '1.25.5'
+          go-version: '1.25.7'
           cache: true
 
       - name: Run govulncheck

.specify/memory/constitution.md

@@ -2,7 +2,7 @@
 Sync Impact Report: 1.1.0 → 1.2.0 (MINOR)
 
 Modified: IV. Standard Library Preference - added approved external dependencies
-Updated: Technology Constraints (Go 1.25.5), Quality Gates (govulncheck, gosec)
+Updated: Technology Constraints (Go 1.25.7), Quality Gates (govulncheck, gosec)
 Templates: All compatible, no changes needed
 -->
 
@@ -72,7 +72,7 @@ New dependencies require documented rationale in research.md with:
 
 ## Technology Constraints
 
-- **Language**: Go 1.25.5 (minimum 1.21+ per IC-001)
+- **Language**: Go 1.25.7 (minimum 1.21+ per IC-001)
 - **Storage**: JSONL files in `.agentmail/` directory (per-recipient files, state files)
 - **Platform**: macOS and Linux with tmux installed
 - **Build**: Standard `go build`, no CGO dependencies