Generate 1 git commit message from the staged files in <changed_files> and their available content in <diff>, using Conventional Commits format (feat:, fix:, refactor:, build:, chore:, docs:, style:, test:, perf:, ci:). Large generated lockfile patches may be listed in <changed_files> but omitted from <diff>; still describe the change conservatively from the filename and other supplied context. Never use !. Breaking changes are assessed at the PR level, not per commit.

Choosing the type: first frame the repo's user POV — who consumes what this repo produces and what they perceive as its output — then judge each change by its impact on that audience, because "user-facing" is defined by that POV and the same edit can warrant different types in different repos (bumping a deployed image tag is chore to an app's users while shipping a brand-new app is feat; in a repo whose product is an automated code review, restyling the review summary is style while a new notification path the reviewer never sees is ci or build). A <repo_guidance> block, when present, states this POV — defer to it. The prefix reflects the most significant staged change. When the staged changes genuinely span several types, pick the one highest in this precedence — feat > fix > perf > refactor > test > build > ci > docs > style > chore. A change that introduces a new user-facing capability or meaningfully extends an existing one is feat even if it also refactors code, adds tests, or updates docs; a bug fix is fix even if it ships with tests or docs. Cosmetic, wording, or layout tweaks to existing UI elements — spacing, sizing, label text, color — that do not add new capability are style (or fix if correcting an error). Only use test, build, ci, docs, style, or chore when no feat, fix, perf, or refactor change is staged; among those lower types pick by the precedence above. Restructuring, renaming, or rewriting confined entirely to test files is test, not refactor — refactor applies only to non-test code; likewise restructuring confined to build, ci, or docs files keeps that file kind's prefix. A script or other helper whose sole role is to run inside the build, CI, or release pipeline — invoked by a pipeline job rather than shipped or executed as part of the product — takes that pipeline's prefix (build or ci), even when it is executable code carrying its own tests; classify such tooling by the pipeline that consumes it, not by the fact that it is runnable code. Adding pipeline-only tooling is ci or build, never feat. Touched, generated, or regenerated documentation or other derived files alongside real code or test changes never make a commit docs or chore — the prefix must reflect the code or test change. Classify by a file's role, not its format: prompt, template, schema, query, and config files are functional code even when written in prose, plain text, markdown, or data formats — editing one to change program behavior is feat, fix, refactor, or perf as appropriate. docs applies only to human-facing documentation (README, guides, code comments, changelogs). Do not downgrade a substantive code change to docs or chore because a related change already appears earlier on the branch.

A <branch>, <branch_commits>, and/or <branch_diffstat> block may precede <changed_files> and <diff> to describe the overall purpose of the branch this commit belongs to. Use that branch context ONLY to disambiguate the prefix when the staged context alone is ambiguous — e.g. new files or infrastructure that exist solely to wire up a brand-new feature take feat. Follow-up commits that refine, fix, tweak, or polish code already introduced earlier in this branch keep their natural type (fix:, refactor:, style:, perf:) — the branch context does not promote them to feat:. Do NOT force the prefix to match the branch's dominant type: a test, refactor, chore, or ci change keeps its own prefix even on a feature branch. The subject must always describe THIS commit's staged changes, not the branch as a whole.

A <repo_guidance> block may precede the other context. It holds repo-specific conventions — commit scopes this repo uses and overrides to the type-classification rules above. Treat it as authoritative: when it conflicts with the default heuristics in this prompt, the repo guidance wins. If it defines scopes, apply the single most fitting one as a Conventional Commits scope, e.g. feat(scope): — never invent a scope it does not list.

Wrap your answer in the exact line marker shown below. Emit NOTHING before the ===COMMIT=== line — no preamble, no restatement of the diff, no explanation of which type you picked or why. Any reasoning you do stays out of the output entirely. ===COMMIT=== is the only marker that exists: the message simply ends the response, so never emit a closing marker such as ===END===.

===COMMIT===
<subject line>

<optional body>

Keep the subject 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 subject is over, rewrite it shorter rather than emitting it. Name the single most significant change and move every other detail to the body — never join two changes with "and" to fit them both in the subject. Write the subject 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 subject 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 commit 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. Include a description body separated by a blank line when the subject leaves a reader asking why, how it affects them, or what else changed; omit it when the subject already says everything there is to say. Keep the body short: aim for 60 words and treat 120 as a hard ceiling, scaled to the number of distinct concerns a reader must hold in their head rather than to the size of the diff — a large but mechanical change still gets one or two sentences. Open with the user-facing or operational impact in plain language — what users or operators experienced, could not do, or can now do, and why (for example, "Tools shared across skills were counted once per skill in connected MCP server totals" or "Delegated subagents failed to authenticate against connected data tools because user credentials were not forwarded"). Follow with the essential technical cause or mechanism so important context is not lost: name the specific files, functions, classes, flags, config keys, or migration details (in backticks, evidenced by the supplied context; never include line numbers) that explain why the issue happened or what a developer or operator needs to know, without letting internal identifiers replace the plain-language explanation. Then stop: give a secondary concern a single plain-language sentence stating its user-facing or operational effect, and do not walk through every case, branch, fallback, renamed helper, or touched file the implementation covers — the diff carries that for the reader who wants it. Drop internal-only churn (helper renames, test additions, formatting) when it ships alongside a user-facing change unless a reader would act on it operationally. If a sentence is true but would not change what the reader understands or does, cut it. Name a trade-off, an off-by-default flag, or a deliberate non-change only where a reader would otherwise get it wrong. Never invent a number, a measurement, a test result, a production impact, or an observed behavior — you have executed nothing and can see only the supplied context, so a count, version, date, or duration is worth stating only when that context actually shows it. Write flatly, as plain prose paragraphs separated by blank lines, hard-wrapped at 72 characters: no marketing adjectives, no numbering, no bullets, no markdown headings, and no meta-commentary about the commit itself. Backticks around a code reference are fine; do not wrap the message as a whole, or the subject line, in a code block or backticks.
