conventional-commit（常规提交）

Create a git commit for the current changes using the Conventional Commits standard.

Context

Based on the conversation, determine what context is relevant for the commit message. If the user provided specific guidance about what to commit or the commit message, use that. Otherwise, analyze the changes to determine an appropriate commit message.

Process

1. Analyze the changes by running:

- git status to see all modified/untracked files - git diff to see unstaged changes - git diff --staged to see already-staged changes - git log --oneline -5 to see recent commit style

1. Stage appropriate files:

- Stage all related changes with git add - Do NOT stage files that appear to contain secrets (.env, credentials, API keys, tokens) - If you detect potential secrets, warn the user and skip those files

1. Determine the commit type based on the changes:

- feat: New feature or capability - fix: Bug fix - docs: Documentation only - style: Formatting, whitespace (not CSS) - refactor: Code restructuring without behavior change - perf: Performance improvement - test: Adding or updating tests - build: Build system or dependencies - ci: CI/CD configuration - chore: Maintenance tasks, tooling, config

1. Determine the scope (optional):

- Use a short identifier for the affected area: feat(parser):, fix(api): - Omit scope if changes are broad or scope is unclear

1. Write the commit message:

- Subject line: <type>[optional scope]: <description> - Use imperative mood ("add" not "added") - Lowercase, no period at end - Max 50 characters if possible, 72 hard limit - Body (if needed): Explain *why*, not *what* - Wrap at 72 characters - Separate from subject with blank line

Commit Format

<type>[scope]: <subject>

[optional body explaining WHY this change was made]

Examples

Simple change:

fix(parser): handle empty input without throwing

With body:

feat(api): add streaming response support

Large responses were causing memory issues in production.
Streaming allows processing chunks incrementally.

Rules

• NEVER commit files that may contain secrets
• NEVER use git commit --amend unless the user explicitly requests it
• NEVER use --no-verify to skip hooks
• If the pre-commit hook fails, fix the issues and create a NEW commit
• If there are no changes to commit, inform the user and stop
• Use a HEREDOC to pass the commit message to ensure proper formatting

Execute

Run the git commands to analyze, stage, and commit the changes now.