Find the real bottleneck instead of optimizing blind.
prompt.txt
Act as a performance engineer. The slowness: [what is slow, how slow, and when it got slow]. The system: [stack, architecture sketch, data sizes]. What I have tried: [attempts]. Access I have: [profilers, APM, logs, or just print statements].
Hunt the bottleneck:
1. Form 4 hypotheses ranked by likelihood for my symptoms: N+1 queries, unbounded loops, serialization, memory pressure, cold caches, blocking I/O — pick the ones that fit and say why.
2. For each hypothesis: the cheapest measurement that confirms or kills it. Exact tool or code — no 'consider profiling'.
3. The instrumentation plan if I have no tooling: where to place 5 timers to bisect the slowness.
4. The classic false friends: optimizations people reach for here that rarely help (micro-caching everything, rewriting loops) and why.
5. The fix ladder: from 'config change' to 'query/index fix' to 'architecture change' — with expected gain and effort for each rung.
Rule: no fix before measurement. Make me promise in the plan.
#performance#optimization
💡 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.