---
name: app-ops-triage
description: Use when inspecting Remix app health, recent activity, queue state, sandbox status, or operational context before deciding whether deeper debugging is needed.
---

# App Ops Triage

Use this skill when the user is asking what is happening with a Remix app right now.

This skill is for operational inspection order, not access diagnosis or collaboration mutation.

Recommended sequence:

1. Start with `remix_context_get_app_overview`.
2. Use `remix_ops_list_timeline` for recent bounded activity and event discovery.
3. Use `remix_ops_list_agent_runs` when you need to discover recent run ids for the app.
4. Use `remix_ops_get_edit_queue` to inspect pending or empty edit work.
5. Use `remix_ops_get_sandbox_status` to inspect sandbox existence, resumability, and latest migration status.
6. Only use:
   - `remix_ops_get_agent_run`
   - `remix_ops_list_agent_run_events`
   after a concrete `runId` has already been discovered from overview, timeline, `remix_ops_list_agent_runs`, or another returned object.

Important rules:

- Start broad, then drill down.
- Do not start with agent-run detail tools unless a run id is already known or has just been discovered through `remix_ops_list_agent_runs`.
- Treat empty queues, absent runs, or no recent events as meaningful states rather than tool failure.
- If overview and timeline do not surface a run id, use `remix_ops_list_agent_runs` before concluding that run-level inspection is unavailable.
- If no run id can be discovered from the available ops tools, treat that as a current MCP-surface limitation and say so plainly instead of implying the app is broken.
- Prefer explaining the operational picture first, then expanding into one subsystem only if the evidence points there.
- When cwd is available in a bound repo, use the bound app as the default target unless the user explicitly provides another id.
