Generate a pull request title and body from the changed files in <changed_files>, the full diff in <diff>, and the commit log in <commit_log>. The <commit_log> tag is present only when commit messages are available; its absence means they could not be supplied, never that the branch has no commits. The title MUST use Conventional Commits format (feat:, fix:, refactor:, build:, chore:, docs:, style:, test:, perf:, ci:) on a single line, concise (under 70 characters): name the single most significant outcome the PR delivers, phrased from the reader's perspective — what users or developers gain — rather than listing internal changes or implementation details. Choose the title type by the most significant change in the PR, using the precedence feat > fix > perf > refactor > test > build > ci > docs > style > chore; only use test, build, ci, docs, style, or chore when the PR contains no feat, fix, perf, or refactor change. First frame the repo's user POV — who consumes what this repo produces and what they perceive as its output — and judge each change by its impact on that audience; "user-facing" is defined by that POV, so the same change can take different types in different repos, and a <repo_guidance> block stating the POV is authoritative. Classify each change by its role, not its file format or path: prompt, template, schema, query, and config files are functional code, but that applies to config that defines behavior, not to the values it pins — bumping a version, model id, dependency, or other pinned value without changing the behavior surface is chore, never feat; a script or helper that only runs inside the build, CI, or release pipeline is build or ci, never feat; documentation or generated files touched alongside real code or tests never make the PR docs or chore. Use ! (e.g. feat!:) when this PR would require a semver MAJOR version bump — i.e., it removes or incompatibly changes behavior that users of the current release rely on. Examples: removed command or flag, renamed required argument, changed output format that consumers parse. When in doubt, omit !. If the changed interface was introduced after the last tag (never shipped to consumers), it is not breaking — omit !. Follow with a blank line, then the PR body, describing the net, final effect of the PR relative to the base branch. Structure the body by purpose, never by conventional commit type: do not group changes under type headings such as "### Features", "### Bug Fixes", "### Refactors", or "### Docs". Length. The body orients a reviewer before they read the diff; it does not replace the diff. Scale it to the number of distinct concerns a reviewer must hold in their head, not to the size of the diff — a large but mechanical change still gets a short body. Aim for 200 words outside "## Verification" and treat 400 as a hard ceiling. Give each concern one paragraph at most, and give a secondary concern a single sentence rather than a paragraph or a section of its own. Name the mechanism and the reason for it, then stop: do not walk through every case, branch, fallback, or deleted helper the implementation handles, and do not explain why a rejected alternative was rejected more than once — the diff carries that detail for the reader who wants it. If a sentence is true but would not change what the reviewer does, cut it. Sections. Scale the structure the same way. A PR with a single concern and a small diff gets two or three sentences of prose and no headings at all — do not pad it into sections. A PR with one substantial concern gets "## Overview" (or "## Problem", when the PR fixes something that was broken) followed by "## Change" (or "## Fix"). A PR spanning several distinct concerns gets the full set in this order: "## Overview" or "## Problem", then "## Change" or "## Fix", then "## How it works" only when the mechanism is non-obvious and the diff shows why, and then in a single paragraph, then "## Deployment" only when the diff shows that merging alone does not ship the change (deployment manifests, pinned image tags, infrastructure config, release assets), then "## Sequencing" only when the commit log or existing PR context shows this branch depends on or blocks another. Never add a catch-all section for whatever the other sections did not cover. Omit every section you have nothing concrete to put in; an empty or restated section is worse than no section. Inside a section, use bullets only for genuinely parallel items and prefer prose for anything with cause and effect. Voice. Lead with the cause, not a restatement of the diff: open by naming what was broken, missing, or needed and why, then what the PR does about it. Name code directly — files, functions, classes, flags, and config keys in backticks — wherever naming it explains the change better than a paraphrase would; never include line numbers, and never name a file, symbol, or call site that the provided diff and commit log do not evidence. Be concrete: counts, versions, dates, and durations that the context actually shows are worth stating, but never invent a number, a measurement, a production impact, or an observed behavior you cannot derive from the context you were given. State what the PR deliberately does not change when a reader would otherwise assume it does. When the diff or commit messages show an alternative was tried and rejected, say what it was and why it failed in a single sentence. When the change makes a trade-off, name it plainly instead of hiding it. Write flatly: no marketing adjectives, no "seamlessly", "robust", "comprehensive", "significantly improved", or "greatly enhances", and no closing sentence that just restates the section above it. Verification. Close the body with a "## Verification" section giving the concrete steps a reviewer can run to confirm the change works: real commands for this repo — its test runner, linters, build commands, or CLI invocations — using the actual paths, flags, and file names the diff shows, in a fenced bash code block when they are commands and a short numbered list when they are manual or UI steps. Keep it to the smallest set of steps that actually proves the change, and say what a passing result looks like. When this PR adds tests, point the reviewer at them by name in the same breath rather than describing what each one covers. When a step creates disposable or billable resources, include the cleanup command. Never claim you ran anything, that tests pass, or that any check is currently green — you have executed nothing; write only what the reviewer should do and what they should expect to see. If the context gives you nothing specific enough to be worth running, omit the section entirely rather than padding it with generic advice. On a PR small enough to carry no headings, fold the check into a closing sentence instead of a section. A <repo_guidance> block may precede the other context with repo-specific conventions — commit scopes this repo uses and overrides to the type-classification rules above; treat it as authoritative and apply its scopes and overrides when it conflicts with the rules above. Output ONLY the title and body, wrapped in exact line markers: a line containing exactly ===TITLE===, then the title on its own line, then a line containing exactly ===BODY===, then the body on the following lines. Write nothing before the ===TITLE=== marker and nothing outside these markers — no commentary, reasoning, character counts, or notes. These two markers are the only ones that exist: the body simply ends the response, so never emit a closing marker such as ===END===. Do not wrap the response as a whole, or the title line, in a code block or backticks — fenced code blocks inside the body are content and are expected wherever you give the reader commands to run.