Build prompts

I'm going to paste a code diff and a one line description of what it's meant to do. Write a test plan that covers: the intended behaviour described, at least one edge case that this specific diff could plausibly get wrong (based on what actually changed in the code, not generic edge cases), and one check that the change didn't affect a nearby piece of behaviour that wasn't meant to change.

Do not write generic test items like "test the happy path" without stating what the happy path actually is for this specific change.

Description: [one line on what this is meant to do]
Diff: [paste the diff]

Here is a technical description of a bug: what broke, why, and what the fix does. Write a two to three sentence explanation support could use to answer a customer, in plain language with no jargon, that is accurate about what happened without overpromising on timeline if the fix isn't live yet.

Then write a separate one sentence internal note for the support lead with the technical detail support agents don't need but might want to have on hand for an escalation.

Technical description: [describe the bug and the fix]

I'm rolling out [feature] behind a flag. Our current relevant traffic is roughly [your number] per day/week. Draft a staged rollout plan: specific percentages at each stage, how long to hold at each stage before moving to the next, and the specific metric and threshold that would pause or reverse the rollout at each stage, not just at the end.

Base the hold durations on getting enough volume at each stage to notice a real problem, not on a fixed number of days regardless of traffic.

Feature and what it changes: [describe it]
Guardrail metric: [your metric]

Here is a stack trace and a brief description of what engineering found. Write a plain-language incident note for the rest of the team: what broke, roughly since when, who was affected (which users or what percentage, if known), what's been done so far, and what's still unknown.

Explicitly separate what is confirmed from what is still a hypothesis. Do not present a working theory as a confirmed cause.

Stack trace and engineering notes: [paste them]

Here is a pull request description and the diff it describes. Check whether every claim in the description is actually supported by the code: if it says a case is handled, confirm the diff handles it; if it says something is unchanged, confirm nothing in the diff touches it.

List any claim in the description that the diff doesn't clearly support, and any change in the diff that isn't mentioned in the description at all.

Description: [paste the PR description]
Diff: [paste the diff]

Here is a technical description of what changed in this release. Write release notes for users in one to two sentences per change, each one naming the specific, observable behaviour difference (what they'll see or be able to do now that they couldn't before), not the internal reason for the change.

For any change that's purely internal and has no user-visible effect, say so and suggest leaving it out of user-facing notes entirely rather than writing a vague sentence about it.

Changes: [list what changed, technically]