How to Get Claude to Fix Bugs Without Rewriting Your App

A passing token-refresh test doesn't prove a customer can log back in after their session expires. Your Claude prompt should make that gap visible before you ship.

For a live SaaS, useful coding prompts give Claude a clear outcome, a narrow boundary, and a way to check the result. You don't need a longer list of instructions. You need a change you can review and evidence you can inspect.

What makes Claude coding prompts work?

Good Claude coding prompts describe the result you want and explain how to check it. They also tell Claude what must stay unchanged.

The Claude Code prompt library calls its prompts “starting points rather than scripts.” Its guidance says to describe the outcome rather than dictate every step. One example asks Claude to add rate limiting while keeping existing tests passing, without naming a file.

That distinction matters when you're maintaining a product you already shipped. You know the customer-facing problem. You may not know which file causes it. Let Claude investigate the code, but don't leave the definition of success open.

A useful prompt includes:

• Outcome: what should work after the change.
• Context: the observed failure and relevant project details.
• Boundary: what Claude can change and what it should leave alone.
• Checks: what evidence would support calling the work done.

For example:

Login fails after a session expires. Investigate the refresh flow and reproduce the failure with a test. Make the smallest fix that follows existing auth patterns. Leave unrelated code unchanged. Run the relevant tests and report anything you couldn't verify.

Compare that with “fix authentication and improve the code.” The second request gives Claude no clear stopping point. “Improve” could mean renaming helpers or replacing code you weren't planning to touch.

Ask for one observable change and evidence that it works.

That doesn't require a rigid prompt formula. If you already have a failing test, give Claude the test. If you only have a customer report, start by asking it to investigate. Match the request to what you actually know.

What context should you give Claude before it edits code?

Give Claude the failure you observed, the steps that trigger it, and the project details that constrain a valid fix.

Whizi's coding prompt guide recommends stating your language and framework versions, constraining the change, asking for likely causes, and asking what could break. Those are useful inputs, not an invitation to paste your entire repository into a chat.

For an expired-session bug, describe the difference between expected and observed behavior. “Login is broken” leaves too much room for guessing. “After a session expires, the next request fails and the browser sends me to login” gives Claude something to investigate.

Use a short brief:

Problem: [what you observed].
Reproduce: [the steps you've confirmed].
Expected: [what should happen].
Stack: [language, framework, and versions].
Already checked: [checks and actual results].
Existing pattern: [a relevant implementation, if you know one].
Start by inspecting the code. Don't edit yet.

Keep observations separate from guesses. “The refresh token is broken” is a proposed explanation. “The refresh request returns this error” is evidence. Give Claude the evidence and label your suspected cause as a suspicion.

If you don't know where authentication lives, ask Claude to find it. The request can stay simple: “Find where this app refreshes sessions and explain the request path.”

Don't fill missing details with confident guesses just to complete the template. Say which parts you haven't checked. That gives Claude a useful investigation boundary and gives you an honest record of what the eventual fix still needs to prove.

Ask for cheap checks before allowing a fix

Claude can propose a debugging plan before it changes any code. For an expired-session failure, ask it to inspect refresh requests, token expiry, and retry behavior before choosing a cause.

Whizi's debugging prompt asks for ranked causes and the cheapest check for each. It explicitly says not to provide a fix yet. That separation gives you a chance to challenge the diagnosis before reviewing a patch built around it.

Try this:

Login fails after sessions expire. Don't edit code yet. Inspect the auth flow and rank the likely causes using the code and errors available. For each cause, suggest the cheapest check that would support or rule it out. Separate facts from guesses. Tell me what evidence you still need.

For this example, useful questions include:

• Does the browser send a refresh request when the session expires?
• Does the server accept that request or return an error?
• Does the client use the refreshed token when it retries?
• What happens if the refresh attempt fails?

These are investigation questions, not claims about your app. Don't turn them into requirements for a fix before you've looked at the answers.

Ask Claude to explain what each check would establish. “Inspect the network tab” is an activity. “Check whether the failed request triggers a refresh request” names a question you can answer.

If Claude can't run the app or inspect browser traffic, have it say so. You can perform the missing check and bring back the result. A clearly stated limit is more useful than a plausible explanation presented as a confirmed cause.

Once the evidence points to a specific failure, approve a narrow fix. You don't need to approve a broader cleanup along with it.

Make the test fail before changing the behavior

A regression test should reproduce the reported bug and fail for the reason you intend to fix. Ask Claude to demonstrate that failure before it edits the application code.

The Claude Code prompt library includes prompts for finding a failing test and for writing tests, running them, and fixing failures. For a live bug, add an explicit checkpoint: show the relevant failure first.

Use this prompt after the investigation:

Write a regression test for the confirmed expired-session failure. Follow the existing test style. Run it before changing application code. Show the command and failure output. Explain why that failure matches the reported bug. Stop if the test fails because of setup, missing dependencies, or another unrelated error.

A red test alone isn't enough. A missing environment variable can make a test fail without reproducing anything about session expiry. You need to inspect what failed, not just whether the command returned an error.

Check three things:

1. The test sets up the conditions from the bug report.
2. It expects the behavior the customer should receive.
3. Its failure points to the broken behavior, rather than a broken test setup.

Then ask Claude to make the smallest change that passes the test. Keep the expected behavior intact. If Claude proposes changing the expectation, require an explanation before accepting it.

Sometimes Claude won't reproduce the bug. Don't ask it to manufacture a failing test anyway. Return to the evidence: the report may lack a step, or the test may exercise the wrong path.

A test that never reproduced the reported failure can't show that you've fixed that failure. It may still test useful behavior, but it answers a different question.

Keep the fix small enough to review

A narrow Claude coding prompt gives you a clear reason to reject unrelated changes. For a token-refresh bug, name the allowed behavior change and tell Claude to preserve surrounding structure.

The AI Coding Guild prompt library builds its prompts around “one reviewable step” and keeping the agent inside a reviewable boundary. That's a useful standard for a solo founder who has to inspect the patch personally.

After you've confirmed the cause, try:

Fix the confirmed token-refresh failure. Follow the existing auth and test patterns. Change as little as possible. Don't rename unrelated code, add dependencies, or refactor nearby modules. If the fix genuinely needs a broader change, explain why and stop for approval. Run the regression test and relevant existing tests.

The boundary isn't a claim that every bug fits into a tiny patch. It's a request to make extra work visible before Claude does it.

When reviewing the diff, ask:

• Does each changed file help reproduce or fix the reported failure?
• Did Claude change behavior outside the refresh path?
• Did it weaken an assertion or remove a check?
• Did it introduce cleanup that could ship separately?

Ask Claude to explain any change you can't connect to the bug. “It was cleaner” isn't enough to include it in an urgent fix.

You can also request a final review of uncommitted changes. But don't let that summary replace reading the diff. The summary tells you what Claude says it changed. The diff shows what actually changed.

Separate optional cleanup from the repair. You can decide whether to do it later, with its own tests and review. Your immediate job is to restore the broken behavior without quietly approving a second project.

What proof should Claude return after a fix?

Claude should report the commands it ran, their results, and the behavior it couldn't test. “Tests pass” leaves out too much to support a shipping decision.

The Claude Code prompt library pairs writing tests with running them and fixing failures. Carry that through to the final response by asking for evidence you can check, rather than a general assurance.

Use a completion prompt like this:

Report what changed and why. List the exact test commands you ran and their results. Separate completed checks from suggested checks. State anything that failed, couldn't run, or remains untested. Explain what could still break. Don't describe the browser login flow as verified unless you actually tested it.

For an expired-session fix, separate the evidence into distinct checks:

• The regression test reproduces the old failure and passes after the change.
• Relevant existing tests still pass.
• The browser handles an expired session as expected.
• A failed refresh leads to the intended recovery behavior.

You may not have completed all of those checks. The point is to make the gap explicit.

A unit test can exercise a refresh helper without exercising the browser's full request sequence. Treat its result as evidence about what that test covers. Don't stretch it into a claim about the entire login experience.

If Claude can't access a browser, ask for a short manual test procedure. Run it yourself and record what happened. If the test environment blocks a command, keep that failure in the handoff rather than replacing it with “should pass.”

Your release decision should rest on completed checks and known gaps. You can choose to ship with an untested edge case. You shouldn't discover that edge case only because a confident summary hid it.

How do you adapt these prompts for features and refactors?

Keep the same outcome, boundary, and checks when you ask Claude to build a feature, refactor code, or review a patch. Change the proof to match the job.

The Claude Code common workflows guide describes prompt recipes for exploring code, fixing bugs, refactoring, testing, and reviewing changes. It also includes planning before editing so you can review proposed changes before they touch disk.

You don't need a separate prompting philosophy for each task. You need a clear answer to “What would make this change acceptable?”

For a feature:

Add [specific behavior] using the existing pattern in [relevant example]. First inspect the code and propose a small plan. Keep unrelated behavior unchanged. Add tests for the agreed behavior, run the relevant checks, and report what's untested. Ask before expanding the scope.

For a refactor:

Refactor [specific area] to achieve [concrete goal]. Preserve its external behavior. Identify the existing tests that cover it before editing. Keep unrelated code unchanged. Run those tests afterward and explain any behavior you couldn't verify.

For a review:

Review my uncommitted changes without editing them. Prioritize bugs and missing tests. For each concern, point to the relevant code and describe a concrete way it could fail. Separate confirmed problems from questions that need more evidence.

These are starting points, not promises that the model will follow every instruction. You still need to inspect its plan and check its work.

For your next live bug, start with the smallest useful request: investigate one failure without editing. Then ask for a test that reproduces it. Approve the fix only after you understand what failed, and ask for the exact checks afterward.

Keep the diff, test output, and remaining gaps together. That gives you something solid to review before you put the change in front of customers.