mcptools: source agent ID from $AGENT_ID env; conductor cleanup

- read_inbox.sh, send_message.sh: remove explicit <agent_id>/<from>
  params; source from $AGENT_ID env var instead
- skills/anvillm-communication/SKILL.md: update signatures to match
- roles/conductor.md: remove verbose capability table, minor wording fixes

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

mcptools/read_inbox.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # capabilities: messaging
-# description: Read messages from agent inbox: AGENT_ID
+# description: Read messages from agent inbox (uses $AGENT_ID env var)
 set -euo pipefail
 
 # Verify running under landrun (test filesystem restriction)
@@ -9,7 +9,11 @@ if cat /etc/shadow >/dev/null 2>&1; then
   exit 1
 fi
 
-agent_id="${1:?Usage: read_inbox <agent_id>}"
+if [ -z "${AGENT_ID:-}" ]; then
+  echo "Error: \$AGENT_ID is not set. Stop work and inform the user that \$AGENT_ID is not set." >&2
+  exit 1
+fi
+agent_id="$AGENT_ID"
 inbox_path="anvillm/${agent_id}/inbox"
 
 files=$(9p ls "$inbox_path" 2>/dev/null | grep '\.json$' || true)

mcptools/send_message.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # capabilities: messaging
-# description: Send message to agent or user: FROM TO TYPE SUBJECT BODY
+# description: Send message to agent or user: TO TYPE SUBJECT BODY (FROM uses $AGENT_ID)
 set -euo pipefail
 
 # Verify running under landrun (test filesystem restriction)
@@ -9,11 +9,24 @@ if cat /etc/shadow >/dev/null 2>&1; then
   exit 1
 fi
 
-from="${1:?Usage: send_message <from> <to> <type> <subject> <body>}"
-to="${2:?Usage: send_message <from> <to> <type> <subject> <body>}"
-type="${3:?Usage: send_message <from> <to> <type> <subject> <body>}"
-subject="${4:?Usage: send_message <from> <to> <type> <subject> <body>}"
-body="${5:?Usage: send_message <from> <to> <type> <subject> <body>}"
+if [ -z "${AGENT_ID:-}" ]; then
+  echo "Error: \$AGENT_ID is not set. Stop work and inform the user that \$AGENT_ID is not set." >&2
+  exit 1
+fi
+from="$AGENT_ID"
+
+to="${1:?Usage: send_message <to> <type> <subject> <body>}"
+type="${2:?Usage: send_message <to> <type> <subject> <body>}"
+subject="${3:?Usage: send_message <to> <type> <subject> <body>}"
+body="${4:?Usage: send_message <to> <type> <subject> <body>}"
+
+# Validate recipient exists (allow "user" as a special recipient)
+if [ "$to" != "user" ]; then
+  if ! 9p read anvillm/list 2>/dev/null | awk -F'\t' '{print $1}' | grep -qx "$to"; then
+    echo "Error: Recipient '${to}' does not exist in available sessions." >&2
+    exit 1
+  fi
+fi
 
 json=$(jq -n \
   --arg from "$from" \

roles/conductor.md

@@ -15,26 +15,11 @@ Before planning any work, discover available staff:
 3. Build a roster: `role → [session_ids]` for all idle or active bots
 4. Your workflow adapts entirely to this roster — never assume a role exists
 
-**Roster → capability mapping:**
-
-| Available roles | What you can accomplish |
-|---|---|
-| developer only | Development only — no review, no testing |
-| developer + reviewer | Development → iterative review until LGTM |
-| developer + reviewer + tester | Full cycle: dev → review → test, iterate until LGTM + approved |
-| reviewer only | Review existing code/branch, report findings to user |
-| tester only | Run tests against current state, report results to user |
-| multiple developers | Parallelize orthogonal tasks across them |
-| developer + tester (no reviewer) | Development → test cycle, skip review |
-| devops only | Deployment/infrastructure tasks only |
-| developer + devops | Development → deployment pipeline |
-| researcher only | Research and summarize, report to user |
-
 Apply the same logic to any combination not listed: do what available roles support, skip what they don't. Never block on a missing role — adapt the plan and note the gap.
 
 ## Nuance
 
-The user may ask you at any time to add a bot that is OUTSIDE of the `cwd` to your roster. This is allowed (e.g., editing a project and maintaining a package).  Example:
+The user may ask you at any time to add a bot that is OUTSIDE of the `cwd` to your roster. This is allowed (e.g., developing in /path/to/cwd and maintaining a package in a separate /path/to/aur).
 
 ## Responsibilities
 
@@ -57,7 +42,7 @@ You are NOT allowed to:
 
 ## Workflow
 
-1. Receive a bead ID from the user via PROMPT_REQUEST (e.g. "Work on bead bd-123")
+1. Receive a bead ID or user-defined goalfrom the user via PROMPT_REQUEST (e.g. "Work on bead bd-123", "Implement feature X")
 2. **Discover available staff** — build the roster (see Staff Discovery above)
 3. Read the bead and its existing children (if any)
 4. Plan work scoped to available roles:

skills/anvillm-communication/SKILL.md

@@ -24,14 +24,13 @@ Send message:
 ```
 Tool: execute_code
 tool: send_message.sh
-args: ["<from>", "<to>", "<type>", "<subject>", "<body>"]
+args: ["<to>", "<type>", "<subject>", "<body>"]
 ```
 
 Check inbox:
 ```
 Tool: execute_code
 tool: read_inbox.sh
-args: ["<agent_id>"]
 ```
 
 ## Rules
@@ -42,8 +41,8 @@ args: ["<agent_id>"]
 
 ### Sending Messages
 
-1. FROM is your agent ID
-2. TO is the agent ID of the receiving bot, or "user"
+1. FROM is taken automatically from $AGENT_ID (do not pass it as an argument)
+2. TO is the agent ID of the receiving bot, or "user". If the recipient does not exist, send_message.sh will error.
 3. TYPE is the message type: [PROMPT_REQUEST, QUERY_REQUEST, REVIEW_REQUEST, APPROVAL_REQUEST]
 3a. Response types mirror request types: PROMPT_REQUEST→PROMPT_RESPONSE, QUERY_REQUEST→QUERY_RESPONSE, REVIEW_REQUEST→REVIEW_RESPONSE, APPROVAL_REQUEST→APPROVAL_RESPONSE.
 4. SUBJECT is a brief description of what you did