360 Secure SkillHub
360 安全技能中心

Commit code safe and nice

在本地 Git 仓库中安全提交改动:先 fetch 检查远程是否领先并用 rebase 同步,遇冲突则中止并给出指引;分析暂存与未暂存 diff,按严格条件判断是否 amend 上一提交;生成带类型、范围与 agent/model 页脚的 conventional commit 信息,仅在用户明确要求时推送。

hugogu
hugogu
热度 39.61
最近更新 2026-05-11 17:38:51
分类:开发依赖:代码执行应用场景:DevOps / 自动化脚本 / 工作流

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add proper-git-commit
Metadata
name
git-commit
description
Smart git commit with remote sync, amend intelligence, and conventional commits. Use when the user asks to commit changes, stage and commit, "/commit", save work to git, push code, or sync and commit. Automatically checks remote for new commits before committing and syncs via rebase if needed. Analyzes whether current changes should amend the previous commit (with strict same-thing criteria). Generates conventional commit messages with agent/model info in the footer. TRIGGER this skill whenever the user mentions committing, staging changes, or saving work to version control — even if they just say "commit this" or "save my changes".
license
MIT
allowed-tools
Bash

Smart Git Commit

Commit local changes safely: sync remote → analyze diff → stage → amend or new commit → push (if asked).


Step 1 — Remote Sync Check

git fetch origin 2>&1

Then check if the remote branch has commits the local branch doesn't:

git status -sb          # shows tracking info, e.g. ## main...origin/main [behind 3]
git rev-list HEAD..@{u} --count 2>/dev/null   # 0 means in sync

If the remote is ahead (count > 0): sync via rebase:

git pull --rebase origin <current-branch>

Watch the output for conflict markers. If the rebase fails or conflicts are reported:

git rebase --abort

Then stop everything and tell the user:

⚠️ Remote conflict — commit aborted

Remote has new commits that conflict with your local changes. The rebase was aborted automatically to keep your work safe.

To see which files conflict:

git diff --name-only --diff-filter=U

To resolve and continue:

# 1. Re-run the rebase
git pull --rebase

# 2. Open each conflicted file and fix the markers:
#    <<<<<<< HEAD        ← your local changes
#    (your code)
#    =======
#    (remote code)
#    >>>>>>> abc1234     ← remote commit

# 3. Stage each resolved file
git add <file1> <file2> ...

# 4. Continue the rebase
git rebase --continue

# 5. Repeat steps 2–4 for each conflicted commit, then run /commit again

To abort and restore your original state:

git rebase --abort   # already done — your branch is back to where it was

Do not proceed with staging or committing. Wait for the user to resolve.

If the rebase succeeds (no conflicts), continue.


Step 2 — Inspect Staged / Unstaged Changes

git status --porcelain   # list of changed files
git diff --staged        # staged diff
git diff                 # unstaged diff

If nothing is staged and there are unstaged changes, stage everything that looks relevant (avoid committing secrets like .env, *.pem, credentials.*):

git add -A               # or specific files — use judgment

If there is truly nothing to commit, tell the user and stop.


Step 3 — Amend Analysis (Strict Criteria)

Compare the current staged diff against the last commit to decide: new commit or --amend?

git log -1 --format="%H %s"   # last commit hash + subject
git show --stat HEAD           # files changed in last commit
git show HEAD                  # full diff of last commit
git log origin/<branch>..HEAD --oneline  # commits not yet pushed

Only amend if ALL of the following are true:

  1. The last commit has not been pushed to the remote (it appears in git log origin/<branch>..HEAD).
  2. The current staged change has the same commit type (feat/fix/docs/…) as the last commit.
  3. The current staged change affects the same scope (same module/area) as the last commit.
  4. The change is a direct continuation or correction of the exact same atomic operation — e.g., a typo fix in code just added, or a file that was accidentally omitted from the last commit.

Do NOT amend in any of these cases:

Situation Why
Last commit is feat:, this is fix: Different type → different thing
Last commit is feat:, this adds tests test: is a separate concern
Last commit is feat:, this reformats code style: is a separate concern
Last commit is feat:, this updates config/CI Different type
Last commit has already been pushed Rewriting published history is dangerous
Scope differs (e.g., auth vs user) Different areas

When in doubt, create a new commit. The amend path is the exception, not the rule.


Step 4 — Generate Commit Message

Analyze the staged diff to determine:

  • type: What kind of change? (see table below)
  • scope (optional): Which module, component, or area?
  • description: One-line summary — imperative mood, present tense, under 72 chars
  • body (optional): Why this change? What problem does it solve? Include only if non-obvious.
  • footer: Breaking changes + issue refs + agent/model info

Commit Types

Type Use for
feat New feature or behavior
fix Bug fix
docs Documentation only
style Formatting, whitespace (no logic change)
refactor Code restructure (no feature or fix)
perf Performance improvement
test Add or update tests
build Build system, dependencies
ci CI/CD, pipeline configuration
chore Maintenance, misc tooling
revert Revert a prior commit

Footer — Agent & Model Info

Always append agent and model info in the footer. Use what's available from the environment:

Co-authored-by: Claude <noreply@anthropic.com>
AI-model: claude-sonnet-4-6

If the exact model ID is available (from the system context), use it. Otherwise use the family name.

Full Format

<type>[optional scope]: <description>

[optional body — explain WHY, not WHAT]

[breaking change if any]
[issue refs if any]
Co-authored-by: Claude <noreply@anthropic.com>
AI-model: <model-id>

Step 5 — Execute Commit

New commit:

git commit -m "$(cat <<'EOF'
<type>[scope]: <description>

<optional body>

Co-authored-by: Claude <noreply@anthropic.com>
AI-model: <model-id>
EOF
)"

Amend last commit (only when criteria in Step 3 are fully met):

git commit --amend -m "$(cat <<'EOF'
<updated message>

Co-authored-by: Claude <noreply@anthropic.com>
AI-model: <model-id>
EOF
)"

Step 6 — Push (only if user asked)

If the user explicitly asked to push:

git push origin <current-branch>

Never force-push to main/master. If a force push is needed, confirm with the user first.


Safety Rules

  • Never commit secrets: .env, *.pem, credentials.*, *.key
  • Never skip hooks with --no-verify unless the user explicitly asks
  • Never use git reset --hard or other destructive commands without explicit user request
  • If a pre-commit hook fails: fix the issue, re-stage, create a new commit (never --amend after hook failure)
  • If the rebase produces conflicts: git rebase --abort and stop — do not proceed

Example Messages

feat(auth): add JWT refresh token rotation

Tokens now rotate on each use to limit exposure window.
Refresh tokens are stored hashed in Redis with a 7-day TTL.

Co-authored-by: Claude <noreply@anthropic.com>
AI-model: claude-sonnet-4-6
fix(api): handle null response from payment gateway

Gateway returns null instead of an error object on timeout;
guard added to prevent unhandled exception in checkout flow.

Closes #482

Co-authored-by: Claude <noreply@anthropic.com>
AI-model: claude-sonnet-4-6
docs: update contributing guide with commit conventions

Co-authored-by: Claude <noreply@anthropic.com>
AI-model: claude-sonnet-4-6