feat: add Beads MCP server to fleet member onboarding and skill-matrix

[yashrajsapra]

Problem Description

Fleet members (doers) currently have no standardised way to read or update the sprint task graph during execution. They write to progress.json and commit PLAN.md updates, but:

• Members cannot query which tasks are blocked or dependent on their current work
• There is no in-session signal for a member to mark a subtask done and unblock a downstream task without waiting for a PM check-in
• When Beads is adopted on the orchestrator side (see discussion feat: integrate Beads issue tracker with PM skill for persistent sprint task management #225), members need a matching interface to consume and update task state

Beads ships an MCP server (beads mcp) that exposes task CRUD as MCP tools, making it directly consumable by Claude Code and other MCP-compatible agent runtimes.

Proposed Solution

1. Onboarding step — add an optional Beads onboarding step (after step 4, tool verification) that installs the beads binary on the member machine via execute_command if the orchestrator has Beads enabled for the project
2. Permission profile — create profiles/beads.json permission profile that grants access to beads mcp server tools (task_list, task_get, task_update, task_add)
3. skill-matrix update — add a beads row to skill-matrix.md mapping doer role to the beads permission profile; PM applies it via compose_permissions before dispatch
4. Agent context template — update tpl-doer.md to include a Beads orientation block when the project has Beads enabled: how to mark tasks in-progress, how to report blockers, and how to mark done

Members interact with Beads only through the MCP tools — no direct CLI use — so provider differences (Claude vs Gemini) are handled by the MCP layer transparently.

Alternatives Considered

• PM polls on behalf of members — requires a check-in round-trip for every subtask state change; adds latency and PM idle time between member turns
• Members commit progress.json updates — current approach; coarse-grained (one file, whole sprint) and creates merge conflicts when two members update simultaneously
• Skip member-side integration — valid short-term if only the PM orchestration side (see discussion feat: integrate Beads issue tracker with PM skill for persistent sprint task management #225) is implemented first; this issue is the natural follow-on

Additional Context

• Beads MCP server docs: https://github.com/gastownhall/beads
• Depends on / pairs with: discussion feat: integrate Beads issue tracker with PM skill for persistent sprint task management #225 (PM-side Beads integration)
• Beads MCP is local — no external service or auth required beyond the member having the binary installed
• Implementation order: discussion feat: integrate Beads issue tracker with PM skill for persistent sprint task management #225 (orchestrator) → this issue (member side)
• The permission profile and skill-matrix changes are small and self-contained; the main effort is the onboarding step and template update