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.
Describe the pattern in words, get a tested regex that makes sense.
Act as a regex expert. I want to match: [describe in plain words, with 2-3 example strings that SHOULD match and 2-3 that should NOT]. Flavor: [JavaScript / Python / PCRE / not sure]. Where it runs: [validation / search-replace / parsing].
Give me:
1. The regex, in a code block, ready to paste.
2. A token-by-token explanation — table format: token, what it matches, why it is there.
3. Walk each of my examples through the regex showing where it matches or rejects.
4. The edge cases my examples did not cover: empty strings, unicode, extra whitespace, lookahead traps — and how the regex handles each.
5. Performance warning if this could catastrophically backtrack, with the safe rewrite.
6. A non-regex alternative in one line if this is honestly simpler done another way — say so if so.
A clean REST API spec before you write a line of code.
Act as a principal engineer designing an API. What it serves: [product and the resources it manages]. Consumers: [mobile app / web frontend / third-party developers]. Scale expectation: [rough]. Auth model: [sessions / tokens / OAuth / undecided].
Design the API:
1. Resources and their relationships, in one diagram-as-text.
2. The endpoint table: method, path, purpose, request shape, success response, the 2 most likely error responses with status codes.
3. Naming and convention decisions: pluralization, versioning, pagination style, filtering — with the one-line reason for each choice.
4. The auth flow in 4 steps, and which endpoints stay public.
5. The 3 design mistakes APIs like this usually make (over-nesting, leaking internals, inconsistent errors) and how my design avoids each.
6. A minimal example session: 3 curl calls showing create, read, and a realistic error.
From question to correct, readable SQL — with the edge cases handled.
Act as a database engineer. My question in words: [what you want to know or change]. My schema: [paste table definitions or describe columns and relationships]. Database: [Postgres / MySQL / SQLite / other]. Rough data size: [rows, if known].
Deliver:
1. The query, formatted for readability with comments on the clever parts.
2. A plain-English walkthrough of each clause and join — what it filters, what it multiplies.
3. The edge cases: NULLs, duplicates, empty results, timezone issues — which apply here and how the query handles them.
4. Performance: will this scan or use an index? If slow at my scale, the index to add or the rewrite that fixes it.
5. A sanity-check query: a quick SELECT I can run first to verify the assumptions the main query relies on.
6. If my question has an ambiguity, ask it before writing SQL — wrong questions make wrong queries.
Act as a maintainer with strict commit hygiene. My diff or description of changes: [paste git diff or describe what changed]. Repo conventions: [conventional commits / freeform / unknown].
Give me:
1. The commit message: type(scope): subject under 50 characters, imperative mood, no period.
2. The body if the change needs it: what changed and why, wrapped at 72 characters — the 'why' matters more than the 'what', the diff already shows the what.
3. If my diff actually contains 2+ logical changes, say so and split it into separate commits with a message for each — mixed commits are the enemy of git bisect.
4. The 3 commit-message sins in my team's likely history (vague 'fix bug', novel-length subjects, describing code instead of intent) shown against my message.
Teach the pattern so I need you less each time: end with the one-line mental test for a good message.
Act as a principal engineer who specializes in incremental refactoring. The code or architecture: [paste code or describe the mess]. The pain: [what makes it hard to work with]. Constraints: [cannot break production, limited time, tests exist or not].
Plan the refactor:
1. Diagnose the 3 core structural problems — name the pattern each violates.
2. The target shape: what good looks like here, in one paragraph and a text sketch.
3. The migration path: ordered steps where each step leaves the code working and deployable. For each step: what changes, what proves it worked, and how to roll it back.
4. The characterization tests to write FIRST if I have no tests — the 3 tests that pin current behavior before I touch anything.
5. What NOT to refactor: the parts where the risk outweighs the cleanliness. Every plan needs this list.
6. Estimate each step in hours for a dev familiar with the stack, so I can stop after any step with value already banked.
The test matrix for your function, including the cases you forgot.
Act as a QA-minded senior engineer. The code or function to test: [paste it or describe its contract — inputs, outputs, side effects]. Framework: [Jest / pytest / JUnit / other].
Generate the test plan:
1. Happy path: the 2-3 tests that prove basic correctness with realistic data.
2. Boundaries: empty, zero, one, max, negative, off-by-one — the exact inputs for each.
3. Malicious or garbage input: wrong types, injection attempts, huge payloads, unicode surprises.
4. State and side effects: what this touches (DB, files, network, globals) and how to test or mock each — with the mock shape.
5. The regression test: for any known past bug [describe if any], the test that locks it dead.
Write the actual test code for the 5 highest-value cases, named so the failure message explains the intent. End with the coverage lie: which important behavior a coverage percentage would NOT catch here.
Cryptic stack trace in, plain-English cause and fix out.
Act as a debugging translator. The full error and stack trace: [paste it, all of it]. My stack and versions: [language, framework, relevant library versions]. What I was doing when it fired: [action or request]. What changed recently: [new code, updates, config, deploys].
Translate it:
1. The one-line plain-English meaning of this error.
2. Where to actually look: which frame in the trace is mine vs library noise, and what line of MY code likely caused it.
3. The 3 most common causes of this exact error in my stack, ranked — with how to check each in under 2 minutes.
4. The most likely fix given my 'what changed' answer, and the verification step that confirms it.
5. If this error is a symptom of something deeper (config drift, version mismatch, environment difference), name the deeper thing and the one command or check that reveals it.
A tight technical spec your team can actually build from.
Act as an engineering lead writing a technical spec. The feature: [what we are building and the user problem it solves]. Context: [stack, existing systems it touches, team size]. Known constraints: [deadlines, performance needs, compliance, 'must reuse X'].
Draft the spec:
1. Problem and goal: 3 sentences, plus explicit non-goals — what we are NOT solving.
2. Proposed design: components, data flow, and the key decisions — each decision with the alternative considered and why it lost.
3. API/data changes: schemas, endpoints, migrations — with backward-compatibility notes.
4. Rollout plan: feature flags, staged release, monitoring, and the rollback trigger.
5. Open questions: everything undecided, each with an owner and a decide-by date.
6. Effort estimate broken by component, with the assumption each estimate leans on.
Keep it under 600 words — a spec nobody finishes reading is a spec nobody follows.
A transfer map from the language you know to the one you need.
Act as a polyglot programming mentor. I know: [language(s) and comfort level]. I need to learn: [target language] for [purpose — job, project, interview]. Time I have: [hours per week, deadline if any].
Build my transfer map:
1. The concept bridge: 8 concepts from my language with their exact equivalent in the target (e.g. list comprehension -> ?). Where no equivalent exists, say what replaces the habit.
2. The traps: 5 things that look familiar but behave differently — the exact bugs they cause for people coming from my background.
3. The genuinely new: 3 concepts with no parallel in what I know, each with a tiny code example and the mental model that makes it click.
4. My 2-week plan: what to build (not read), in what order, sized to my hours. Week 1 builds confidence with familiar patterns; week 2 forces the new concepts.
5. The cheat-sheet table: the 10 most-googled translations between my two languages.
Find the real bottleneck instead of optimizing blind.
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.
Settle the 'which tech' debate with criteria, not vibes.
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.