Support Engineer

Every project breaks sometimes. A build fails with a message nobody understands. The app goes blank on one page. Dark mode suddenly makes the text disappear. The fix is often small, but finding it can take a whole afternoon.

Support Engineer does the detective work for you. It reads the error, opens the code at the exact line that failed, and works out why it broke. Then it makes the fix and runs the failing command again to prove it works.

It works like a good mechanic. A mechanic does not swap a part just because a warning light is on. It listens, reads the fault codes, checks the part that failed, and only then makes the change. It also starts the car again before handing the keys back. Support Engineer follows the same order every time. It is also like a doctor who runs a test before giving medicine. It looks for the cause of the symptom, so the fix treats the illness and not just the cough. It also keeps to a few hard rules. It never hides an error to make a build turn green. It never removes a check, and it never weakens a security step just to get past a problem. If two different approaches both fail, it stops and tells you what it found and what it tried. You decide the next move, instead of watching it guess. It also asks before it reinstalls or upgrades packages, deletes files, overwrites components or pushes code. Those steps are hard to undo, so they wait for your yes.

• Diagnose build errors, runtime crashes (when the app stops while it is running), type errors (data used the wrong way) and dependency conflicts (two packages that need different versions of the same part).
• Read the error message and the code at the line where it failed, before it changes anything.
• Fix visual breakages, such as text that vanishes in dark mode, colours that ignore your theme, or buttons that give no feedback when you hover over them.
• Fix animation and component errors. For example, a list that animates wrongly because its items have no unique ID, or a part of the page that cannot load on the server.
• Re-run the command that failed after every fix, and show you the result line. It never claims a fix works until it has seen the command pass. If a fix fails, the result says so.
• Keep notes on the problems your project tends to hit and the fixes that worked, so the next one is faster to solve.
• Work in the Files, Review, Terminal and Browser panels. In the Browser panel it can open the broken page and show you what it sees.
• Read error reports and tickets from your GitHub, Sentry, Linear and Jira accounts, once you connect them, so the bug report and the code are looked at together.

The fix skill handles a bug from start to finish. You describe the problem in plain words. The team uses the project's file index (a list of every file and what it does) and its feature map (a list of what each feature depends on) to find the cause. Then it makes a targeted fix and checks it. Use it whenever something is broken and nobody knows why. Support Engineer also keeps to the same method when it works on its own: read the error, find the cause, make a small fix, and check that the fix holds. For example: "The dashboard goes blank after I sign in. Find out why and fix it."

The most common request is also the clearest one. Here is how a build error goes from broken to fixed.

1. You say, "The build fails with a module not found error. Fix it." You can paste the full error too.
2. Support Engineer reads the whole message first, including the file and line number it names. A "module not found" error means the code asks for a piece of code that is not where it expects to find it.
3. It reads the last few entries in the project's dev log, which is the running list of past problems and fixes. It checks whether this has happened before.
4. It opens the file the error points to and reads the line that asks for the missing piece.
5. It names the cause before it touches anything. The cause might be a path that points to a folder that has moved, or a package that was never installed. You see the cause in one sentence.
6. It makes the smallest change that fixes that cause. If the fix needs a package to be installed or upgraded, it asks you first.
7. It runs the same build command that failed. If the build passes, it shows you the result line, so you see proof and not a promise.
8. If the same error comes back, it tries one different approach. If that also fails, it stops. It reports the error, the cause it suspects, and both things it tried. It does not keep changing things at random, the way a mechanic would not keep replacing parts without a diagnosis.
9. You get the root cause, the file it changed, the command that now passes, and a new entry in the dev log so the team remembers the fix next time.

What you get at the end is a short note you can act on. It has the cause in one sentence, the file that changed, the proof that the command passes now, and the lesson kept for next time. If it had to stop instead, you get the error, the suspected cause and both attempts, so you can choose the next step.