Common Use Cases

Use this page when you know the job you want done, but not the Mogplex surface that should own it.

The fastest path is usually the smallest surface that can express the job. Move up to a heavier surface only when the workflow needs more structure.

Review a pull request

Start with Assignments when one repo should always use the same review behavior.

Use Triggers when one GitHub App installation should wake an agent directly on pr_opened or pr_comment.

Use Automations when review should branch into follow-up steps, such as:

• review first, then edit only when findings are real
• split review across multiple agents
• keep draft changes separate until a workflow is published

Read next: GitHub Routing Cookbook.

Triage a new issue

Use Assignments when issue triage is standing responsibility for one repo.

Use Triggers when issue_opened or issue_comment should wake one triage agent for an installation.

Use Automations when triage should classify the issue and then branch into follow-up agents, delays, or edits.

The agent should usually use the triage role, not review, because the job is to classify, respond, or decide next steps rather than inspect a code diff.

Read next: Automation Agent Roles.

Route a GitHub mention

Use Triggers for the smallest mention route:

@mogplex
@mogplex/triage

Use Automations when a mention should start a workflow graph instead of waking one agent.

Mention routing depends on exact syntax:

• @mogplex is a bare mention
• @mogplex/<agent-slug> is a targeted mention
• @mogplex triage is not a targeted mention

Read next: GitHub Routing Cookbook.

Start work from Slack

Use Slack when the request naturally starts in a team channel or DM.

Choose the Slack shape based on context:

• use DMs for conversational help
• use an unlinked channel when Mogplex should answer in Slack without a repo default
• use a linked channel when @mogplex should start repo-agent work for one repository

If the channel is linked, configure repo-agent enabled state, optional allowed Slack user IDs, and optional monthly limits before sending broad team traffic through it.

Read next: Slack.

Investigate a CI failure

Use Assignments when one repo should always use the same CI failure investigator.

Use Triggers when the CI failure event should wake one agent from the GitHub App installation.

Use Automations when the failure path should branch, such as review -> condition -> edit.

After the route starts, use Observability to find the run, model calls, tool calls, pressure signals, and errors. Use Observability Runbook when you need a full debug sequence.

Run Mogplex locally

Use the Mogplex CLI when you want a repo-local cockpit with:

• live timeline events
• approvals and permission gates
• diffs and drawers
• model selection
• MCP and memory context
• token and cost visibility

Install it from CLI Installation, then run:

mogplex

Use Slash Commands once the cockpit is open.

Run Mogplex from CI or scripts

Use Headless Runs when a script, CI job, or dashboard should start a run without opening the interactive cockpit.

Typical sequence:

1. get a repo ID from the CLI or API
2. start a run with mogplex run --repo <repo-id> ...
3. tail events with mogplex runs events <run-id> --follow
4. inspect the final status with mogplex runs get <run-id>

Use CI Integration for a GitHub Actions shape.

Create reusable agent behavior

Use Agents when the reusable behavior should be shared across repos or routing surfaces.

Create or fork an agent when you need durable:

• name and description
• category
• model choice
• system prompt
• mention slug

Use Skills, Rules, and Context when the agent needs reusable procedures, shared instructions, or background context.

Read next: Agent Authoring.

Launch or inspect sandbox-backed work

Start with Projects when the repo is the unit of work.

Use Vercel when sandbox or preview behavior depends on repository linkage, project metadata, or environment synchronization.

Use Sandboxes when you need to inspect live, pending, pinned, or stale sandbox state.

Read next: Sandbox Setup Checklist.

Debug a route that did not fire

Check in this order:

1. Settings for GitHub identity and account state
2. Installations for GitHub App coverage
3. Projects for repo import state
4. the route owner: Triggers, Assignments, or Automations
5. Observability, but only after a run actually exists

If the repo is only visible through OAuth, hosted GitHub routing will not be healthy yet. Fix App coverage first.

Use the hosted API

Use the API Reference when another system needs to list repos, start runs, inspect run events, read model metadata, or fetch runtime state.

Use API Authentication before wiring clients. Use API Errors when you need response shape and status behavior. Use API Quickstart when you want the shortest complete token-to-run path.

Quick map