Agent Config Doctor

Try it free. Three requests, no card.

Paste your config file, tell it what your agent did wrong, and read the diagnosis before you
pay anything. After that it is US$1.00 per hour, minimum one hour.

What this looks like

You paste this:

# CLAUDE.md
Run tests with: pytest -q
Build with: make release
Be concise.

And you say this:

It told me the package had a test suite and it didn't. I shipped broken code.

You get back this:

Evidence — "It told me the package had a test suite and it didn't."
Class — C1, unsourced claim reported as fact.
What your file says now — Be concise.
Why it did not work — Nothing in the file separates what the agent checked from what it
assumed, and Be concise. actively discourages the sentence that would have exposed it
("no test file found at tests/"). A claim with no source is indistinguishable from a verified
one, so you stop checking.
Replacement rule:

Label every claim: fact / finding / hypothesis / proposal.
Anything labelled fact names where you checked and when.
If you did not open the file, say so instead of describing it.

Then: the gaps your file leaves open, which rules to move to the top, and at most three
questions.

Why this is not a config generator

A generator writes you a file from a template. This reads the file you already have and finds
which rule was ignored — something no amount of reading the file alone will tell you.

That is why it asks what went wrong. Without an incident it still reports what your file itself
shows: rules that contradict each other, instructions no one can verify, stale dated claims, or
a line that tries to direct whoever reads it. But an incident is what turns a list of gaps into
a diagnosis.

Where the rules came from

Seven failure classes, each taken from a logged incident on a production pipeline run with a
coding agent — not from a best-practice list.

• C1 Unsourced claims reported as fact
• C2 "Done" reported for work that does not exist
• C3 Over-production — fifty-two files for a twelve-dollar deliverable, fourteen assets
  never used
• C4 Questions instead of a deliverable — an automated review once rejected a submission
  for replying with questions only
• C5 Irreversible actions taken without a human
• C6 Stale facts treated as current
• C7 Changes proposed to something the agent never inspected — one plan called for a
  screenshot in an image slot that renders at 54 pixels

What makes a replacement rule work

The four tests every rewrite here has to pass, and the reason most config files quietly fail:

1. A violation must be visible. "Be accurate" cannot be checked. "Label every claim and give
   a source for facts" can.
2. Prefer a mechanical check over an instruction. If a script can enforce it, it says so.
3. Constrain the output, not the process. Rules about what may be reported survive long
   conversations. Step-by-step procedure gets buried.
4. Short and early beats complete and buried.

Who this is for

People running Claude Code, Cursor, Copilot or Codex on real work, who already wrote a config
file and watched the agent ignore it.

Who this is not for

• You have no config file and no incident yet. You will get a sensible starter file, but the
  diagnosis is the product and it needs something to diagnose.
• You want the whole file rewritten. It replaces the rules that failed and tells you which ones
  to move. It does not hand back a new file.

Limits, stated plainly

• It makes failures visible. It does not promise they stop. No rewrite can guarantee an
  agent's behaviour.
• It works from your evidence. With no incident and nothing quotable in your file, it says so
  rather than presenting a checklist as a diagnosis.
• It reads what you paste. It does not connect to your repository.
• Replacement rules come back in the language your config file is written in, since that text
  goes straight back into it.