--- title: Self-diagnosis recipes description: Prompts and patterns for letting a coding agent diagnose itself — catching its own loops, checking whether it has failed this way before, and costing its plan. keywords: agent self diagnosis, Claude Code loop detection, agent debugging itself, MCP recipes, agent cost awareness eyebrow: Agents & MCP --- # Self-diagnosis recipes Concrete things to ask once the [MCP server is connected](/docs/mcp/install/). Each of these is a prompt you can paste, and a pattern worth turning into a [skill](/docs/mcp/skills/). ## Before starting work ### "Have I tried this before?" > Using clawmetry, search my recent sessions for anything touching > ``. If you find one, read its trace and tell me how it ended > before you start. This is the single highest-value one. Most repeated agent spend is a second attempt at a problem whose first attempt is sitting in the store, unread. ### "What did the last attempt cost?" > Using clawmetry, get the cost summary for the last 7 days and list my five > most expensive sessions. If any of them are about this task, tell me what > approach they used. Cost-aware agents make different choices. An agent that knows the last attempt was $12 will propose reading the schema before regenerating the migration. ## While working ### "Am I looping?" > Using clawmetry, list my events for this session filtered to `tool_call`. > If the same tool and arguments appear more than three times, stop and tell me > instead of trying again. Three identical calls is the same threshold ClawMetry's own `stuck_loop` detector uses. An agent that checks this on itself catches the loop before the detector has to. ### "Is this error familiar?" > Using clawmetry, list events of type `error` from the last 14 days and see > whether any match the error I just hit. If one does, read that session's > trace and tell me what fixed it — or what did not. The agent has your entire error history. It is the fastest incident search you have, because it is scoped to your machine and your work. ### "What did I change since it last worked?" > Using clawmetry, find the most recent session where `` > succeeded, then the most recent where it failed. Diff what the agent did > differently. ## After a failure ### Post-mortem on one session > Using clawmetry, get the full trace for session ``. Walk it and tell me: > the first step that went wrong, what the agent believed at that point, and > what evidence it had for that belief. The `why` endpoint on the dashboard does this visually; asking the agent to do it produces something you can paste into an issue. ### "Which tool keeps failing me?" > Using clawmetry, list `tool_result` events from the last week and group them > by tool. Tell me which tools have the highest failure rate and show me one > example of each failure. A tool with a high failure rate is usually a configuration problem — a wrong path, a missing credential, a permission — not a model problem. This finds it. ## Weekly, as a habit ### The spend review > Using clawmetry, get my cost summary for the last 7 days and the 7 before > that. Tell me what changed, which runtime drove it, and whether any single > session is responsible for more than 20% of the total. ### The waste review > Using clawmetry, list my sessions from the last week. For each one over $2, > read enough of its trace to say whether it produced a durable result — a file > change, a merged fix — or whether it ended without one. Total the second group. That second number is the one that changes behaviour. It is also exactly what ClawMetry's `no_progress` detector estimates, so the two should agree; if they do not, the agent's reading is worth trusting more, because it can tell "wrote a file" from "wrote a file that was then reverted". ## Making the agent do this unprompted Recipes only help if someone remembers to run them. Two ways to make it automatic: **Put it in the agent's instructions.** A line in `CLAUDE.md` or the equivalent: ```markdown Before starting a non-trivial task, use the clawmetry MCP server to check whether a previous session already attempted it, and say what you found. If you make the same tool call with the same arguments three times, stop. ``` **Make it a skill.** → [Skills and prompts](/docs/mcp/skills/) ## A note on trust The agent is reading its own past output. That is genuinely useful and it is also a feedback loop: an agent that misdiagnosed something last week will read that misdiagnosis back as evidence this week. The events are facts — a tool was called, it returned this error, it cost this much. The agent's *narration* in a past transcript is not. Prompts that ask for the tool stream ("list events of type error") tend to be more reliable than ones that ask for a summary of what the agent said it was doing.