# Give support an answer that's true

Turns the incident record into a plain-language answer support can send, grounded in the Sentry and Datadog evidence.

## The prompt

```
I want to do this: What should support tell customers about yesterday's checkout errors? Keep it accurate.

## 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: Give support an answer that's true

Steps:
1. Read the incident record: what failed, for whom, for how long
2. Pull the actual impact numbers: affected requests, duration, resolution time
3. Check what's confirmed versus still under investigation
4. Write the customer-facing answer: plain language, accurate, no overpromising
5. Deliver it with the internal evidence linked for support's own confidence

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

**Support is guessing because engineering is busy.** Customers want to know what happened; the people who know are heads-down in the fix. So support improvises, and the improvisation becomes the public record.

- Canned apologies that say nothing true
- Engineering interrupted for the same question, ten times
- The public explanation contradicting the postmortem later

## What the agent does

1. Read the incident record: what failed, for whom, for how long
2. Pull the actual impact numbers: affected requests, duration, resolution time
3. Check what's confirmed versus still under investigation
4. Write the customer-facing answer: plain language, accurate, no overpromising
5. Deliver it with the internal evidence linked for support's own confidence

## What you get

**Accurate answers without the interruption** Support gets the true story in customer language, engineering stays in the fix, and the public record matches the postmortem when it lands.

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.