AI Example Prompts

Get oriented in code you did not write.

You are a senior engineer onboarding me to this codebase. Given the files below, explain:
1. The high-level architecture and how data flows through it.
2. The 3-5 most important files or modules and what each is responsible for.
3. The conventions and patterns I should follow to stay consistent.
4. Anything that looks surprising, risky, or like tech debt.

Be concrete and cite file/function names. Ask me for any files you need to see.

<paste files or describe the repo>

Turn a vague ask into an implementation plan.

Act as a pragmatic staff engineer. I want to build: <describe the feature>.

Before writing code, produce:
1. A short list of clarifying questions where the requirements are ambiguous.
2. 2-3 implementation approaches with trade-offs (complexity, performance, blast radius).
3. Your recommended approach and why.
4. A step-by-step plan, including tests and edge cases.

Stack: <languages/frameworks>. Constraints: <perf, deadlines, team size>.

Cover the cases you would forget.

Write a thorough test suite for the code below. Include:
- Happy path cases.
- Edge cases and boundary conditions.
- Error and failure handling.
- Any concurrency or ordering issues you can spot.

Use <test framework>. Explain the reasoning for any non-obvious case before the code.

<paste code>

Find real bugs, not style nits.

Review this diff as a skeptical senior engineer whose goal is to find defects, not to praise it. Focus on:
- Correctness bugs and unhandled edge cases.
- Security issues (injection, authz, secrets, unsafe input).
- Concurrency, race conditions, and resource leaks.
- Anything that will break at scale or under failure.

For each finding: state the concrete scenario that triggers it and the severity. Ignore formatting. If you find nothing serious, say so plainly.

<paste diff>

Understand the blast radius before you merge.

Given this change, assess the risk of shipping it:
1. What could break, and who/what depends on this code?
2. What is the worst realistic failure mode in production?
3. What should I test or monitor before and after rollout?
4. Is there a safer, more incremental way to ship this?

<paste diff or description>

Reason through a bug instead of guessing.

Help me debug this methodically. Do not jump to a fix.

Symptom: <what is happening>
Expected: <what should happen>
What I have tried: <list>
Relevant code/logs: <paste>

First, list the most likely hypotheses ranked by probability. For each, tell me the single fastest check to confirm or rule it out. We will work through them one at a time.

Decode the stack trace and the root cause.

Explain this error in plain language: what it means, the most common root causes, and how to confirm which one applies to me. Then give the fix.

Error / stack trace:
<paste>

Context: <language, framework, what I was doing>

Rehearse feedback that lands with care.

I need to have a difficult conversation with a team member. Help me prepare using a Radical Candor mindset — care personally, challenge directly.

Situation: <what happened>
My goal for the conversation: <outcome>
What I am worried about: <concern>

Give me: an opening line, the core message stated kindly but clearly, likely responses and how to handle each, and what I should ask rather than tell.

Specific, fair, growth-oriented feedback.

Help me write a balanced performance review for a team member. I will give you rough notes; you turn them into specific, evidence-based feedback.

Turn vague praise into concrete examples, frame growth areas as opportunities with clear next steps, and keep the tone honest and supportive. Flag anywhere my notes are too thin to be fair.

Notes:
<paste bullet points>

Align the team around a clear rationale.

Help me write a concise decision doc (one page) for: <the decision>.

Structure it as: Context → Options considered → Decision → Rationale → Risks & mitigations → What changes now. Write for a smart reader who was not in the room. Keep it tight and skimmable.

My rough thinking: <notes>

Edit for clarity without losing your voice.

Edit the text below for clarity and impact. Keep my voice — do not make it sound corporate or generic. Specifically:
- Cut filler and hedging.
- Tighten long sentences.
- Flag anything unclear or unsupported.

Show the edited version, then a short bullet list of the most important changes and why.

<paste text>

Same substance, right altitude for each reader.

Take the core message below and rewrite it for three audiences:
1. Executives (outcome and impact first, minimal detail).
2. Engineers (precise, technical, assumes context).
3. The whole company (plain language, why it matters to them).

Keep the facts identical; change only the framing and level of detail.

Core message: <paste>

Understand something deeply, at your level.

Teach me <concept> as if I am a capable professional who is new to this topic.
1. Start with the core idea in one paragraph, using an analogy.
2. Build up the details in layers, checking my understanding as you go.
3. Give a concrete worked example.
4. End with the 3 things most people get wrong.

After each section, ask me one question to check I followed before moving on.

Go from zero to competent, deliberately.

I want to learn <skill> to the point where I can <specific goal>. I can spend about <time budget>.

Design an Ultralearning-style plan: the highest-leverage subtopics in order, how I will practice each (not just read), how I will get feedback, and a project that would prove I have learned it. Cut anything that is not essential to my goal.

Find the flaws before reality does.

Act as a thoughtful skeptic. Here is my plan: <describe>.

Do a pre-mortem: assume it is 6 months later and this failed. Walk backward through the most likely reasons why. Then tell me the two or three assumptions the whole plan rests on, and how I could cheaply test each one now.

Surface the option you are not seeing.

I am deciding between: <options>. Here is my current lean and reasoning: <notes>.

Steelman the option I am NOT choosing. Then name any option I have not considered. Finally, tell me what additional information would most change my decision — so I know what to go find out.