| name | pr |
| description | Creates pull requests with proper formatting. Use when creating PRs, opening pull requests, or preparing changes for review. |
Pull Requests
PR Title
Use Conventional Commit format, same as commit messages:
<type>(<scope>): <description>
Types
feat: User-facing features or behavior changes (must change production code)
fix: Bug fixes (must change production code)
docs: Documentation only
style: Code style/formatting (no logic changes)
refactor: Code restructuring without behavior change
test: Adding or updating tests
chore: CI/CD, tooling, dependency bumps, configs (no production code)
PR Description Template
## Summary
One sentence describing the overall change.
- Optional supporting details
- If needed
## Test plan
- [ ] How to verify it works
For any change to extraction or a check, the test plan must show the result against the committed fixture and the programmatic-mutation cases (structure removed → STRUCTURE_CHANGED, value changed → MISMATCH, etc.). For anything that sends a notification, confirm it was exercised with --dry-run and never delivered to a live recipient during testing.
Labels
Apply labels using gh pr create --label <label> or gh pr edit --add-label <label>.
Apply all labels that fit. Only use these labels:
enhancement - User-facing features or improvements (must change production code behavior)
refactor - Production code changes that don't alter behavior
bug - Fixes broken production code functionality
test - Changes to tests
documentation - Documentation changes
No label needed for dependency bumps, CI/CD, tooling, or infrastructure changes.
Branch Naming
Use type/short-description:
feat/google-business-check
fix/hours-normalization
chore/pre-commit-hooks
Instructions
- Run
git log main..HEAD to see commits for this branch
- Run
git diff main...HEAD to see all changes
- Summarize the changes in 1-2 sentences
- Create a test plan with verification steps
- Apply appropriate labels