Imported from YSMsimon/Warden (
skills/git-workflow/SKILL.md). Install upstream withnpx skills add YSMsimon/Warden --skill git-workflow. Copyright stays with the author.
Git Workflow
Help the user work effectively with git — from individual commits to full branching strategies and pull request descriptions.
Commit messages — Conventional Commits
Format
<type>(<scope>): <short summary>
<optional body — explain WHY, not what>
<optional footer>
Types
| Type | When to use |
|---|---|
feat |
New user-facing feature |
fix |
Bug fix |
refactor |
Code restructuring, no behaviour change |
perf |
Performance improvement |
test |
Adding or fixing tests |
docs |
Documentation only |
chore |
Build, deps, tooling |
ci |
CI/CD pipeline |
revert |
Reverting a previous commit |
Rules
- Summary: max 50 chars, imperative mood ("add" not "added"), no trailing period
- Blank line between summary and body
- Body: explain why — the diff shows what
- Wrap body at 72 characters
- Reference issues in footer:
Closes #42
Branching strategy
GitHub Flow (default — simple projects, CI/CD)
mainis always deployable- Branch for every feature or fix
- PR → review → merge to
main
Branch naming: feature/jwt-refresh, fix/profile-update-race, chore/upgrade-dependencies
Git Flow (versioned releases, larger teams)
main: production, always taggeddevelop: integration branchfeature/*: from develop, back to developrelease/*: from develop when prepping a releasehotfix/*: from main for urgent fixes, merge back to both main and develop
When the user provides context
If they share a diff or describe changes — write the commit message directly, don't just explain the format.
If they show a messy branch history — recommend the exact rebase commands with the real commit count.
If they describe a PR — write the full PR description using the template.
