Prompts

You are a project coordinator for [team or project]. Turn the raw meeting notes below into a list of action items. For each item give: the task in one sentence, the owner (or "unassigned" — never guess a name), and the deadline if one was mentioned. Format the result as [output format]. List decisions that were made separately from tasks. If something is ambiguous, put it under "Needs clarification" rather than inventing details. Notes: [meeting notes]

Summarize the document below for [who is this summary for?]. Length budget: [length budget]. Lead with the single most important takeaway in one sentence. Then cover: what changed or was decided, any numbers that matter, and anything that requires action from the reader. Preserve exact figures and dates — do not round or paraphrase them. If the document contradicts itself or something important is missing, note that at the end instead of smoothing it over. Document: [document text]

Rewrite my email draft below so it is professional and clear. The recipient is [who is receiving it?]. What I need from them: [what do you need from them?]. Rules: keep every factual point I made; remove heat, blame and filler; do not add flattery or apologies I didn't make; keep it shorter than my draft. Ask for the specific thing I need with a concrete deadline if I mentioned one. Write it in my voice, not corporate boilerplate — plain words, short sentences. My draft: [your draft]

Write my weekly status update for [who reads it?]. Use exactly three sections: Done (what shipped or finished, with impact in one clause), Blocked (each blocker with the specific ask that would unblock it and who I need it from), and Next (top priorities for next week, max three). Keep it under 150 words. No pleasantries, no "great progress this week" framing — just the facts, in the first person. If my notes mention something half-done, put it in Next, not Done. My raw notes: [your raw notes]

Explain the code below to [explain it to…]. Structure: one sentence on what it does overall; then walk the flow top to bottom, explaining WHY at each step, not just what; then list any assumptions it makes about its inputs or environment, and the most likely way it breaks. If you are not certain what something does, say so explicitly instead of guessing — and do not invent behaviour for functions whose definitions you cannot see. Code: [the code]

Write unit tests for the code below using [test framework]. Before writing any test, list the behaviours worth testing — normal cases, edge cases (empty input, boundaries, invalid types), and error paths — then implement each as one focused test with a name that states the expected behaviour. Test the public behaviour, not the implementation details: no asserting on internal calls unless a side effect IS the contract. If a behaviour is ambiguous from the code alone, write the test name and mark it with a TODO comment asking me, instead of guessing the intent. Extra attention to: [what worries you most?] Code: [the code to test]

Review this code change as a senior engineer. Context: [what is this change for?]. Report findings in severity order: first anything that is a BUG (wrong output, crash, security hole, data loss) with the concrete scenario that triggers it; then risks (missing error handling, races, performance cliffs); last, style points — clearly labelled as optional. For each finding, quote the exact line and propose the fix. Do not pad the review: if the change is sound, say "nothing blocking" and stop. Do not invent requirements the change was never trying to meet. The change: [the diff or changed code]

Write a regular expression ([regex flavour]) that matches: [what should it match?]. It MUST match all of these: [examples that must match] It must NOT match any of these: [examples that must not match] Give the pattern, then explain it piece by piece, then list what it deliberately does not handle. Verify it against every example above before answering — if the requirements conflict, or an example can't be satisfied, say which and why instead of handing me a pattern that fails them. Prefer a readable pattern over a maximally clever one.

Write a [sql dialect] query. Schema (the ONLY tables and columns that exist): [your tables and columns] Question to answer: [what do you want to know?] Rules: use only the tables and columns above — if the question needs data the schema doesn't have, say so instead of inventing a column. State any assumption you make (how NULLs are treated, what ties do, date boundaries) as comments in the query. Then explain in two sentences what the query does and where it could be slow on a large table.

Extract structured data from the text below. Return ONLY valid JSON matching this shape: [the fields you want (as a json example)] Rules: every value must come from the text — never infer or embellish. Use null for anything the text doesn't state, and copy numbers, dates and names exactly as written (note the original form if you must normalise). If the text contains multiple records, return an array with one object each. After the JSON, list anything ambiguous you had to leave out. Text: [the messy text]

Write a pull request description from my notes below. Structure: a one-line summary a changelog could reuse; **Why** (the problem, and why now); **What changed** (grouped by area, not file-by-file); **How it's tested** (only what I actually did — never claim tests I didn't mention); **Review notes** (the risky part a reviewer should stare at, and anything I chose NOT to do, with the reason). Keep it under 250 words, no marketing tone. If my notes leave a section empty, write "—" rather than padding it. My notes: [your raw notes about the change]

Rewrite my technical update for [who is reading?]. Lead with what it means for THEM — what they can now do, stop worrying about, or need to decide. Replace jargon with plain language (one short parenthetical is allowed where a term must stay). Keep every number and date exact. Do not inflate: if something is partially done or carries risk, say so plainly — the goal is a reader who trusts these updates. End with the single next thing they should expect and when. Under [length limit]. My update: [your technical update]

Help me decide: [the decision]. The options I'm considering: [your options] My constraints and what matters most, in order: [constraints, most important first] Evaluate each option against my criteria specifically — not generic pros and cons. Name the strongest argument AGAINST each option, including the one you end up recommending. Flag anything I seem to be missing (an option, a constraint, a risk). Then recommend one option and state what evidence or event should change my mind.

Help me debug this error. Context: [what were you doing?]. First, translate what the error literally says in one plain sentence. Then list the most likely causes RANKED by probability given my context — for each: why it fits, and the quickest command or check to confirm or rule it out. Do not jump to a fix for cause #1 as if it were certain. If the error alone cannot distinguish the causes, tell me exactly what extra information would. Error: [the full error output]

You are helping [your role relative to them] prepare for a 1:1 with [who the 1:1 is with]. Below are recent, scattered observations about them and the working relationship. Build a 1:1 agenda with three sections: (1) topics to raise, each with a specific, open-ended question rather than a yes/no check-in, (2) things worth recognizing or thanking them for, and (3) one thing to ask about their side that hasn't come up yet. Keep the whole agenda to what fits in 30 minutes. If the notes don't give you enough to ask something specific about a topic, say so instead of inventing a generic question. Observations: [recent observations]

Turn the goals below into an OKR for [team], covering [time period]. Write one objective: a short, ambitious, qualitative statement of direction (not a metric). Then write exactly three key results, each a measurable outcome with a specific number or threshold, not an activity ("launch the new pricing page" is an activity; "increase trial-to-paid conversion from 4% to 6%" is a key result). If a stated goal genuinely cannot be turned into a number with the information given, list it separately under "not measurable as stated" along with what data would be needed, instead of forcing a fake metric onto it. Goals: [goals (rough notes are fine)]

Assemble a project kickoff brief for [project name] from the rough notes below. Structure it under these headings: Scope (what this project will deliver), Non-goals (what it explicitly will not cover, to prevent scope creep), Roles (who owns what, using only names or teams mentioned in the notes), Risks (anything the notes suggest could go wrong), and Milestones (in order, with dates only where one was actually given). If the notes don't mention a non-goal, an owner for some piece of scope, or any dates, leave that item as "not yet defined" rather than guessing one. Raw notes: [rough planning notes]

Review the project plan below for [project name] and identify risks. For each risk give: a one-sentence description, likelihood (low/medium/high), impact (low/medium/high), an early-warning sign someone could actually notice before the risk becomes a problem, and a specific mitigation (not "monitor closely"). Sort the list with the highest likelihood-times-impact risks first. Base every risk on something in the plan — a dependency, a deadline, a resource gap — and if you're inferring a risk that isn't directly supported by the plan, label it as speculative rather than presenting it as certain. Project plan: [project plan or summary]

Help me draft difficult feedback for [who the feedback is for] about [what the feedback is about]. Use the situation-behaviour-impact structure: describe the specific situation (when/where), the observable behaviour (what was actually said or done, not a character judgment), the impact it had (on the work, the team, or others — stated plainly, not exaggerated), and end with a specific request for what to do differently going forward. Do not use labels like "unprofessional" or "lazy" — describe the behaviour instead of naming a trait. If the details I gave you are too thin to describe a specific situation or behaviour, tell me what's missing instead of writing something generic. What happened: [what happened]

Help me prepare to negotiate [what you're negotiating]. My target is [your target number or outcome]. Build the case in four parts: (1) an opening statement that states the ask directly without over-apologizing, (2) three supporting points drawn only from my achievements below, each tied to a concrete result rather than a general claim of hard work, (3) two fallback asks I could accept if the target number isn't possible (e.g. adjusted title, extra time off, a review date), and (4) short, calm responses to the pushback I'm anticipating. If my achievements list doesn't clearly support the target number, tell me honestly where the case is weak instead of overstating it. Market data: [market data you have] My achievements: [your achievements] Pushback I expect: [pushback you expect]

Build a slide-by-slide outline for a presentation to [audience]. Goal of the talk: [goal of the talk]. Time limit: [time limit]. Estimate roughly how many slides fit the time limit at about 1-2 minutes per slide, then outline each one with: a slide title, the single message it needs to land (one sentence — if a slide needs two messages, split it into two slides), and the supporting point or data to put on it. End with one slide that states the specific action or decision you want from the audience. Use only the source material below for content — if it doesn't cover something you'd normally include, note the gap instead of inventing supporting data. Source material / notes: [source material or notes]

Generate an FAQ for [product or policy] using only the documentation pasted below. Write each question the way a real user would phrase it (casual, specific), not the way the documentation is organized internally. Answer each one in 2-4 sentences using only information found in the source text — do not add anything from general knowledge about similar products, even if it seems likely to be true. Group questions under a small number of natural categories. If a question a user would obviously ask isn't answered anywhere in the source text, list it under "Not covered by current docs" instead of guessing an answer. Documentation: [source documentation]

Write a job description for [role title] on [team] using the facts below. Structure it as: a 2-3 sentence overview of the role and why it exists, "What you'll be responsible for" written as outcomes ("own the checkout funnel's conversion rate"), not a laundry list of tasks ("attend meetings, write code"), then "Must-have" and "Nice-to-have" as two clearly separated lists — anything that would actually block a hire belongs in must-have, everything else goes in nice-to-have, even if the notes lumped them together. Keep the tone direct, no corporate filler like "fast-paced environment" or "wear many hats" unless the notes specifically support it. If the notes don't give you enough to write the compensation or location section, leave it as a placeholder rather than inventing a number or policy. Role facts: [role facts and notes]

Build a 30/60/90 day onboarding plan for a new [role title] joining [team]. For each of the three phases, give: the primary focus (e.g. learning vs. contributing vs. owning), 3-4 concrete goals specific to this role and team (not generic "get to know the team" filler), and one named checkpoint — a specific meeting, review or deliverable that marks the phase as complete. Use the team context below to make the goals specific; where the context doesn't tell you enough to make a goal specific (e.g. which systems, which people), name the gap so the hiring manager can fill it in rather than leaving a vague placeholder goal in the plan. Team context: [team context]

Build a retrospective agenda for [team] covering [sprint period], based on the events below. Group the events into 2-4 themes worth discussing (not a topic per event). For each theme, write one open question that invites explanation rather than assigning blame (ask about the process or circumstances, not "why did X person do Y"). End the agenda with a decision format for turning discussion into action: a fixed number of concrete changes the team will commit to trying next sprint, each with an owner. If an event in the list is too vague to turn into a real discussion theme, leave it out rather than forcing a theme around it. Sprint events: [what happened this sprint]

Write a reply to the customer complaint below. Here are the facts of the case: [facts of the case]. What we're able to offer: [what you can offer]. Structure the reply as: acknowledge the specific problem they described (not a generic "sorry for the inconvenience"), state plainly what happened based only on the facts given, offer the concrete remedy, and say what will change so it doesn't happen again if the facts support that. Avoid weasel words and passive voice that obscure who did what ("mistakes were made", "we understand your frustration" as a stand-in for actually addressing it). If the facts don't actually explain why the problem happened, say plainly that we're still looking into the cause rather than implying an explanation we don't have. Customer's complaint: [customer's complaint]

Turn the task list below into a ranked plan for this week, given these constraints: [constraints]. Rank every task from highest to lowest priority, and for each one give a one-line reason tied to the constraints (deadline pressure, dependency on someone else, or impact) rather than a restatement of the task itself. Draw a clear line under the tasks that fit this week given the constraints, and list everything below that line under "Not this week" with the reason it lost out to what's above it. If two tasks seem equally urgent from the information given, say so explicitly instead of arbitrarily ranking one above the other. Task list: [task list]

Write interview questions for a [seniority level] [role title] candidate, focused on: [focus areas and context]. Write 4-5 behavioural questions and 4-5 technical or role-specific questions. For each question, add a short note on what a good answer looks like at this level — specific enough that an interviewer with less experience in this area could still evaluate the response, and calibrated to the level given (a good answer from a senior candidate should look different from a good answer from a junior one). Base the technical questions only on the focus areas given; if a focus area is too broad to write a fair, specific question about, say so and suggest what would need to be narrowed down first. Focus areas and any additional context: [focus areas and context]

Tighten the paragraph below. Keep its meaning and its author's voice — don't flatten it into generic prose. Cut filler, throat-clearing and redundant qualifiers; keep every fact and number exact. After the rewrite, list what you changed and why, as short bullets (e.g. "cut 'in order to' — filler"). If the paragraph's point is genuinely ambiguous, say so instead of guessing at what it meant. Paragraph: [the paragraph]

Write 10 headline options for a piece about [what is the piece about?]. The core, verifiable point of the piece is: [the one verifiable point it can back up]. Cover at least these styles, one headline each, and label the style in brackets: how-to, question, number/list, contrarian, benefit-led, curiosity gap, direct statement. Fill the rest with whichever styles fit best. Every headline must be something the piece can actually back up — no promising a twist, secret or result that [the one verifiable point it can back up] doesn't support. If [the one verifiable point it can back up] is too thin to support a given style honestly, skip that style instead of forcing a dishonest one.

Rewrite the text below so it reads at a [target reading level] reading level. Simplify sentence structure and vocabulary, not the substance: keep every fact, number, date and named entity exactly as given — do not round, drop or generalize them. If a technical term has no simple equivalent, keep the term and add a short plain-language gloss in parentheses the first time it appears. If you can't simplify a sentence without losing a fact, say so instead of quietly cutting the fact. Text: [the text to simplify]

Proofread the text below. Find only mechanical errors — spelling, grammar, punctuation, subject-verb agreement, and typos — nothing else. Do NOT rewrite, rephrase, restyle or improve the writing in any way; if a sentence is awkward but not incorrect, leave it alone. For each error, quote the exact original text, give the corrected version, and name the error type. If you find no errors, say so — do not invent one just to seem thorough. Text: [the text to proofread]

Build a section-by-section outline for a blog post on [topic], written for [audience]. The angle: [your angle]. For each section give: a working heading, and the ONE point that section must land before the reader moves on — not a list of subtopics, the single takeaway. Order the sections so each one earns the next. Say what the intro must promise and what the conclusion must resolve. If [your angle] doesn't obviously support a strong ending, flag that instead of forcing a tidy conclusion.

Turn the article below into 3 social posts, one each for: [the three platforms]. Size and tone each post for its platform's norms. Give each post a different hook — don't reuse the same opening angle three times. Any quote you use must be copied exactly from the article; never paraphrase something and present it as a quote. No clickbait: the hook must be a specific claim from the article, not a promise the post doesn't deliver on. If the article doesn't give you enough for a genuinely different third hook, say so rather than repeating one. Article: [the article text]

Write 8 subject lines for the email below. Every subject line must be 50 characters or fewer — count the characters and discard any that don't fit. Cover a mix of approaches, labelled: direct/plain, curiosity gap, deadline/urgency, number-led, question, benefit-led, personalized-sounding, and one more of your choice. Every subject line must accurately reflect what's actually in the email — no promising content, urgency or a deadline the body doesn't contain. If the email has no real deadline, skip the deadline-based subject line rather than inventing one. Email body: [the email body]

Find every passive-voice sentence in the text below and rewrite it in active voice — but only where the actor is known or can be reasonably inferred from context; never invent a subject the text doesn't imply. For each sentence you leave passive, say why: the actor is genuinely unknown, unimportant to the point being made, or the passive is actually the clearer choice. Show a before/after pair for every sentence you change. If none of the text is passive, say so. Text: [the text to convert]

Build a learning roadmap for [skill to learn]. My current level: [your current level]. Time available: [time available]. Break it into stages — as many as are genuinely needed, don't pad or compress to hit a round number. For each stage give: what to focus on, one project that forces you to use it (not a tutorial to follow), roughly how long it takes at my pace, and a concrete "you're ready for the next stage when..." test I can check myself against. If my stated level and the skill's actual prerequisites don't match, say so before building a roadmap around that gap.

Turn the notes below into flashcards for spaced repetition. Break every idea down into atomic facts — one fact per card, never a card that requires remembering two things to get right. Write each question so it tests RECALL (you must produce the answer from memory) rather than recognition (you could guess right from the phrasing alone) — avoid true/false and avoid echoing half the answer in the question. A good card reads: "Q: Which HTTP status code means the client must authenticate first? A: 401." Use plain Q/A format by default; use a cloze deletion ("___") instead where a fill-in-the-blank tests the fact more directly. If a note is too vague to turn into a specific, checkable fact, leave it out and list it separately instead of inventing detail to make a card out of it. Notes: [your notes]

Quiz me on [topic] at [depth] depth. Act as the quizzer, not the explainer. Ask me ONE question at a time, then stop and wait for my answer — never ask several questions in a row or answer for me. After each answer, grade it honestly (correct / partially correct / incorrect) and, if I got it wrong, give the correct answer with a one-line reason why. Keep a running note of which areas I'm getting wrong and weight later questions toward those, rather than moving on evenly. If I ask you to just tell me the answer instead of quizzing me, do it once, then return to quizzing. If a question of mine reveals a gap in what you know about [topic], say so instead of guessing at an answer.

Explain [concept to explain] at three levels, clearly labelled: 1. To a curious child — a concrete analogy, no jargon, but nothing that's technically false just to simplify it. 2. To a student who's studied the basics of the field — the real terminology and the actual mechanism, not a longer analogy. 3. To a practitioner — the precise, technical version, including the caveats and edge cases the first two levels had to skip. Each level should add genuine precision, not just length or bigger words — someone reading all three should feel the concept sharpen, not just repeat. If [concept to explain] is genuinely contested or has no single correct explanation, say so at whichever level that matters.

Summarize the research text below into exactly these five parts: Claim — the single main finding, in one sentence. Method — how they tested it, in plain language (sample size, design, what was measured). Evidence strength — how confident this specific result should make someone, given the method — not how confident the abstract sounds. Limitations the authors admit — quote or closely paraphrase their own stated caveats; don't add limitations they didn't mention. What it does NOT show — conclusions the paper is commonly stretched to support that this result doesn't actually establish. If the text doesn't give enough detail for any of these five parts, write "not stated" for that part instead of inferring it. Paper text: [abstract or paper text]

I hold this position: [your position]. My reasoning: [your reasoning]. Write the STRONGEST version of the opposing case — the argument a smart, well-informed critic who disagrees with me would actually make, not a weak version that's easy to dismiss. Use real considerations, not a strawman. Then name the single crux: the one fact, definition or value disagreement that, if resolved, would settle which side is right. If my reasoning already addresses the strongest counterargument, say that plainly instead of manufacturing a new objection just to seem balanced.

Plan a refactor of the code below. Goal: [what's the refactor for?]. Break the refactor into an ordered sequence of steps, where each step is small enough to ship on its own (a mergeable PR) and leaves the code in a working state — no step that only makes sense once a later step lands. For each step, state: what changes, why it's safe to deploy alone, and the specific check (test, invariant, or manual verification) that would catch a behaviour regression introduced by that step. Keep logic changes and structural changes in separate steps — one concern per step. If part of the current behaviour is ambiguous or looks intentional-but-undocumented, flag it and ask rather than assuming which parts are safe to change. Code: [the code to refactor]

Suggest names for [what needs a name?]. Context: [naming context]. Give exactly 8 candidates. For each one: the name, the naming convention it follows (camelCase, snake_case, a domain term, an abbreviation, etc.), and one line on any collision or confusion risk — with an existing name in the context above, a reserved word, or a near-homonym already in use. Group the candidates if some are clearly stronger fits than others, and say which one you'd pick and why. If the context doesn't give you enough to judge collisions with any confidence, say so instead of inventing a codebase you haven't seen.

Review this API endpoint or schema design as a senior API reviewer. Existing conventions in this API: [existing api conventions]. Check it in this order: (1) consistency — does naming, casing, and status-code use match the conventions above; (2) error shape — is the error response structured the same way as the rest of the API, with a machine-readable code and a human message; (3) versioning — does this change need a version bump, and is it backward compatible for clients already calling the old shape; (4) the client's-eye view — walk through any awkward or multi-step call a client would now have to make because of this design. Rank findings by how much client pain they cause. If you don't actually know this API's error format or versioning scheme, ask rather than grading the design against generic REST defaults. Design: [the endpoint or schema design]

Write docstrings for the code below in [docstring style] style. For each function or class, document: what it does (behaviour, not implementation), the edge cases and error conditions it handles or explicitly doesn't, and any non-obvious side effect. Do not write a docstring that just restates the parameter names as prose — every parameter line must add information the signature doesn't already give: units, valid ranges, what an empty or null value means, or what happens if it's wrong. Skip any function that's already self-explanatory instead of padding it with a docstring that adds nothing. If a function's behaviour is ambiguous from the code alone, say what's unclear rather than guessing. Code: [the code to document]

Turn the raw commit log below into a user-facing changelog for [release version]. Group entries under Added / Changed / Fixed headings, and omit any heading with nothing under it. Rewrite each entry in plain, user-facing language — what changed for someone using the product, not the internal mechanism. Each entry should read like: "- Invoices can now be exported as CSV from the billing screen." Drop anything a user wouldn't care about: refactors, dependency bumps, test changes, CI config, internal renames. If a commit message is too vague to classify or to rewrite honestly, list it under a separate "Needs clarification" heading instead of guessing what it meant for users. Commits: [raw commit log]

Draft an Architecture Decision Record for this decision: [the decision being recorded]. Options that were considered: [options considered]. Write it in standard ADR format: Context (the forces and constraints that made this decision necessary), Decision (what was chosen, stated as one clear sentence), and Consequences (both the benefits AND the costs or risks this decision accepts — never write a consequences section that is all upside). For each rejected option, give the one-line reason it lost. If the context given doesn't actually explain why this decision is being made now, ask rather than inventing a plausible-sounding business justification.

Help me debug a performance issue. Symptoms: [what's slow, and when]. Relevant stack and code: [relevant stack, code, or trace]. List the plausible causes ranked from most to least likely given the symptoms. For each hypothesis, name the specific measurement or diagnostic — a profiler trace, a query's EXPLAIN plan, a timing log, a metric to check — that would confirm or rule it out, before proposing any fix for it. Only after the ranked list, suggest a fix for the top hypothesis, labelled clearly as provisional until that measurement is actually taken. If the symptoms are equally consistent with several unrelated causes, say so instead of picking one to sound decisive.

Review this form or endpoint for security issues: [the form or endpoint]. Walk it against each of these, and report only what actually applies to what's described here — no generic security lecture: input validation (type, length, and allowed values on every field); authorization (can a user act on someone else's data, and is the check enforced server-side); rate limiting (can it be spammed or brute-forced); injection (SQL, command, template, or stored XSS via input rendered elsewhere); and CSRF (a state-changing request with no token check, if this is browser-form-based). Rank findings by exploitability, and for each one give the concrete request an attacker would send. If something isn't described precisely enough to judge — for instance whether there's a server-side auth check — list it as a question instead of assuming the best or worst case.

Generate [number of rows] rows of realistic mock data for this schema, as [output format]. Make the data look real, not obviously synthetic: varied names including non-ASCII and unicode ones, realistic-looking but fake emails and IDs, dates spanning a believable range. Include a few edge-case rows on purpose: a boundary date (today, far past, far future — wherever the field allows it), a null or empty value in every field that's nullable, and a name with an apostrophe, accent, or non-Latin script to catch encoding bugs. Never put a null in a field the schema marks required. If the schema doesn't say whether a field is required or nullable, ask instead of guessing. Schema: [the schema]

Turn these messy observations into a proper bug report: [raw observations]. Structure it as: a title naming the symptom and where it happens (like "Checkout: 500 after applying an expired coupon on mobile Safari", never "bug in checkout"); numbered reproduction steps in the order they must happen; Expected vs Actual behaviour, stated as two separate lines; Environment (browser, OS, app version, account type — whatever is known); and a severity rating with one sentence justifying it (who's affected, how often, whether there's a workaround). If the observations don't give enough to fill a section — reproduction steps, environment, or frequency — list what's missing as explicit questions at the end instead of inventing plausible-sounding steps.

Convert the code below to [target language], written idiomatically for that language — not a line-by-line transliteration of the original's structure. After the converted code, list every behaviour difference this introduces or that the target language forces: numeric precision and overflow handling, how errors or exceptions propagate compared to the original, differences in default mutability or concurrency model, and standard-library edge cases such as string encoding or integer division. If part of the original logic has no clean equivalent in [target language], say so and explain the closest approximation rather than silently changing what it does. Code: [the code to convert]

Write a migration plan for this schema or API change: [the schema or api change]. Constraints: [constraints]. Structure the plan in the expand-migrate-contract pattern: Expand (add the new shape alongside the old, additive only), Migrate (backfill data and move readers and writers to the new shape, with the old shape still present as a fallback), Contract (remove the old shape once nothing depends on it). Each phase must be independently deployable and safe to leave running for days if the next phase is delayed. For every phase, state the rollback: what it takes to revert just that phase without touching data written by later phases. If a phase can't be made backward-compatible under the stated constraints, say which one and why, instead of presenting a plan that quietly assumes downtime is acceptable.