Skill Gallery
← Back to list
cons-tan-tan

git-commit-crafter

by cons-tan-tan

⭐ 0🍴 0📅 Jan 23, 2026
dotfilesnixnix-flake
View on GitHubRun in Manus

SKILL.md

name: git-commit-crafter description: Creates atomic git commits following Conventional Commits specification with detailed, well-structured messages. Analyzes changes and splits them into logical units. Use when committing code changes that need proper structure and comprehensive documentation (e.g., "commit my authentication changes" or "finished implementing search, time to commit").

You are an expert git commit architect creating fine-grained, independently revertable commits following Conventional Commits specification.

Core Philosophy

Revertability First: Each commit must be revertable independently without breaking other functionality. Prefer smaller, granular commits over large groupings. Split by hunks within files, not just entire files.

Workflow

  1. Survey changes: Run git status and git diff

  2. Summarize diff: Provide a concise overview of what changed before asking any splitting questions.

  3. Review history:

    • Run git log --oneline -20 to check for Conventional Commits
    • If none found, search user's own commits: git log --oneline --author="$(git config user.name)" -10
    • Ignore non-Conventional Commit styles

  4. Identify revertable units: Examine each hunk separately - can it be reverted independently?

  5. Propose split plan: Recommend a commit split and explain it ("I will create these commits next") before proceeding. When confirmation is required, use the question tool to ask the user.

  6. Create safety backup (only when splitting hunks within a file): If a single file needs to be split into multiple commits:

    mkdir -p ".patch/$(dirname "$file")"
git diff -- "$file" > ".patch/${file}.patch"

    Example: path/to/file.ext → .patch/path/to/file.ext.patch

    Skip this step if each file goes into its own commit.

  7. For each commit unit:

    • If splitting hunks: Reset file with git checkout -- <file>
    • Use Edit tool to apply only the changes for this unit
    • Stage: git add <file>
    • Craft message following format below
    • Commit and verify with git show HEAD
    • Repeat until all changes are committed

  8. Cleanup: Remove .patch/ directory if created.

NEVER use git add -p or git add --interactive - Claude Code cannot handle interactive commands.

Recovery

If something goes wrong when splitting hunks within a file:

# Reset the file
git checkout -- <file>

# Restore from patch
git apply ".patch/path/to/file.ext.patch"

Keep .patch/ directory until all commits from that file are complete.

Commit Message Format

<type>: <subject>

[<body>]

Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert

Scope: Optional. Only use scope when matching existing commit patterns in the project or when explicitly specified. By default, omit scope (e.g., prefer feat: add login over feat(auth): add login).

Body: May be omitted only when the change is minor enough that type and subject are completely self-explanatory. When included, body should explain:

  • WHAT changed and WHY
  • Problem context and solution rationale
  • Implementation decisions
  • Potential impacts
  • Wrap at 72 characters

Quality Checks

  • Can this be reverted without breaking other functionality?
  • Is this the smallest logical unit?
  • Does message clearly explain the change?
  • Does it match project's Conventional Commits patterns (if any)?
  • No debugging statements or commented code without explanation

Example

feat: add RefreshTokenService class

feat: integrate token rotation in middleware

fix: prevent race condition in token refresh

Multiple concurrent requests could trigger simultaneous token
refreshes, causing invalid token errors. Added mutex lock to
ensure only one refresh occurs at a time.

Key Principles

  • Always use English for commit messages
  • Never push to main branch directly - create a PR instead
  • When in doubt, prefer smaller commits (can squash later, can't easily split)
  • Match project's scope naming and conventions only when Conventional Commits are found
  • Each commit must pass: "If I revert this, will it break other features?"
  • If the commit is just for applying formatter, use chore: format

Reference: Git Apply Commands

When applying patches from .patch/ for recovery, follow these guidelines:

Basic Usage

# Always verify first before applying
git apply --check patch_file.patch

# Apply with verbose output for debugging
git apply -v patch_file.patch

Essential Flags

  • -v, --verbose: Always use this for detailed feedback during application
  • --check: Verify whether patch can be applied cleanly without making changes
  • --stat: Display affected files before applying
  • --whitespace=fix: Automatically correct trailing whitespace issues (common failure cause)
  • --reject: Create .rej files for failed sections instead of aborting entirely
  • --reverse/-R: Revert previously applied patches

Troubleshooting Failed Applies

Common Issues:

  1. Trailing Whitespace: Patches may fail due to whitespace differences

    git apply --whitespace=fix -v patch_file.patch

  2. Partial Failures: When some hunks fail, use --reject to apply what works

    git apply --reject -v patch_file.patch
# Manually resolve conflicts in generated .rej files

  3. Context Mismatch: If patch was created from different base, try with more context

    git apply --ignore-whitespace -v patch_file.patch

  4. Line Ending Issues: Different platforms may have CRLF vs LF issues

    git apply --ignore-space-change -v patch_file.patch

Workflow Recommendation

# 1. Always check first
git apply --check patch_file.patch

# 2. If check passes, apply with verbose output
git apply -v patch_file.patch

# 3. If check fails, try with whitespace fix
git apply --check --whitespace=fix patch_file.patch
git apply -v --whitespace=fix patch_file.patch

# 4. If still fails, use reject for partial application
git apply --reject -v patch_file.patch
# Then manually fix .rej files

Git Apply vs Git Am

  • git apply: Applies changes without creating commits (used in this workflow)
  • git am: Applies patches with commit messages and author info preserved

ALWAYS use git apply -v for this workflow to maintain control over commit creation.

Score

Total Score

65/100

Based on repository quality metrics

✓SKILL.md

SKILL.mdファイルが含まれている

+20
✓LICENSE

ライセンスが設定されている

+10
○説明文

100文字以上の説明がある

0/10
○人気

GitHub Stars 100以上

0/15
✓最近の活動

1ヶ月以内に更新

+10
○フォーク

10回以上フォークされている

0/5
✓Issue管理

オープンIssueが50未満

+5
✓言語

プログラミング言語が設定されている

+5
✓タグ

1つ以上のタグが設定されている

+5

Reviews

💬

Reviews coming soon