Resolve AI

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: alerts
description: List and filter alerts in Resolve. Use when the user asks "show me alerts", "any new alerts", "alerts on <team>", "find the alert matching <pattern>", "alerts that auto-investigated", "alerts where <label> is critical/missing", or wants a focused alerts view (separate from a full overview snapshot).
version: 0.1.0
argument-hint: <optional filter description>
license: Apache-2.0
---

# List Resolve Alerts

Use for focused alert listings and alert drill-downs.

## Arguments

If `$ARGUMENTS` is non-empty, translate it into `list_alerts` filters.

If `$ARGUMENTS` is empty, call `list_alerts` with the tool defaults. Only ask the user to narrow if the result set is overwhelming.

## Filter Intent

Map common phrasings to the right filter family:

- **Time** — "today", "last week", "since deploy", explicit date ranges.
- **Ownership** — team, alert rule, alert ID, or entity.
- **Investigation state** — auto-investigated alerts, alerts with or without linked investigations.
- **Labels** — severity, service, environment, team, missing labels, or substring matches.

Examples:

- "critical alerts in the last hour" → time filter + severity label.
- "alerts where `service` is missing" → missing-label filter.
- "alerts containing 'timeout'" → substring label filter on the best matching message/description label.
- "alerts for High CPU rule" → rule key if known, otherwise filter by rule/title labels.

For unsupported inverse filters, fetch a reasonable recent set and post-filter locally.

## Output

Summarize compactly:

- Count + the time range covered.
- Severity / action breakdown when it's informative.
- Per-alert one-liner: `time`, `title`, `severity`, `action`, `is_auto_investigated`, `entity_key`.
- Surface investigation links only when the result includes an `investigation_id`; never fabricate one.
- Preserve any `[label](path)` citations verbatim.

If the list is long, group by `alert_rule_key` or a salient label and offer to narrow further.

## Handoffs

- "Show me everything happening in Resolve" — broader than just alerts → `resolve-ai:overview`.
- "Open the investigation for this alert" — use the alert's `investigation_id` directly → `resolve-ai:investigate <investigation_id>`.
- "Tell Resolve about this alert" — promote a finding into that investigation → `resolve-ai:steer`.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: apply-fix
description: Turn a Resolve investigation's root-cause findings into code changes in your local repo. Use when the user wants to translate findings into code changes — phrases like "fix this based on Resolve", "implement Resolve's mitigation", "apply the fix from this investigation", "remediate the root cause Resolve found", or wants to write code to address a theory Resolve identified.
version: 0.1.0
license: Apache-2.0
---

# Apply Fix from Resolve Findings

Bridges Resolve's production-side diagnosis to local code edits.

## Workflow

1. **Pick the target finding.** Usually a root-cause theory from `get_investigation`. If multiple, ask the user which to address.
2. **Read the theory and its citations** via `read_file` on the theory's path and its citation paths. Citations are log lines, queries, traces — the supporting evidence.
3. **Gather what's missing for a code change.** Theories describe what's broken in production, not what to write locally. You fill that in by reading local code: which file owns the relevant path, what the current implementation does, where the change goes.
4. **Optionally**, send a code-shaped question back to Resolve via `ask` for context you can't infer locally. Don't block on it — work in parallel.
5. **Locate the relevant local code** with Grep/Read.
6. **Propose the fix:** the theory addressed, the citations supporting it, the files being changed, why the change should work. Then implement.
7. **Open a PR.** If a PR-creation skill is available, load and use it to open the pull request; otherwise follow the repo's normal PR flow. Land the work as a reviewable PR, not a dirty working tree.
8. **Optionally** call `steer_investigation` with "Applied mitigation: <summary>" so the investigation records the fix.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: ask
description: Send Resolve a question or a request to investigate — continuing an existing chat or investigation, or starting a fresh one. Use when the user wants to send a message to Resolve — phrases like "ask Resolve about X", "follow up with Resolve", "what does Resolve think about Y", "have Resolve check Z", or wants Resolve to clarify a finding.
version: 0.1.0
argument-hint: <message>
license: Apache-2.0
---

# Ask Resolve

Use when the user wants Resolve to answer a question or do more investigation work.

## Arguments

If `$ARGUMENTS` is non-empty, use it as the user's base message and proceed (enrich with conversation context as below, then call `ask`).

If `$ARGUMENTS` is empty (skill invoked without a clear question), ask the user once what they want to ask Resolve. Treat their next reply as the base message.

## Composing the message

Before calling `ask`, enrich the user's base message with context from the current conversation **that directly supports the specific question being asked**.

**Be ruthlessly selective.** Do not dump every file you've read, every command you've run, or the conversation transcript. Include only what makes the question more answerable. If a piece of context isn't load-bearing for this specific message, leave it out.

Candidates to consider (include only those tied to the question):

- File paths the user opened or edited **in the path of investigating this exact issue**
- Error messages, log lines, or stack traces that name the symptom the user is asking about
- Git context (branch, recent commits, working changes) **when the question is about a change being made**
- URLs the user referenced that frame this question (Slack threads, dashboards, related canvases)
- A one-line framing of what the user is working on — only if the question doesn't stand on its own

Format the enriched message as the user's question first, then a brief `## Local context` block with only the relevant items. Most asks need 1–3 lines of context, not a dump.

## Picking scope

Default to whatever investigation/chat is currently in context:

- The user just engaged an investigation via `investigate` → scope the ask to it.
- A chat is already in flight under that investigation → continue it.
- The user switches to a different investigation mid-conversation → start fresh there.
- No active context → standalone Resolve chat.

## After asking

Call `ask` with the selected scope and enriched message, then surface the returned URL.

If the response includes a `stream_command`, follow it using Codex's long-running command mechanism:

- Run the command with `functions.exec_command`.
- Request network escalation if sandbox networking blocks the stream.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: chats
description: List recent Resolve chats. Use when the user asks "show me my chats", "what chats are in flight", "any chats running", "chats from last week", or wants a focused chat list (separate from a full overview snapshot).
version: 0.1.0
argument-hint: <optional time range, e.g. "last 7 days">
license: Apache-2.0
---

# List Resolve Chats

Wraps `list_chats`.

## Arguments

If `$ARGUMENTS` is non-empty, parse it into filter intent. Empty → call with defaults.

`list_chats` has no server-side `status` filter. When the user asks for "running" / "in flight" / "errored", fetch and post-filter on `status`.

## Output

- Count + time range covered.
- Status breakdown when informative; surface `running` first — the agent is still working.
- Per-chat one-liner: `name`, `status`, `updated_at`, canvas URL (`<your-resolve-host>/chat/<chat_id>`).
- Preserve `[label](path)` citations verbatim.

## Handoffs

- Read what Resolve said on a chat → `get_chat` with the `chat_id`.
- Send a new message in a chat → `resolve-ai:ask` with the `chat_id`.
- Investigations view → `resolve-ai:investigations`.
- Alerts view → `resolve-ai:alerts`.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: create-skill
description: Write or tune a skill for the Resolve plugin — encoding workflow guidance, not tool API details.
version: 0.1.0
license: Apache-2.0
---

# Write or Tune a Plugin Skill

**New skill** — draft a `SKILL.md` for the workflow the user describes.

**Tuning an existing skill** — read the skill the user points at, apply the boundary rules below, and trim anything that belongs in a tool description instead.

## Before writing

1. **Read the relevant Resolve MCP tool descriptions** — know exactly what each tool already documents so you don't repeat it in the skill.
2. **Read all the existing skills from this plugin** — know what's already covered so you hand off rather than duplicate.

## What does NOT go in a skill

**Don't repeat tool descriptions** for any tools the skill uses — Resolve MCP, Grafana, Slack, or anything else. Anything the tool description already says stays there:

- Parameter names, enums, defaults, or limits.
- Stream semantics or protocol details.

**Don't repeat other skills.** If the workflow needs to query Resolve or continue a conversation, hand off to `resolve-ai:ask` rather than re-describing how it works. Skills compose; they don't duplicate.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: demo
description: Run a guided, self-paced tour of Resolve using the connected org's live data — surface the environment, resume a chat, fire several in parallel, drill a real RCA with its evidence and a live thread, then investigate something from scratch. Use when someone wants to demo Resolve, give a tour, or show a new user what it can do — phrases like "demo Resolve", "give me a tour", "walk them through Resolve", "show me what Resolve can do", "demo this to <person>".
version: 0.1.0
argument-hint: [optional emphasis, or "start"]
license: Apache-2.0
---

# Demo Resolve

A guided, checkpointed walkthrough of Resolve using **your connected org's live data**. You drive each step at your own pace. The arc escalates:

**surface → resume a chat → many in parallel → drill a real RCA (evidence + live thread) → turn the findings into a code-fix PR → investigate from scratch.**

Every beat stands alone — stop anywhere and it's still a complete demo.

This skill orchestrates with direct tool calls and its own narration. For the streaming beats it follows the `stream_command` streaming already documented in the `ask` and `investigate` skills rather than restating the host-specific mechanics here.

## Arguments

If `$ARGUMENTS` carries an emphasis (e.g. "focus on logs", "keep it short"), bias curation and beat selection toward it. Otherwise run the default arc. Treat a bare `start` as "begin the tour".

## Two run modes

Establish the mode at the start and honor it for **every** command, every beat:

- **Auto** (default — today's behavior): _you_ run each command via the tools, pausing at checkpoints for the user's "go" or to let them pick an option.
- **Manual** (hand-me-the-commands): you do **not** execute the beat's action. Compose the **full command with its args/message filled in** and present it for the user to type themselves, then **stop and wait** for them to run it before moving on. You may still run read-only setup (e.g. `overview`) so the commands you hand over carry real IDs/values, but every action command (`ask`, `investigate`, `steer`, `apply-fix`) is theirs to enter. Because they're invoking the real skills, those skills' own run/format behavior (streaming, citations, canvas URLs) applies as-is.

Select via `$ARGUMENTS` (`auto` / `manual`); if unset, ask once at pre-flight.

## Two registers in your output

- **Tour narration** (plain prose): the lines you walk the user through — clean, jargon-light, short.
- **Control cue** (prefix `▶`): meta prompts to the user, not part of the narration. End every beat with a cue that previews exactly what the next step will do, e.g. `▶ Next: open a real RCA and pull the raw telemetry behind its top theory. Say "go", pick from the menu, or tell me what to show.`
- **Command tag** (prefix `▷`): name the command for each beat's capability. In **auto** mode it's just the label, so the user learns it — `▷ Run it yourself: $resolve-ai:overview`. In **manual** mode it's the _full runnable command with composed args_, and you stop and wait for the user to enter it — e.g. `▷ Type this: $resolve-ai:ask Follow-up: of the error spikes in svc-analysis, which one is most worth acting on first?`. Mapping (args from each skill's own `argument-hint`): surface → `$resolve-ai:overview` (focused lists `$resolve-ai:alerts`, `$resolve-ai:investigations`, `$resolve-ai:chats`); resume / ask / thread / parallel → `$resolve-ai:ask <message>`; redirect a live investigation → `$resolve-ai:steer <message>`; drill or start an RCA → `$resolve-ai:investigate <url-or-id | problem>`; apply a fix → `$resolve-ai:apply-fix`.

## Pacing — light checkpoints

Pause only at: the start, the post-overview menu, and before any step that **sends a message or starts an investigation**. Auto-flow narration within a beat. In **auto** mode, never send a chat or start an investigation without an explicit "go" in that same turn; the read-only beats (overview, RCA drill, evidence) need no consent. In **manual** mode you never execute an action yourself — you present the full command and wait for the user to run it, which is the natural checkpoint.

## Beats

### 0 · Pre-flight (you only)

On launch, don't start the tour yet. Settle the **run mode** (auto vs manual — ask if `$ARGUMENTS` didn't set it) and lay out the agenda for yourself, then `▶ Mode: <auto|manual>. Say "start" when you're ready.` Wait.

### 1 · Orient — what Resolve is

One breath on Resolve: it's an AI SRE for your production incidents. Start with the big picture, then the two primitives everything centers on.

**The big picture** — `$resolve-ai:overview` shows investigations, recent alerts, and in-flight chats at a glance. (`$resolve-ai:alerts` for just the firing feed that auto-triggers investigations; `$resolve-ai:help-resolve` to get oriented.)

**Investigations** — structured root-cause workspaces (theories, cited evidence, mitigations, tied to the triggering alert):

- `$resolve-ai:investigate` — open an existing RCA or start a new one
- `$resolve-ai:investigations` — list recent investigations
- `$resolve-ai:ask` — ask a question or open a thread on an investigation
- `$resolve-ai:steer` — redirect a running investigation with a new finding
- `$resolve-ai:apply-fix` — turn its findings into a code change, right here

**Chats** — standalone conversations with Resolve — ask anything about your environment:

- `$resolve-ai:ask` — start or continue a standalone chat
- `$resolve-ai:chats` — list recent chats

### 2 · Surface — the environment

Call `list_investigations`, `list_alerts` (with `limit: 20`), `list_chats` in parallel, org-wide. Present a tight snapshot: counts plus a couple of headline items.

**Curate with taste — this is a demo, not a dump.** Privately pick three things to use later:

- **best RCA to drill** (beat 5): a **non-`triage_only`** investigation that _has theories_ — prefer `ALERT`/`INCIDENT`; skip smoke-tests.
- **best existing chat to resume** (beat 3): a real question-style chat from `list_chats`, status `complete`.
- **best alert to investigate cold** (beat 7): a genuine recent firing alert.

`▶ Menu — where first? (a) resume a chat, (b) ask several at once, (c) drill a real RCA + its evidence, (d) investigate something from scratch. Or say "tour" to go in order.`

### 3 · Resume a chat

Take the existing chat picked in beat 2 and **send a follow-up to it** — `ask` with that `chat_id` (include `investigation_id` if it's investigation-scoped). The point: chats persist, you resume a real prior conversation instead of starting cold. Stream the reply per the `ask` skill — run its returned `stream_command`, which scopes to the new turn.
`▶ Send the follow-up to "<chat name>"? Say "go".` ← consent before sending

### 4 · Many in parallel

Fire **two or three** questions concurrently, each streaming its own `stream_command` in the background, side by side. The point: Resolve isn't one-at-a-time. (The `ask` skill blesses parallel streams.)

Use **concrete, service-scoped** asks, not vague aggregates — vague ones make the agent guess time ranges and stall. Good shapes (substitute a real service from beat 2):

- recent error spikes in `<service>` logs — grouped by pattern, calling out new or surging ones
- health metrics for `<service>` for an operational review — error rate, latency p50/p90/p99, saturation
- pod health in `<service>` metrics — restarts, OOM kills, pods not Ready

Keep **one ask deliberately simple** — even a plain `hi` or a one-liner — so its quick reply lands while the heavier scoped ones are still streaming; the contrast makes the parallelism obvious.
`▶ Fire <N> in parallel? Say "go".`

### 5 · Drill a real RCA — evidence + a live thread

On the RCA picked in beat 2:

1. **Read it** (no consent — read-only): `get_investigation` → narrate status/phase, the top theory and its confidence.
2. **Get the evidence:** `read_file` a citation path from that theory to surface the raw telemetry behind the claim — the actual query or log lines the agent used. This is the trust moment: every conclusion traces to real data.
3. **Open a thread on it** (consent — sends a message): an investigation-scoped `ask` (pass `investigation_id`, no `chat_id`) that asks a sharp follow-up about the finding, then stream the answer per the `ask` skill — run its returned `stream_command`. Shows you can _converse with a specific RCA_, not just read it.
   `▶ Open a thread on this RCA with "<question>"? Say "go".`

### 6 · Apply the fix in code — close the loop with a PR (opt-in)

Take the root cause and the thread answer from beat 5 and turn them into a local change — Resolve diagnosed it in production; now write the fix in the editor. Run the `apply-fix` flow: read the theory and its citations, locate the owning code with Grep/Read, **propose** the change (theory addressed, files touched, why it works), implement on a "go", then **open a PR** — loading a PR-creation skill if one's available — so the loop ends at a reviewable pull request, not just a dirty tree. If the root cause is infra/config that doesn't live in this repo, say so and show the change you _would_ make rather than forcing an edit.
`▷ Run it yourself: $resolve-ai:apply-fix`
`▶ This edits local code and opens a PR. Apply the fix? Say "go" — or skip.`

### 7 · Investigate from scratch (the climax) — opt-in

Seed a brand-new investigation from the **real recent alert** picked in beat 2: compose a short markdown prompt from its title/labels, show it to the user ("this fired ~<N> min ago — watch Resolve take it cold"), and only on explicit yes call `start_investigation`. Then stream it live per the `investigate` skill — run its returned `stream_command` — theory cards and the evidence trail forming in real time.
`▶ This starts a real investigation (uses org credits). Start it? Say "go".`

### 8 · Recap + toolbox

One line recapping the loop, then hand over the controls — the skills they can run themselves: `$resolve-ai:overview`, `$resolve-ai:ask`, `$resolve-ai:investigate`, `$resolve-ai:alerts` / `$resolve-ai:investigations` / `$resolve-ai:chats`, `$resolve-ai:steer`, `$resolve-ai:apply-fix`.

## Notes

- **IDs are ephemeral** — always select from a fresh `overview`, never hardcode an investigation/chat/alert ID.
- Preserve `[label](path)` citations verbatim; always surface canvas URLs.
- Keep each beat to a couple of lines. The live data is the star — let it carry the demo.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: feedback
description: Send Resolve your feedback — on an investigation's root cause, a chat answer, or the Resolve experience itself. Use when you've resolved or mitigated your issue, an investigation or chat wraps up, or you want to rate or comment on Resolve.
version: 0.1.0
argument-hint: <optional feedback text>
license: Apache-2.0
---

# Submit Feedback to Resolve

Wraps `submit_feedback`. Engage when work wraps up — the user fixed or mitigated the issue, or an investigation or chat concluded — or whenever they explicitly want to rate or comment on Resolve. Offer once; if they pass, drop it.

Route to what they're judging: an **investigation**'s root cause, a **chat** answer, or the **product** / MCP experience itself. If their intent spans more than one, send a separate call per target. Use only IDs returned by Resolve tools.

Two parts, handled differently:

- **Verdict** (good/bad) — the user's own judgment. Never guess or pre-fill it.
- **Note** — draft it from what you observed this session so they don't retype it; never invent diagnostics. If `$ARGUMENTS` is non-empty, use it as the note.

So: with session context, draft the note and ask only for the verdict in one turn. With none, ask briefly what they want to say and what it's about. Then submit, and tell the user in one line what you sent and where.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: help-resolve
description: Introduce Resolve (the AI DevOps investigation platform) and route the user to the right next step — investigate, ask, apply a fix, or get an overview. Use when the user mentions "Resolve", "resolve.ai", asks "what is Resolve" or "how do I use Resolve", pastes a Resolve URL, or describes a production incident or active investigation they want Resolve to help with.
version: 0.1.0
license: Apache-2.0
---

# Resolve

Resolve (resolve.ai) is an AI DevOps investigation platform. It runs structured RCAs on production incidents, surfaces alert correlations, builds theory cards with citations, and lets you chat with the investigation as it works.

When the user mentions production incidents, alerts, active investigations, or asks about Resolve, this skill engages. From here:

- User pasted a Resolve URL or named an investigation → `resolve-ai:investigate` to load and summarize it.
- User described a problem with no existing URL → `resolve-ai:investigate` to compose a prompt and (with confirmation) kick off a new investigation.
- User wants to translate findings to local code changes → `resolve-ai:apply-fix`.

## Response Style

Preserve `[label](path)` markdown citations verbatim — they're paths the user can drill into via `read_file`. Always surface canvas URLs. Keep replies concise; let the user drive depth.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: investigate
description: Have Resolve run a root-cause investigation — open an existing canvas, or start a new one. Use when the user pastes a Resolve URL, names an investigation ID, references an alert, or describes a problem — phrases like "investigate X", "look into Y", "have Resolve check Z", "start an investigation", "rca this", or "root cause this".
version: 0.1.0
argument-hint: <resolve-url | investigation-id | problem-description>
license: Apache-2.0
---

# Investigate with Resolve

Opens an existing investigation, or starts a new one after first discovering whether Resolve is already working on the same thing. **Starting a new investigation kicks off a real run — always confirm explicitly with the user before doing so.**

## Arguments

If `$ARGUMENTS` is non-empty, treat it as the input and route immediately (see below).

If `$ARGUMENTS` is empty, ask the user what they want to investigate (a URL, an ID, or a problem description). Treat their next reply as the input.

## Routing

**Path A — Input is a Resolve URL or canvas ID** (URLs follow `<your-resolve-host>/chat/<id>`; the ID is the last path segment, or the user may give you just the ID directly).

1. Extract the canvas ID.
2. Call `get_investigation`.
3. Summarize state for the user: status, phase, top theories, alerts. Include the canvas URL.
4. Drill into specific theories, the report, or evidence via `read_file` when the user asks.

No confirmation needed — this path is read-only.

**Path B — Input is a free-form problem description** (e.g. "frontend is slow", "DB queries timing out", an alert name).

Before starting fresh, **always check whether Resolve is already working on this**.

1. **Discover existing candidates first.** If recent `list_alerts` / `list_investigations` output is already in the conversation (e.g. from a prior `overview`, `alerts`, or `investigations` call), reuse it — do not re-fetch. Otherwise call those tools for recent activity. Either way, match the returned items against the user's input locally (by title, alert rule, labels, and recency) to find anything Resolve is already working on. Read-only — costs nothing and prevents duplicating in-flight work.
2. **If candidates exist**, surface the top matches with their canvas URLs and ask the user: "Open one of these, or start a new investigation?" Wait for an explicit answer. If they pick one, switch to Path A on that ID. Otherwise fall through.
3. **Compose the investigation prompt.** Resolve is starting from a blank slate — include grounded context generously. Better to over-include than under-include:
   - File paths, services, components, or subsystems the user pointed at
   - Error messages, log lines, stack traces, exception types (paste them verbatim)
   - Symptoms: what's broken, who's affected, when it started, what changed recently
   - Git context (branch, recent commits, working changes) when the issue may be tied to a local change
   - URLs the user referenced (Slack threads, dashboards, alert pages, related canvases)
   - Suspected causes, hypotheses, or ruled-out paths the user has already explored
   - Reproduction steps, environment details, or scope (single user vs widespread)

   Format as markdown with clear sections (e.g. `## Symptom`, `## What I've checked`, `## Suspected area`) — the prompt seeds the investigation, so structure helps Resolve route to the right agents.

4. **Confirmation gate (required).** Show the user the composed prompt and ask explicitly: "Start a new investigation with this?" Wait for an unambiguous yes. Do not proceed on tacit agreement, silence, or "go ahead" inferred from earlier turns.
5. Only on explicit yes, call `start_investigation`.
6. Surface the returned canvas URL.

After either path you're engaged with that investigation. Subsequent follow-ups use `ask`.

## Following the investigation live

After starting a new investigation, default to following it: run the returned `stream_command` with the host's long-running command mechanism and relay notable progress as it arrives. For an existing in-flight investigation, follow only if the user asks.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: investigations
description: List recent Resolve investigations. Use when the user asks "show me investigations", "list my team's investigations", "investigations from last week", "what auto-investigations ran today", "any manual investigations this month", or wants a focused investigations view (separate from a full overview snapshot).
version: 0.1.0
argument-hint: <optional filter description>
license: Apache-2.0
---

# List Resolve Investigations

Wraps `list_investigations`.

## Arguments

If `$ARGUMENTS` is non-empty, translate it into `list_investigations` filters.

If `$ARGUMENTS` is empty, call `list_investigations` with the tool defaults. Only ask the user to narrow if the result set is overwhelming.

## Filter Intent

Map common phrasings to the right filter family:

- **Time** — "today", "last week", explicit date ranges, or "since deploy".
- **Ownership** — team, service, or alert context.
- **Run origin** — auto-investigations vs human-started investigations.
- **Source** — alert-driven, chat-started, incident, or triage-only.
- **Volume** — use a limit when the user asks for "top", "latest N", or a short list.

## Output

Summarize compactly:

- Count + the time range covered.
- Per-investigation one-liner: `title`, `phase`, `stop_reason` (if terminal), `run_type`, `use_case`, `team`, primary alert summary if present, `created_at`, and the canvas URL (`<your-resolve-host>/chat/<investigation_id>`).
- When the list is long, group by `phase`, `team`, or `run_type` and offer to narrow.
- Always surface canvas URLs — they're the user's drill-in path.
- Preserve any `[label](path)` citations verbatim.

After listing, offer the next step: `resolve-ai:investigate <id>` to load one, or `resolve-ai:ask` if the user wants to follow up on a specific investigation.

## Handoffs

- "Show me everything happening in Resolve" — broader snapshot → `resolve-ai:overview`.
- "Open this one" — drill in → `resolve-ai:investigate <id>`.
- "Show me firing alerts" — alerts-focused view → `resolve-ai:alerts`.
- "What chats are in flight?" — `resolve-ai:chats`, or `resolve-ai:overview` for the unified view.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: overview
description: Get the big-picture view across all of Resolve — open investigations, recent alerts, in-flight chats. Not for the status of a single investigation or chat.
version: 0.1.0
license: Apache-2.0
---

# Resolve Overview

## Tools

- `list_investigations`
- `list_alerts`
- `list_chats`

Fire in parallel. Don't infer scope from prior turns — overview means org-wide unless the user is explicit about narrowing.

## Output

Three sections — Investigations, Alerts, Chats — each with a count and one tight line per item carrying the fields that matter (title/name · status/phase · severity · URL).

## Handoffs

- Specific investigation → `resolve-ai:investigate <id>`.
- Specific chat → `get_chat` with the `chat_id`.
- Just alerts → `resolve-ai:alerts`. Just investigations → `resolve-ai:investigations`. Just chats → `resolve-ai:chats`.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: prod-context
description: Get production context from Resolve for the area you're about to change — so the work is grounded in what production looks like and aware of how the change could affect it, before you start rather than after the PR is up. Use before implementing a fix or feature, when finalizing a plan or approach, or before editing anything that affects a production system — application code, infrastructure, or config-as-code (Helm, Terraform, Dockerfiles, CI/CD, SQL/migrations, protos) — or when the user says "let's build/fix/implement X". Surfaces the area's normal operational profile (traffic and usage, telemetry coverage, baseline latency/error rate), the regression risk of the change, plus any active alerts, open investigations, recent incidents or deploys, and known fragility.
version: 0.1.0
argument-hint: [optional focus, e.g. a service or concern]
license: Apache-2.0
---

# Pre-implementation production context

Before implementing a change to a production-facing path, get the runtime picture the code can't
show — real traffic, telemetry coverage, baselines, live trouble — and let it shape the approach.
Resolve owns the telemetry and the service map; query it only for what you can't read off the repo.

## When to trigger

Trigger at the **plan → implement boundary**: the task is understood, the in-scope files or areas
are known, and no code is written yet — so production reality can still shape the approach, not
just validate it afterwards.

Skip trivial changes (typo, comment, formatting, docs-only) and anything no production system
would monitor.

## Decide whether to ask

Ask Resolve only when a **production runtime unknown** would change how you build this. If the open
questions are answerable by reading the repo, or the area is quiet with no runtime unknowns, skip
the ask — say so in one line and continue with the work.

## Compose the ask

Pick the few angles that fit this change — don't ask all of them, and don't ask generically. Each
is something the code can't tell you.

Know the area:

- **Operational profile** — real traffic and request volume, peak vs quiet, how heavily it's
  exercised. A hot path demands far more care than a rarely-hit endpoint.
- **Telemetry coverage** — what observability exists here (logs, metrics, traces) and where the
  blind spots are: will you be able to see your change's effect?
- **Baseline behavior** — the normal latency / error rate / throughput, so you know what "good"
  looks like.

Check for trouble:

- **Is the ground shaking?** — active alerts, ongoing incidents, or open investigations on the
  area. Don't build on top of an active fire — or realize your change _is_ about it.
- **Regression history** — recent deploys and prior incidents on these paths; where it's bitten
  before, build defensively.
- **Runtime downstream fanout** — what actually gets hit downstream at volume, from traces and the
  service map. Scopes rollout and testing.
- **What to verify after** — given the change, the production signals to watch post-deploy.

Make it exact. Gather a tight bundle — be ruthlessly selective, no transcript dumps:

- **Task** — one line on what's being implemented.
- **In-scope files/areas** — the paths you've read or named. Paths are enough; don't map them to
  services yourself, Resolve does that.
- **Approach** — the intended plan, if there is one.
- **Symptoms/errors/tickets** — verbatim where they frame the change.
- **Git framing** — run `git rev-parse --abbrev-ref HEAD` and `git log --oneline -3`, and include
  the branch and recent subjects.

Put the concrete question(s) first, then a short `## What I'm about to change` block, and send via
`resolve-ai:ask`. For example:

- New feature/endpoint → _operational profile_ + _telemetry coverage_: "About to add `<X>` to
  `<service>`. How much traffic/usage does this area see, is it a hot path, and what telemetry
  already covers it — will I be able to observe this change?"
- Change to a high-fanout component → _runtime fanout_ + _regression history_: "About to change
  `<component>` in `<files>`. What actually depends on this in production, has changing it caused
  incidents before, and what should I watch after deploy?"
- Bugfix in a sensitive area → _ground shaking_ + _baseline_: "About to fix `<bug>` in `<files>`.
  Any open investigations or active alerts on `<area>`, and what's the normal error rate/latency so
  I can tell if the fix actually helps?"

## After asking

Don't block. Fire the ask and immediately continue planning and implementing — never gate code
changes, the PR, or any other work on the reply. Pause only if the user explicitly asks to wait.

When the reply lands:

- Summarize what Resolve returned in 2–4 bullets.
- Adjust the approach and call out the change explicitly — e.g. it's a high-traffic hot path so
  gate it behind a flag and test harder; lots depends on it downstream so stage the rollout;
  telemetry is thin so add instrumentation with the change; an open investigation overlaps the
  area; a recent deploy is already shaky.
- Fire at most one sharpening follow-up if something is directly relevant.

If Resolve comes back unremarkable — low-traffic, healthy, nothing in flight — say so in one line
and carry on.

View saved version →

---
# Copyright 2026 Resolve AI, Inc.
# SPDX-License-Identifier: Apache-2.0
name: steer
description: Steer a Resolve investigation by sending it a new finding, hypothesis, or directive to redirect it. Use when the user wants to promote a local observation back to Resolve — phrases like "tell Resolve I found X", "steer this investigation", "send Resolve this observation", or "promote this back to Resolve".
version: 0.1.0
argument-hint: <message>
license: Apache-2.0
---

# Steer Investigation

Send a directive to an active investigation. This is the canonical channel for promoting local observations into Resolve's investigation flow.

## Arguments

If `$ARGUMENTS` is non-empty, use it as the base of the steer message. Enrich with conversation context as below before calling `steer_investigation`.

If `$ARGUMENTS` is empty, ask the user once what they want to steer Resolve with. Treat their next reply as the base.

## Enriching with conversation context

Before calling the tool, expand the base message with conversation signals **that directly support the finding being promoted**. Be ruthlessly selective:

- Specific file paths or code snippets that demonstrate the finding
- Error messages or log lines from this conversation that back up the observation
- Git context (branch, commit) if the finding is tied to a local change
- URLs the user referenced that informed the finding

If a piece of context doesn't strengthen the steer, leave it out.

## Composing the message

A good steer message is:

- **Specific.** "Latency spike correlates with the 14:52 deploy of the affected service" beats "I think it's the deploy."
- **Anchored.** Reference times, services, files, or theory IDs from `get_investigation` when relevant.
- **Actionable.** Either an observation Resolve should integrate, or a directive for the agent teams ("focus on the connection pool theory").
- **Markdown.** Bullets, file paths, code references — anything the human side of an investigation would benefit from.

## After steering

Effects surface via:

- The activity timeline — re-read via `read_file` on the timeline path from `get_investigation`.
- Updated theories on next `get_investigation`.
- **Live, if the user wants to watch the effect land:** follow any returned stream with the host's long-running command mechanism.