| name | git-workflow |
| description | Enforce branch-based workflow with draft PRs for emoji_gen. Use when starting new work, creating branches, or opening pull requests. Mentions of "new feature", "bug fix", "start work", "create PR", or "pull request" should trigger this Skill. Use when this capability is needed. |
| metadata | {"author":"ForceInjection"} |
Git Workflow for emoji_gen
This Skill enforces the branch-based workflow with draft PRs required for all non-trivial changes.
Core Principle
ALWAYS use feature branches and draft PRs for any non-trivial work.
Complete Workflow
1. Start New Work
Before making any changes:
git checkout main
git pull origin main
git checkout -b <type>/<descriptive-name>
2. Branch Naming Convention
Use Conventional Commits prefixes:
| Prefix | Use For | Example |
|---|
feat/ | New features | feat/add-emoji-categories |
fix/ | Bug fixes | fix/negative-count-validation |
docs/ | Documentation | docs/update-readme-install |
build/ | Build/CI changes | build/add-msrv-check |
test/ | Test additions | test/add-pool-size-validation |
refactor/ | Code refactoring | refactor/extract-selection-logic |
perf/ | Performance | perf/optimize-emoji-lookup |
chore/ | Maintenance | chore/update-dependencies |
Examples:
git checkout -b feat/add-emoji-filtering
git checkout -b fix/unicode-encoding-bug
git checkout -b docs/docker-workflow
git checkout -b build/ci-coverage-reporting
3. Make Changes and Commit
Work on your changes, committing as you go:
git add <files>
git commit -m "..."
git push
4. Create Draft Pull Request
After first commit:
git push -u origin <branch-name>
gh pr create --draft --title "<type>: descriptive title" --body "$(cat <<'EOF'
## Summary
[Brief description of changes and motivation]
## Changes
- [Bullet point list of key changes]
- [Another change]
## Test Plan
- [ ] [Testing step 1]
- [ ] [Testing step 2]
- [ ] Run `./docker-dev.sh test`
- [ ] Run `./docker-dev.sh clippy`
๐ค Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
Shortcut for auto-generated title/body:
gh pr create --draft --fill
See pr-template.md for the full PR description template.
5. Continue Working
Push additional commits to the branch:
git add .
git commit -m "..."
git push
The PR automatically updates with each push.
6. Mark PR as Ready
When work is complete and CI passes:
gh pr ready
7. Merge After Review
After CI passes and review is complete:
gh pr merge --squash
gh pr view --web
When to Use This Workflow
ALWAYS use feature branches and draft PRs for:
- โ
New features
- โ
Bug fixes
- โ
Refactoring
- โ
Documentation updates
- โ
CI/CD changes
- โ
Any non-trivial changes
Direct commits to main are ONLY acceptable for:
- โ Emergency hotfixes (use with extreme caution)
- โ Version bumps for releases
PR Best Practices
Title Format
Follow Conventional Commits format:
feat: add emoji category filtering
fix: correct negative count validation
docs: update installation instructions
build(ci): add MSRV verification workflow
Description Structure
See pr-template.md, but include:
- Summary: What changed and why
- Changes: Bulleted list of key changes
- Test Plan: How to verify the changes work
- Breaking Changes: If applicable
- Related Issues: Link any related issues
Before Marking Ready
Checklist:
Common Commands
gh pr status
gh pr view --web
git branch --show-current
git log main..HEAD
git diff main...HEAD
Workflow Example
git checkout main
git pull origin main
git checkout -b feat/add-emoji-categories
git add src/lib.rs
git commit -m "feat: add emoji category support"
git push -u origin feat/add-emoji-categories
gh pr create --draft --title "feat: add emoji category filtering" \
--body "Implements emoji categorization and filtering by category"
git add .
git commit -m "feat: add category tests"
git push
gh pr ready
gh pr merge --squash
Error Prevention
DO NOT:
- Start work without creating a branch
- Commit directly to main
- Create PRs that aren't marked as draft initially
- Push without running tests locally first
- Skip the PR process for non-trivial changes
DO:
- Always start from updated main
- Use descriptive branch names
- Create draft PRs early in the process
- Keep PRs focused on a single change
- Ensure CI passes before marking ready
Source: ForceInjection/domain-driven-design-skills โ distributed by TomeVault.