Turn the bug report into a fix
Investigates the ticket against Datadog, Sentry and Axiom, tests the theories, and drafts the fix with its reasoning.
I want to do this: Users report intermittent timeouts on search. Find the cause and draft the fix. ## 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: Turn the bug report into a fix Steps: 1. Find the symptom in the telemetry: when the timeouts happen, to whom, how often 2. Check what changed around when reports started 3. Test the candidate causes against logs, traces, and code until one is proven 4. Draft the fix with the root cause and validation reasoning attached 5. Deliver it for review, linked to the evidence that justified it 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.
"Intermittent" is a week of your life.
The ticket says timeouts, sometimes. Reproducing it means hours across logs, traces, and deploy history before the actual work starts, and the trail is cold by the time you pick it up.
- Half a day to reproduce before a minute of fixing
- The intermittent bug that never fires while you watch
- Tickets bounced back with "cannot reproduce"
One prompt, this much work. Every step on your real data.
- 1 Find the symptom in the telemetry: when the timeouts happen, to whom, how often
- 2 Check what changed around when reports started
- 3 Test the candidate causes against logs, traces, and code until one is proven
- 4 Draft the fix with the root cause and validation reasoning attached
- 5 Deliver it for review, linked to the evidence that justified it
The ticket comes back with the fix
Cause proven against production data, fix drafted with its reasoning, ready for review. The week of reproduction becomes an afternoon of reading.
Confirm the bug
“Can you confirm the bug in ticket #513 from the logs, and which release introduced it?” Answer support
“What should support tell customers about yesterday's checkout errors? Keep it accurate.” The backlog bug
“This flaky 502 has been in the backlog for a month. Find the actual cause.”