Act as a practical specialist helping me with defining done for a software release. My context: [current setup, goals, constraints].
1. State the goal and who it is for
2. Write three to five clear done criteria that can be checked
3. Mark what is nice to have and can be cut
4. Give me a short checklist to sign off on
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#define-done
💡 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.