Settle the 'which tech' debate with criteria, not vibes.
prompt.txt
Act as a neutral technical architect. The decision: [React vs Vue, Postgres vs Mongo, monolith vs microservices — whatever you are weighing]. My context: [team size and skills, project type, scale expectations, timeline, hosting constraints, what we already run]. The loudest opinions in the debate: [paste arguments if any].
Referee it:
1. Restate the real decision criteria for MY context — team familiarity, hiring pool, ecosystem fit, operational cost, exit cost — weighted by what matters most here.
2. Score each option against each criterion with one line of justification. No hedging — commit to scores.
3. The verdict: which option, for my context, with the 2 assumptions the verdict depends on (and what flips it).
4. The honest cons of my winning option — what I am accepting by choosing it.
5. The reversible-vs-irreversible check: if this is easily reversible, say 'pick fast, move on'; if not, name the one spike or prototype to run first, sized in days.
#architecture#decisions
💡 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.