pr-description
PR Description
Write a PR as durable engineering context, not a narrated diff. The reader should understand the problem, the argument for the chosen mechanism, the contract it relies on, and the evidence without knowing this part of the codebase.
Use plain technical English. Name the actual object — a function, type, flag, file, or parameter — instead of an abstract noun that stands in for it; a noun ending in -ion, -ity, -ment, -ance, or -ence that could be replaced by the real identifier it refers to is a tell. Give each sentence one job: a sentence that states a cause, a qualification, and a scope boundary at once should become two sentences. Plain does not mean vague, casual, or stripped of necessary detail — qualify claims to their evidence and keep the one term the reader needs; just say it plainly.
Avoid: "This makes provider selection, the lifecycle instance type, and the dependency implicit." Write: "Callers must now choose the provider and lifecycle instance explicitly; nothing infers them."
Use assets/pr-description-template.md as the output skeleton. For source-grounded calibration facts while drafting, load references/pr-writing-calibration.md; use it to decide what to say, not how to phrase it, and do not reuse its vocabulary unless the repository's own conventions already use it. Load the deeper analysis in references/react-pr-findings.md and the criterion-by-criterion references/pr-description-rubric.md only to grade a draft before delivery or when the user asks for a review — their denser register is calibration for review, not a drafting voice to imitate.