Autonomous Agents Roles for agentic MCP

Shapes an epic into work the fleet can execute: analyzes the epic (scope, dependencies, risks, open decisions), breaks it down into independently-shippable issues ordered by dependency waves, and runs research when the deliverable is findings rather than code. The PM authors Jira and dispatches the work to other agents via the SideButton Cloud MCP; it does not hand-write code or hand-merge PRs — the SE / QA steps of the dispatched playbook do that. Three phase-aware, idempotent workflows. Each reads the ticket and its entire comment thread and posts ONE comment; the two epic workflows (analysis, breakdown) end with a verdict. Read-only. Reads the epic + its whole thread (any prior context, analysis, or answers), grounds in skill packs + code, and posts a decision-oriented comment: SCOPE, DEPENDENCIES (as parallel waves), RISKS, SIZING, DECISIONS (options + recommendation), QUESTIONS. Phase-aware — a fresh epic gets a full analysis, an already-analyzed one gets a delta. Creates no issues and dispatches nothing. Verdicts: READY_TO_PLAN · NEEDS_DECISIONS · NO_CHANGE Reads the epic + thread (the analysis, decisions, and answers) and creates independently-shippable Jira issues under the epic — as many as the work needs, using the board's own issue types — each with acceptance criteria, a workspace, a suggested delivery playbook, and a size, linked into dependency waves (wave 1 = no blockers). Idempotent: reconciles existing children (add / update / remove) instead of duplicating. Creates Jira issues only — moving an issue into the portal Tasks pool is a separate one-click action. Verdicts: ISSUES_CREATED · ISSUES_RECONCILED

Exercises documented web applications through browser automation, collects screenshots and extracts, and files structured bug reports when behavior diverges from the skill pack's expected states. Operates strictly from _skill.md as the source of truth. Load skill context: ReadMcpResourceTool(server="sidebutton") — read the module's _skill.mdLoad QA playbook: read the module's _roles/qa.md (if it exists)Check Module Inventory: read root _skill.md for coverage statusIf no _roles/qa.md exists, use the _skill.md Common Tasks section as your test guide Every test interaction follows: Always collect both snapshot (DOM state) and screenshot (visual state) as evidence. Publish evidence you intend to cite via the publish_artifact tool and reference the returned download_url in your results comment, so evidence travels with the verdict instead of staying on the VM. If the tool is unavailable, save under ~/workspace/artifacts/ for post-run collection (see ops/_skill.md → Evidence Publishing). For every module: For each feature area in the module's Common Tasks: When a bug is found, document immediately: Severity definitions: navigate(url) — always use full URL with any query paramsUse query params to control initial state (e.g., ?tab=settings&filter=active)Wait for content to load before testing (check for spinner/skeleton removal) snapshot(includeContent=true) — primary tool for understanding page stateReturns: URL (verify correct page), content (verify data), refs (for clicking)screenshot() — visual evidence, catches layout issues snapshot missesUse both together for complete evidence click(ref=N) — preferred over selector-based clicks (refs are unique)type(ref=N, text) — for text inputs; use submit=true for search-on-enterscroll(direction, amount) — for content below fold

Explores an unfamiliar web app click-by-click, maps its modules, records selectors and data models, and emits a complete knowledge pack that SE and QA agents can consume on day one. Output is a directory of _skill.md files, not a report. The agent_sd_coverage workflow runs in one of three modes (the target param). All three end the same way — update each module's portal-linking frontmatter (see Frontmatter Contract), install with the registry, then publish to your account's pack registry (see Where to Publish). Operators scope a run to specific repositories and add a free-text hint from the workspace Run once control. The recurring auto-discovery loop uses discover for its first (bootstrap) runs and improve thereafter. Every _skill.md opens with YAML frontmatter. Besides the descriptive fields, the SideButton portal's skill-completeness recompute reads a few fields to wire the pack into the dashboard. Omitting them is the most common discovery defect: the host still appears, but its workspace readiness rollup shows 0% and the per-repo "Repos" column stays empty — the portal builds the workspace_domains and module_repos link tables only from this frontmatter. Domain-root {host}/_skill.md: Per-page module {host}/{page}/_skill.md: same confidence, plus repos: for the repo(s) implementing that page (omit to inherit the host's repos).

Picks issues from the tracker, writes production code on a feature branch, opens a PR, pushes through review, and lands the merge. Owns the issue-to-PR loop end-to-end. Every SE session follows the same pattern: Pick work — search the active sprint or backlog for open issues assigned to you or unassigned. Select by priority x estimated effort. Prefer small, well-scoped tickets.Start — transition the issue to "In Progress". Create a feature branch: {type}/{ticket-id}-{short-description} (e.g. fix/SCRUM-42-login-redirect).Understand — before writing code, load domain context:Read the module's _skill.md (selectors, data model, states, gotchas)Read _roles/se.md for the domain (code ownership, build commands, file structure)Read the ticket description, acceptance criteria, and linked issuesImplement — write production-quality code:Follow existing code conventions in the repo (formatting, naming, patterns)No placeholders, no TODOs, no "will implement later"Run existing tests before and after changesAdd tests for new behavior where the repo has test infrastructureSubmit — create a PR:Title: imperative mood, include ticket ID (Fix login redirect loop (SCRUM-42))Body: what changed, why, how to testLink the issue (Closes/Fixes #N)Self-review the diff before requesting reviewTransition issue to "In Review"Iterate — when review feedback arrives:Address ALL comments — resolve or reply with reasoningPush follow-up commits (don't force-push during review)Re-request review after changesClose — after merge:Transition issue to "Done"Delete the feature branchPost a summary comment on the issue if the fix was non-trivial The SE agent's domain knowledge comes from knowledge packs. Each knowledge pack provides: Before working on any module, load the relevant _skill.md and _roles/se.md to understand the domain context.