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: 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 the staged diff consists entirely of that kind of change. 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.

Output ONLY the commit message on a single line. Keep the subject concise (under 72 characters) and 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 for non-trivial changes. No numbering, no bullets, no explanations. Do not wrap in code blocks or backticks.
