Push Pr Review Merge

---
description: Push committed changes to remote, create PR, initiate code review, iterate until ready, merge if approved
---

# Push, PR, Review, and Merge

## Context Loading (profile:ship)
Before creating PRs, run `npm test` to verify pre-commit tests pass.

You are tasked with handling the post-commit Git workflow: pushing to remote, creating PR, reviewing iteratively, and merging if approved.

## Process:

### 1. Assess Current State
- Run `git status` to confirm commits exist
- Check current branch name
- If on main/master, create feature branch with descriptive name based on commits
- Ensure branch naming follows: `<type>/<short-description>` (e.g., `feat/email-validation`, `fix/auth-bug`)

### 2. Push to Remote
- Run `git push origin <branch>` or `git push -u origin <branch>` if first push
- Handle any push errors (authentication, conflicts, etc.)
- Verify push succeeded

### 3. Create Pull Request
Use GitHub CLI (`gh`) to create PR:
```bash
gh pr create --title "PR Title" --body "PR Description"

PR Title Format:

• Imperative mood, present tense
• Concise summary of changes
• Example: "Add email validation with comprehensive security testing"

PR Body Structure:

## Summary
[Brief overview of what changed and why]

## Changes
- [Change 1]
- [Change 2]
- [Change 3]

## Test Plan
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] E2E tests pass (if applicable)
- [ ] Manual testing completed

## Related Issues
Closes #[issue-number] (if applicable)

---
🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

4. Initiate Multi-Perspective Code Review

Conduct comprehensive reviews from 6 different perspectives. For EACH perspective:

a) Product Manager Review

Focus Areas:

• Business value and ROI assessment
• User experience impact
• Strategic alignment with product goals
• Feature completeness

Action: Post review comment with:

• Approval/Request Changes decision
• Business impact assessment
• Recommended improvements (if any)

b) Developer Review

Focus Areas:

• Code quality and maintainability
• Performance and scalability
• Adherence to coding standards
• Architecture consistency
• Documentation completeness

Action: Post review comment with:

• Approval/Request Changes decision
• Technical issues found
• Code improvement suggestions
• Performance concerns

c) Quality Engineer Review

Focus Areas:

• Test coverage (unit, integration, E2E)
• Edge cases and potential bugs
• Regression risk assessment
• Test quality and effectiveness

Action: Post review comment with:

• Approval/Request Changes decision
• Missing test scenarios
• Edge cases not covered
• Recommended additional tests

d) Security Engineer Review

Focus Areas:

• Security vulnerabilities (OWASP Top 10)
• Data handling and privacy
• Authentication/authorization issues
• Input validation and sanitization
• Compliance (GDPR, HIPAA if applicable)

Action: Post review comment with:

• Approval/Request Changes decision
• Security issues identified
• Vulnerability severity ratings
• Required security fixes

e) DevOps Review

Focus Areas:

• CI/CD pipeline compatibility
• Infrastructure and configuration changes
• Monitoring and alerting needs
• Deployment considerations
• Performance monitoring

Action: Post review comment with:

• Approval/Request Changes decision
• Infrastructure requirements
• Deployment risks
• Monitoring recommendations

f) UI/UX Designer Review

Focus Areas:

• Visual consistency with design system
• Usability and accessibility (WCAG)
• User flow and interaction design
• Responsive design considerations

Action: Post review comment with:

• Approval/Request Changes decision
• Design inconsistencies
• Accessibility issues
• UX improvements

5. Iterative Review Process

After posting all 6 reviews:

1. Analyze Review Feedback:

   • Count approvals vs requests for changes
   • Identify blocking issues
   • Categorize issues by severity (critical, important, minor)

2. Apply Fixes for Issues:

   • For each blocking issue found:
     • Implement the fix
     • Create atomic commit for the fix
     • Push fix to branch
     • Post comment acknowledging fix

3. Re-review After Fixes:

   • Re-run reviews from perspectives that requested changes
   • Verify issues are resolved
   • Update approval status

4. Track Approval Status:

   Product Manager: ✅ Approved
   Developer: ✅ Approved
   Quality Engineer: ⚠️ Requested Changes
   Security Engineer: ✅ Approved
   DevOps: ✅ Approved
   UI/UX Designer: ✅ Approved
   
   Status: 5/6 approvals (1 pending fixes)
   

5. Iterate Until Ready:

   • Continue fixing and re-reviewing until all 6 perspectives approve
   • Maximum 3 iteration cycles (prevent infinite loops)
   • If stuck after 3 cycles, report issues and request human intervention

6. Merge if Approved

Approval Criteria:

• All 6 perspective reviews approve
• No blocking comments remain
• CI checks pass (if configured)
• Branch is up-to-date with base branch

Merge Process:

# Check PR status
gh pr view --json state,mergeable,reviewDecision

# If approved and mergeable:
gh pr merge --squash --delete-branch

# Or use rebase strategy if preferred:
gh pr merge --rebase --delete-branch

Post-Merge:

• Confirm merge succeeded
• Verify branch was deleted
• Post summary of merge

7. Sync Cloudflare Worker (MANDATORY)

CRITICAL: After every successful merge, synchronize the Cloudflare Worker with Vercel's CRON_SECRET.

This step prevents HMAC authentication failures that cause pipeline stalls. The CRON_SECRET must be identical between Vercel and Cloudflare Worker.

Sync Process:

# Run the sync script from project root
./scripts/sync-cloudflare-worker-secret.sh

What this does:

1. Pulls CRON_SECRET from Vercel production environment
2. Validates the secret (checks for trailin