Back to list
francisfuzz

git-workflow

by francisfuzz

Randomness at your command, emojis on a whim 🦀

0🍴 0📅 Dec 24, 2025

SKILL.md


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. allowed-tools: Bash, Read

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:

# Ensure you're on main and up-to-date
git checkout main
git pull origin main

# Create feature branch with conventional naming
git checkout -b <type>/<descriptive-name>

2. Branch Naming Convention

Use Conventional Commits prefixes:

PrefixUse ForExample
feat/New featuresfeat/add-emoji-categories
fix/Bug fixesfix/negative-count-validation
docs/Documentationdocs/update-readme-install
build/Build/CI changesbuild/add-msrv-check
test/Test additionstest/add-pool-size-validation
refactor/Code refactoringrefactor/extract-selection-logic
perf/Performanceperf/optimize-emoji-lookup
chore/Maintenancechore/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:

# Stage your changes
git add <files>

# Create commit following Conventional Commits
# (Use the conventional-commits Skill for proper formatting)
git commit -m "..."

# Push commits to remote
git push

4. Create Draft Pull Request

After first commit:

# Push branch to remote
git push -u origin <branch-name>

# Create draft PR
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:

# Make more changes
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:

# Via GitHub CLI
gh pr merge --squash

# Or use GitHub web UI
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:

  1. Summary: What changed and why
  2. Changes: Bulleted list of key changes
  3. Test Plan: How to verify the changes work
  4. Breaking Changes: If applicable
  5. Related Issues: Link any related issues

Before Marking Ready

Checklist:

  • All commits follow Conventional Commits format
  • Tests pass: ./docker-dev.sh test
  • Linting passes: ./docker-dev.sh clippy
  • Documentation updated if needed
  • PR description is complete
  • CI checks are passing

Common Commands

# View PR status
gh pr status

# View PR in browser
gh pr view --web

# Check current branch
git branch --show-current

# See what would be in PR
git log main..HEAD

# See diff vs main
git diff main...HEAD

Workflow Example

# 1. Start new feature
git checkout main
git pull origin main
git checkout -b feat/add-emoji-categories

# 2. Make changes
# ... edit files ...
git add src/lib.rs
git commit -m "feat: add emoji category support"

# 3. Push and create draft PR
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"

# 4. Continue working
# ... make more changes ...
git add .
git commit -m "feat: add category tests"
git push

# 5. When ready
gh pr ready

# 6. After CI and review
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

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
最近の活動

3ヶ月以内に更新

+5
フォーク

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

0/5
Issue管理

オープンIssueが50未満

+5
言語

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

+5
タグ

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

+5

Reviews

💬

Reviews coming soon