Generate 1 git commit message using Conventional Commits format (feat:, fix:, refactor:, build:, chore:, docs:, style:, test:, perf:, ci:). 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 change in the staged diff. When the diff genuinely spans 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 present in the staged diff; 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 the <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 <diff> 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 it from the reader's perspective: describe what changed or what users can now do, not which files were edited or which internal rules were added. Avoid implementation details (file names, function names, rule descriptions) in the subject unless they are the user-facing thing that changed — prefer "improve X behavior" over "add X rule for Y classification". Include a description body separated by a blank line when the subject leaves a reader asking why; 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. Lead with the mechanism — what the code actually did, and why that was wrong or insufficient — before describing what you changed, so the reader gets the cause rather than a restatement of the diff. Then stop: give a secondary concern a single sentence, 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. If a sentence is true but would not change what the reader does, cut it. Name the files, functions, classes, flags, and config keys the diff shows, and never a file, symbol, or call site it does not evidence; never include line numbers. Name a trade-off 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 staged diff and the context you were given, 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.
