olakunlevpn Git Workflow Standards
This skill MUST be loaded automatically before ANY git operation. Do NOT wait for the user to ask.
Auto-triggers: git commit, git push, git branch, git merge, git rebase, git tag, "commit this", "push this", "create a branch", "merge this".
Absolute Rules
- NO AI attribution. Never. Zero. No Co-Authored-By with any AI name, email, or company. The developer is the sole author.
- No
git add .orgit add -A. Always add specific files. - Every commit is atomic. One logical change per commit. Never bundle unrelated changes.
- Every commit message follows the format below exactly.
Commit Message Format
The 50/72 Rule (STRICT)
<type>: <subject> ← 50 chars max, no period
← blank line
<body> ← 72 chars per line, optional
← blank line
<footer> ← issue refs, optional
Subject Line Rules
- 50 characters maximum. Not 51. Not "roughly 50". Exactly 50 or less.
- Imperative mood. Write as a command: "Add", "Fix", "Remove", "Update", "Refactor". Never "Added", "Fixed", "Adds", "Fixing".
- Capitalize first letter after the type prefix.
- No period at the end.
- No filler words. No "just", "simply", "basically", "a bit of", "some".
- No redundancy. Never repeat the type in the subject:
fix: Fix the bugis wrong.fix: Resolve login timeoutis correct. - Specific, not vague. Never "update files", "fix stuff", "changes", "improvements", "misc".
Type Prefixes (Conventional Commits)
Use EXACTLY one of these. Nothing else.
feat: New feature for the user
fix: Bug fix
refactor: Code change that is not a fix or feature
perf: Performance improvement
test: Adding or correcting tests
docs: Documentation only (README, comments)
style: Formatting (whitespace, semicolons, no logic change)
chore: Maintenance (dependencies, config, build)
ci: CI/CD pipeline changes
revert: Revert a previous commit
Body Rules (Optional but Recommended for Complex Changes)
- Wrap at 72 characters per line.
- Explain WHY the change was made, not WHAT changed (the diff shows what).
- Explain how behavior differs from before.
- Keep it short. 2-4 lines maximum.
Footer Rules (Optional)
- Reference issues:
Resolves #123orCloses #456 - Breaking changes:
BREAKING CHANGE: description
Commit Message Examples
Good (Concise, Specific, Professional)
feat: Add order export to CSV
fix: Prevent duplicate payment webhook processing
refactor: Extract order total calculation to service
perf: Add index on orders.status column
chore: Update laravel/framework to 11.5
fix: Handle null customer on order detail page
The order detail page crashed when accessing customer.name
on orders without an assigned customer. Now shows a dash.
Resolves #87
feat: Add bulk status update for orders
Adds a bulk action on the orders table that allows
changing status of multiple selected orders at once.
refactor: Move notification logic to observer
Notification dispatching was scattered across three
controllers. Consolidated into OrderObserver for
single responsibility.
Bad (NEVER Write These)
# Too vague
fix: Fix bug
update: Update files
chore: Changes
feat: Add some stuff
# Redundant (type repeated in subject)
fix: Fix the login issue
feat: Add new feature for orders
refactor: Refactor the code
# Past tense (should be imperative)
fix: Fixed the timeout error
feat: Added CSV export
refactor: Moved logic to service
# AI attribution (BANNED)
feat: Add order export
Co-Authored-By: Claude <noreply@anthropic.com>
# Too long subject (over 50 chars)
feat: Add the ability for administrators to export all orders to CSV format
# Has period at end
fix: Resolve login timeout.
# Vague filler words
fix: Just fix a small issue with the login
feat: Simply add a little export button
Branch Naming
FORMAT: <type>/<short-description>
TYPES:
feature/ → New feature
fix/ → Bug fix
refactor/ → Code restructure
chore/ → Maintenance
hotfix/ → Urgent production fix
RULES:
- kebab-case only: feature/order-export (not feature/orderExport)
- Short and descriptive: fix/duplicate-webhook (not fix/fix-the-issue-with-duplicate-webhook-processing)
- No ticket numbers alone: feature/order-export not feature/JIRA-123
- Include ticket if helpful: feature/order-export-JIRA-123
Examples
feature/order-csv-export
fix/duplicate-payment-webhook
refactor/extract-order-service
chore/update-dependencies
hotfix/login-timeout
Git Workflow
Adding Files
NEVER:
git add .
git add -A
git add --all
ALWAYS:
git add app/Models/Order.php
git add app/Http/Controllers/OrderController.php
git add app/ config/ database/ resources/ routes/ tests/
Committing
BEFORE every commit:
1. git status → verify only intended files are staged
2. git diff --staged → review what you're committing
3. Write the commit message following the format above
4. Check: is the subject under 50 chars?
5. Check: is it imperative mood?
6. Check: is there ANY AI attribution? Remove it.
7. Commit.
Pushing
BEFORE every push:
1. git log --oneline -5 → review recent commits
2. Verify no AI co-author in any commit
3. Verify no .env, .claude/, plan files committed
4. Push.
Pull Requests
PR TITLE:
- Same format as commit subject: <type>: <description>
- Under 70 characters
PR BODY:
- ## Summary (2-3 bullet points of what changed)
- ## Test plan (how to verify)
- NO AI attribution or "built with" badges
- Reference related issues
NEVER mention AI tools in PR descriptions.
Atomic Commits
Each commit represents ONE logical change. Split work into small, focused commits.
GOOD (3 atomic commits):
feat: Add order export action
feat: Add CSV formatter for orders
test: Add tests for order export
BAD (1 bundled commit):
feat: Add order export with CSV formatting and tests
GOOD (2 atomic commits):
fix: Handle null customer on order page
refactor: Extract customer display to component
BAD (1 bundled commit):
fix: Handle null customer and refactor display component
When to Split
Split when the commit message needs "and":
"Add export AND fix null customer" → 2 commits
"Update model AND add migration" → 2 commits
"Refactor service AND add tests" → 2 commits
Tags and Releases
FORMAT: v<major>.<minor>.<patch>
EXAMPLES: v1.0.0, v1.2.3, v2.0.0-beta
Annotated tags only:
git tag -a v1.0.0 -m "Release v1.0.0"
Tag messages follow the same rules: imperative, concise, no AI.
Pre-Commit Checklist (Run Every Time)
[ ] Only project files staged (no .env, .claude/, plans, skills)
[ ] Subject line under 50 characters
[ ] Imperative mood (Add, Fix, Remove — not Added, Fixed)
[ ] Correct type prefix (feat, fix, refactor, etc.)
[ ] No period at end of subject
[ ] No AI attribution anywhere in the message
[ ] No Co-Authored-By trailer
[ ] Atomic: one logical change only
[ ] Body wraps at 72 chars (if present)
[ ] No vague messages (no "update files", "fix stuff", "changes")