Stats
Actions
Tags
From git-workflow-guards
Use when committing changes to git, before running commit commands, to ensure explicit file staging, verification, and PR-friendly commit message format
How this skill is triggered — by the user, by Claude, or both
Slash command
/git-workflow-guards:making-git-commitsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create clean, PR-friendly commits with explicit file staging and verification. **Core principle:** Only commit files you modified, verify what's staged, and write commit messages suitable as GitHub PR titles.
Create clean, PR-friendly commits with explicit file staging and verification. Core principle: Only commit files you modified, verify what's staged, and write commit messages suitable as GitHub PR titles.
Following the letter IS following the spirit. The workflow below is not negotiable—skipping steps to "save time" creates more work later.
Use this skill when:
digraph commit_flow {
"Changes ready" [shape=doublecircle];
"Add specific files" [shape=box];
"Verify staged changes" [shape=box];
"Write PR-friendly message" [shape=box];
"Create commit" [shape=box];
"Verify commit contents" [shape=box];
"Done" [shape=doublecircle];
"Changes ready" -> "Add specific files";
"Add specific files" -> "Verify staged changes";
"Verify staged changes" -> "Write PR-friendly message";
"Write PR-friendly message" -> "Create commit";
"Create commit" -> "Verify commit contents";
"Verify commit contents" -> "Done";
}
Stage only files you modified
# ✅ Explicitly list files
git add path/to/file1.py path/to/file2.py
# ❌ NEVER use these (includes unrelated changes)
git add -A
git add .
git commit -a
Verify what will be committed
# REQUIRED: Shows exactly WHAT changed, not just WHICH files
git diff --cached
Never skip this step. git status is NOT enough—it only shows file names, not actual changes.
Create commit with PR-friendly message
git commit -m "$(cat <<'EOF'
Short description (50-72 chars)
- Highlight key features
- Explain what and why
- Be concise and clear
EOF
)"
Verify commit after creation
# Confirm only your changes were included
git show --stat
First line: (50-72 characters)
[component], scope tags)Body: (after blank line)
ALWAYS check project documentation first:
Look for:
[tool-name], feat:, fix:)When conventions exist, follow them exactly. When unsure, check documentation—don't guess.
✅ Good - With scope prefix:
[api] Add rate limiting middleware
- Implements token bucket algorithm
- Configurable per-endpoint limits
- Includes retry-after headers
✅ Good - Without scope prefix:
Add centralized error handling
- Creates unified error response format
- Adds logging for all errors
- Improves client error messages
✅ Good - Conventional commits:
feat(auth): add OAuth2 provider support
- Implements authorization code flow
- Adds token refresh mechanism
- Includes session management
❌ Bad - Multiple violations:
updated some files and fixed bugs.
Violations: Past tense, period at end, too vague, not PR-friendly
| Mistake | Why Bad | Fix |
|---|---|---|
git add -A | Commits unrelated WIP | Stage files explicitly by path |
git add . | Commits everything in directory | Stage specific files |
git commit -a | Commits all tracked changes | Stage explicitly first |
Skip git diff --cached | Don't see what you're committing | Always verify before commit |
| Past tense message | Not standard convention | Use imperative: "Add" not "Added" |
| Period at end of first line | Not PR title format | Remove trailing period |
| Long first line (>72 chars) | Hard to read in git log | Keep under 72 characters |
| No blank line before body | Formatting issue | Always add blank line |
| Vague descriptions | Unclear what changed | Be specific about changes |
These thoughts mean you're about to violate the rules:
git add -A to save time"git status is good enough for verification"All of these mean: STOP. Follow the process exactly. No shortcuts, no exceptions.
NEVER skip verification. Not for trivial commits, not under time pressure, not ever.
Every step in the workflow exists because skipping it causes problems:
git diff --cached → surprising changes in commitsgit show --stat → don't know what you actually committedTime pressure is not an excuse. This workflow takes 30-60 seconds and prevents:
Evidence before assertions. Before claiming "changes committed," verify exactly what went into the commit.
# 1. Stage specific files only
git add path/file1 path/file2
# 2. Verify what's staged
git diff --cached
# 3. Commit with proper message (check project conventions!)
git commit -m "$(cat <<'EOF'
Short description
- Key change 1
- Key change 2
EOF
)"
# 4. Verify commit
git show --stat
| Excuse | Reality |
|---|---|
| "Too simple to verify" | Verification takes 5 seconds, catches mistakes |
| "I know what I changed" | Memory is fallible, unrelated files sneak in |
| "User is in a hurry" | Bad commits create more work later |
| "It's just debugging code" | Debug code shouldn't be committed |
"git status is enough" | git diff --cached shows WHAT changed, not just WHICH files |
| "Message doesn't matter for small commits" | Small commits accumulate, unclear history compounds |
| "Simple commits don't need body" | All commits need proper format for consistency |
| "Character limit is a suggestion" | It's a requirement—longer messages break tools |
| "I'll check conventions if needed" | ALWAYS check first, don't assume |
| "Following spirit > letter" | Following the letter IS following the spirit |
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub zainrizvi/git-workflow-guards --plugin git-workflow-guards