When should I use pr-workflow?

pr-workflow is useful in the following scenarios: • Automating pre-PR local validation (testing, building, and linting) to catch errors before they reach the remote repository. • Standardizing PR documentation using structured templates and naming conventions to improve project traceability and changelog clarity. • Enforcing strict quality gates by monitoring CI check statuses and requiring explicit approvals before allowing a squash-merge. • Managing development status through automated issue labeling and status updates to keep team members informed of progress and blockers.

When & Why to Use This Skill

This Claude skill streamlines the Pull Request (PR) lifecycle by enforcing a rigorous workflow that includes pre-validation checks, CI monitoring, and multi-stage review requirements. It ensures high code quality and project stability by automating GitHub CLI operations and strictly adhering to 'no-merge' safety protocols until all quality gates are passed.

Use Cases

Automating pre-PR local validation (testing, building, and linting) to catch errors before they reach the remote repository.
Standardizing PR documentation using structured templates and naming conventions to improve project traceability and changelog clarity.
Enforcing strict quality gates by monitoring CI check statuses and requiring explicit approvals before allowing a squash-merge.
Managing development status through automated issue labeling and status updates to keep team members informed of progress and blockers.

name	pr-workflow
description	Use when creating, reviewing, or merging pull requests. Includes CI checks, review requirements, and merge approval rules.

name

pr-workflow

description

Use when creating, reviewing, or merging pull requests. Includes CI checks, review requirements, and merge approval rules.

PR Merge Workflow

NEVER MERGE YOURSELF - ALWAYS WAIT FOR USER APPROVAL!

STEPS (All Required)

1. Pre-PR Validation

# Run quality checks
npm test           # or: go test ./...
npm run build      # or: go build ./...
npm run lint       # or: golangci-lint run

2. Create PR

gh pr create --title "type: description (closes #issue)" --body "..."

3. Wait for CI

gh pr checks <pr-number> --watch

4. Request Reviews

Code review from team member
Security review (if auth/API changes)
Mobile review (if UI changes)

5. Address Feedback

Fix all CRITICAL issues immediately
Fix HIGH issues before merge
Create follow-up tickets for MEDIUM/LOW

6. Wait for Approval

gh pr view <pr-number> --json reviews --jq '.reviews[] | select(.state == "APPROVED")'

IF NO APPROVAL -> STOP AND WAIT!

7. After Approval Only

gh pr merge <pr-number> --squash --delete-branch

REVIEW VERDICTS

Verdict	Action
PASS	Can be merged
NEEDS WORK	DO NOT merge! Fix first!
FAIL	DO NOT merge! Blocker!

PR TITLE CONVENTION

type: short description (closes #issue)

Types:
- feat: New feature
- fix: Bug fix
- refactor: Code refactoring
- docs: Documentation
- test: Adding tests
- chore: Maintenance

PR DESCRIPTION TEMPLATE

## Summary
- What changed and why

## Test Plan
- [ ] Unit tests added/updated
- [ ] Manual testing completed
- [ ] Edge cases verified

## Checklist
- [ ] Code follows project standards
- [ ] Tests pass (100% green)
- [ ] No TODOs in code
- [ ] Documentation updated (if needed)

ISSUE LABEL WORKFLOW

Label	When to Use
`in progress`	Actively working on issue
`blocked`	Waiting on dependency
`ready for review`	PR created, awaiting review

# Add label
gh issue edit <nr> --add-label "in progress"

# Add blocker comment
gh issue comment <nr> --body "Blocked by #<dependency> - [reason]"

NEVER DO

Merge without approval
Force push to shared branches
Skip CI checks
Merge with failing tests
Push directly to main

"Quality gates exist for a reason."