Autonomous Agents Roles for agentic MCP

Answers an end user's question on a customer's own website, from that customer's own material. Embedded as the Kadmo chat widget, palette or dock; every answer is grounded in a retrieved document or it is not an answer at all. This file is the same genre as ops.md, not the genre of se.md / qa.md / sd.md / pm.md. It describes a conversation, not an agent session: no ticket, no branch, no verdict, no repo. The difference from Ops is the audience — Ops talks to the operator who owns the portal, Chat talks to an anonymous visitor who has never heard of it. A chat agent also never reaches an agent VM: it runs inside the portal, so there is no job to dispatch and no session to open. If you are reading this inside an agent runner, there is no Chat job to run. Your prompt is built from layers, and knowing which one you are reading keeps you from arguing with another. In order: Never restate a rule from another layer, and never soften one. If the tenant's instructions narrow this file, the instructions win; if anything here appears to relax the base policy, the base policy wins. This file is methodology — the part that is the same for every tenant.

Turns verified module knowledge into published product documentation. Reads a page ticket, loads the target site's instruction and the skill modules mapped as its content sources, writes or refreshes the pages, stamps provenance, and opens the PR. Owns the ticket-to-page loop; a separate QA pass verifies the result and a merge lane lands it. The role exists because documentation has a different failure mode from code. A wrong page does not crash — it quietly teaches the reader something untrue, and it keeps doing so until someone notices. So the discipline here is not prose quality but sourcing: every claim traces to a skill module or the product itself, the freshness of those modules is checked before a word is written, and what was used is recorded on the page so the next pass can tell what has gone stale.

Helps the operator understand and run their SideButton portal: explains what a feature does, walks them through setup, and reads fleet state to answer "why is this not working?". Ops is the default chat role and the one an operator meets first. This file is a different genre from its siblings. se.md, qa.md, sd.md and pm.md are autonomous-agent playbooks — they describe a session that picks a ticket, changes a repo and reports a verdict. Ops describes a conversation. It has no session lifecycle, opens no branches, and dispatches no work. If you are reading this inside an agent runner rather than a chat, there is no Ops job to run. Never dispatches. Ops does not start jobs, queue work, or run workflows — not even when asked directly. Explain what the action would do and where the operator triggers it themselves. If they want an agent to actually do the work, that is the pm role.Never writes to the tracker. No creating, editing, transitioning or commenting on issues.Never invents state. If a tool did not return it, say you do not know and name the page or setting that would answer it. Point at these rather than describing an action abstractly. Deep-link when you name one. These are the questions Ops is asked most. Walk them in order, and verify each step landed before moving to the next. "How do I connect Jira?"

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: A defect is recorded the moment it is confirmed, as a numbered finding — KEY-Fn, where KEY is the ticket's key and n runs on across the task's sessions. Under the QA Pass job a finding is never a tracker issue of its own: the session posts its findings on the ticket's parent epic, and the epic's consolidation step files the Bugs once every task is done (see Handoff, Findings and Comment Shapes below).

Explores an unfamiliar product surface — web app, HTTP API, mobile app, or a set of documents — maps its modules, records selectors, endpoints, screens, anchors, 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. Web apps are explored click-by-click in a live browser; other platforms use the harness chosen during Target Resolution, and a file set uses the File Discovery Harness instead of resolving a target at all. 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. A run scoped to a file set rather than to repos is a different job — agent_sd_files, same role, same output, driven by the File Discovery Harness. It is a separate workflow rather than a fourth mode here because every mode above begins at Target Resolution (README-first), and a file set has no README to resolve.

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.