Commit code safe and nice

Smart git commit with remote sync, amend intelligence, and conventional commits. Use when the user asks to commit changes, stage and commit, "/commit", save...

Security Scan

The skill mostly does what it says (git staging/amend/push), but its runtime instructions ask for broad automatic triggering, vague judgment calls about staging (including a blanket git add -A), and embedding model/agent metadata into commits — together these create a non-trivial risk of accidental pushes or secret exposure and a mismatch between declared metadata and the instructions.

Purpose & Capability

The name/description match the git commands and flow in SKILL.md (fetch, rebase, diff, amend/new commit, generate conventional commits). However, the SKILL.md prescribes embedding agent/model info into commit footers and instructs the skill to 'TRIGGER' on any mention of committing — this aggressive trigger behavior is not reflected in the registry metadata (always:false) and feels disproportionate to a simple commit helper.

Instruction Scope

Instructions include running repository-wide commands (git fetch/pull/rebase, git add -A, git push) and rely on the agent's 'judgment' to stage changes while also telling it to avoid secrets. This is ambiguous and grants broad discretion: a blanket git add -A can stage secrets accidentally; automatic rebase/pull and push behavior can expose private data or rewrite history without an explicit, enforced confirmation step. The SKILL.md's required trigger behavior ('TRIGGER this skill whenever the user mentions committing') is overly broad and risks unintended commits or pushes.

Install Mechanism

Instruction-only skill with no install steps and no code files. Lowest installation risk — nothing is written to disk by a package mechanism.

Credentials

The skill asks the agent to append 'Co-authored-by: Claude <[e-mail]>' and 'AI-model: <model-id>' using 'what's available from the environment' but declares no required environment variables. Expecting model or system context without declaring required env vars is an untracked data request. Including model identifiers and a fixed vendor email in commits may leak internal runtime metadata to remote Git servers and seems unnecessary for a generic git helper.

Persistence & Privilege

Metadata does not request always:true and the skill is user-invocable only — appropriate. However, combined with the SKILL.md's instruction to trigger on casual mentions and to perform networked operations (fetch/pull/rebase/push), autonomous invocation (the platform default) would give this skill the ability to modify and push remote repositories without strong explicit confirmation. That combination raises operational risk even though no permanent presence or special privileges are requested.

What to consider before installing

This skill appears to implement a helpful commit workflow but has practical risks. Before installing or enabling it: 1) Require explicit user confirmation before any git pull/rebase or push — do not allow automatic network operations on casual mentions. 2) Remove or make optional the automatic 'git add -A' and instead present a staged-file selection to the user; ensure it never stages known secret files by default. 3) Make the inclusion of AI-model or vendor info in commit footers optional and clearly documented — this can leak runtime/model metadata to remote servers. 4) Test the skill in a disposable repository to observe behavior (especially rebase/abort flows). 5) If you do enable autonomous invocation, restrict triggers (do not trigger on every mention of 'commit' — require a command/confirmation). These changes would reduce the risk of accidental data exposure or unwanted pushes.

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 <[e-mail]>
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 <[e-mail]>
AI-model: <model-id>

---

Step 5 — Execute Commit

New commit:

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

<optional body>

Co-authored-by: Claude <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
AI-model: claude-sonnet-4-6

docs: update contributing guide with commit conventions

Co-authored-by: Claude <[e-mail]>
AI-model: claude-sonnet-4-6