yy-commit

yy-commit

Description

Help users create standardized Git commits, generate commit messages that conform to project-specific conventions or generate Chinese commit messages that conform to the Conventional Commits specification.

Use cases

The user says "commit code", "commit", "create a commit"
The user says "commit this", "make a commit"
The user says "save the completed changes and commit"
The user needs to commit after completing a feature or fix
The user says "commit src/a.ts src/b.ts", "commit the src/ directory" (specifying specific files/directories)
The user says "commit all files", "commit everything" (semantically equivalent to committing all changes)

Should not trigger:

The user only wants to stage files or run git add
The user is only viewing git status or history
The user requests other operations such as git push, pull, merge
The user requests modifying code or implementing features

Instructions

Step 1. Analyze the current state and run mode

Parameter parsing

Detect whether the user specified file/directory paths when invoking (such as "commit src/a.ts src/b.ts", "commit the src/ directory", "commit all changes").

Decision branches：

The user specified file/directory paths(including semantically equivalent expressions such as "all files", "every file"): mark asuser-specified commit scope mode, run the commands below only for the specified paths; skip Step 2 (do not judge atomicity, do not delineate groups), directly use the specified files as the commit scope, and proceed to Step 3
The user did not specify file/directory paths: keep the regular flow, run the commands below for all changes, and then proceed to Step 2

Run the following commands in parallel (when the user specifies files/directories,git diff and git diff --staged only for the specified paths):

git status
git diff
git diff --staged
git log --oneline -5

git status output interpretation rules：

Changes not staged for commit + modified: lines starting with → there are modified files, need to commit
Untracked files: + filename → there are new files, need to commit
Changes to be committed: + filename → there are staged files, need to commit
nothing to commit, working tree clean → no changes, inform the user and terminate the flow
no changes added to commit → only indicates the staging area is empty, does not mean there are no changes; must be judged in combination with the above items

Collect the following information for use in subsequent steps:

Which files have been modified
The specific content of the changes
Whether there is currently staged content（git diff --staged when non-empty, record the list of staged files, for the side-effect warning in Step 4)
Recent commit records (used in Step 3 to infer the project's commit style)

Quick commit mode determination: determine once in this step whether to enable quick mode, to avoid repeated judgment in subsequent steps.

The user's request contains explicit expressions such as "commit directly", "commit immediately", "commit right away", "no confirmation needed", "no need to confirm", "skip confirmation", "direct commit" → mark as quick commit mode
User expressions that are not within the above keywords but are semantically equivalent (such as "stop asking me" or "go ahead") → also mark as quick commit mode
Other cases → normal mode

Step 2. Understand the changes and define the commit scope

Prerequisite: perform this step only when no user-specified files/directories were detected in step 1. If the user has already specified the commit scope, skip this step and go directly to step 3.

2.1 Understand the intent of the changes

Understand the purpose of this commit by combining the following information:

Code change analysis: identify new features, bug fixes, optimization refactors, documentation updates, etc. from the diff
Conversation context: extract the features the user wants to implement, the problems mentioned, or the requirements
Change scope: determine the affected modules or functional areas
Deep understanding: understand not only "what was done" but also "why it was done this way"

Change ownership and scope rules：

Use the current git status、git diff and git diff --staged as the complete source of truth for the commit scope; staged, unstaged, and untracked changes all belong to the user by default
Conversation context is only used to understand the intent of the changes and generate the commit message, and must not be used to exclude, override, or revert changes in the workspace that are not mentioned in the conversation
When a change cannot be mapped to a conversation requirement, show it and ask the user how to group it; it must not be treated as an extraneous change or skipped during re-staging
Each finally selected file is staged with its complete current content; it is not permitted to keep only the code blocks related to the conversation requirements or automatically restore the remaining code blocks

2.2 Define the commit grouping for this commit

Use atomicity as the primary criterion to determine whether all changes are suitable to be committed at once.

This skill processes only one atomic unit of commits at a time. If it is not suitable to commit all at once, tell the user which changes are suitable as groups, and let the user choose from the following options:

Select a single group to commit (single choice)
Force committing all changes at once
Automatic group commit (commit each group separately)

Option handling rules：

Select a single group: use the selected group as the commit scope and go to step 3
Force committing all at once: use all changes as the commit scope and go to step 3
Automatic group commit: enter the loop process, executing steps 3-5 in sequence for each group until all groups are committed

Atomicity criteria：

Core criterion: whether a commit constitutes a single atomic logical unit—all changes revolve around the same intent and share the same rollback boundary, and removing any part individually does not affect the workability of the remaining parts
If it is still unclear how to group them according to the core criterion, refer to resources/atomicity-criteria.md for specific reference signals to determine the grouping

Step 3. Generate the commit message

Determine the commit message generation specification：

The project has defined a commit specification(declared in AGENTS.md, README, or other explicit rules): the project's agreed specification must be used first
The project has not defined a commit specification: usethe customized Conventional Commits specification

Complex changes provide candidate options:

When a single change involves multiple dimensions (such as including both new features and refactoring), or the intent of the change can be described from different angles, provide 2 candidate commit messages for the user to choose from, helping the user find the most accurate expression. For simple changes (clear intent, single change), only 1 needs to be generated.

Candidate option display and selection interaction：

In the candidate list, provide two exits: "Regenerate" and "Fill in commit message manually"
After the user selects a candidate, proceed to the final confirmation in step 4; when the user selects "Regenerate", return to this step to regenerate candidates; when the user selects "Fill in commit message manually", directly collect the user's input and skip to step 4
Quick commit mode (already determined in step 1): directly generate 1 candidate and proceed to step 4 for display, skipping the candidate display and selection interaction

Step 4. Display and confirm

Display to the user:

Staging area side-effect warning(only when step 1 detects that git diff --staged is non-empty, and the staging scope of this commit is inconsistent with the existing staged content): clearly inform the user that "before executing the commit, git reset HEAD will first rebuild the staging area, then re-stage according to the current complete contents of the following files; this operation will not restore the workspace files", and wait for the user's explicit consent before the user confirms
The list of files to be staged, confirming that it includes all manual changes the user requested to commit
Sensitive file warning (such as if files with sensitive naming characteristics exist in the staging list, see resources/sensitive-file-patterns.md; newly added files trigger a mandatory block; modified/deleted files only warn)
Key change summary (main changes extracted from the diff)
The generated complete commit message (including body)
Main branch protection reminder(when step 1 detects that git status output contains On branch main or On branch master , always execute): remind the user that they are currently on the main branch and recommend working on a feature branch

Limitations of quick commit mode:

The main branch reminder is not affected by quick commit mode and is always executed
Staging area side effect mandatory block: when step 1 detects existing staged content and it is inconsistent with the scope of this commit, even if quick commit mode is triggered, the process must stop and fall back to regular confirmation
Newly added sensitive file mandatory block: when newly added files with sensitive naming characteristics exist in the staging list, even if quick commit mode is triggered, the process must stop and fall back to regular confirmation; the user must explicitly exempt the file or remove it from the staging list before continuing
Modified/deleted sensitive file warning: when modified or deleted files with sensitive naming characteristics exist in the staging list, display a warning but do not block the process

Regular mode: Display confirmation options to the user as a numbered list

1. 确认提交
0. 取消提交

User selection handling：

Select 1: proceed to step 5 to execute the commit
Select 0: terminate this commit process and output "Cancelled"
User expresses modification feedback: regenerate according to the "Commit Message Modification Rules", return to step 4, and display the confirmation options again
User directly provides the complete commit message: use the content provided by the user as authoritative, return to step 4 to display and wait for final confirmation
The user's reply content intent is unclear(neither confirming/canceling a number, nor a recognizable modification suggestion or complete commit information): proactively ask specifically what they are dissatisfied with, and guide the user to express the direction of modification

Rules for modifying commit information:

By default, treat user feedback as a correction to the semantics after the colon description and do not require the user to manually rewrite the prefix
Based on the new description, code changes, conversation context, and project conventions, re-evaluate whether the prefix matches; handle according to the following priority:
- The project has fixed prefix conventions: the prefix must be adapted to the project conventions first (such as 功能:、重构:、文档:）
- The project has no fixed conventions and the current prefix matches the nature of the change: keep the prefix, only adjust the description
- The project has no fixed conventions but the prefix does not match the nature of the change: automatically re-derive type/scope
The user only points out vague feedback such as "the title is inappropriate", "this is not a fix", "this is actually a requirement" → treat this as allowing the AI to automatically recalculate the prefix based on the real changes
Only when the user explicitly specifies the prefix type should that prefix be kept as a hard constraint
If the commit message contains a body (the default case), prioritize keeping the body and only update the parts directly affected by user feedback
Only when the user explicitly requests regenerating the entire commit message should the complete commit message be regenerated

Display format (when the project uses Chinese prefix conventions, replace the examples' feat(auth): with the corresponding Chinese prefix, such as 功能:）：

即将提交以下更改：

⚠️ 检测到当前暂存区已有改动，提交前将先清空暂存区，仅保留以下文件（仅在副作用场景出现）

📝 暂存文件：
  - src/auth/login.ts
  - src/components/LoginForm.vue
  - vite.config.ts

⚠️ 敏感文件警告：
  - [新增] .env（环境变量文件）
  - [修改] config/credentials.json（凭据文件）

📊 主要变更：
  - 新增 JWT token 生成逻辑
  - 添加登录表单验证
  - 调整 vite 构建别名以支持新模块

💬 提交信息：
feat(auth): 添加 JWT 用户认证功能

- 新增 JWT token 生成逻辑
- 添加登录表单验证
- 补充登录失败场景的错误提示

⚠️ 当前位于 main 分支，建议在功能分支工作。

是否确认提交？

Step 5. Execute commit

After the user confirms, execute in order (cannot be parallel).

# 1. 清空暂存区，重建最终选定的暂存内容；不会修改工作区文件
git reset HEAD

# 2. 按当前完整内容暂存选定的文件，不得根据对话上下文筛除代码块
git add <file1> <file2> ...

# 3. 创建提交
# 默认：title + body
git commit -m "<title>" -m "<body>"

# 仅 title
git commit -m "<title>"

Commit command constraints:

The commit message must be passed using the -m parameter; heredoc (cat <<'EOF'）、here-string（@'...'@) or other shell-specific syntax is prohibited
For multi-line commit messages, use multiple -m parameters:git commit -m "<title>" -m "<body line 1>" -m "<body line 2>", this syntax is compatible in mainstream shells such as bash, pwsh, zsh, etc.
Handling quotes and special characters in the commit message: prefer usingsingle quotesto wrap the -m parameter value (-m '<title>'), to prevent the shell from performing variable expansion or command substitution on characters such as $、`、\ ; if the message contains single quotes, switch to wrapping with double quotes and apply backslash escaping to $、`、\、" Escape backslashes
after constructing the git commit command, confirm that each -m parameter value in the command is complete and not truncated before executing

Prohibited items:

It is prohibited to add signatures or notes such as Co-Authored-By: and other attribution notes
It is prohibited to use heredoc, here-string, or other shell-specific syntax to pass the commit message; the -m parameter must be used

Step 6. Verify the commit result

After committing, immediately verify whether the commit message was written completely, and immediately fix any truncation found.

Run the following command to get the actual committed message:
```
git log -1 --format="%H%n%s%n%b"
```
Compare the actual message with the expected title and body word by word:
- Check whether the title is complete and not truncated after the colon or elsewhere
- Check whether the body is complete and whether each line's content is complete

If truncation or inconsistency is found, use git commit --amend to fix:

git commit --amend -m "<title>" -m "<body line 1>" -m "<body line 2>"

After fixing, run again git log -1 --format="%H%n%s%n%b" Confirm the message is complete
Display the final commit message in the output

Validation rules:

Must compare word by word; do not only check the length or part of the content
If truncation is found, it must be fixed; do not skip it
After fixing, it must be verified again until completeness is confirmed

Step 7. Output the result

Output the commit result, including:

List of committed files
Commit message
Commit hash

A reference example of the output is as follows:

✓ 提交成功

提交文件：
  - skills/yy-create-rule/SKILL.md
  - skills/yy-create-rule/resources/rule-best-practices.md

提交哈希：7660360

提交信息：refactor(yy-create-rule): 添加规则内容通用性约束

变更统计：2 files changed, 2 insertions(+)

Special case handling

No changes

If git status shows no changes, inform the user:

当前工作区没有未提交的变更。

如果你期望有变更，可能的原因：
- 文件尚未保存
- 变更已经在之前的提交中
- .gitignore 忽略了这些文件

Conflicts or unpushed commits

In step 1, when parsing git status output, identify the following signals and alert the user:

Merge conflict: if the status contains the UU、AA、DD、AU、UA、DU、UD marker files → remind the user to resolve the conflict before committing
Unpushed local commits: if the status contains Your branch is ahead of 'origin/...' by N commit(s) → only indicate that unpushed commits exist; do not block this commit
Local branch behind remote: if the status contains Your branch is behind 'origin/...' → only indicate it; do not block this commit

Safety boundaries

Prohibited actions:

Skipping hooks: do not use --no-verify and other flags
Force operations: do not use --force or --amend(unless the user explicitly requests it, or it is part of the automatic fix in the step 6 validation process)
Adding attribution: do not add Co-Authored-By: and other attribution notes
Reverting user changes: do not use git restore、git checkout --、git clean or patches to overwrite workspace files just because a change was not mentioned in the conversation

Main branch protection:

When currently on the main/master branch, remind the user to consider working on a feature branch; do not add extra confirmation interactions that block the commit process

Excluding source authority:

Use .gitignore as the authoritative exclusion source; do not add a secondary blacklist on top of it
Files that are not ignored are considered allowed to commit; for files with sensitive naming characteristics, always display a warning
Adding new sensitive files triggers a mandatory block; modifying/deleting sensitive files only warns and does not block

Best practices

The commit message should answer \"what this commit does and why it was done\"
Prioritize explaining the purpose/reason for the change, not just describing the change itself
Keep the commit message precise: small changes should have specific descriptions; avoid being too broad
Take user feedback seriously: if the user thinks the commit message is not good enough, adjust and optimize it immediately
Prioritize using conversation context to understand the true intent
When the intent of the change is unclear, ask the user
Keep commits small and focused
Use meaningful scopes to help locate things quickly
When the commit message involves specific file names, the original file names must be preserved and not translated

Path format conventions

When mentioning file paths in documentation, prefer relative paths
When mentioning file paths in the terminal, prefer absolute paths
Use forward slashes as path separators, and wrap paths in quotes when they contain spaces