Git Commits Skill

Creates GitHub PRs, commits, and branch names that match @klohto's established patterns.

Branch Naming

Format: tomik/<identifier>

• Use tomik/ prefix (your nickname)
• Identifier can be:
  • Ticket ID: tomik/APP-310, tomik/INF-446, tomik/PLA-313-cache
  • Feature slug: tomik/faster-ci, tomik/sonarqube, tomik/ghes
  • Descriptive: tomik/fix-unicode-bug-in-gh, tomik/case_sensitive_emails

Examples:

tomik/APP-310
tomik/speedup-gh-ci
tomik/ghes-runtime
tomik/required-claude-code-review

PR Title Conventions

Format: <type>: <descriptive summary of what the PR does>

Types (Conventional Commits)

• feat: - New features
• fix: - Bug fixes
• docs: - Documentation changes
• style: - Code style/formatting (no logic change)
• refactor: - Code restructuring (no feature/fix)
• perf: - Performance improvements
• test: - Adding or fixing tests
• build: - Build system or dependencies
• ci: - CI/CD configuration
• chore: - Maintenance tasks, tooling
• revert: - Reverting a previous commit

Style

• Lowercase after type prefix
• Descriptive - clearly state what the PR accomplishes
• Action-oriented, explain the outcome
• No period at end
• Include ticket ID in branch, not always in title

Examples:

feat: add support for sonarqube cloud as security scanner
feat: run integration tests with multiple workers for faster CI
fix: unicode encoding bug in GitHub webhook workflow
fix: missing environment variables for all PoV deployments
fix: lowercase email comparison on reactivation and permit admin
refactor: extract VCS abstraction layer for multi-provider support
perf: introduce caching with mitm proxy to reduce API calls
test: add integration tests for GitLab webhook handling
ci: split integration tests into fast and slow workflows
docs: add GHES setup guide to README
chore: upgrade pytest-xdist to v3.5

PR Description

Always include a description that explains what the PR does and why.

Keep it terse but informative - no fluff, just the facts.

For bug fixes with context:

Entra sometimes provides email like "FirstName.Lastname@Domain.COM", but we do an exact match on the invited user's email, leading to 403.

For feature PRs with scope:

* PR support for Bitbucket
* Fix PR statuses on all providers
* Fix minor API call inconsistencies

Tested on all providers except for GitHub due to minor changes (tested in isolation)

For structured changes:

Adds the missing "Last 1 Day" option to the Date Range filter in Reports.

## Changes
- Add `LAST_1_DAY = "1d"` to `DateRangePreset` enum
- Add unit test for the new preset

Fixes APP-310

For multi-part changes:

* make integration tests work with multiple workers
* make them faster
* fix bugs in tests
* split the tests to 2 github workflows (fast & slow) to make them even faster

Key patterns:

• Use bullet points with * (not -) for lists in body
• Use - for sub-items under headers
• Reference ticket with Fixes APP-310 at end
• Include testing notes when relevant
• Explain the problem being solved and how
• Keep it terse - no fluff, every sentence adds value

Commit Message Conventions

Format: <type>: <description> or just description for WIP

Types (Conventional Commits - same as PR)

• feat: - New feature
• fix: - Bug fix
• docs: - Documentation
• style: - Formatting
• refactor: - Code restructuring
• perf: - Performance
• test: - Tests
• build: - Build/deps
• ci: - CI/CD
• chore: - Maintenance
• revert: - Revert

Style

• Lowercase after prefix
• Present tense, imperative mood
• No period
• Concise but descriptive

During development (WIP commits):

Simple, no prefix needed:

remove bpython
runner changed
change cores
cleanup
format
testing diff worker count

Final/meaningful commits:

feat: run integration tests with multiple workers
fix: worktree tests checking the same repository
refactor: scoping to make integration run reliably in parallel
test: add LAST_1_DAY preset to DateRangePreset enum
ci: split workflows into fast and slow jobs

Usage Examples

Create a branch and PR for a ticket:

# Create branch
git checkout -b tomik/APP-123

# After changes, create PR
gh pr create \
  --title "feat: implement user preference caching to reduce database load" \
  --body "Adds Redis-based caching layer for user preferences.

* Cache preferences on first fetch with 5min TTL
* Invalidate on preference update
* Fallback to DB on cache miss

Reduces DB queries by ~40% on dashboard load."

Create a bug fix PR with context:

gh pr create \
  --title "bug: fix race condition in webhook handler causing duplicate entries" \
  --body "Concurrent webhook deliveries were causing duplicate entries due to missing lock.

Added mutex around the handler to ensure sequential processing."

Create a feature PR with bullet points:

gh pr create \
  --title "feat: add GitLab merge request support for automated PR creation" \
  --body "Extends VCS abstraction to support GitLab MRs alongside GitHub PRs.

* Add MR creation endpoint
* Add MR status tracking  
* Fix webhook signature validation

Tested against GitLab Cloud and self-hosted.

Fixes COR-456"

Staging Files

NEVER use git add -A or git add . - only stage the specific files that were modified in the current thread/task.

Use git add <file1> <file2> ... with explicit file paths.

Quick Reference

Element	Pattern	Example
Branch	tomik/<slug>	tomik/APP-310
Feature PR	feat: <descriptive>	feat: add Redis caching layer to reduce API latency
Bug fix PR	fix: <descriptive>	fix: null pointer in parser when input is empty
Refactor PR	refactor: <descriptive>	refactor: extract auth logic into dedicated service
CI PR	ci: <descriptive>	ci: parallelize integration tests across 4 workers
WIP commit	<desc>	testing new approach
Final commit	<type>: <desc>	feat: implement retry logic with exponential backoff
PR body	what + why + how	Problem, solution, testing notes, ticket ref