Act as a practical specialist helping me with deciding not to over-engineer a solution. My context: [current setup, goals, constraints].
1. Name the temptation
2. Count the real cost
3. Set a clear limit
4. Plan what to do instead
Use my details, not a generic example. If a fact needed for the plan is missing, ask for it or mark the assumption. Keep the result ready to use.
#coding#deciding-not-to
💡 Replace the [brackets] with your details — the more specific, the sharper the answer.
A systematic bug hunt instead of staring at the screen for hours.
Act as a senior engineer pairing with me on a bug. Language/framework: [stack]. The bug: [what happens]. What I expected: [expected behavior]. The relevant code: [paste code]. What I have tried: [attempts]. Error messages: [paste any].
Do not just hand me a fix. Walk me through it:
1. Restate the bug as a precise, testable statement.
2. List the 4 most likely causes, ordered by probability given my symptoms, with the reasoning for each.
3. For the top cause: the smallest experiment that confirms or eliminates it — the exact line to add or change and what output proves what.
4. Only then, the likely fix, explained so I understand why it works.
5. End with: how this class of bug is usually prevented, and the one test or assertion I should add so it never silently returns.
A senior-level review: correctness, style, and the stuff linters miss.
Act as a staff engineer doing a code review. Language: [language]. Context: [what this code does and where it runs]. The code: [paste it].
Review in priority order:
1. Correctness: bugs, edge cases, race conditions, off-by-ones. For each: the input that triggers it.
2. Design: is this structured right? Naming, responsibilities, hidden coupling. If a function does too much, show the split.
3. Readability: the 3 changes that would most help a stranger understand this in one read.
4. Performance: only flag it if it matters at realistic scale — say what scale that is.
5. Security: anything an attacker or careless user could exploit.
Format: line or snippet, severity (blocker / should-fix / nit), issue, suggested fix. End with a verdict: approve, approve-with-changes, or needs-rework — and the single most important fix if I only make one.
Paste unfamiliar code, get a map of what it actually does.
Act as a senior developer onboarding me to unfamiliar code. The code or files: [paste code]. What I know so far: [context, or 'nothing']. My experience level: [beginner / intermediate / senior in other stacks].
Explain it as a map, not a lecture:
1. The one-paragraph summary: what this does and why it exists.
2. The flow: trace a request/execution through the code step by step — input to output, naming the functions that matter at each hop.
3. The key concepts I need to understand first, with a 2-sentence explanation of each as used here (not generic definitions).
4. The gotchas: non-obvious behavior, implicit assumptions, and the places a new person typically breaks things.
5. A 5-question self-quiz with answers hidden at the end, so I can check I actually understood.
Use an analogy for the overall architecture if one genuinely fits — skip it if forced.