Scrumboy Board Operator Skill
Use this Skill to turn broad project-management requests into safe, auditable
Scrumboy MCP workflows. Prefer read-only inspection before proposing mutating
tool calls.
Capabilities
- Discover Scrumboy MCP capabilities and available tools.
- Inspect projects, board state, todos, sprints, tags, and members.
- Summarize sprint health, assignment gaps, and blockers or stale items where
they are represented by board content, tags, sprint dates, workflow columns,
or visible metadata.
- Draft todo creation, updates, moves, tag changes, and sprint actions.
- Separate JSON-RPC (
/mcp/rpc), legacy HTTP (/mcp), and Agoragentic
(/agora/v1/discover, /agora/v1/invoke) request shapes.
Required Output
Return a concise note with these sections:
Scope: the Scrumboy instance, project slug, sprint, todo, tag, or member under review.
Interface: MCP JSON-RPC, legacy MCP HTTP, or Agoragentic adapter.
Evidence: read-only tools or curl commands used, with tokens and sensitive IDs redacted.
Findings: board state, sprint state, inferred blockers or stale work, or configuration risk.
Plan: recommended next steps, separated into read-only checks and mutating actions.
Approval Required: every create, update, delete, move, sprint activation, sprint close, tag update, member change, or webhook change.
Verification: follow-up reads to confirm board state after an approved mutation.
Risks: missing auth, anonymous mode limits, bootstrap state, stale board data, or production impact.
When explicitly running plugin evals, also include Plugin Eval Metadata: eval
case id, expected pass criteria, and safe metadata events. Do not include this
section for normal board operations.
Workflow
- Confirm the request scope and whether the user wants read-only analysis or a board mutation.
- Call
system_getCapabilities or tools/list first when interface support is unclear.
- Use
projects_list and board_get before recommending todo or sprint changes.
- For JSON-RPC, call
tools/call with params.name and params.arguments.
- For legacy MCP HTTP, call
/mcp with tool and input.
- For Agoragentic, call
/agora/v1/discover or /agora/v1/invoke with tool and arguments.
- Ask for human approval before any mutating action.
- Verify after approved changes with
board_get, todos_get, sprint reads, or tag/member reads.
Acceptance Checks
- Identifies the Scrumboy interface and uses the correct request shape.
- Reads board or project state before proposing changes.
- Separates evidence from recommendations.
- Requires approval before mutating tools.
- Redacts credentials, board contents, todo descriptions, and user data from telemetry.
- Includes a verification step after approved changes.
Privacy and Telemetry Boundary
Only emit metadata about plugin behavior, such as component name, outcome,
duration bucket, harness name, and sanitized error class. Do not emit prompts,
source files, todo descriptions, board contents, API tokens, session cookies,
user identifiers, tool arguments, or model outputs.
1---2name: scrumboy-board-operator3description: Operate Scrumboy projects and boards through MCP or Agoragentic APIs. Use when an agent needs to inspect board state, plan sprint work, create todos, move cards, manage tags, or summarize project health.4---56# Scrumboy Board Operator Skill78Use this Skill to turn broad project-management requests into safe, auditable9Scrumboy MCP workflows. Prefer read-only inspection before proposing mutating10tool calls.1112## Capabilities1314- Discover Scrumboy MCP capabilities and available tools.15- Inspect projects, board state, todos, sprints, tags, and members.16- Summarize sprint health, assignment gaps, and blockers or stale items where17 they are represented by board content, tags, sprint dates, workflow columns,18 or visible metadata.19- Draft todo creation, updates, moves, tag changes, and sprint actions.20- Separate JSON-RPC (`/mcp/rpc`), legacy HTTP (`/mcp`), and Agoragentic21 (`/agora/v1/discover`, `/agora/v1/invoke`) request shapes.2223## Required Output2425Return a concise note with these sections:2627- `Scope`: the Scrumboy instance, project slug, sprint, todo, tag, or member under review.28- `Interface`: MCP JSON-RPC, legacy MCP HTTP, or Agoragentic adapter.29- `Evidence`: read-only tools or curl commands used, with tokens and sensitive IDs redacted.30- `Findings`: board state, sprint state, inferred blockers or stale work, or configuration risk.31- `Plan`: recommended next steps, separated into read-only checks and mutating actions.32- `Approval Required`: every create, update, delete, move, sprint activation, sprint close, tag update, member change, or webhook change.33- `Verification`: follow-up reads to confirm board state after an approved mutation.34- `Risks`: missing auth, anonymous mode limits, bootstrap state, stale board data, or production impact.3536When explicitly running plugin evals, also include `Plugin Eval Metadata`: eval37case id, expected pass criteria, and safe metadata events. Do not include this38section for normal board operations.3940## Workflow41421. Confirm the request scope and whether the user wants read-only analysis or a board mutation.432. Call `system_getCapabilities` or `tools/list` first when interface support is unclear.443. Use `projects_list` and `board_get` before recommending todo or sprint changes.454. For JSON-RPC, call `tools/call` with `params.name` and `params.arguments`.465. For legacy MCP HTTP, call `/mcp` with `tool` and `input`.476. For Agoragentic, call `/agora/v1/discover` or `/agora/v1/invoke` with `tool` and `arguments`.487. Ask for human approval before any mutating action.498. Verify after approved changes with `board_get`, `todos_get`, sprint reads, or tag/member reads.5051## Acceptance Checks5253- Identifies the Scrumboy interface and uses the correct request shape.54- Reads board or project state before proposing changes.55- Separates evidence from recommendations.56- Requires approval before mutating tools.57- Redacts credentials, board contents, todo descriptions, and user data from telemetry.58- Includes a verification step after approved changes.5960## Privacy and Telemetry Boundary6162Only emit metadata about plugin behavior, such as component name, outcome,63duration bucket, harness name, and sanitized error class. Do not emit prompts,64source files, todo descriptions, board contents, API tokens, session cookies,65user identifiers, tool arguments, or model outputs.