Brief the war room without leaving it
Turns the live investigation into a Slack update on what is broken, what is confirmed and what is next, pitched at whoever is asking.
I want to do this: Summarise the open incident for the exec channel: impact, cause so far, next steps. ## 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: Brief the war room without leaving it Steps: 1. Read the live investigation: confirmed findings, open hypotheses, current impact 2. Pull the impact numbers from the telemetry: who's affected, how much, since when 3. Separate what's proven from what's still being tested 4. Write the brief for the audience: impact, cause so far, next steps, ETA honesty 5. Deliver it ready to paste, with the evidence linked for whoever wants depth 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.
Updating people is a second incident.
The engineers debugging are the only ones who know the state, and every status request pulls one of them out of the fix. The exec summary and the engineer summary are different documents, both overdue.
- Context-switching from the fix to the update, every twenty minutes
- The exec channel reading raw stack traces
- Two updates that contradict each other
One prompt, this much work. Every step on your real data.
- 1 Read the live investigation: confirmed findings, open hypotheses, current impact
- 2 Pull the impact numbers from the telemetry: who's affected, how much, since when
- 3 Separate what's proven from what's still being tested
- 4 Write the brief for the audience: impact, cause so far, next steps, ETA honesty
- 5 Deliver it ready to paste, with the evidence linked for whoever wants depth
Everyone informed, nobody interrupted
The update comes from the investigation record, not from pulling an engineer out of the fix. One version of the truth, phrased for the audience reading it.
What broke overnight? 
“Triage everything that fired overnight: what was real, what was noise, and what's still open?” Root cause 
“P99 on checkout-api doubled at 14:10. Find the cause and show the evidence.” Postmortem “Write the postmortem for yesterday's incident: timeline, root cause, and the follow-ups.” First responder “We're seeing 500s on api.example.com. Start an investigation and post findings to #incidents.” What changed? 
“Did anything deploy or change config in the last two hours that could explain this latency?” Close the loop “The incident is resolved. Draft the permanent fix and link the evidence.” Which release? “Errors started around Tuesday. Which release introduced them?” Dedupe the pager “Group last month's pages into distinct issues. How many were the same thing twice?” Audit the alerts “Go through our alert rules: which ones fire the most, and which were ever real?”
“Triage everything that fired overnight: what was real, what was noise, and what's still open?” Root cause 
“P99 on checkout-api doubled at 14:10. Find the cause and show the evidence.” Postmortem “Write the postmortem for yesterday's incident: timeline, root cause, and the follow-ups.” First responder “We're seeing 500s on api.example.com. Start an investigation and post findings to #incidents.” What changed? “Did anything deploy or change config in the last two hours that could explain this latency?” Close the loop “The incident is resolved. Draft the permanent fix and link the evidence.” Which release? “Errors started around Tuesday. Which release introduced them?” Dedupe the pager “Group last month's pages into distinct issues. How many were the same thing twice?” Audit the alerts “Go through our alert rules: which ones fire the most, and which were ever real?”