Skip to content
Back to skills

Commit 52

ASecurity

This skill should be used when the user says "commit changes", "commit this", "commit my work", "save to git", "save my changes", "push this", "push my work", "create a commit", or wants to save their work to version control. Handles the full git workflow including staging, committing, and pushing.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 27, 2026
code-qualitygobashgit

Security analysis

A100/100

Scanned September 27, 2026

npx -y skills add David-Li0406/meta-skill-evloving --skill commit-52 --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Commit 52?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Commit 52
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/david-li0406-commit-52/badge)](https://www.skillsdirectory.com/skills/david-li0406-commit-52)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: commit
description: This skill should be used when the user says "commit changes", "commit this", "commit my work", "save to git", "save my changes", "push this", "push my work", "create a commit", or wants to save their work to version control. Handles the full git workflow including staging, committing, and pushing.
---

# Git Commit Workflow

Direct execution of git commit workflow - no agent delegation, fast and simple.

## Trigger Phrases

This skill activates on:
- "commit changes", "commit this", "commit my work"
- "save to git", "save my changes", "save this to git"
- "push this", "push my changes", "push my work"
- "create a commit", "make a commit"
- "git commit", "check in my changes"

## Proactive Triggering

After completing implementation work, **proactively offer** to commit:
- "I've finished implementing the feature. Would you like me to commit these changes?"
- Use AskUserQuestion with options: "Yes, commit now" / "No, I'll review first"

## Workflow

### Step 1: Assess Changes

```bash
git status
git diff
```

**If no changes:** Report "No changes to commit" and end.

### Step 2: Stage Files

Stage logically related changes:
```bash
git add <files>
```

**Skip sensitive files:** .env, credentials, tokens - warn user if detected.

### Step 3: Create Conventional Commit

Analyze changes and determine:
- **Type:** feat, fix, docs, style, refactor, perf, test, chore
- **Scope:** Component/area affected
- **Subject:** Imperative, lowercase, max 50 chars, no period

**Commit format:**
```
<type>(<scope>): <subject>

[Narrative body explaining WHAT and WHY - 2-4 sentences, NO bullet points]
```

**Good example:**
```
feat(auth): add session timeout handling

Implements automatic session refresh when user activity is detected
within the timeout window. Sessions now persist across page reloads
using localStorage with encrypted tokens.
```

**Bad example (avoid):**
```
feat(auth): add features

- Added timeout
- Added refresh
- Added localStorage
```

### Step 4: Execute Commit

```bash
git commit -m "$(cat <<'EOF'
<commit message here>
EOF
)"
```

### Step 5: Handle Pre-commit Hooks

If hooks modify files:
1. Stage the modified files
2. Amend the commit: `git commit --amend --no-edit`

### Step 6: Ask About Push

Use AskUserQuestion:
- "Commit successful! Push to remote?"
- Options: "Yes, push now" / "No, keep local"

### Step 7: Push (if confirmed)

```bash
git push
# or if no upstream:
git push -u origin <branch>
```

## Safety Rules

- NEVER commit .env files or credentials
- NEVER force push without explicit user request
- NEVER amend commits on shared branches without warning
- Always show what will be committed before committing

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…