Fixing an issue
Copy an issue as a prompt for any coding agent, hand it to Cursor or Claude Code to push a fix branch, read it over MCP, then close it, and learn when the fix did not hold.
An issue is written to be fixed from: the root cause, the suggested change and the failing traces are everything a coding agent needs. There are three ways to hand it over, and one thing to do afterwards: close it.
| Way | Good for |
|---|---|
| Copy as prompt | Any coding agent or chat, pasted in by you. |
| Fix | Cursor or Claude Code in the cloud, started from the issue; it pushes a branch. |
| MCP | A coding agent in your editor that reads the issue and replays its failures itself. |
Copy as prompt
Copy as prompt in the issue drawer copies the issue as a prompt for any coding agent: exactly what an agent reads over MCP.
Fix this issue in the "neobank.fraud_detection" agent (Trodo issue #207).
# Customer never told after a card freeze: notify_customer fails and is not retried
Kind of fix: Tool: a tool or external API misbehaves, or is called against its contract.
Seen 20 time(s), last 2026-09-30T08:14:02.000Z.
## Root cause
In fraud reviews that end in a freeze, freeze_card succeeds but the follow-up
notify_customer call fails ("notify_customer failed") and the agent neither retries
nor falls back. The card is frozen with no message to the customer, who finds out
at the till and calls support.
## Suggested change
Retry notify_customer once with backoff after freeze_card. If it still fails, queue
the notification and say in the case note that the customer has not been told.
## Evidence (20 of 20, newest first)
- span 5c1e… in run 91ad… step notify_customer: Error: notify_customer failed
- span 0f7b… in run 3e20… step notify_customer: Error: notify_customer failed
- …
The root cause is a lead: confirm it against the evidence before changing code.
With the Trodo MCP, get_issue_failures (issue_id 207) returns each failure's inputs to replay it.A rewritten issue says which version it is, so you know the prompt is current. Up to 20 pieces of evidence are included.
Hand it to a coding agent
Fix, next to Mark closed, starts a cloud coding agent on the issue.
Click Fix
With no coding agent connected, the button reads Connect Agent and takes you to set one up. With both connected, pick one; with one, it is used.
Add instructions (optional)
Keep the change minimal, or a file to start from.
Wait for the branch
The button reads Fixing… while the agent works; only one fix runs per issue at a time. The agent gets the issue and its evidence, reads the rest over the Trodo MCP (including the inputs to replay each failure), fixes the root cause, and pushes a fresh branch starting trodo/heal-.
Review and merge
The timeline shows Fix started and Fix branch trodo/heal-…. Review the branch, open the pull request, merge.
Close the issue
Once the fix is live, Mark closed. See Closing.
Fixing a Regression gives the agent the previous attempt too: the fix that did not hold and what it changed, so the second attempt does not repeat the first.
To have every new issue handed over without a click, use the agent template Triage, then hand to your coding agent. See Evals, alerts and issues.
Connecting Cursor or Claude Code
Both connect the same way: an automation on their side that uses the Trodo MCP server, and its endpoint and token pasted into Trodo under Settings → Integrations. You need a Trodo MCP key first.
Create a routine in Claude Code. Paste the system prompt shown on Trodo's Claude Code integration page, choose a model, and select the repository.
Set the trigger to API, and add the Trodo MCP server to the routine's connectors.
Copy the routine's API endpoint URL and API token into Settings → Integrations → Claude Code, then Save and Verify connection.
Create an automation at cursor.com/automations with a Webhook trigger, and pick the repository and base branch.
Paste the system prompt shown on Trodo's Cursor integration page, choose a model, and add the Trodo MCP server as a tool.
Copy the webhook URL, and a Cursor API key from cursor.com/settings, into Settings → Integrations → Cursor, then Save and Verify connection.
Over MCP
A coding agent connected to the Trodo MCP server with the mcp:issue scope can work an issue itself:
| Tool | Returns |
|---|---|
list_issues | The team's issues, filtered by status (including regression), category or agent. |
get_issue_details | One issue with its root cause, suggested change, every piece of evidence with its failing step and error, the evals that failed on it, and the timeline. |
get_issue_failures | The evidence with what is needed to replay it: a span's input, output and error; a run's, with the spans that failed in it. Paged, with how many can still be replayed and how many aged out of retention. |
get_issue_members | The evidence as ids, grouped by kind. |
get_issue_timeline | Evidence over time, per day by default. |
set_issue_status | Closes an issue. |
get_run_signals, get_span_signals | The issues a run or span is evidence for, and what failed in it. |
A useful instruction for an editor agent: Get Trodo issue 207, replay three of its failures from get_issue_failures, fix the cause, and show me they pass.
Closing
Mark closed when the fix is live, not when the branch is pushed. A closed issue leaves the default list (Open and Regression) and Reopen brings it back.
Closing is what makes a regression possible. A problem that returns after its issue is closed reopens that issue; a problem that returns while nobody has closed it just adds evidence to an open issue, and nobody learns the fix failed.
Regressions
When new evidence lands on a closed issue, it reopens with the status Regression and the timeline says Came back (regression), with the reason, such as the alert that fired.
New evidence comes from what is watching: a tracker whose alert fires again, or an eval that files the same finding. So keep the tracker that found an issue running after you fix it; that is what will tell you if it comes back.
Example: kyc-rulebook search unavailable was fixed with a retry and closed. When the index moved to a new cluster, the retrieval-failures alert fired again, Lucid matched the cause, and the issue reopened as a Regression with the new failures linked. A note on its timeline records why the first fix was not enough: the fallback to manual review never shipped.
Merging
Merge into… in the drawer lists the other open issues in view. Pick the one this is the same problem as: this issue's evidence moves there, this one becomes Merged and points to it, and both timelines record it. Merge into the one with more evidence, then ask Lucid to rewrite it so its root cause covers both.
Rewriting
Issues are rewritten by Lucid, so every version has the same shape and a coding agent can rely on it. Tell Lucid what is wrong: Issue #198's suggested change should mention the retry, rewrite it. The rewrite is a new version; the previous text stays on the timeline.
Evals, alerts and issues
Evals decide what is wrong, alerts decide how much is too much, and Lucid decides what the problem is. How an eval result becomes evidence on an issue, how any alert can file issues, and the agent templates that wire them together.
Overview
Watch a number about your agents and get told in Slack or a webhook the moment it crosses a line you set.