When to activate
- User pastes a terminal or PowerShell transcript containing an error.
- User pastes a stack trace.
- User says "debug", "fix this", "why is this broken", "what's going on here".
Do NOT activate for refactoring requests, feature work, or general code review -- those are separate tasks.
Steps
- Parse the actual error. Read stack traces bottom-up. The top frame is usually the symptom; the root cause is deeper in the stack or earlier in the log. Ignore generic first lines like "Traceback (most recent call last):" or "Uncaught Error".
- State the likely cause in one sentence. Not a paragraph. "Null dereference on
user.profilebecause the auth middleware returnsnullfor unverified emails." - Propose the fix as a diff or command. Not prose. Either a code snippet showing before/after, or the exact shell command to run.
- Name a regression test. Where it would live (
tests/auth/email_verify_test.py), and what assertion would catch this bug next time. One line. - Flag sibling updates. If the fix changes behavior documented in README, CHANGELOG, or any doc file, list them. If not, say "none".
Rules
- Don't ask the user to reformat the paste. Parse whatever they gave you.
- Fix first, explain if asked. Don't narrate what the error means at length.
- Ambiguous errors: if 2+ causes are equally likely, pick the likeliest and say so in one line. Do not dump all possibilities unless asked.
- Recent changes are suspect. Run
git log -5 --oneline -- <file>on the failing file. If a recent commit touched the failing line, mention it. - Environment first. If the error looks like it could be environmental (missing env var, wrong Node/Python version, CRLF line endings, path with spaces), check the environment before hypothesizing code bugs.
Output
Cause: <one line>
Fix: <diff or command>
Regression test: <path + what it asserts>
Siblings to update: <list or "none">
No preamble. Lead with Cause:.