Stop 3 of 9 · Daily
Logs and screenshots
Upload the event log export, the error screenshot and the system dump, and get back ranked causes with a check for each instead of a paragraph of maybes.
Evidence beats description
Half of a support ticket's life is Tariq describing a machine to himself. The screenshot is on his phone, the event log is on the laptop, the build details are in Atera, and the reasoning happens in his head across all three. Claude is good at the part where those three sources get lined up against each other, but only if it can see them.
So stop describing. Upload. An Event Viewer export saved as CSV, a screenshot of the actual dialog rather than a retyped version of it, and the machine's own inventory dump. Three files, one prompt, a ranked answer.
Getting the evidence out
Filter the log first. Event Viewer, filter the Application and System logs to Error and Critical, set the time range to the fifteen minutes either side of the failure, then Save Filtered Log File As, and choose CSV. Fifteen minutes of filtered rows tells Claude more than four thousand unfiltered ones.
For the machine's own facts, one read-only command is enough. Read it before you run it, as with every command in this course: this one writes a text file to the desktop and changes nothing.
systeminfo > "$env:USERPROFILE\Desktop\sysinfo.txt"
The screenshot matters more than people expect. Error codes get retyped wrong, and the window title, the button labels and what is behind the dialog all carry information the user did not think to mention.
The prompt that produces a plan
Attached are three files from one machine at Grantham and Reed: a filtered Application and System log export as CSV, a screenshot of the error the user saw, and a systeminfo dump. Give me a table with three columns: possible cause, how confident you are and why, and the single fastest check that would confirm or eliminate it. Rank by a combination of likelihood and how cheap the check is, so I work the list top down. Rules: quote the exact event IDs or log lines that support each cause. Do not offer a cause with nothing in the evidence behind it. If the evidence does not reach a conclusion, say what is missing and what I should capture next. The user says it started after Tuesday morning and happens about twice a day.
Here is a screenshot of an error a user sent with no other information. Tell me what application and what version this is, what the error code means, what you can infer from what is visible behind the dialog, and the two questions I should ask her before I touch the machine.
When the honest answer is "I do not know"
Ask for it explicitly and you will get it. The last rule in that prompt is the important one: if the logs do not support a conclusion, Claude should say which evidence is missing rather than picking the most common cause and dressing it up. A ranked list where the top row says "insufficient evidence, capture a reliability history next" is a good answer. It sends Tariq back to the machine with a specific thing to collect instead of a theory to defend.