End the incident with the fix
Takes the verdict from the mitigated incident and drafts the permanent fix in GitHub, with the evidence trail attached, so the same incident doesn't come back.
I want to do this: The incident is resolved. Draft the permanent fix and link the evidence. ## 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: End the incident with the fix Steps: 1. Read the investigation's verdict and the exact mechanism it proved 2. Locate the code and config behind the cause in the connected repos 3. Draft the permanent fix with the incident evidence linked in the description 4. Note what would validate it: the metric that should move, the error that should stop 5. Deliver the draft for review, tied back to the issue it closes 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.
"Mitigated" quietly becomes "done".
The mitigation stopped the bleeding, the war room dissolved, and the permanent fix became a ticket nobody owns. Next month the same incident happens again, with the same investigation.
- The follow-up ticket that ages into folklore
- The same root cause investigated twice
- Fixes shipped without the incident context that justified them
One prompt, this much work. Every step on your real data.
- 1 Read the investigation's verdict and the exact mechanism it proved
- 2 Locate the code and config behind the cause in the connected repos
- 3 Draft the permanent fix with the incident evidence linked in the description
- 4 Note what would validate it: the metric that should move, the error that should stop
- 5 Deliver the draft for review, tied back to the issue it closes
Resolved means fixed, not paused
The incident ends with a reviewable fix that cites its own evidence, not a ticket in the backlog. The rerun next month doesn't happen.
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?” War-room brief “Summarise the open incident for the exec channel: impact, cause so far, next steps.” 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?” War-room brief “Summarise the open incident for the exec channel: impact, cause so far, next steps.” 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?”