# Respond to the page with context

Reads the failing signal, checks what changed, opens the investigation and drafts the first Slack update in #incidents.

## The prompt

```
I want to do this: We're seeing 500s on api.example.com. Start an investigation and post findings to #incidents.

## Setup (skip if Polylane is already set up)

Read and follow https://polylane.com/auth.md for non-interactive signup and setup. Start by checking whether I am already signed in; reuse my account and workspace.

If the CLI is missing, bootstrap it without starting the interactive wizard:

curl -fsSL 'https://polylane.com/setup?ref=prompts' | bash -s -- --install-only

Then follow the guide through email verification, workspace selection, source connections, and MCP authentication. Ask me for an email code or OAuth consent only when needed. Verify each step; report pending setup instead of claiming success from installation alone.

## How to work

Over MCP: searchTools lists what this workspace exposes, with each tool's schema; call it first. runTool runs one tool, runCode chains several in one call and returns just the answer. search and execute cover the full Polylane REST API: threads, issues, investigations, autofixes, memories.
From the terminal: the polylane CLI wraps the same API, with structured output and non-interactive flags everywhere.
Reads always work. Write tools appear only if I have opted in, and every write is screened.

## Task: Respond to the page with context

Steps:
1. Read the failing signal: which endpoints, since when, how bad
2. Check deploys and config changes in the window across providers
3. Start the Polylane investigation on the issue so hypotheses run in parallel
4. Pull the blast radius from the context graph: what else is affected
5. Draft the first status update with the evidence so far, ready to post

Ground every claim in data you actually pulled: the query, the log line, the change record. If the data is inconclusive, say so. Ask me before anything that writes.
```

## What it replaces

**The first ten minutes are tab management.** Every page starts the same: open the dashboard, open the deploy list, open Slack, type "looking". Ten minutes of setup before any actual debugging happens, at the hour you're worst at it.

- Four tabs open before the first real query
- The deploy three minutes before the spike, missed until later
- "Any update?" arriving before you have one

## What the agent does

1. Read the failing signal: which endpoints, since when, how bad
2. Check deploys and config changes in the window across providers
3. Start the Polylane investigation on the issue so hypotheses run in parallel
4. Pull the blast radius from the context graph: what else is affected
5. Draft the first status update with the evidence so far, ready to post

## What you get

**Land in the incident, not in the tabs** Thirty seconds after the page you have the signal, the suspect change, and a running investigation. The first Slack update is written before anyone asks.

Every prompt: https://polylane.com/prompts/

Get started with one command: `curl -fsSL https://polylane.com/setup | bash` installs the CLI, connects your coding agents, and creates the account.
