Autonomous Agents Roles for agentic MCP

Runs the sprint loop: triages incoming tickets, dispatches work to SE and QA agents, watches progress daily, unblocks stalled issues, and closes out the sprint with a burndown report leadership actually reads. The PM agent uses 2 phase-detecting, idempotent workflows: Detects the current sprint phase and acts accordingly: PLAN (no active sprint or sprint empty) — groom backlog (stale, dupes, incomplete), velocity analysis from last 2-3 sprints, scope next sprint up to capacity, group by execution orderMANAGE (active sprint with work) — assess state (tickets by status, stalled >24h, PR CI, agent fleet, silent failures, dependency violations, unclassified new), dispatch stalled, merge ready, triage newCLOSE (all Done or sprint end) — carry over incomplete, release notes from merged PRs, velocity trend + forecast, close sprint Detects the ticket's phase and acts accordingly: PLAN (no subtasks) — load product knowledge from skill packs, gap analysis, decompose into subtasks with acceptance criteria, assign execution groupsREFINE (subtasks exist, gaps remain) — check completeness, dependencies, execution order, fix gapsMANAGE (subtasks ready) — dispatch SE/QA per lifecycle state, track PRs, merge after QA PASS, handle failuresVALIDATE & CLOSE (all Done) — verify on live site, transition parent to Done The PM agent uses these tool categories: SideButton Cloud MCP (primary) — mcp__sidebutton-cloud__dispatch_agent_job for fast, reliable, parallel dispatchPortal chat (backup) — fallback when Cloud MCP unavailable

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. 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 After mutations: wait 1-2s before verifying (API calls may be async)After navigation: wait for page-ready indicator (heading, table, or key element)Snapshot vs screenshot timing: snapshot reflects DOM (may miss animations); screenshot reflects visual (may show mid-transition). Use both.Connection issues: if tools start failing, check get_browser_status(). User may need to refresh browser tab.Cache/stale data: some apps cache aggressively. Navigate away and back to force refetch.

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. Source code is optional. Without it, SE role files are lightweight stubs with TODO markers. With it, you can grep for components, controllers, and hooks to build full responsibility maps. Every SD session follows the same pattern: Read inventory — open skill pack root _skill.md, read the Module Inventory tablePick work — find the lowest-coverage high-priority module (or run Session 0 if no inventory exists)Document — fill the next sections of that module's _skill.mdGenerate roles — if _skill.md reached 75%, generate _roles/qa.md and _roles/se.md (start at 45%)Update inventory — update coverage % in root _skill.md Module Inventory tablePublish — validate pack, commit, push, and create PR if git repo Run this when the skill pack doesn't exist yet or has no Module Inventory. Navigate to target app URLHandle authentication if needed:Look for login form, OAuth redirect, SSODocument auth flow for future sessionsIf credentials needed, ask operatorsnapshot(includeContent=true) — capture full navigation treescreenshot — visual baseline of authenticated state For each navigation link (sidebar, topbar, menu):

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.