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 adds or alters user-facing capability 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. 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. scaffolding or boilerplate that exists to serve a new feature takes 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. 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.
