Best AI Prompts for Software Engineers in 2026 (25 Copy-Paste Prompts)

**Prompt 1: Code Review Checklist Generation** Use this when: you're about to review a pull request and want a structured checklist tailored to the specific language, framework, or change type — so you don't miss common issues. Generate a code review checklist for the following pull request. Language and framework: [e.g., TypeScript / React, Python / FastAPI, Go / gRPC]. Change type: [new feature / bug fix / refactor / performance optimization / security patch — specify]. PR description: [paste the PR description or summarize what the change does]. Key files changed: [list the main files or modules being modified]. For this review, create a checklist covering: (1) Correctness — logic errors, edge cases, off-by-one errors, null handling, error path coverage, (2) Security — injection risks, authentication/authorization checks, sensitive data exposure, input validation, (3) Performance — N+1 queries, unnecessary re-renders, blocking I/O, memory allocation patterns, (4) Maintainability — naming clarity, function length, magic numbers, dead code, (5) Testing — test coverage for the new behavior, edge case tests, test quality (not just passing, but meaningful assertions), (6) API design — if the PR changes a public interface, backward compatibility and contract clarity, (7) Observability — logging, metrics, error messages that make the new code debuggable in production. Format as a numbered checklist with a one-line explanation of why each item matters for this specific change type. Why it works: Generic code review checklists miss language- and framework-specific failure modes. A tailored checklist for the specific change type — with explanations of why each item matters — produces thorough reviews in less time, because reviewers know exactly what to look for rather than relying on memory.

**Prompt 2: Bug Root Cause Analysis** Use this when: you're debugging a production issue or test failure and need to think through the root cause systematically before writing a fix. Help me diagnose the root cause of the following bug. System description: [describe the service or component — what it does, the key dependencies, the data flow]. Bug description: [describe what's happening — the symptom, the error message or incorrect behavior, when it occurs]. Reproduction steps: [how to reproduce it — specific inputs, sequence of events, environment conditions]. Error logs or stack trace: [paste any relevant logs, stack traces, or error output]. What I've already ruled out: [list the hypotheses you've already tested and eliminated]. For this analysis, provide: (1) The 3-5 most likely root causes ranked by probability, with the specific reasoning for each, (2) For each hypothesis, the exact test to confirm or eliminate it — what to check, where to look, what output would confirm or rule it out, (3) The order to test them — start with the hypothesis that can be tested fastest with the highest probability, (4) Common causes of this error type in [the language/framework] that are frequently missed, (5) Once confirmed: the fix approach and the regression test to write. Format as a structured debugging plan, not a list of guesses. Why it works: Debugging without a structured hypothesis list produces thrashing — re-testing the same things, going in circles, and getting frustrated. A ranked hypothesis list with specific tests produces linear progress: each test either confirms or eliminates a cause, and you converge on the root cause faster.

**Prompt 3: Pull Request Description Writing** Use this when: you've finished a feature or fix and need to write a clear, complete PR description that gives reviewers the context they need without having to read every line of code. Write a pull request description for the following change. What the code does: [describe the change — what problem it solves, what behavior it adds or modifies, what was broken and what is now fixed]. Files changed (summary): [list the key files and what changed in each — not every file, just the important ones]. Technical approach: [explain the key technical decision or design choice made in this PR — why this approach vs alternatives]. Testing: [describe how the change was tested — unit tests, integration tests, manual testing, regression tests]. Reviewer guidance: [anything specific reviewers should focus on — a tricky part of the implementation, an assumption that needs validation, a potential edge case to think about]. The PR description should include: (1) A one-sentence summary (the 'what' and 'why'), (2) Problem / motivation — what was wrong or missing before this change, (3) Solution — what the code does at a high level, (4) Technical notes — the key design choice and its rationale, (5) Testing — what was tested and how, (6) Review focus — what you most want feedback on. Length: concise — under 400 words. Avoid: vague descriptions like 'fixes bug' or 'updates component' that give reviewers nothing to work with. Why it works: PRs without context force reviewers to reconstruct your reasoning from the diff alone, which takes longer and produces shallower reviews. A clear description that explains the 'why' before the 'what' reduces review time and produces better feedback because reviewers know what assumptions to check.

**Prompt 4: Code Refactoring Plan** Use this when: you need to refactor a complex or messy piece of code and want a structured plan before you start — covering approach, risks, and sequence of changes. Create a refactoring plan for the following code. Code to refactor: [paste the code or describe the module/component]. Problem description: [describe what's wrong with the current code — what makes it hard to maintain, understand, test, or extend]. Refactoring goal: [what you want to achieve — e.g., 'split this 500-line class into smaller, focused classes,' 'replace the ad-hoc caching with a consistent caching layer,' 'eliminate the tight coupling between the order processor and the payment service']. Constraints: [what you must not break — existing API contracts, backward compatibility, production SLAs, test coverage]. The plan should include: (1) The specific refactoring steps in the order they should be done — with a rationale for the sequencing, (2) For each step: what changes, what to test before moving on, and what the safe stopping point is, (3) Risk identification — which steps carry the highest risk of introducing regressions and what to watch for, (4) The rollback plan for each risky step, (5) Suggested test additions to add before or alongside the refactoring to catch regressions. Format as a step-by-step plan that a teammate could follow if you're unavailable. Why it works: Refactoring without a plan produces the 'now I have two problems' failure mode — you start changing things, break something, and can't easily roll back because the changes are entangled. A sequenced refactoring plan with explicit stopping points and risk notes produces refactors that can be paused, reviewed, and completed safely.

**Prompt 5: Test Case Generation** Use this when: you've written a function or module and need to write comprehensive tests — covering the happy path, edge cases, and error conditions that you might miss writing tests manually. Generate a comprehensive test suite for the following function or module. Code to test: [paste the function, class, or module]. Framework: [Jest / pytest / Go testing / RSpec / JUnit — specify]. What the code is supposed to do: [describe the intended behavior in plain language — not just the code, but the business logic it implements]. Known edge cases: [any edge cases you already know about]. Generate tests covering: (1) Happy path — the primary intended behavior with typical inputs, (2) Boundary conditions — min/max values, empty arrays, single-element arrays, zero, null, undefined, (3) Error conditions — invalid inputs, missing required fields, values that should trigger exceptions or error returns, (4) Concurrency or state issues (if applicable) — race conditions, shared state mutations, order-dependent behavior, (5) Performance-sensitive paths (if applicable) — inputs that could produce O(n²) or worse behavior. For each test: (1) A descriptive test name that explains what's being tested and the expected outcome, (2) Clear arrange/act/assert structure, (3) A one-line comment explaining why this test exists — what failure it would catch. Flag any behavior in the code that appears untestable without refactoring and suggest the minimal change to make it testable. Why it works: Tests written manually by the author of the code tend to test the implementation rather than the specification — they verify that the code does what the code does, not that it does what it should. An externally structured test suite that generates from the specification description is more likely to catch the edge cases the author didn't think to test.

**Prompt 6: Architecture Decision Record (ADR) Draft** Use this when: you've made an architectural decision — choosing a technology, a design pattern, or an approach — and need to document it as an ADR before moving on. Write an Architecture Decision Record for the following decision. Decision title: [concise title — e.g., 'Use event sourcing for order state management' / 'Switch from REST to gRPC for internal service communication']. Context: [describe the technical situation that drove this decision — the problem being solved, the constraints, the alternatives that were considered]. Decision: [what was decided]. Consequences: [what the decision enables and what it constrains going forward]. For the ADR, include: (1) Status: [proposed / accepted / deprecated / superseded by ADR-XXX], (2) Context: a clear description of the problem and the forces at play — technical, operational, organizational — that drove this decision, (3) Decision: a precise statement of what was decided and the key rationale, (4) Considered alternatives: 2-4 alternatives that were seriously considered, each with their specific trade-offs, (5) Consequences: the positive and negative consequences of this decision — what becomes easier, what becomes harder, what technical debt or complexity is introduced, (6) Follow-up actions: any implementation steps, migration plans, or review dates that should result from this decision. Format: standard ADR structure (Markdown). Length: concise — the goal is a document a new engineer can read in 3 minutes and understand why the decision was made. Why it works: Undocumented architectural decisions create the 'why did we do it this way?' problem — where engineers spend hours reconstructing context that should have been captured when the decision was fresh. An ADR written at decision time takes 20 minutes and saves hours of future confusion.

**Prompt 7: README Writing** Use this when: you need to write or update a README for a project, service, or library — making it useful for a new engineer joining the team or a consumer of the code who needs to understand it quickly. Write a comprehensive README for the following project. Project name and type: [name and what it is — e.g., 'PaymentService — a Go microservice for processing payment transactions']. What it does: [describe the primary function and the problem it solves]. Technology stack: [the key technologies, frameworks, and dependencies]. Intended audience: [who will read this — internal engineers, external developers, open-source contributors]. The README should include: (1) A one-sentence description that makes the project's purpose immediately clear, (2) Features or capabilities — what the project does in bullet form, (3) Prerequisites — what you need installed before you can run this project, (4) Quick start — the minimal steps to get it running locally, (5) Configuration — the key environment variables or config options, (6) Usage — the key commands, API endpoints, or integration patterns, with examples, (7) Architecture overview — a brief description of how the project is structured and how the key components fit together, (8) Development — how to run tests, lint, and build, (9) Deployment — how the project is deployed to staging and production, (10) Contributing — the PR process, coding conventions, and review expectations, (11) License and ownership. Tone: clear, direct, assumes technical competence but not familiarity with this specific codebase. Every section should be useful on day one for an engineer who has never seen this code before. Why it works: READMEs written after the fact are always incomplete — the author no longer remembers what a new person needs to know. Writing the README against a complete template that covers prerequisites, quick start, and architecture ensures the new engineer can be productive without a synchronous onboarding session.

**Prompt 8: API Documentation** Use this when: you need to write clear, complete documentation for an API — either internal or external — covering endpoints, request/response formats, authentication, and error handling. Write API documentation for the following endpoint or service. API name and purpose: [the name and what the API does]. Authentication method: [API key / OAuth2 / JWT / none — describe the mechanism]. For each endpoint, provide: Endpoint: [HTTP method + path — e.g., POST /v1/orders]. Description: [what this endpoint does in plain language]. Request: [headers, path parameters, query parameters, request body — with field names, types, required/optional, and descriptions]. Response: [success response structure with field descriptions, and the HTTP status code]. Error responses: [the error codes this endpoint can return, with the condition that triggers each and what the consumer should do]. Rate limits: [if applicable]. Example: [a complete example request and response]. For the overall API documentation, include: (1) Authentication guide — how to obtain credentials and include them in requests, (2) Base URL and versioning — the base URL structure and how versioning works, (3) Common error codes — a table of error codes used across all endpoints with descriptions, (4) Rate limiting and pagination — if applicable, how these work globally. Format as Markdown suitable for a developer portal or README. Why it works: API documentation that lists endpoints but omits error codes and authentication examples forces consumers to learn through trial and error. Complete documentation that includes error handling, authentication, and realistic examples reduces integration time by an order of magnitude.

**Prompt 9: Runbook Creation** Use this when: you need to create or update a runbook for a service you own — so that on-call engineers can diagnose and resolve common issues without waking you up. Create an operations runbook for the following service or failure scenario. Service name: [the service or system]. Failure scenario: [the specific issue or class of issues this runbook addresses — e.g., 'high memory usage alert,' 'payment processing errors,' 'database connection pool exhaustion']. System context: [relevant architecture details — what the service does, its key dependencies, the monitoring and alerting tools in use]. The runbook should include: (1) Alert description — what alert fires, what metric threshold triggered it, and what it means in plain language, (2) Impact — what breaks for users or downstream services when this happens, (3) Severity classification — how urgent is this? What's the SLA for response? (4) Immediate checks (first 5 minutes) — the first 3-5 things to look at, with exact commands, dashboard links, or log queries, (5) Diagnosis steps — how to determine what's actually causing the issue, with decision branches: 'If you see X, it's probably Y — check Z,' (6) Resolution steps — numbered actions to resolve the issue, (7) Rollback procedure — if the resolution doesn't work, how to revert to a stable state, (8) Escalation criteria — when to escalate, who to escalate to, and what information to include, (9) Post-incident actions — what to file, what to update, what to investigate after resolution. Format as a numbered procedure document. Commands should be exact — copy-paste ready. Why it works: On-call runbooks that require domain knowledge to follow are useless at 3am when the domain expert is asleep. A runbook with exact commands, decision branches, and clear escalation criteria means any engineer on rotation can diagnose and resolve common issues without specialized knowledge.

**Prompt 10: Technical Specification Writing** Use this when: you're about to build a non-trivial feature or system and need to write a technical spec that gets alignment from stakeholders and gives the engineering team a clear implementation guide. Write a technical specification for the following feature or system. Feature name: [the name]. Problem it solves: [what user or business problem this addresses — in plain language]. Scope: [what is in scope for this implementation, and explicitly what is out of scope]. Stakeholders: [the PM, design, data, or ops stakeholders who need to approve this spec]. Technical approach: [the high-level implementation approach — the key architectural decisions, the components involved, the data flow]. The spec should include: (1) Executive summary — 3-4 sentences: what, why, and the recommended approach, (2) Background and motivation — the context that makes this feature necessary, (3) Goals and success criteria — what 'done' looks like, including measurable acceptance criteria, (4) Non-goals — what is explicitly not being built in this phase, (5) Technical design — the detailed implementation: data models, API contracts, system interactions, key algorithms, (6) Dependencies — what other systems, services, or teams this depends on, (7) Security and privacy considerations — how this change handles authentication, authorization, and data privacy, (8) Observability — how you'll know the feature is working correctly in production, (9) Rollout plan — phased rollout strategy, feature flags, canary deployment, (10) Open questions — decisions still to be made, with the person or team responsible for resolving them. Format as a technical design document with clear section headers. Target length: comprehensive enough to execute from, concise enough that stakeholders will actually read it. Why it works: Features built without a spec tend to drift from the original intent and produce the 'that's not what I asked for' conversation at launch. A spec that explicitly defines non-goals, acceptance criteria, and open questions aligns stakeholders before the first line of code is written.

**Prompt 11: System Design Document** Use this when: you're designing a new system or major component and need to produce a structured design document that covers the key decisions, trade-offs, and constraints. Write a system design document for the following system. System description: [what the system does, who uses it, and the scale it needs to handle — requests per second, data volume, latency requirements, number of users]. Business context: [why this system is being built or redesigned — the business outcome it enables]. Constraints: [technical constraints: existing infrastructure, required cloud provider, language ecosystem, team expertise; timeline; budget]. For the design document, cover: (1) System overview — a clear description of what the system does and who it serves, (2) Requirements: functional (what it must do) and non-functional (latency, throughput, availability, consistency, security), (3) High-level architecture — the major components, how they interact, and the data flow through the system, (4) Component design — for each major component, the specific technology choices and their rationale, (5) Data model — the core data entities, relationships, and storage choices, (6) API design — the key interfaces between components, (7) Scalability approach — how the system handles growth in traffic or data, (8) Reliability and failure handling — how the system handles component failures and maintains availability, (9) Security design — authentication, authorization, data protection, (10) Trade-offs and alternatives — the major design choices that were considered and why the chosen approach was selected. Format as a structured engineering design document. Why it works: System designs discussed verbally or in informal diagrams lose the rationale for key decisions — six months later, no one remembers why the design looks the way it does. A written design document with explicit trade-off analysis produces alignment before implementation and context for future modifications.

**Prompt 12: Trade-off Analysis** Use this when: you have two or more implementation approaches and need to produce a structured trade-off analysis — for your own decision-making or to present to your team or manager. Write a trade-off analysis for the following technical decision. Decision: [describe the choice — e.g., 'synchronous vs asynchronous order processing,' 'PostgreSQL vs DynamoDB for user session storage,' 'monolith vs microservices for the v2 architecture']. Option A: [describe the first option]. Option B: [describe the second option — add Option C if needed]. Context: [the system context that makes this decision consequential — scale, team size, latency requirements, consistency requirements, operational complexity tolerance]. For each option, analyze: (1) Performance and scalability — how it behaves under current and projected load, (2) Operational complexity — what the ops and on-call burden looks like, (3) Development velocity — how fast can the team move with this choice, (4) Cost — infrastructure and engineering time costs, (5) Risk — what can go wrong and how hard it is to recover, (6) Reversibility — how expensive is it to change this decision later. Then: (7) Recommendation — which option you recommend, with explicit reasoning, (8) Conditions under which you would recommend the other option — what would have to be true to make the alternative the better choice. Format as a structured analysis document suitable for an RFC or design review. Why it works: Technical decisions made through informal discussion often paper over the real trade-offs, and the team later disagrees about what was decided and why. A structured trade-off analysis that makes the reasoning explicit produces decisions that are harder to second-guess and easier to revisit with new information.

**Prompt 13: Capacity Planning Analysis** Use this when: you need to estimate the infrastructure capacity required for a new feature, a traffic spike, or a launch — and need to show your reasoning. Help me create a capacity planning analysis for the following scenario. System: [describe the service — what it does, the current infrastructure, the current load — requests per second, data volume, peak traffic patterns]. Growth scenario: [the event or projection driving this analysis — e.g., 'a 10x traffic increase over 6 months,' 'a product launch expected to add 50K users in the first week,' 'a new data pipeline processing 1TB/day']. Current metrics: [current request rates, response times, database query times, memory and CPU utilization — whatever you have]. The analysis should cover: (1) Current capacity baseline — what the system can handle today at current utilization, (2) Bottleneck identification — the components that will hit their limits first under the projected growth, (3) Growth projections — estimated load at 3, 6, and 12 months under the described growth scenario, (4) Scaling options for each bottleneck: horizontal scaling, vertical scaling, caching, database read replicas, CDN, queue-based smoothing — with the expected capacity gain and cost per option, (5) Recommended scaling plan with sequencing and trigger thresholds, (6) Cost estimate — order-of-magnitude infrastructure cost impact of the recommendation, (7) Risk: what fails first if the projection is significantly wrong. Format as a planning document with clear assumptions stated explicitly. Why it works: Capacity estimates made informally ('it should handle the load') fail publicly when they're wrong. A structured capacity plan with stated assumptions and explicit bottleneck identification allows stakeholders to interrogate the reasoning and adjust for new information before a production incident makes the gaps visible.

**Prompt 14: Incident Post-Mortem** Use this when: a production incident has been resolved and you need to write a thorough blameless post-mortem that produces real improvements — not a formality. Write a blameless post-mortem for the following incident. Incident summary: [what happened, the impact, and the duration]. Timeline: [the sequence of events from the first symptom to resolution, with approximate timestamps]. Root cause: [what technically caused the incident]. Contributing factors: [the systemic or environmental factors that made the incident possible or worse — not individual blame]. What went well: [what aspects of detection, response, and communication worked effectively]. What didn't go well: [what slowed down detection, resolution, or communication]. The post-mortem should include: (1) Incident summary — a 3-sentence description of what happened and the business impact, (2) Timeline — key events with timestamps and a note on who was involved at each stage, (3) Root cause analysis — the specific technical failure, explained clearly for a non-expert audience, (4) Contributing factors — the systemic issues using '5 Whys' framing: 'This happened because..., which happened because...' — trace to the systemic root, not the proximate cause, (5) What went well — specific observations about effective response, with the lesson to preserve, (6) What needs improvement — specific gaps, each with a root cause and a recommended improvement, (7) Action items — specific, assignable tasks with owners and due dates, (8) Metrics — MTTR, MTTD, user impact, revenue impact if measurable. Tone: blameless, specific, forward-looking. Frame all findings as 'what made this possible' not 'who caused this.' Why it works: Post-mortems that focus on individual failures produce defensive writing and no real improvements. A blameless structure that maps to systemic causes produces the action items that actually change the system — and builds the psychological safety that means incidents get reported and escalated quickly next time.

**Prompt 15: Migration Plan** Use this when: you need to plan and document a system migration — database, infrastructure, architecture, or technology stack — in a way that stakeholders can approve and the team can execute safely. Create a migration plan for the following change. Migration description: [what is being migrated — e.g., 'moving from MongoDB to PostgreSQL for user data,' 'migrating from a monolith to microservices,' 'upgrading the Kubernetes cluster from v1.26 to v1.30']. Why migrating: [the specific reason — performance, cost, maintainability, vendor end-of-life, scalability requirement]. Current state: [describe the existing system — size, traffic, dependencies, data volume]. Target state: [describe the desired end state]. Constraints: [zero-downtime requirement, data consistency requirements, rollback requirements, timeline, team capacity]. The migration plan should cover: (1) Executive summary — the what, why, and recommended approach in 4 sentences, (2) Migration strategy — the specific approach (big bang / phased / strangler fig / dual-write / blue-green — with rationale), (3) Phases — a numbered phase-by-phase plan with what changes in each phase, the acceptance criteria to move to the next phase, and the rollback point for each phase, (4) Data migration approach — how data is moved with consistency guarantees, (5) Testing strategy — how you validate correctness at each phase before proceeding, (6) Rollback plan — how to revert each phase if something goes wrong, (7) Communication plan — who needs to know, when, and what they need to do (other teams, external consumers, ops), (8) Risk register — the top 5 risks with mitigation strategy for each. Format as a project plan document suitable for stakeholder sign-off. Why it works: Migrations planned informally produce 'we'll figure it out' failures at the most inopportune moment — typically during the migration window itself. A phased plan with explicit rollback points, acceptance criteria, and a risk register converts a high-stress migration into a structured operation that can be paused if something doesn't look right.

**Prompt 16: System Design Interview Preparation** Use this when: you have a system design interview coming up and want to prepare for the specific type of problem you're likely to face — structured, domain-specific preparation rather than generic review. Help me prepare for a system design interview. Target company and role: [company / level — e.g., 'Staff Engineer at a mid-size fintech']. My background: [your experience level, domains of expertise, systems you've built or owned]. Interview format: [what you know about the format — 45-minute whiteboard, collaborative Excalidraw, specific problem types]. System type to prepare for: [e.g., 'URL shortener,' 'ride-sharing backend,' 'real-time notification system,' 'distributed rate limiter,' 'payment processing system']. For the preparation: (1) Walk me through a model solution to this type of problem using the systematic approach: requirements clarification → capacity estimation → high-level design → detailed component design → trade-offs and bottlenecks, (2) The 5 most likely follow-up questions after the initial design — with model answers, (3) The 3 most common mistakes candidates make on this type of problem and how to avoid them, (4) The specific areas where Staff/Senior vs Mid-level candidates differentiate — what demonstrating senior judgment looks like in the answer, (5) A 2-week preparation plan that builds the systematic habits, not just the knowledge. Format as structured preparation notes I can review the night before the interview. Why it works: System design interview preparation that memorizes solutions rather than practicing the framework produces candidates who can answer the prepared question but freeze on variations. Preparation that builds the systematic habits — requirements → capacity → design → trade-offs — produces consistent performance on novel problems.

**Prompt 17: Software Engineer Resume Rewrite** Use this when: you're updating your resume for a new role or promotion and want to translate your technical work into impact-forward bullets that signal seniority and attract senior engineering roles. Rewrite my software engineering resume for maximum impact. Target role: [describe the role and level — e.g., 'Senior Software Engineer at a Series B fintech' / 'Staff Engineer at a FAANG-adjacent company']. My current bullets (rough): [paste your existing experience bullets, job descriptions, or accomplishment notes]. Technology stack I work in: [the main languages, frameworks, and infrastructure tools I use]. For each bullet: (1) Lead with the business or engineering outcome first — 'Reduced API latency from 800ms to 120ms by...' not 'Worked on optimizing API,' (2) Show technical specificity — name the specific technology, the specific scale, the specific problem class, (3) Demonstrate scope and ownership — system scale (users served, requests/day, data volume), team size influenced, revenue or cost impact, (4) Use active engineering verbs — 'architected,' 'shipped,' 'reduced,' 'eliminated,' 'migrated,' not 'helped with' or 'worked on,' (5) For bullets without clear metrics — ask me 3 specific questions to surface them: what was the before/after, what was the scale, what would have happened without this change. After each rewrite, explain: why the change is stronger for the target role and seniority level. Also produce: a technical skills section organized for maximum signal at the target level. Why it works: Software engineering resumes routinely describe responsibilities ('worked on the backend API') instead of impact ('eliminated a 400ms database bottleneck that was causing 12% of user sessions to time out on checkout'). Senior engineering hiring managers scan for evidence of technical ownership and measurable outcomes — not a list of technologies touched.

**Prompt 18: Behavioral Interview Preparation** Use this when: you have a behavioral interview or 'leadership principles' interview coming up and want to prepare structured STAR-format stories from your actual work experience. Help me prepare behavioral interview answers for the following competencies. Role I'm interviewing for: [level and company type]. Competencies to prepare: [list 3-5 from: technical leadership, dealing with ambiguity, influencing without authority, delivering under pressure, handling technical disagreement, mentoring, cross-functional collaboration, making data-driven decisions]. For each competency: (1) Ask me for a rough description of a relevant experience — I'll provide the raw story, (2) Help me structure it into a clear STAR format: Situation → Task → Action → Result, (3) For the Actions section specifically: ensure the story demonstrates my personal judgment and contribution, not just what the team did, (4) For the Result section: push me to quantify the outcome — what changed, by how much, and what happened as a result of my action, (5) Identify the 'growth edge' moment in the story — the part where I learned something or changed my approach — which is what interviewers at senior levels are looking for. Also: flag any story that sounds too team-focused and help me reframe it to highlight my specific decision or contribution. Why it works: Behavioral interview preparation that memorizes stories verbatim produces rigid, monotone answers. STAR structure with quantified results and an explicit growth moment produces stories that are convincing at senior levels — because they demonstrate that you've operated at the level you're interviewing for, not just participated in projects that happened at that level.

**Prompt 19: Performance Review Self-Assessment** Use this when: you have a performance review cycle coming up and need to write a compelling self-assessment that accurately represents your impact and builds your case for the next level. Help me write a software engineering performance review self-assessment. Review period: [the time period being reviewed]. Target level and current level: [your current level and what you're trying to demonstrate — e.g., 'currently SWE2, making the case for SWE3']. Key projects or contributions: [list the 3-5 most significant things you worked on this period — describe them briefly]. The self-assessment should cover: (1) Technical impact — the specific technical contributions, in priority order, with the outcome for each. For each contribution: what was the problem, what did you build or change, what was the result (in numbers where possible), and what's the business significance, (2) Scope and complexity — evidence of operating at or above your current level's expectations for scope and ambiguity, (3) Engineering quality — how you've contributed to code quality, test coverage, technical debt reduction, or engineering standards, (4) Collaboration and influence — how you've helped teammates, reviewed code, mentored juniors, or influenced technical decisions beyond your immediate work, (5) Areas of growth — what you've gotten noticeably better at and a specific example, (6) Areas to develop — a self-aware statement of what you're working on improving — this signals maturity, not weakness. Tone: confident, specific, evidence-forward — not humble-braggy, not falsely modest. Length: 600-900 words. Why it works: Self-assessments that list activities ('worked on the data pipeline, reviewed PRs') instead of impact ('designed and shipped a data pipeline that reduced reporting latency from 4 hours to 8 minutes, enabling same-day business decisions for the analytics team') fail to build the promotion case at senior levels. A self-assessment written in outcome language with specific evidence produces the artifact managers can use in calibration discussions.

**Prompt 20: Promotion Case Building** Use this when: you want to make a deliberate push for promotion and need to build the written case — evidence, framing, and the conversation structure — before you talk to your manager. Help me build a promotion case from Senior Engineer to Staff Engineer [or relevant level]. Current evidence: [describe the work you've done that you believe demonstrates Staff-level impact — list specific projects, decisions, or initiatives with rough outcomes]. Level definitions: [paste or describe the promotion criteria for your company — the behavioral or impact expectations for the target level]. Gaps I'm aware of: [the areas where you know your case is weak or underdeveloped]. For the promotion case: (1) Gap analysis — map my current evidence against the level criteria; identify which criteria are well-supported, which are partially supported, and which are gaps I need to close before making the ask, (2) Evidence framing — for each supported criterion, help me write a 2-3 sentence evidence statement that connects my specific work to the level expectation, (3) Gap-closing strategy — for the criteria where my case is weakest, the specific opportunities in the next 60-90 days to generate the evidence I'm missing, (4) The conversation structure — how to open and run the promotion conversation with my manager in a way that positions it as collaborative planning, not a demand, (5) The 3 most likely objections my manager will raise and how to respond to each. Format as a working document I can update as I close the evidence gaps. Why it works: Engineers who want to get promoted but haven't built their case explicitly often don't know what's missing. A gap analysis against the level criteria converts vague ambition into a specific evidence-building campaign — and the conversation structure ensures the promotion conversation is a productive alignment, not a surprise that puts the manager on the defensive.

**Prompt 21: RFC (Request for Comments) Writing** Use this when: you want to propose a significant technical change — a new architecture, a process improvement, a technology adoption — and need a structured document that invites thoughtful feedback before you build. Write an RFC for the following technical proposal. Proposal title: [concise title]. Problem statement: [the specific problem this proposal addresses — why the status quo is insufficient]. Proposed solution: [what you're proposing — described at the level needed to evaluate the approach, not the implementation]. Alternatives considered: [the other approaches you evaluated before settling on this proposal]. The RFC should include: (1) Summary — a TL;DR of the proposal in 4-5 sentences: problem, solution, key trade-offs, recommendation, (2) Motivation — the specific problem, with evidence of its significance (incident data, performance metrics, developer feedback), (3) Detailed proposal — the technical design with enough specificity for the team to evaluate it, (4) Alternatives — 2-4 alternatives seriously considered, with the specific reasons for not choosing each, (5) Impact — who and what is affected by this change; what needs to change in other systems, processes, or team workflows, (6) Implementation plan — the phases of implementation, the estimated effort, and the rollout approach, (7) Risks and mitigations — the specific risks of this approach and how each would be mitigated, (8) Success criteria — how you'll know the proposal has achieved its goal, (9) Open questions — the specific questions you want feedback on, with the person or team you'd ask if you had to decide today. Format as a Markdown document. Tone: direct, intellectually honest about trade-offs — not a sales document for a predetermined conclusion. Why it works: Technical proposals made without an RFC process produce decisions by whoever talks loudest in Slack. An RFC that explicitly invites disagreement by naming the alternatives and the open questions surfaces the objections before implementation rather than during code review — which is when changing direction is cheap.

**Prompt 22: Engineering Update for Non-Technical Stakeholders** Use this when: you need to communicate a technical situation — a project status, a technical debt decision, an incident summary, or an architecture choice — to a product, business, or executive audience that doesn't speak engineering. Write an engineering update for non-technical stakeholders on the following topic. Topic: [describe the technical situation — e.g., 'we need to delay feature delivery by two weeks to address tech debt,' 'we're migrating to a new infrastructure platform,' 'we had a service outage last night']. Audience: [PM / VP Product / CEO / finance / customer success — describe their likely level of technical context]. The update should: (1) Lead with business impact, not technical detail — start with what it means for the business, the product, or the users before explaining the cause, (2) Explain the technical reality in business terms — use analogies where helpful, avoid jargon, focus on the 'why it matters' not the 'what it is,' (3) State clearly what's being done — what the engineering team is doing and by when, (4) Make a specific ask if needed — a decision, a resource, an approval, (5) Be honest about uncertainty — what you know, what you don't yet know, and when you'll have more information. Format: a structured written update under 300 words. Tone: direct, confident, non-defensive. Avoid: blaming vendors, excessive technical detail, passive voice, or vague timelines. Why it works: Engineering updates written for an engineering audience that land in a PM or executive's inbox force them to decode the technical content — which either doesn't happen (they skim it) or produces anxiety (they don't understand what it means for them). A business-first update that explains impact before cause produces informed stakeholders who can make decisions, not confused stakeholders who escalate to your manager.

**Prompt 23: Code Review Feedback Writing** Use this when: you've reviewed a PR and need to write feedback that is technically precise, constructive, and teaches — rather than feedback that is terse, harsh, or opaque. Help me write code review feedback for the following PR. Context: [brief description of the PR and what it does]. My technical observation: [describe the issue you found — the code, the pattern, the approach — and what the problem is with it]. The reviewer's level: [junior / mid / senior — and a sentence about their context if relevant, e.g., 'new to the codebase,' 'very experienced but new to this pattern']. The feedback should: (1) State the observation clearly without implying incompetence — describe what the code does, not how obvious the error is, (2) Explain the 'why' — not just 'this is wrong' but why it matters: performance, correctness, security, maintainability, (3) Suggest a concrete alternative or improvement — not just 'fix this,' but 'consider X because Y,' (4) Flag the severity appropriately — is this a blocker (must fix before merge), a suggestion (strong recommendation), or a nit (minor style preference), (5) Where relevant: point to a resource, a pattern in the existing codebase, or a prior discussion that helps the reviewer understand the context. Tone: direct, helpful, intellectually collaborative. Avoid: 'just,' 'simply,' 'obviously,' 'you should have,' or any framing that makes the reviewer feel bad for not knowing this. Why it works: Code review feedback that is technically correct but delivered poorly — 'this is a memory leak, fix it' — teaches nothing and damages the relationship. Feedback that explains the 'why,' suggests the specific improvement, and calibrates tone to the reviewer's level produces engineers who learn from reviews and who request your feedback specifically.

**Prompt 24: Technical Mentoring Plan** Use this when: you're mentoring a junior or mid-level engineer and want to create a structured development plan — so the mentoring relationship produces growth, not just advice. Create a technical mentoring plan for the following mentee situation. Mentee background: [describe the engineer — level, years of experience, current strengths, technical areas they want to develop]. Development goals: [what they want to improve — 'get better at system design,' 'learn to write more scalable code,' 'develop the skills to take on tech lead responsibilities']. Your capacity: [how much time you can invest — e.g., '30-minute weekly 1:1, plus asynchronous code review feedback']. Timeline: [the planning horizon — 3 months / 6 months]. The mentoring plan should include: (1) Goal clarity — translate their stated goals into 2-3 specific, measurable outcomes: 'can lead a system design discussion for a feature of X complexity,' 'consistently writes code that passes code review with no major comments,' (2) Skill gaps — the specific skills or knowledge gaps between their current state and the goals, ranked by priority, (3) Learning approaches — for each skill gap: the specific activities that will develop it (projects to take on, books to read, talks to watch, problems to practice), (4) Monthly focus areas — break the timeline into focused monthly themes so the mentoring has structure, (5) How to use the 1:1 time — a template for the weekly 1:1 that separates growth-focused time from tactical support, (6) Success indicators — how you'll know at the 3/6-month mark that the mentoring is working. Format as a working plan you'd share with the mentee at the start of the engagement. Why it works: Mentoring relationships that are purely reactive — 'come to me when you're stuck' — produce slow growth. A structured plan that names specific skills, assigns specific activities, and reserves 1:1 time for growth rather than just problem-solving produces measurably faster progression and mentees who develop the meta-skill of deliberate improvement.

**Prompt 25: Engineering Team Onboarding Plan** Use this when: a new engineer is joining your team and you need to create an onboarding plan that makes them productive faster — and doesn't require you to babysit them for their first month. Create a software engineering team onboarding plan for a new hire. New hire profile: [level and background — e.g., 'Mid-level backend engineer, strong Python, new to distributed systems and our infrastructure stack']. Team context: [what your team does, the tech stack, the deployment infrastructure, the key services they'll own or contribute to]. Onboarding goals: [what 'successful onboarding' looks like at 30, 60, and 90 days]. The onboarding plan should include: (1) Week 1: Environment setup checklist — development environment, access to systems, key internal tools and where to find documentation, (2) Week 1-2: Codebase orientation — the specific areas of the codebase to read first, in order; the key architectural concepts to understand before contributing, (3) First contribution — a specific, scoped first task that gets them into the codebase with a real change, sized for achievable success with light support, (4) Key learning milestones by week 4, 8, and 12 — specific skills or knowledge that mark progression, (5) Who to talk to — the key people for each domain (infra, product, data, QA), with a brief description of what each person owns, (6) Communication norms — how the team communicates, the PR process, the incident protocol, meeting cadence, (7) 30/60/90 check-in structure — the specific questions to review at each checkpoint to course-correct the onboarding. Format as a document you'd hand to the new engineer on day one — it should be self-directed enough that they can follow it without constant guidance. Why it works: Onboarding plans that are verbal or ad-hoc produce new engineers who are productive in month 3 instead of month 1 — because every question requires interrupting a teammate. A written, structured plan that answers the 'where do I find this?' and 'who should I talk to?' questions in advance produces engineers who are contributing meaningful code in their first two weeks.