Commit Workflow

Complete workflow for creating commits following project standards.

Process

1. Use commit-creator agent

   • Run /commit-staged [context] for automated commit handling
   • Or follow manual steps below

2. Analyze staged files only

   • Check all staged files: git diff --cached --name-only
   • Read diffs: git diff --cached
   • Completely ignore unstaged changes

3. Commit message format

   • First line: {task-type}: brief description of the big picture change
   • Task types: feat, fix, refactor, docs, style, test, build
   • Focus on ‘why’ and ‘what’, not implementation details
   • For complex changes, add bullet points after blank line

4. Message examples

   • feat: implement user authentication system
   • fix: resolve memory leak in data processing pipeline
   • refactor: restructure API handlers to align with project architecture

5. Documentation update

   • Check README.md for:
     • New features that should be documented
     • Outdated descriptions no longer matching implementation
     • Missing setup instructions for new dependencies
   • Update as needed based on staged changes

6. Execution

   • Commit uses HEREDOC syntax for proper formatting
   • Verify commit message has correct format
   • Don’t add test plans to commit messages

Best Practices

• Analyze staged files before writing message
• Keep first line concise (50 chars recommended)
• Use active voice in message
• Refere

…(truncated)

Pull Request Workflow

Complete workflow for creating pull requests following project standards.

Process

1. Verify staged changes exist with git diff --cached --name-only

2. Branch setup

   • If on main/master, create feature branch first: feature/brief-description or fix/brief-description
   • Use github-dev:commit-creator subagent to handle staged changes if needed

3. Documentation check

   • Update README.md or docs based on changes compared to target branch
   • For config/API changes, use mcp__tavily__tavily_search to verify info and include sources

4. Analyze all commits

   • Use git diff <base-branch>...HEAD to review complete changeset
   • PR message must describe all commits, not just latest
   • Focus on what changed from reviewer perspective

5. Create PR

   • Use /pr-creator agent or gh pr create with parameters:
     • -t (title): Start with capital letter, use verb, NO “fix:” or “feat:” prefix
     • -b (body): Brief summary + bullet points with inline markdown links
     • -a @me (self-assign)
     • -r <reviewer>: Find via gh pr list --repo <owner>/<repo> --author @me --limit 5

6. PR Body Guidelines

   • Summary: Few words or 1 sentence describing changes
   • Changes: Bullet points with inline links [src/auth.py:42](src/auth.py#L42)
   • Examples: For significant changes, include before/after code examples
   • No test plans: Never mention test procedures in PR

Examples

W

…(truncated)

GitHub CLI Setup

Configure gh CLI for GitHub access.

Quick Setup

gh auth login

Select: GitHub.com → HTTPS → Login with browser

Verify Authentication

gh auth status
gh api user --jq '.login'

Troubleshooting

If gh commands fail:

1. Check authentication - gh auth status
2. Re-login if needed - gh auth login
3. Check scopes - Ensure token has repo access
4. Update gh - brew upgrade gh or equivalent