Source: https://learn.nodegx.io/build/when-it-breaks
Summary: What to tell Claude when your app breaks, and how to stop going round in circles.

# When something goes wrong

Things will break while you build. That is normal, and it does not mean you did something wrong. Tell Claude exactly what you see, and it can usually fix it.

## Say what you see and what you expected

Claude can't see your screen. Give it three things in one message: what you did, what happened, and what you expected to happen.

```text
In NodeGX, on the Tasks page, I clicked "Add task". Nothing happened.
I expected a new empty task to appear at the top of the list.
```

"It's broken" gives Claude nothing to go on. "I see this, I expected that" gives it the whole problem.

## Send Claude a screenshot

A picture of the problem is quicker than describing it, and Claude reads pictures well.

- **Mac:** press Cmd+Ctrl+Shift+4 and drag a box around the problem. The picture goes to your clipboard.
- **Windows:** press Win+Shift+S and drag a box. The picture goes to your clipboard.

Then click in Claude's message box and paste (Cmd+V on a Mac, Ctrl+V on Windows). You can also drag an image file into the message box.

## Paste the whole error message

If you see an error message anywhere, copy all of it and paste it in. Don't retype it or cut it short. The part that looks like nonsense is often the part Claude needs.

You may also see Claude say that NodeGX refused a change. That is NodeGX checking Claude's work before it is saved: a wrong change is turned down with an explanation, and nothing is written. Claude usually fixes it by itself. You only need to step in if the same thing keeps happening.

## Four traps to watch for

### The same fix fails again and again

Claude tries a fix and the problem comes back. It tries again, and it comes back again. By now Claude is guessing, and the failed tries in the conversation keep pulling it the same wrong way.

**If the same fix has failed twice, stop.** Don't let it try a third time. Ask Claude to explain the cause before it changes anything:

```text
Stop. This fix hasn't worked twice now.
Before you change anything else in NodeGX, explain what you think
is causing this, and how you would check that you're right.
Don't change anything yet.
```

Read the answer. If it makes sense to you, let Claude go ahead. If it doesn't, or Claude isn't sure, start again in a fresh conversation with a clean write-up:

```text
Write me a short note about this problem: what's wrong, what we tried,
and why each try didn't work. I'll paste it into a new conversation.
```

A fresh conversation isn't weighed down by the failed tries, and it often finds the cause quickly. [One job per conversation](https://learn.nodegx.io/build/one-job-per-conversation) shows how to start one.

### You didn't read the plan

Claude shows you a plan before it builds. It is easy to skim it and say "go ahead". Then the result isn't what you wanted, and the plan said so all along.

When this happens, go back to the plan and find the line that was wrong. Tell Claude which line, and what you meant instead. Next time, read the plan before you say yes. If it's too long to read, ask Claude to shorten it:

```text
Shorten this plan to the things I will see change in the app.
```

### The side-task spiral

You're working on the log-in page. Claude notices the menu looks wrong and offers to fix it while it's there. That fix turns up another problem. Later on, you're deep in the menu and the log-in page is half done.

When Claude spots something outside the job you're on, park it:

```text
Good catch. Write down what's wrong with the menu so we can do it next,
in its own conversation. Let's finish the log-in page first.
```

### The bug that keeps coming back

You fixed a bug last week. Now it's back. Each time, Claude tries much the same fix and hits the same wall.

The cause is often not in the app but in what Claude reads about it. Your project's brief and notes may say one thing while the app now does another, and Claude follows the notes straight back into the bug. Ask it to check them first:

```text
We've fixed this bug before and it's back. Before you change anything,
read this NodeGX project's brief and notes. Tell me if anything in them
doesn't match how the app works now, or might be steering you wrong.
```

Fix the notes first, then the bug.

::: everything The observe connector
NodeGX has a second connector, called Observe, that watches your app while it runs. With it, Claude can record a click and follow what it does inside the app, or ask why a value on screen is empty. It works out where the data stopped, so you don't have to go looking.

To set it up, open **Editor Settings** in NodeGX and find **Connect an AI agent**. Click **Copy the command** in the **Observe** row and run that command in a terminal.

Observe needs the NodeGX editor running with your app's preview started. Start a new conversation afterwards, so Claude sees the new tools.

```text
Use the NodeGX observe connector. Start a trace, then I'll click
"Add task" in the preview. Then tell me why the task list is still empty.
```
:::

## Quick reference

- Say what you did, what you saw and what you expected.
- Add a screenshot. Paste any error message in full.
- Same fix failed twice? Stop, and ask Claude to explain the cause first.
- Read the plan before you say yes.
- Park side tasks for their own conversation.
- A bug that keeps coming back: have Claude check the project's brief and notes.