An existing PR title and body are provided in <existing_pr>, along with an auto-generated draft in <draft> (grouped from conventional commit messages) a list of changed files in <changed_files>, and the available patch in <diff>. Update the PR title and body to reflect new commits. <draft>, <changed_files>, and <diff> cover only the commits added since <existing_pr> was written — they are a slice of the branch, not its current state. The rest of the branch is still present but is not shown to you, so <existing_pr> is the only record of it: never delete, narrow, or rewrite existing content on the grounds that <draft> does not mention it. Carry all of it forward and extend it with the new commits. Use <diff> to verify the draft and identify compatibility changes missing from commit messages. Large generated lockfile patches may be listed in <changed_files> but omitted from <diff>; do not infer their contents. PRESERVATION RULES. Treat <existing_pr> as authoritative for all content it covers. Copy it verbatim — same wording, punctuation, capitalization, bullet order, section order, and section headers. Stylistic rewording is forbidden; factual correction from new commits is required. Title — rewrite ONLY if new commits change the Conventional Commits type or scope, OR if the title's claim is now inaccurate (e.g. the feature was renamed, narrowed, or reverted in new commits). Otherwise leave byte-identical. Existing prose and bullets — rewrite ONLY if a new commit invalidates the claim (e.g. a later commit changes the described behavior). Remove ONLY if the change was fully reverted. Otherwise leave byte-identical — do NOT adjust phrasing, tense, punctuation (periods, dashes, em-dashes, commas), or capitalization. Section headers and section order — never change; in particular, do not restructure an existing body to match the section scheme described below, and do not add headings to an existing body that has none. Adding new content — extend the existing section that covers the same concern, appending to the end of it. Do not interleave with or reorder existing content. Add a new section only if new commits introduce a concern no existing section covers. Intra-branch refinements — entries under a "### Intra-branch refinements" section in the draft (and any other new commit that fixes/refactors code introduced earlier in this same branch) refine existing work; prefer correcting the existing description in place (if its claim is now wrong) over adding new content, and never emit them as a standalone section. Do not list the refinement itself. If uncertain whether a change is warranted, prefer no change. Write a polished PR title in Conventional Commits format (feat:, fix:, refactor:, build:, chore:, docs:, style:, test:, perf:, ci:) on a single line and a refined body. Keep the title on one line and at most 70 characters including the type prefix — this is a hard limit, not a target. Count the characters before you answer; if the title is over, rewrite it shorter rather than emitting it. Name the single most significant outcome the PR delivers and leave every other detail for the body — never join two changes with "and" to fit them both in the title. Write the title from the repo's user POV (<repo_guidance> when present, otherwise who consumes what this repo produces): for a user-facing change, state in plain language what users can now do, see, or no longer hit (for example, "stop cutting off long chat answers" or "keep active plan from carrying over when switching chats"), naming the user-visible surface, command, or setting when it disambiguates where the change applies. Never put internal jargon, file paths, function or class names, state keys, or config keys in the title unless that identifier is itself the user-facing interface that changed (say "stop cutting off long chat answers", not "remove `max_tokens` cap"), and never fall back to vague filler like "improve X behavior" or "update Y handling" — name the concrete behavior change. If a new capability is switched off by default or has no user-facing surface wired yet, do not claim live user behavior changed; when the PR has no user-visible effect (refactor, test, build, ci, chore), state the concrete operational or maintainer-visible outcome plainly (for example, "build backend images from locked dependencies") rather than listing edited files or internal steps. When you do change the type, choose it 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. Independently of the title type, inspect <diff> for compatibility changes; commit subjects and <draft> can omit them. Check removed or renamed documented commands, agent or plugin names, config keys, environment variables, public API arguments, and machine-readable output fields. A replacement with similar functionality does not preserve compatibility unless the old interface still works (for example, through an alias). Internal helper changes and additive optional fields alone are not breaking changes. When the context shows an incompatible user-facing change, mark its change label with `(breaking)`, for example `- **Form and tracker updates (breaking):** ...`, and explain the old interface, its replacement or removal, and the migration users need in that same item. On a small PR without a Changes list, put `(breaking)` beside the affected change in prose; do not add sections solely for the marker. If any change is marked `(breaking)`, automatically add exactly one `!` immediately before the title's colon, after any scope: `feat!:`, `feat(ui)!:`, or `fix!:`. Keep the type selected above; a breaking fix does not become a feature. Without breaking changes, use the ordinary prefix. Do not mark a change breaking when context establishes that the interface was introduced after the last tag and never shipped, or that compatibility is preserved. A version tag alone does not establish when an interface shipped; unknown release history does not cancel an evidenced incompatibility. If incompatibility itself is uncertain, explain the concrete uncertainty alongside the change without a `(breaking)` marker or `!` solely for that uncertainty. Do not emit a generic compatibility-warning blockquote. For updates, retain existing breaking labels and the title's `!` when the supplied diff does not cover that earlier work; remove them only when supplied context establishes that the incompatibility is gone or was misclassified. These compatibility annotations and title corrections are required even when existing wording would otherwise be preserved. Replace legacy generic compatibility-warning blockquotes with the supported change-specific annotations, preserving any concrete unresolved concern in prose. Keep the existing body's shape — its sections, their order, and whether it has headings at all. Focus on the net, final effect of the PR relative to the base branch. The structure, voice, and verification rules that follow govern only content you add; they never license restructuring or restyling what <existing_pr> already covers. 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. Inside a section, 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. When a PR ships user-facing changes, do not give internal plumbing (refactors, helper renames, test additions, CI tweaks, or dependency bumps without a behavior change) its own bullet or paragraph; mention an internal change only when a reviewer or operator would act on it or notice it operationally (such as schema migrations, where images or assets come from, or how the app builds, loads, or deploys). Sections. Scale the structure the same way. A PR with a single concern and a small diff gets no headings at all — do not pad it into sections — and stays under 60 words across one to three short sentences: when a single sentence is not enough, put a blank line between the sentence stating the problem or outcome and the sentence stating what changed so they never run together into one dense paragraph, and do not catalogue every touched path or rule the short diff already shows at a glance. 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. Match each heading's number to what it covers: use "## Change", "## Fix", or "## Problem" when the section covers exactly one, and "## Changes", "## Fixes", or "## Problems" when the section covers several distinct ones. 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. Frame the body from the repo's user POV (<repo_guidance> when present, otherwise who consumes what this repo produces). Lead with the user-facing or operational effect in plain language, not code internals or a restatement of the diff: open by stating what users can now do, see, or no longer hit and why (for example, "Switching between chat sessions no longer carries over an active plan or lets an older session overwrite the one you opened" or "Chat answers no longer get cut off", rather than opening with "`useSessionSwitch` resets `planSlice`" or "`max_tokens` cap removed"). Follow that plain-language outcome with the essential technical cause or mechanism so important information is not lost — the root cause, key architectural or config detail, migration, or compatibility impact — naming files, functions, classes, flags, and config keys in backticks where they anchor the explanation for a reviewer rather than replacing the plain-language description; never include line numbers, and never name a file, symbol, or call site that the provided diff and commit log do not evidence. When several files or layers change to deliver one user-visible outcome (for example, a component change and the page that wires it up), describe that single outcome once rather than splitting it by file. Before calling a change user-facing, check in the supplied context that it is active by default and wired to a user-visible surface; if a capability is behind an off-by-default flag or has no UI or caller wired yet, state plainly that it is not yet active by default. 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 steps a reviewer takes to see the changed behavior work for themselves — the evidence CI cannot give them. Every step runs the product rather than checking it: invoke the CLI command, send the request, or walk the UI flow this diff changes, with a concrete input built from the actual commands, flags, paths, and file names the diff shows, and state the specific output or resulting state the reviewer should observe. Never list the test suite, linters, type checkers, formatters, or build commands, and never tell the reviewer to run the tests this PR adds — CI runs those and the author already knows their result. Use a fenced bash code block for commands and a short numbered list for manual or UI steps. Keep it to the smallest set of steps that proves the change, usually one to three. 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 change has no behavior a reviewer can exercise outside the test suite — a pure refactor, a test-only, CI-only, or docs-only change — or the context gives you nothing specific enough to run, omit the section entirely rather than padding it with generic advice or a test command. On a PR small enough to carry no headings, put the check in a closing one-sentence paragraph separated by a blank line instead of a "## Verification" 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.
