Skip to content
Back to skills

Commit Push

BSecurity

Create atomic git commits with terse Conventional Commits messages, then push to remote. Subject ≤50 chars, body only when "why" isn't obvious. Never force pushes. Use when the user says "commit and push", "commit & push", "/commit-push", or asks to stage, commit, and push in one flow.

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 1, 2026
developmentgobashnodegitapisecurity

Works with

  • claude code
  • cli
  • api

Security analysis

B75/100
  • criticalReads or references SSH private keys

Pro shows the line behind each finding and how to fix it

Scanned September 1, 2026

npx -y skills add samuelpatro/.claude --skill commit-push --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Commit Push?

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

Security grade badge for Commit Push
[![Security: B — Skills Directory](https://www.skillsdirectory.com/api/skills/samuelpatro-commit-push/badge)](https://www.skillsdirectory.com/skills/samuelpatro-commit-push)

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-push
effort: low
allowed-tools: Read, Grep, Glob, Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git log:*), Bash(git push:*), Bash(git branch:*), Bash(git remote:*)
description: >
  Create atomic git commits with terse Conventional Commits messages, then push to remote.
  Subject ≤50 chars, body only when "why" isn't obvious. Never force pushes.
  Use when the user says "commit and push", "commit & push", "/commit-push", or asks to stage, commit, and push in one flow.
---

## Context

- Current git status: !`git status --short`
- Diff summary (file + line counts): !`git diff HEAD --stat`
- Current branch: !`git branch --show-current`
- Recent commits (for style matching): !`git log --oneline -10`

The full diff is intentionally NOT loaded above. Read hunks on demand with `git diff HEAD -- <file>` for only the files you need to inspect to write the message and decide splits. Do not run `git diff HEAD` with no path filter.

## Your task

Create atomic, self-contained commits with terse, exact messages, then push to the remote. Conventional Commits format. No fluff. Why over what.

### Commit Splitting

Split into multiple commits when changes involve:

- **Different concerns** — unrelated parts of the codebase
- **Different types** — mixing feat/fix/refactor/tests/docs/config
- **Different file patterns** — source vs docs vs config
- **Large changesets** — break down for reviewability

Each commit must build and make sense on its own. If all changes relate to one concern, a single commit is fine.

### Message Rules

**Subject line:**
- `<type>(<scope>): <imperative summary>` — `<scope>` optional
- Types: `feat`, `fix`, `refactor`, `perf`, `docs`, `test`, `chore`, `build`, `ci`, `style`, `revert`
- Imperative mood: "add", "fix", "remove" — not "added", "adds", "adding"
- ≤50 chars when possible, hard cap 72
- No trailing period
- Match project convention for capitalization after the colon (check recent commits above)

**Body (only if needed):**
- Skip entirely when the subject is self-explanatory
- Add body only for: non-obvious *why*, breaking changes, migration notes, linked issues
- Wrap at 72 chars
- Bullets `-` not `*`
- Reference issues/PRs at end: `Closes #42`, `Refs #17`

**Auto-clarity — always include body for:** breaking changes, security fixes, data migrations, revert commits.

**Breaking changes:** mark subject with `!` and add a `BREAKING CHANGE:` footer explaining the migration.

**What NEVER goes in:**
- "This commit does X", "I", "we", "now", "currently" — the diff says what
- "As requested by..." — use `Co-authored-by:` trailer instead
- AI attribution: "Generated with Claude Code", co-authorship footers, 🤖 emoji
- Emoji unless project convention requires
- Restating the filename when the scope already covers it

### Examples

```
fix(auth): handle expired refresh token
```

```
feat(api): add GET /users/:id/profile

Mobile client needs profile data without the full user payload
to reduce LTE bandwidth on cold-launch screens.

Closes #128
```

### HEREDOC Format

```
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>

<body if needed>
EOF
)"
```

### Staging Rules

- Stage specific files by name — do NOT use `git add -A` or `git add .`
- NEVER stage files that may contain secrets: `.env`, `.env.*`, `credentials.json`, `*.key`, `*.pem`, `*.p12`, `id_rsa*`, `token.json`, `secret*`. Warn the user and skip them.
- If all changes are already staged, do not re-stage them.

### Push Rules

- After all commits are created, push to the remote.
- Use `git push origin <current-branch>`.
- If the branch has no upstream, use `git push -u origin <current-branch>`.
- If the push fails due to diverged history, do NOT force push. Inform the user and stop.

### Edge Cases

- No changes (nothing staged, nothing modified): say so and stop. Do not create an empty commit.
- Only untracked files that look like generated artifacts (`dist/`, `node_modules/`, `*.log`): warn the user instead of committing them.
- If the user says "normal mode" or "verbose commit": allow a longer, descriptive style for this commit only.

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…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.