commit
GitHub指导在 Storage Redirect X 项目中准备、审查和创建 Git 提交。涵盖验证变更、运行检查、排除无关文件、遵循提交规范及独立格式化 Rust 代码,确保原子性提交。
Trigger Scenarios
Install
npx skills add Kindness-Kismet/Storage-redirection-X-Public --skill commit -g -y
SKILL.md
Frontmatter
{
"name": "commit",
"description": "Prepare, review, and create Git commits for Storage Redirect X. Use when the user requests a commit, a commit message, or an amendment, and before any assistant-initiated git commit, including --amend. Pushing requires separate explicit approval."
}
Local Commits
Create an atomic commit promptly after each independently working requirement passes its necessary checks. Include only changes belonging to that requirement and follow AGENTS.md.
Workflow
- Confirm the repository, current branch, upstream, and worktree with
git status --short --branch. Inspect staged and unstaged changes separately. Do not switch branches or absorb unrelated changes. - Verify the final behavior using the checks appropriate to the changed paths. Run clippy for
srx_core/changes andlintDebugforandroid/changes. Do not create test files by default; run existing checks where relevant. - Check each new path with
git check-ignore --no-index -v <path>. A final negated pattern permits tracking; a positive pattern excludes it. Keep build artifacts, credentials, and local plans or records out of the index. Do not bypass the allowlist withgit add -f. - Stage explicit paths with
git add -- <path>. To stop tracking an authorized file, confirm its absolute path and usegit rm --cached -- <path>so its local copy remains intact. Never use broad staging commands. - Review
git diff --cached --checkand the completegit diff --cached. Confirm scope, required build inputs, license notices, and actual verification results before committing. Do not commit incomplete work or claim failed checks passed. - Review the message against the rules below, then execute
git commit. Apply the same review before--amend. - Verify the saved message with
git log -1 --format=%Band inspectgit status --short --branch. - Complete the Rust formatting phase below before finishing. If the worktree was already clean at entry, skip creating a task commit and start that phase directly. Report all commit IDs, scopes, verification results, and remaining worktree changes.
Rust Formatting
- Start only with a clean index and worktree. If uncommitted changes exist, verify and commit the authorized changes first, following the workflow above; do not run even a formatting check before those commits. Preserve unrelated or unfinished changes and defer formatting until they are resolved. Do not stash, reset, or absorb them merely to obtain a clean worktree.
- Run
cargo fmt --all --check. If it passes, no formatting commit is needed. If it reports formatting differences, runcargo fmt --all. Diagnose tool or parsing failures instead of treating them as formatting differences. - Review the complete diff and confirm it contains only formatter-generated Rust changes. Run
cargo fmt --all --checkagain andcargo clippy --manifest-path srx_core/Cargo.toml --target aarch64-linux-android -- -D warnings. - Stage only the explicit formatted paths, review
git diff --cached --checkandgit diff --cached, and create one separate commit such aschore: Format Rust sources. Never mix formatting with functional changes or amend it into the preceding task commit. - Verify the saved commit and clean worktree. This formatting-only commit completes the phase; do not recursively start another formatting phase for it.
Commit Message
The subject and body must be entirely in English. Chinese response and source-comment rules do not apply to Git messages.
Use type: imperative summary, at most 70 characters. Supported types include feat, fix, build, docs, refactor, chore, and test.
Explain why the change is needed, its final behavior, and the checks actually performed. State relevant limitations without copying raw logs. Add an issue-closing reference only after reading the issue and verifying its complete acceptance criteria.
Push and Amend
Create the local commit first. Before pushing, describe the changes, remote, target branch, and all outgoing commits; wait for explicit approval. Follow any stricter task-specific push rule, including the version-bump skill.
Amend only unpublished task-owned commits when authorized. Do not rewrite public history or force-push without separate explicit approval.
If ownership is unclear or a command fails, preserve the worktree and index, report the concrete blocker, and do not reset or delete user changes.
Version History
- e5eeb2e Current 2026-11-02 12:30


