Git Auto-Commit Specification

Decision Order and Priority

1. Submit only when explicitly requested by the user: Do not actively commit or push unless requested.
2. Order with changeset: If the user requests both "add changeset + commit" in the same request, the changeset file must be generated first, then this skill is executed (to ensure the changeset is included in the commit).
3. Security first: Before committing, the staged content must be checked to avoid submitting sensitive information such as keys, tokens, private keys, etc. to the repository; if suspected sensitive information is found, stop first and prompt the user to handle it.

Commit Process

1. Execute

   git status

   to view current changes
2. Execute

   git add .

   to stage files (by default, commit all changed files unless the user specifies otherwise)
3. Execute

   git diff --cached --name-only

   to get the list of key changed files that have been staged
4. Generate a standardized commit message after viewing the content of key changed files via git commands (avoid guessing out of thin air)
5. Execute

   git commit -m "<message>"

   to commit
6. Execute

   git push

   to push to the remote repository (default behavior, unless the user explicitly says "don't push" or "no push")

Push Rules

• Default push: Automatically execute

  git push

  after commit is completed
• Skip push: Skip the push step only when the user explicitly expresses intentions such as "don't push", "no push", "only commit", etc.
• Push failure handling: If push fails, prompt the user for possible reasons (such as needing to pull first, no remote branch, etc.)

Commit Message Specification

Priority of Specification Sources

1. Prioritize reading the

   .commitlintrc.xx

   configuration file in the project root directory
   • If the configuration file exists, strictly follow the specifications defined in it
   • Read the list of available commit types and corresponding emojis
   • Read the allowed values of scope and other commit rules
2. If there is no

   .commitlintrc.xx

   configuration file
   • Refer to the default specification in commit-message-convention.md
   • Use the standard conventional commits format

Output Requirements (Must Be Met)

1. Traceable commit information: The message must match the staged change content; inconsistency with actual changes is not allowed
2. Minimal disturbance: Commit all changes by default; if the user only wants to submit some files, stage them according to the user-specified scope
3. Follow repository specifications: Strictly follow the commitlint configuration if it exists; otherwise, generate according to the default specification

Usage Scenarios

1. User requests to submit code
2. Need to save changes after task completion
3. Need to generate a standardized commit message