pr-template-generator

What this skill does

# PR Template Generator Skill

Generate comprehensive pull request descriptions that help reviewers understand changes quickly and improve team collaboration.

## Instructions

You are a pull request documentation expert. When invoked:

1. **Analyze Changes**:
   - Review git diff and commit history
   - Identify type of changes (feature, bugfix, refactor, etc.)
   - Understand the scope and impact
   - Detect breaking changes
   - Identify affected components

2. **Generate PR Description**:
   - Clear, concise title following conventions
   - Comprehensive summary of changes
   - Motivation and context
   - Technical approach and decisions
   - Testing strategy
   - Deployment considerations

3. **Include Checklist**:
   - Pre-merge requirements
   - Testing verification
   - Documentation updates
   - Breaking change warnings
   - Migration steps if needed

4. **Add Metadata**:
   - Related issues and tickets
   - Type labels (feature, bugfix, etc.)
   - Priority and urgency
   - Required reviewers
   - Estimated review time

5. **Communication Tips**:
   - Use clear, non-technical language where possible
   - Highlight reviewer focus areas
   - Include screenshots/recordings for UI changes
   - Link to relevant documentation
   - Explain trade-offs and alternatives considered

## PR Title Conventions

### Format Patterns

```
# Conventional Commits Style
feat: Add user profile page
fix: Resolve login redirect issue
refactor: Simplify authentication logic
docs: Update API documentation
test: Add integration tests for checkout
chore: Update dependencies
perf: Optimize database queries
style: Fix linting issues

# With Scope
feat(auth): Add OAuth2 provider support
fix(api): Handle null responses correctly
refactor(database): Migrate to connection pooling

# With Ticket Reference
feat: Add export functionality [JIRA-123]
fix: Memory leak in websocket handler (#456)

# Breaking Changes
feat!: Migrate to v2 API endpoints
refactor!: Remove deprecated methods
```

### Title Best Practices

```
✅ GOOD Titles:
- feat: Add real-time notification system
- fix: Prevent duplicate order submissions
- refactor: Extract payment processing logic
- perf: Reduce initial page load time by 40%

❌ BAD Titles:
- Update code
- Fix bug
- Changes
- WIP
- asdfasdf
```

## PR Description Templates

### Feature Addition Template

```markdown
## Summary

This PR adds a comprehensive notification system that allows users to receive real-time updates about order status, messages, and system alerts.

## Motivation

**Problem**: Users currently have no way to receive updates about important events without refreshing the page or checking email. This leads to delayed responses and poor user experience.

**Solution**: Implement a WebSocket-based notification system with persistent storage, allowing users to:
- Receive real-time notifications
- View notification history
- Mark notifications as read
- Configure notification preferences

## Changes

### Added
- WebSocket server for real-time notifications (`src/websocket/`)
- Notification service and database schema (`src/models/Notification.js`)
- Frontend notification component with toast UI
- User notification preferences page
- Email fallback for offline users

### Modified
- Updated `User` model to include notification settings
- Enhanced authentication middleware to support WebSocket connections
- Modified dashboard to display notification bell icon

### Removed
- Old polling-based notification checker (deprecated)

## Technical Details

### Architecture
```
Client (React) <--WebSocket--> Server (Node.js) <--> Redis Pub/Sub <--> Database
```

### Key Implementation Decisions
1. **WebSocket vs. Server-Sent Events**: Chose WebSocket for bidirectional communication
2. **Redis Pub/Sub**: Enables horizontal scaling across multiple server instances
3. **Persistent Storage**: MongoDB for notification history (7-day retention)
4. **Email Fallback**: Queue-based email notifications for offline users

### Database Schema
```javascript
{
  userId: ObjectId,
  type: String,           // 'order', 'message', 'system'
  title: String,
  message: String,
  data: Object,           // Type-specific payload
  read: Boolean,
  createdAt: Date,
  expiresAt: Date        // TTL index for auto-cleanup
}
```

## Testing

### Unit Tests
- [x] Notification service (create, mark read, delete)
- [x] WebSocket connection handling
- [x] User preferences validation
- [x] Email fallback queue

### Integration Tests
- [x] End-to-end notification flow
- [x] Real-time delivery verification
- [x] Reconnection after disconnect
- [x] Multi-device synchronization

### Manual Testing
- [x] Tested in Chrome, Firefox, Safari
- [x] Mobile responsiveness verified
- [x] Tested with 100+ concurrent connections
- [x] Verified email fallback with offline users

## Screenshots

### Notification Toast
![Notification Toast](https://example.com/screenshots/toast.png)

### Notification Center
![Notification Center](https://example.com/screenshots/center.png)

### Settings Page
![Settings](https://example.com/screenshots/settings.png)

## Performance Impact

- WebSocket connection: ~5KB per user
- Redis memory: ~1MB per 10,000 notifications
- Database: 200 writes/sec tested (current load: 10/sec)
- Client bundle: +15KB gzipped

## Breaking Changes

None - This is a new feature with no breaking changes to existing APIs.

## Migration Guide

No migration needed. New notifications table will be created automatically via migration:

```bash
npm run migrate:latest
```

## Deployment Notes

### Prerequisites
- Redis server required (update docker-compose.yml included)
- Environment variables (see `.env.example`)
- Run database migration before deployment

### Configuration
```bash
REDIS_URL=redis://localhost:6379
WEBSOCKET_PORT=3001
NOTIFICATION_RETENTION_DAYS=7
EMAIL_FALLBACK_ENABLED=true
```

### Rollout Strategy
1. Deploy Redis infrastructure
2. Run database migrations
3. Deploy backend (rolling deployment)
4. Deploy frontend (feature flag enabled)
5. Monitor error rates and WebSocket connections
6. Gradual rollout: 10% → 50% → 100% over 3 days

## Documentation

- [x] API documentation updated
- [x] User guide created
- [x] WebSocket protocol documented
- [x] Troubleshooting guide added

## Dependencies

### New Dependencies
- `ws` (^8.0.0) - WebSocket library
- `ioredis` (^5.0.0) - Redis client
- `socket.io-client` (^4.0.0) - Frontend WebSocket client

### Security Audit
All new dependencies scanned with `npm audit` - no vulnerabilities found.

## Checklist

### Before Review
- [x] Code follows project style guidelines
- [x] All tests passing (unit + integration)
- [x] No console.log statements in production code
- [x] Documentation updated
- [x] Accessibility tested (keyboard navigation, screen readers)
- [x] Error handling implemented
- [x] Logging added for debugging

### Reviewer Focus Areas
- 🔍 **Security**: WebSocket authentication and authorization
- 🔍 **Performance**: Connection scaling and memory usage
- 🔍 **Error Handling**: Reconnection logic and edge cases
- 🔍 **UX**: Notification UI and user preferences

### Post-Merge
- [ ] Monitor error rates in production
- [ ] Verify WebSocket connection stability
- [ ] Check Redis memory usage
- [ ] Gather user feedback on notification UX

## Related Issues

Closes #234
Related to #189, #201

## Reviewers

- @backend-team (WebSocket and Redis implementation)
- @frontend-team (UI components and state management)
- @qa-team (Testing strategy verification)

**Estimated Review Time**: 30-45 minutes

## Additional Notes

- Feature flag: `ENABLE_NOTIFICATIONS` (default: false)
- Backwards compatible with existing systems
- Can be disabled without affecting core functionality
- Monitoring dashboard: `/admin/notifications/stats`

## Questions for Reviewers

1. Should we add rate limiting per user for notification creation?
2. Is 7-day retention sufficient, or should we increase it?
3. Should we add push notifications (PWA) in this PR o