Plan the jump to a new library without breaking production.
prompt.txt
Act as a tech lead planning a migration. Moving from: [current library/version]. Moving to: [target]. Codebase size and shape: [rough size, monolith or services]. Test coverage: [honest percentage]. Team size: [n]. Deadline pressure: [timeline].
Plan the migration:
1. Breaking changes that will actually bite us given how we use [current library], not the full changelog.
2. A strangler-fig sequence: 3-6 phases where each phase ships independently and leaves the system working. For each phase: scope, risk, and rollback plan.
3. The compatibility shim: whether to wrap the old API, and the smallest wrapper that covers 80% of call sites.
4. The search patterns to find every usage: exact grep or IDE queries for the top 5 APIs we call.
5. What to test manually because tests will not catch it.
6. A one-paragraph status update I can paste to stakeholders explaining the plan and risk.
#refactoring#planning
💡 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.