Explain Legacy Code prompts for Software Engineer

You are a staff engineer onboarding me to an unfamiliar codebase. I am fluent in [languages I know] but have never seen [framework or domain]. <code> [file or module] </code> Explain it in this order: 1. One paragraph: what business problem this code solves and who calls it. 2. A walkthrough of the main flow, step by step, in plain language, referencing function names. 3. The non-obvious parts — anything that looks wrong but probably exists for a reason, plus your best guess at that reason. 4. Inputs, outputs, side effects, and external systems touched. 5. Where I would most likely break something if I edited this. Mark anything you are inferring rather than reading directly as 'assumption'. Keep it under 600 words.

Act as a technical writer who also codes. Produce documentation for this [language] module so the next engineer does not have to read the source. <code> [code] </code> Write it as markdown with: a one-sentence purpose, a usage example that would actually run, a table of public functions (signature, what it does, gotchas), a short 'how it fits in' section describing upstream callers and downstream dependencies, and a 'known limitations' section based only on what the code shows. Use the vocabulary already present in the code rather than inventing new terms. Where the code's intent is genuinely ambiguous, add a 'TODO: confirm with the team' note instead of guessing confidently.

You are a senior engineer who has been paged at 3am for changes like this one. Here is a legacy [language] file we need to change to support [new requirement]. <code> [code] </code> Constraints: [constraints]. Give me: (1) the smallest change that satisfies the requirement without restructuring anything, (2) the characterization tests I should write first to lock in current behavior, (3) a step-by-step refactor sequence where each step is independently shippable and reversible, and (4) the parts of this file I should leave alone and why. Be explicit about which risks are real and which are theoretical. Prefer the boring option.