[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6EQ8JM0YRMBVNB1M6YAA4H4":3,"skill-same:01M6EQ8JM0YRMBVNB1M6YAA4H4":61},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":35,"repositoryHtmlUrl":36,"repositoryHomepageUrl":37,"ownerHtmlUrl":38,"ownerBlogUrl":6,"ownerDescription":39,"updatedAt":40,"install":41,"resources":54},"01M6EQ8JM0YRMBVNB1M6YAA4H4","pr-template-generator",null,"Generate comprehensive pull request descriptions that help reviewers understand changes quickly a...","ComeOnOliver\u002Fskillshub","ComeOnOliver","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43215937?v=4","01M6E5JNFECJAAVFE0W7SMWWD2","Haoran Shu","01M6E5JNNDQS7AJZDYFQ8TPZCK",66,"MIT","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fcuriouslearner\u002Fpr-template-generator\u002FSKILL.md",[],[19,20,21,22,23,24,25,26],"pr","template","pr template generator","pull request","generate","help","pull","understand","2026-11-10 10:12:30",false,"---\nname: pr-template-generator\ndescription: Generate comprehensive pull request descriptions that help reviewers understand changes quickly a...\n---\n\n# PR Template Generator Skill\n\nGenerate comprehensive pull request descriptions that help reviewers understand changes quickly and improve team collaboration.\n\n## Instructions\n\nYou are a pull request documentation expert. When invoked:\n\n1. **Analyze Changes**:\n   - Review git diff and commit history\n   - Identify type of changes (feature, bugfix, refactor, etc.)\n   - Understand the scope and impact\n   - Detect breaking changes\n   - Identify affected components\n\n2. **Generate PR Description**:\n   - Clear, concise title following conventions\n   - Comprehensive summary of changes\n   - Motivation and context\n   - Technical approach and decisions\n   - Testing strategy\n   - Deployment considerations\n\n3. **Include Checklist**:\n   - Pre-merge requirements\n   - Testing verification\n   - Documentation updates\n   - Breaking change warnings\n   - Migration steps if needed\n\n4. **Add Metadata**:\n   - Related issues and tickets\n   - Type labels (feature, bugfix, etc.)\n   - Priority and urgency\n   - Required reviewers\n   - Estimated review time\n\n5. **Communication Tips**:\n   - Use clear, non-technical language where possible\n   - Highlight reviewer focus areas\n   - Include screenshots\u002Frecordings for UI changes\n   - Link to relevant documentation\n   - Explain trade-offs and alternatives considered\n\n## PR Title Conventions\n\n### Format Patterns\n\n```\n# Conventional Commits Style\nfeat: Add user profile page\nfix: Resolve login redirect issue\nrefactor: Simplify authentication logic\ndocs: Update API documentation\ntest: Add integration tests for checkout\nchore: Update dependencies\nperf: Optimize database queries\nstyle: Fix linting issues\n\n# With Scope\nfeat(auth): Add OAuth2 provider support\nfix(api): Handle null responses correctly\nrefactor(database): Migrate to connection pooling\n\n# With Ticket Reference\nfeat: Add export functionality [JIRA-123]\nfix: Memory leak in websocket handler (#456)\n\n# Breaking Changes\nfeat!: Migrate to v2 API endpoints\nrefactor!: Remove deprecated methods\n```\n\n### Title Best Practices\n\n```\n✅ GOOD Titles:\n- feat: Add real-time notification system\n- fix: Prevent duplicate order submissions\n- refactor: Extract payment processing logic\n- perf: Reduce initial page load time by 40%\n\n❌ BAD Titles:\n- Update code\n- Fix bug\n- Changes\n- WIP\n- asdfasdf\n```\n\n## PR Description Templates\n\n### Feature Addition Template\n\n```markdown\n## Summary\n\nThis PR adds a comprehensive notification system that allows users to receive real-time updates about order status, messages, and system alerts.\n\n## Motivation\n\n**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.\n\n**Solution**: Implement a WebSocket-based notification system with persistent storage, allowing users to:\n- Receive real-time notifications\n- View notification history\n- Mark notifications as read\n- Configure notification preferences\n\n## Changes\n\n### Added\n- WebSocket server for real-time notifications (`src\u002Fwebsocket\u002F`)\n- Notification service and database schema (`src\u002Fmodels\u002FNotification.js`)\n- Frontend notification component with toast UI\n- User notification preferences page\n- Email fallback for offline users\n\n### Modified\n- Updated `User` model to include notification settings\n- Enhanced authentication middleware to support WebSocket connections\n- Modified dashboard to display notification bell icon\n\n### Removed\n- Old polling-based notification checker (deprecated)\n\n## Technical Details\n\n### Architecture\n```\nClient (React) \u003C--WebSocket--> Server (Node.js) \u003C--> Redis Pub\u002FSub \u003C--> Database\n```\n\n### Key Implementation Decisions\n1. **WebSocket vs. Server-Sent Events**: Chose WebSocket for bidirectional communication\n2. **Redis Pub\u002FSub**: Enables horizontal scaling across multiple server instances\n3. **Persistent Storage**: MongoDB for notification history (7-day retention)\n4. **Email Fallback**: Queue-based email notifications for offline users\n\n### Database Schema\n```javascript\n{\n  userId: ObjectId,\n  type: String,           \u002F\u002F 'order', 'message', 'system'\n  title: String,\n  message: String,\n  data: Object,           \u002F\u002F Type-specific payload\n  read: Boolean,\n  createdAt: Date,\n  expiresAt: Date        \u002F\u002F TTL index for auto-cleanup\n}\n```\n\n## Testing\n\n### Unit Tests\n- [x] Notification service (create, mark read, delete)\n- [x] WebSocket connection handling\n- [x] User preferences validation\n- [x] Email fallback queue\n\n### Integration Tests\n- [x] End-to-end notification flow\n- [x] Real-time delivery verification\n- [x] Reconnection after disconnect\n- [x] Multi-device synchronization\n\n### Manual Testing\n- [x] Tested in Chrome, Firefox, Safari\n- [x] Mobile responsiveness verified\n- [x] Tested with 100+ concurrent connections\n- [x] Verified email fallback with offline users\n\n## Screenshots\n\n### Notification Toast\n![Notification Toast](https:\u002F\u002Fexample.com\u002Fscreenshots\u002Ftoast.png)\n\n### Notification Center\n![Notification Center](https:\u002F\u002Fexample.com\u002Fscreenshots\u002Fcenter.png)\n\n### Settings Page\n![Settings](https:\u002F\u002Fexample.com\u002Fscreenshots\u002Fsettings.png)\n\n## Performance Impact\n\n- WebSocket connection: ~5KB per user\n- Redis memory: ~1MB per 10,000 notifications\n- Database: 200 writes\u002Fsec tested (current load: 10\u002Fsec)\n- Client bundle: +15KB gzipped\n\n## Breaking Changes\n\nNone - This is a new feature with no breaking changes to existing APIs.\n\n## Migration Guide\n\nNo migration needed. New notifications table will be created automatically via migration:\n\n```bash\nnpm run migrate:latest\n```\n\n## Deployment Notes\n\n### Prerequisites\n- Redis server required (update docker-compose.yml included)\n- Environment variables (see `.env.example`)\n- Run database migration before deployment\n\n### Configuration\n```bash\nREDIS_URL=redis:\u002F\u002Flocalhost:6379\nWEBSOCKET_PORT=3001\nNOTIFICATION_RETENTION_DAYS=7\nEMAIL_FALLBACK_ENABLED=true\n```\n\n### Rollout Strategy\n1. Deploy Redis infrastructure\n2. Run database migrations\n3. Deploy backend (rolling deployment)\n4. Deploy frontend (feature flag enabled)\n5. Monitor error rates and WebSocket connections\n6. Gradual rollout: 10% → 50% → 100% over 3 days\n\n## Documentation\n\n- [x] API documentation updated\n- [x] User guide created\n- [x] WebSocket protocol documented\n- [x] Troubleshooting guide added\n\n## Dependencies\n\n### New Dependencies\n- `ws` (^8.0.0) - WebSocket library\n- `ioredis` (^5.0.0) - Redis client\n- `socket.io-client` (^4.0.0) - Frontend WebSocket client\n\n### Security Audit\nAll new dependencies scanned with `npm audit` - no vulnerabilities found.\n\n## Checklist\n\n### Before Review\n- [x] Code follows project style guidelines\n- [x] All tests passing (unit + integration)\n- [x] No console.log statements in production code\n- [x] Documentation updated\n- [x] Accessibility tested (keyboard navigation, screen readers)\n- [x] Error handling implemented\n- [x] Logging added for debugging\n\n### Reviewer Focus Areas\n- ? **Security**: WebSocket authentication and authorization\n- ? **Performance**: Connection scaling and memory usage\n- ? **Error Handling**: Reconnection logic and edge cases\n- ? **UX**: Notification UI and user preferences\n\n### Post-Merge\n- [ ] Monitor error rates in production\n- [ ] Verify WebSocket connection stability\n- [ ] Check Redis memory usage\n- [ ] Gather user feedback on notification UX\n\n## Related Issues\n\nCloses #234\nRelated to #189, #201\n\n## Reviewers\n\n- @backend-team (WebSocket and Redis implementation)\n- @frontend-team (UI components and state management)\n- @qa-team (Testing strategy verification)\n\n**Estimated Review Time**: 30-45 minutes\n\n## Additional Notes\n\n- Feature flag: `ENABLE_NOTIFICATIONS` (default: false)\n- Backwards compatible with existing systems\n- Can be disabled without affecting core functionality\n- Monitoring dashboard: `\u002Fadmin\u002Fnotifications\u002Fstats`\n\n## Questions for Reviewers\n\n1. Should we add rate limiting per user for notification creation?\n2. Is 7-day retention sufficient, or should we increase it?\n3. Should we add push notifications (PWA) in this PR or separate?\n\n## Follow-up Tasks\n\n- [ ] Add push notification support (PWA) - Ticket #245\n- [ ] Implement notification grouping\u002Fbundling - Ticket #246\n- [ ] Add notification analytics dashboard - Ticket #247\n- [ ] Create notification templates system - Ticket #248\n```\n\n### Bug Fix Template\n\n```markdown\n## Summary\n\nFixes a critical bug where users were unable to submit orders when using discount codes that exceeded the order total, resulting in negative final amounts.\n\n## Issue\n\n**Bug Description**: When users applied discount codes worth more than their cart total, the checkout process would fail silently, leaving users unable to complete their purchase.\n\n**Impact**:\n- Severity: HIGH\n- Affected Users: ~500 users\u002Fday\n- Revenue Impact: Estimated $2,000\u002Fday in lost sales\n- First Reported: 2024-01-10\n- Browser: All browsers\n- Environment: Production only\n\n**Error Message**:\n```\nValidationError: Order total cannot be negative\n  at OrderService.validate (src\u002Fservices\u002FOrderService.js:45)\n```\n\n## Root Cause\n\nThe discount validation logic in `OrderService.calculateTotal()` was checking for negative amounts AFTER applying the discount, but before the minimum order total constraint was applied.\n\n```javascript\n\u002F\u002F ❌ BEFORE (Buggy Code)\nconst subtotal = calculateSubtotal(items);\nconst discountAmount = calculateDiscount(subtotal, discountCode);\nconst total = subtotal - discountAmount;\n\nif (total \u003C 0) {\n  throw new ValidationError('Order total cannot be negative');\n}\n\n\u002F\u002F Minimum order total check never reached\n```\n\nThe issue occurred because:\n1. Discount validation happened in wrong order\n2. No cap on discount amount vs. order total\n3. Frontend didn't validate before submission\n4. Error message wasn't user-friendly\n\n## Solution\n\n### Backend Changes\n\n```javascript\n\u002F\u002F ✅ AFTER (Fixed Code)\nconst subtotal = calculateSubtotal(items);\nconst discountAmount = calculateDiscount(subtotal, discountCode);\n\n\u002F\u002F Cap discount at subtotal amount\nconst cappedDiscount = Math.min(discountAmount, subtotal);\nconst total = Math.max(subtotal - cappedDiscount, 0);\n\n\u002F\u002F Ensure minimum order value if needed\nif (total > 0 && total \u003C MINIMUM_ORDER_TOTAL) {\n  throw new ValidationError(\n    `Order total must be at least $${MINIMUM_ORDER_TOTAL}`\n  );\n}\n```\n\n### Frontend Changes\n\nAdded client-side validation to prevent invalid submissions:\n- Check discount vs. cart total before submission\n- Display warning when discount exceeds total\n- Show final amount preview\n- Improved error messaging\n\n## Testing\n\n### Reproduction Steps (Before Fix)\n1. Add item to cart ($10)\n2. Apply discount code worth $15\n3. Proceed to checkout\n4. Click \"Place Order\"\n5. ❌ Order fails with validation error\n\n### Verification Steps (After Fix)\n1. Add item to cart ($10)\n2. Apply discount code worth $15\n3. ✅ Discount capped at $10 (free order)\n4. Proceed to checkout\n5. ✅ Order succeeds with $0 total\n\n### Test Cases Added\n\n```javascript\ndescribe('Order Discount Validation', () => {\n  it('should cap discount at subtotal amount', () => {\n    const order = { subtotal: 50, discount: 75 };\n    const total = calculateTotal(order);\n    expect(total).toBe(0);\n  });\n\n  it('should allow discounts equal to subtotal', () => {\n    const order = { subtotal: 100, discount: 100 };\n    const total = calculateTotal(order);\n    expect(total).toBe(0);\n  });\n\n  it('should apply partial discounts correctly', () => {\n    const order = { subtotal: 100, discount: 25 };\n    const total = calculateTotal(order);\n    expect(total).toBe(75);\n  });\n\n  it('should handle percentage discounts', () => {\n    const order = { subtotal: 100, discountPercent: 150 };\n    const total = calculateTotal(order);\n    expect(total).toBe(0); \u002F\u002F Capped at 100%\n  });\n});\n```\n\n### Regression Testing\n- [x] Normal discount codes (under total)\n- [x] Exact match discount codes\n- [x] Excessive discount codes (over total)\n- [x] Multiple discount codes\n- [x] Expired discount codes\n- [x] Invalid discount codes\n- [x] Free shipping combinations\n- [x] Tax calculations with discounts\n\n## Changes Made\n\n### Modified Files\n- `src\u002Fservices\u002FOrderService.js` - Fixed discount calculation logic\n- `src\u002Fvalidators\u002FOrderValidator.js` - Added discount amount validation\n- `src\u002Fcontrollers\u002FOrderController.js` - Improved error messages\n- `client\u002Fsrc\u002Fcomponents\u002FCheckout.jsx` - Added client-side validation\n- `client\u002Fsrc\u002Futils\u002FpriceCalculator.js` - Frontend discount preview\n\n### Tests Added\n- `tests\u002Funit\u002FOrderService.test.js` - Discount edge cases\n- `tests\u002Fintegration\u002Fcheckout.test.js` - End-to-end checkout flow\n\n## Deployment Plan\n\n### Pre-Deployment\n- [x] Notify customer support team about fix\n- [x] Prepare FAQ for users who encountered issue\n- [x] Database cleanup script for failed orders (if needed)\n\n### Deployment\n- Low-risk deployment (backwards compatible)\n- No database migrations required\n- Can be deployed during business hours\n- Estimated downtime: 0 minutes (rolling deployment)\n\n### Post-Deployment Monitoring\n- Monitor order success rate (expect 2-3% increase)\n- Track discount code usage patterns\n- Alert on validation errors\n- Customer support ticket volume\n\n### Rollback Plan\nIf issues detected:\n```bash\ngit revert \u003Ccommit-hash>\nnpm run deploy:production\n```\n\n## Checklist\n\n- [x] Bug reproduced and documented\n- [x] Root cause identified\n- [x] Fix implemented and tested\n- [x] Unit tests added\n- [x] Integration tests added\n- [x] Manual testing completed\n- [x] Edge cases covered\n- [x] Error messages improved\n- [x] Documentation updated\n- [x] Customer support notified\n\n## Related Issues\n\nFixes #312\nRelated to #298 (discount validation improvements)\n\n## Additional Notes\n\n### Future Improvements\n- Add admin alert for excessive discount codes\n- Implement discount code usage analytics\n- Consider A\u002FB testing discount UI improvements\n\n### Known Limitations\n- Does not address stacking multiple discount codes (separate issue #315)\n- Minimum order total validation could be improved (tracked in #316)\n```\n\n### Refactoring Template\n\n```markdown\n## Summary\n\nRefactors the payment processing module to improve code maintainability, testability, and separation of concerns. No functional changes or breaking changes.\n\n## Motivation\n\nThe current payment processing code has become difficult to maintain due to:\n- Multiple payment providers mixed in single file (~1,200 lines)\n- Tight coupling between business logic and provider APIs\n- Difficult to test (requires mocking multiple external services)\n- Code duplication across payment methods\n- Hard to add new payment providers\n\n**Technical Debt**: This refactoring addresses item #45 in our technical debt register.\n\n## Refactoring Goals\n\n1. **Separation of Concerns**: Extract provider-specific logic\n2. **Testability**: Enable mocking and unit testing\n3. **Maintainability**: Reduce file size and complexity\n4. **Extensibility**: Make adding new providers easier\n5. **Type Safety**: Add TypeScript interfaces\n\n## Changes Overview\n\n### Before (Problematic Structure)\n```\nsrc\u002Fservices\u002F\n  └── PaymentService.js (1,200 lines)\n      ├── Stripe logic\n      ├── PayPal logic\n      ├── Square logic\n      └── Common logic (mixed)\n```\n\n### After (Improved Structure)\n```\nsrc\u002Fservices\u002Fpayment\u002F\n  ├── PaymentService.js (200 lines)      \u002F\u002F Orchestration layer\n  ├── PaymentProvider.interface.ts       \u002F\u002F Provider contract\n  ├── providers\u002F\n  │   ├── StripeProvider.js (150 lines)\n  │   ├── PayPalProvider.js (180 lines)\n  │   └── SquareProvider.js (160 lines)\n  ├── utils\u002F\n  │   ├── currencyConverter.js\n  │   └── paymentValidator.js\n  └── tests\u002F\n      ├── PaymentService.test.js\n      └── providers\u002F\n          ├── StripeProvider.test.js\n          ├── PayPalProvider.test.js\n          └── SquareProvider.test.js\n```\n\n## Technical Details\n\n### Payment Provider Interface\n\n```typescript\ninterface PaymentProvider {\n  \u002F\u002F Provider identification\n  readonly name: string;\n  readonly supportedCurrencies: string[];\n\n  \u002F\u002F Core payment operations\n  createPaymentIntent(amount: number, currency: string, metadata?: object): Promise\u003CPaymentIntent>;\n  capturePayment(paymentId: string): Promise\u003CPaymentResult>;\n  refundPayment(paymentId: string, amount?: number): Promise\u003CRefundResult>;\n\n  \u002F\u002F Customer management\n  createCustomer(customerData: CustomerData): Promise\u003CCustomer>;\n  attachPaymentMethod(customerId: string, paymentMethodId: string): Promise\u003Cvoid>;\n\n  \u002F\u002F Webhooks\n  verifyWebhookSignature(payload: string, signature: string): boolean;\n  handleWebhookEvent(event: WebhookEvent): Promise\u003Cvoid>;\n}\n```\n\n### Refactored Service Layer\n\n```javascript\n\u002F\u002F ✅ AFTER: Clean orchestration\nclass PaymentService {\n  constructor() {\n    this.providers = {\n      stripe: new StripeProvider(config.stripe),\n      paypal: new PayPalProvider(config.paypal),\n      square: new SquareProvider(config.square)\n    };\n  }\n\n  async processPayment(orderId, paymentMethod, amount, currency) {\n    const provider = this.getProvider(paymentMethod);\n\n    try {\n      \u002F\u002F Business logic\n      const order = await this.validateOrder(orderId);\n      const convertedAmount = await this.convertCurrency(amount, currency);\n\n      \u002F\u002F Delegate to provider\n      const result = await provider.createPaymentIntent(\n        convertedAmount,\n        currency,\n        { orderId, customerId: order.customerId }\n      );\n\n      \u002F\u002F Store transaction\n      await this.saveTransaction(orderId, result);\n\n      return result;\n    } catch (error) {\n      await this.handlePaymentError(error, orderId);\n      throw error;\n    }\n  }\n\n  getProvider(method) {\n    const provider = this.providers[method];\n    if (!provider) {\n      throw new Error(`Unsupported payment method: ${method}`);\n    }\n    return provider;\n  }\n}\n```\n\n## Benefits\n\n### Improved Testability\n\n```javascript\n\u002F\u002F ✅ Easy to mock providers\ndescribe('PaymentService', () => {\n  it('should process payment with selected provider', async () => {\n    const mockProvider = {\n      createPaymentIntent: jest.fn().mockResolvedValue({ id: '123' })\n    };\n\n    const service = new PaymentService();\n    service.providers.stripe = mockProvider;\n\n    await service.processPayment('order-1', 'stripe', 100, 'USD');\n\n    expect(mockProvider.createPaymentIntent).toHaveBeenCalledWith(\n      100,\n      'USD',\n      expect.objectContaining({ orderId: 'order-1' })\n    );\n  });\n});\n```\n\n### Reduced Complexity\n\n| Metric | Before | After | Improvement |\n|--------|--------|-------|-------------|\n| Cyclomatic Complexity | 45 | 8 | 82% ↓ |\n| Lines of Code (main file) | 1,200 | 200 | 83% ↓ |\n| Test Coverage | 45% | 87% | 93% ↑ |\n| Number of Files | 1 | 12 | Better organization |\n\n### Easier to Extend\n\nAdding a new payment provider now requires:\n\n```javascript\n\u002F\u002F 1. Create new provider class\nclass NewProvider implements PaymentProvider {\n  \u002F\u002F Implement interface methods\n}\n\n\u002F\u002F 2. Register in service\nthis.providers.newprovider = new NewProvider(config);\n\n\u002F\u002F That's it! No changes to existing code.\n```\n\n## Testing\n\n### Test Coverage\n\n- [x] All existing tests still passing (100% backwards compatible)\n- [x] New unit tests for each provider (87% coverage)\n- [x] Integration tests for payment flows\n- [x] Error handling scenarios\n- [x] Provider switching logic\n\n### Regression Testing\n\nExtensive testing performed:\n- [x] All payment methods tested in staging\n- [x] Refund flows verified\n- [x] Webhook handling tested\n- [x] Currency conversion edge cases\n- [x] Error scenarios and retries\n\n## Migration Notes\n\n### Backwards Compatibility\n\n✅ **100% backwards compatible**\n\nAll existing API interfaces remain unchanged:\n```javascript\n\u002F\u002F Old code still works\npaymentService.processPayment(orderId, 'stripe', 100, 'USD');\n```\n\n### Database Changes\n\nNone required - this is purely code reorganization.\n\n### Configuration Changes\n\nOptional: New config structure (old structure still supported):\n\n```javascript\n\u002F\u002F New recommended structure\n{\n  payment: {\n    providers: {\n      stripe: { apiKey: '...', webhookSecret: '...' },\n      paypal: { clientId: '...', clientSecret: '...' },\n      square: { accessToken: '...', locationId: '...' }\n    }\n  }\n}\n```\n\n## Code Quality Improvements\n\n### ESLint Results\n- Before: 47 warnings, 12 errors\n- After: 0 warnings, 0 errors\n\n### Type Safety\n- Added TypeScript interfaces for all provider contracts\n- Improved IntelliSense and autocomplete\n- Compile-time error detection\n\n### Documentation\n- [x] JSDoc comments added to all public methods\n- [x] README updated with new architecture\n- [x] Provider implementation guide created\n- [x] Migration guide for future providers\n\n## Performance Impact\n\n### Benchmarks\n\nNo performance regression detected:\n\n| Operation | Before | After | Change |\n|-----------|--------|-------|--------|\n| Payment creation | 245ms | 242ms | -1.2% |\n| Refund processing | 180ms | 178ms | -1.1% |\n| Webhook handling | 95ms | 93ms | -2.1% |\n\nBundle size impact:\n- Main bundle: +2KB (0.1% increase)\n- Code splitting enabled: Individual provider modules loaded on demand\n\n## Deployment Plan\n\n### Risk Assessment\n- **Risk Level**: LOW (refactoring only, no business logic changes)\n- **Rollback Complexity**: Easy (git revert)\n- **Testing Coverage**: High (87% test coverage)\n\n### Deployment Strategy\n1. Deploy to staging environment\n2. Run full regression test suite\n3. Monitor for 24 hours\n4. Deploy to production (rolling deployment)\n5. Monitor payment success rates\n\n### Monitoring\n- Track payment success\u002Ffailure rates\n- Monitor provider-specific metrics\n- Alert on any regression in processing times\n\n## Checklist\n\n- [x] All existing tests pass\n- [x] New tests added (87% coverage)\n- [x] Code review completed\n- [x] No functional changes\n- [x] Performance benchmarked (no regression)\n- [x] Documentation updated\n- [x] Type definitions added\n- [x] ESLint\u002FPrettier applied\n- [x] Backwards compatible\n\n## Future Work\n\nThis refactoring enables:\n- [ ] Add Google Pay provider (#401)\n- [ ] Implement payment retry logic (#402)\n- [ ] Add payment analytics dashboard (#403)\n- [ ] Optimize currency conversion caching (#404)\n\n## Related Issues\n\nAddresses technical debt item #45\nRelated to #389 (payment provider abstraction discussion)\n\n## Review Notes\n\n**Focus Areas for Reviewers**:\n- Architecture and design patterns\n- Provider interface completeness\n- Test coverage and scenarios\n- Migration path for new providers\n\n**Estimated Review Time**: 45-60 minutes (larger refactor)\n```\n\n## Usage Examples\n\n```\n@pr-template-generator\n@pr-template-generator --type feature\n@pr-template-generator --type bugfix\n@pr-template-generator --type refactor\n@pr-template-generator --include-screenshots\n@pr-template-generator --minimal\n```\n\n## PR Description Checklist\n\n### Essential Elements\n- [ ] Clear title following conventions\n- [ ] Summary of changes (what and why)\n- [ ] Type of change (feature, bugfix, refactor, etc.)\n- [ ] Testing performed\n- [ ] Breaking changes documented\n- [ ] Related issues linked\n\n### Context and Motivation\n- [ ] Problem statement\n- [ ] Why this approach was chosen\n- [ ] Alternatives considered\n- [ ] Impact on users\u002Fsystem\n- [ ] Business value delivered\n\n### Technical Details\n- [ ] Architecture changes explained\n- [ ] Key implementation decisions documented\n- [ ] Database schema changes (if any)\n- [ ] API changes (if any)\n- [ ] Performance implications\n\n### Testing and Quality\n- [ ] Unit test coverage\n- [ ] Integration tests\n- [ ] Manual testing steps\n- [ ] Edge cases considered\n- [ ] Regression testing performed\n\n### Documentation\n- [ ] Code comments added\n- [ ] API docs updated\n- [ ] User documentation updated\n- [ ] README changes (if needed)\n- [ ] Migration guide (if needed)\n\n### Deployment\n- [ ] Deployment plan outlined\n- [ ] Configuration changes documented\n- [ ] Environment variables updated\n- [ ] Migration scripts included\n- [ ] Rollback plan defined\n\n### Visual Changes\n- [ ] Screenshots included\n- [ ] Before\u002Fafter comparisons\n- [ ] Mobile screenshots\n- [ ] Accessibility tested\n- [ ] Browser compatibility verified\n\n### Collaboration\n- [ ] Specific reviewers assigned\n- [ ] Review focus areas highlighted\n- [ ] Questions for reviewers listed\n- [ ] Estimated review time provided\n- [ ] Related team members tagged\n\n## Best Practices\n\n### Writing Clear Descriptions\n\n**DO**:\n- Use bullet points for easy scanning\n- Include code examples for complex changes\n- Add visual aids (screenshots, diagrams, recordings)\n- Explain the \"why\" not just the \"what\"\n- Be specific about impacts and trade-offs\n- Link to relevant documentation\n- Call out areas needing extra attention\n\n**DON'T**:\n- Use vague descriptions (\"updated code\", \"fixed stuff\")\n- Assume reviewers have full context\n- Skip testing information\n- Forget to link related issues\n- Ignore breaking changes\n- Rush the description\n- Use jargon without explanation\n\n### For Reviewers\n\nHelp reviewers by:\n- Estimating review time\n- Highlighting complex areas\n- Providing test accounts\u002Fdata if needed\n- Including step-by-step testing guide\n- Asking specific questions\n- Explaining non-obvious decisions\n\n### For Complex PRs\n\nFor large or complex PRs:\n- Break into smaller PRs when possible\n- Provide architecture diagrams\n- Record video walkthrough\n- Schedule synchronous review session\n- Create detailed testing guide\n- Explain migration strategy thoroughly\n\n## Communication Tips\n\n### Tone and Style\n- Be clear and concise\n- Use active voice\n- Be respectful and collaborative\n- Acknowledge uncertainty\n- Ask for feedback\n- Explain trade-offs objectively\n\n### Screenshots and Videos\n\nWhen to include visuals:\n- **Always**: UI\u002FUX changes\n- **Recommended**: Complex workflows, architecture changes\n- **Optional**: Backend-only changes\n\nTools for screenshots:\n- Chrome DevTools device mode (mobile screenshots)\n- Annotated screenshots (use arrows, highlights)\n- GIF recordings for interactions (LICEcap, ScreenToGif)\n- Video recordings for complex flows (Loom, QuickTime)\n\n### Code Examples\n\nInclude code snippets for:\n- API usage examples\n- Migration steps\n- Breaking changes\n- Complex logic explanation\n- Before\u002Fafter comparisons\n\n## GitHub-Specific Features\n\n### Using Markdown Features\n\n```markdown\n# Syntax highlighting\n```javascript\nconst example = 'code';\n```\n\n# Task lists\n- [x] Completed task\n- [ ] Pending task\n\n# Tables\n| Column 1 | Column 2 |\n|----------|----------|\n| Data     | Data     |\n\n# Collapsible sections\n\u003Cdetails>\n\u003Csummary>Click to expand\u003C\u002Fsummary>\nHidden content here\n\u003C\u002Fdetails>\n\n# Mentions\n@username for people\n#123 for issues\n\n# Labels and metadata\nCloses #123\nFixes #456\nRelated to #789\n```\n\n### PR Templates in Repository\n\nCreate `.github\u002Fpull_request_template.md`:\n\n```markdown\n## Description\n\u003C!-- Describe your changes -->\n\n## Type of Change\n- [ ] Bug fix\n- [ ] New feature\n- [ ] Breaking change\n- [ ] Documentation update\n\n## Testing\n\u003C!-- Describe testing performed -->\n\n## Checklist\n- [ ] Tests added\n- [ ] Documentation updated\n- [ ] No breaking changes\n```\n\n## Notes\n\n- Customize templates to match your team's workflow\n- Keep descriptions up-to-date as PR evolves\n- Use PR description as documentation for future reference\n- Good descriptions reduce review time and improve quality\n- Include deployment and rollback plans for production changes\n- Screenshots are worth a thousand words for UI changes\n- Always link related issues and tickets\n- Ask for help when uncertain\n- Be thorough but concise\n- Update description if implementation changes during review\n","# PR Template Generator Skill\n\nGenerate comprehensive pull request descriptions that help reviewers understand changes quickly and improve team collaboration.\n\n## Instructions\n\nYou are a pull request documentation expert. When invoked:\n\n1. **Analyze Changes**:\n   - Review git diff and commit history\n   - Identify type of changes (feature, bugfix, refactor, etc.)\n   - Understand the scope and impact\n   - Detect breaking changes\n   - Identify affected components\n\n2. **Generate PR Description**:\n   - Clear, concise title following conventions\n   - Comprehensive summary of changes\n   - Motivation and context\n   - Technical approach and decisions\n   - Testing strategy\n   - Deployment considerations\n\n3. **Include Checklist**:\n   - Pre-merge requirements\n   - Testing verification\n   - Documentation updates\n   - Breaking change warnings\n   - Migration steps if needed\n\n4. **Add Metadata**:\n   - Related issues and tickets\n   - Type labels (feature, bugfix, etc.)\n   - Priority and urgency\n   - Required reviewers\n   - Estimated review time\n\n5. **Communication Tips**:\n   - Use clear, non-technical language where possible\n   - Highlight reviewer focus areas\n   - Include screenshots\u002Frecordings for UI changes\n   - Link to relevant documentation\n   - Explain trade-offs and alternatives considered\n\n## PR Title Conventions\n\n### Format Patterns\n\n```\n# Conventional Commits Style\nfeat: Add user profile page\nfix: Resolve login redirect issue\nrefactor: Simplify authentication logic\ndocs: Update API documentation\ntest: Add integration tests for checkout\nchore: Update dependencies\nperf: Optimize database queries\nstyle: Fix linting issues\n\n# With Scope\nfeat(auth): Add OAuth2 provider support\nfix(api): Handle null responses correctly\nrefactor(database): Migrate to connection pooling\n\n# With Ticket Reference\nfeat: Add export functionality [JIRA-123]\nfix: Memory leak in websocket handler (#456)\n\n# Breaking Changes\nfeat!: Migrate to v2 API endpoints\nrefactor!: Remove deprecated methods\n```\n\n### Title Best Practices\n\n```\n✅ GOOD Titles:\n- feat: Add real-time notification system\n- fix: Prevent duplicate order submissions\n- refactor: Extract payment processing logic\n- perf: Reduce initial page load time by 40%\n\n❌ BAD Titles:\n- Update code\n- Fix bug\n- Changes\n- WIP\n- asdfasdf\n```\n\n## PR Description Templates\n\n### Feature Addition Template\n\n```markdown\n## Summary\n\nThis PR adds a comprehensive notification system that allows users to receive real-time updates about order status, messages, and system alerts.\n\n## Motivation\n\n**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.\n\n**Solution**: Implement a WebSocket-based notification system with persistent storage, allowing users to:\n- Receive real-time notifications\n- View notification history\n- Mark notifications as read\n- Configure notification preferences\n\n## Changes\n\n### Added\n- WebSocket server for real-time notifications (`src\u002Fwebsocket\u002F`)\n- Notification service and database schema (`src\u002Fmodels\u002FNotification.js`)\n- Frontend notification component with toast UI\n- User notification preferences page\n- Email fallback for offline users\n\n### Modified\n- Updated `User` model to include notification settings\n- Enhanced authentication middleware to support WebSocket connections\n- Modified dashboard to display notification bell icon\n\n### Removed\n- Old polling-based notification checker (deprecated)\n\n## Technical Details\n\n### Architecture\n```\nClient (React) \u003C--WebSocket--> Server (Node.js) \u003C--> Redis Pub\u002FSub \u003C--> Database\n```\n\n### Key Implementation Decisions\n1. **WebSocket vs. Server-Sent Events**: Chose WebSocket for bidirectional communication\n2. **Redis Pub\u002FSub**: Enables horizontal scaling across multiple server instances\n3. **Persistent Storage**: MongoDB for notification history (7-day retention)\n4. **Email Fallback**: Queue-based email notifications for offline users\n\n### Database Schema\n```javascript\n{\n  userId: ObjectId,\n  type: String,           \u002F\u002F 'order', 'message', 'system'\n  title: String,\n  message: String,\n  data: Object,           \u002F\u002F Type-specific payload\n  read: Boolean,\n  createdAt: Date,\n  expiresAt: Date        \u002F\u002F TTL index for auto-cleanup\n}\n```\n\n## Testing\n\n### Unit Tests\n- [x] Notification service (create, mark read, delete)\n- [x] WebSocket connection handling\n- [x] User preferences validation\n- [x] Email fallback queue\n\n### Integration Tests\n- [x] End-to-end notification flow\n- [x] Real-time delivery verification\n- [x] Reconnection after disconnect\n- [x] Multi-device synchronization\n\n### Manual Testing\n- [x] Tested in Chrome, Firefox, Safari\n- [x] Mobile responsiveness verified\n- [x] Tested with 100+ concurrent connections\n- [x] Verified email fallback with offline users\n\n## Screenshots\n\n### Notification Toast\n![Notification Toast](https:\u002F\u002Fexample.com\u002Fscreenshots\u002Ftoast.png)\n\n### Notification Center\n![Notification Center](https:\u002F\u002Fexample.com\u002Fscreenshots\u002Fcenter.png)\n\n### Settings Page\n![Settings](https:\u002F\u002Fexample.com\u002Fscreenshots\u002Fsettings.png)\n\n## Performance Impact\n\n- WebSocket connection: ~5KB per user\n- Redis memory: ~1MB per 10,000 notifications\n- Database: 200 writes\u002Fsec tested (current load: 10\u002Fsec)\n- Client bundle: +15KB gzipped\n\n## Breaking Changes\n\nNone - This is a new feature with no breaking changes to existing APIs.\n\n## Migration Guide\n\nNo migration needed. New notifications table will be created automatically via migration:\n\n```bash\nnpm run migrate:latest\n```\n\n## Deployment Notes\n\n### Prerequisites\n- Redis server required (update docker-compose.yml included)\n- Environment variables (see `.env.example`)\n- Run database migration before deployment\n\n### Configuration\n```bash\nREDIS_URL=redis:\u002F\u002Flocalhost:6379\nWEBSOCKET_PORT=3001\nNOTIFICATION_RETENTION_DAYS=7\nEMAIL_FALLBACK_ENABLED=true\n```\n\n### Rollout Strategy\n1. Deploy Redis infrastructure\n2. Run database migrations\n3. Deploy backend (rolling deployment)\n4. Deploy frontend (feature flag enabled)\n5. Monitor error rates and WebSocket connections\n6. Gradual rollout: 10% → 50% → 100% over 3 days\n\n## Documentation\n\n- [x] API documentation updated\n- [x] User guide created\n- [x] WebSocket protocol documented\n- [x] Troubleshooting guide added\n\n## Dependencies\n\n### New Dependencies\n- `ws` (^8.0.0) - WebSocket library\n- `ioredis` (^5.0.0) - Redis client\n- `socket.io-client` (^4.0.0) - Frontend WebSocket client\n\n### Security Audit\nAll new dependencies scanned with `npm audit` - no vulnerabilities found.\n\n## Checklist\n\n### Before Review\n- [x] Code follows project style guidelines\n- [x] All tests passing (unit + integration)\n- [x] No console.log statements in production code\n- [x] Documentation updated\n- [x] Accessibility tested (keyboard navigation, screen readers)\n- [x] Error handling implemented\n- [x] Logging added for debugging\n\n### Reviewer Focus Areas\n- ? **Security**: WebSocket authentication and authorization\n- ? **Performance**: Connection scaling and memory usage\n- ? **Error Handling**: Reconnection logic and edge cases\n- ? **UX**: Notification UI and user preferences\n\n### Post-Merge\n- [ ] Monitor error rates in production\n- [ ] Verify WebSocket connection stability\n- [ ] Check Redis memory usage\n- [ ] Gather user feedback on notification UX\n\n## Related Issues\n\nCloses #234\nRelated to #189, #201\n\n## Reviewers\n\n- @backend-team (WebSocket and Redis implementation)\n- @frontend-team (UI components and state management)\n- @qa-team (Testing strategy verification)\n\n**Estimated Review Time**: 30-45 minutes\n\n## Additional Notes\n\n- Feature flag: `ENABLE_NOTIFICATIONS` (default: false)\n- Backwards compatible with existing systems\n- Can be disabled without affecting core functionality\n- Monitoring dashboard: `\u002Fadmin\u002Fnotifications\u002Fstats`\n\n## Questions for Reviewers\n\n1. Should we add rate limiting per user for notification creation?\n2. Is 7-day retention sufficient, or should we increase it?\n3. Should we add push notifications (PWA) in this PR or separate?\n\n## Follow-up Tasks\n\n- [ ] Add push notification support (PWA) - Ticket #245\n- [ ] Implement notification grouping\u002Fbundling - Ticket #246\n- [ ] Add notification analytics dashboard - Ticket #247\n- [ ] Create notification templates system - Ticket #248\n```\n\n### Bug Fix Template\n\n```markdown\n## Summary\n\nFixes a critical bug where users were unable to submit orders when using discount codes that exceeded the order total, resulting in negative final amounts.\n\n## Issue\n\n**Bug Description**: When users applied discount codes worth more than their cart total, the checkout process would fail silently, leaving users unable to complete their purchase.\n\n**Impact**:\n- Severity: HIGH\n- Affected Users: ~500 users\u002Fday\n- Revenue Impact: Estimated $2,000\u002Fday in lost sales\n- First Reported: 2024-01-10\n- Browser: All browsers\n- Environment: Production only\n\n**Error Message**:\n```\nValidationError: Order total cannot be negative\n  at OrderService.validate (src\u002Fservices\u002FOrderService.js:45)\n```\n\n## Root Cause\n\nThe discount validation logic in `OrderService.calculateTotal()` was checking for negative amounts AFTER applying the discount, but before the minimum order total constraint was applied.\n\n```javascript\n\u002F\u002F ❌ BEFORE (Buggy Code)\nconst subtotal = calculateSubtotal(items);\nconst discountAmount = calculateDiscount(subtotal, discountCode);\nconst total = subtotal - discountAmount;\n\nif (total \u003C 0) {\n  throw new ValidationError('Order total cannot be negative');\n}\n\n\u002F\u002F Minimum order total check never reached\n```\n\nThe issue occurred because:\n1. Discount validation happened in wrong order\n2. No cap on discount amount vs. order total\n3. Frontend didn't validate before submission\n4. Error message wasn't user-friendly\n\n## Solution\n\n### Backend Changes\n\n```javascript\n\u002F\u002F ✅ AFTER (Fixed Code)\nconst subtotal = calculateSubtotal(items);\nconst discountAmount = calculateDiscount(subtotal, discountCode);\n\n\u002F\u002F Cap discount at subtotal amount\nconst cappedDiscount = Math.min(discountAmount, subtotal);\nconst total = Math.max(subtotal - cappedDiscount, 0);\n\n\u002F\u002F Ensure minimum order value if needed\nif (total > 0 && total \u003C MINIMUM_ORDER_TOTAL) {\n  throw new ValidationError(\n    `Order total must be at least $${MINIMUM_ORDER_TOTAL}`\n  );\n}\n```\n\n### Frontend Changes\n\nAdded client-side validation to prevent invalid submissions:\n- Check discount vs. cart total before submission\n- Display warning when discount exceeds total\n- Show final amount preview\n- Improved error messaging\n\n## Testing\n\n### Reproduction Steps (Before Fix)\n1. Add item to cart ($10)\n2. Apply discount code worth $15\n3. Proceed to checkout\n4. Click \"Place Order\"\n5. ❌ Order fails with validation error\n\n### Verification Steps (After Fix)\n1. Add item to cart ($10)\n2. Apply discount code worth $15\n3. ✅ Discount capped at $10 (free order)\n4. Proceed to checkout\n5. ✅ Order succeeds with $0 total\n\n### Test Cases Added\n\n```javascript\ndescribe('Order Discount Validation', () => {\n  it('should cap discount at subtotal amount', () => {\n    const order = { subtotal: 50, discount: 75 };\n    const total = calculateTotal(order);\n    expect(total).toBe(0);\n  });\n\n  it('should allow discounts equal to subtotal', () => {\n    const order = { subtotal: 100, discount: 100 };\n    const total = calculateTotal(order);\n    expect(total).toBe(0);\n  });\n\n  it('should apply partial discounts correctly', () => {\n    const order = { subtotal: 100, discount: 25 };\n    const total = calculateTotal(order);\n    expect(total).toBe(75);\n  });\n\n  it('should handle percentage discounts', () => {\n    const order = { subtotal: 100, discountPercent: 150 };\n    const total = calculateTotal(order);\n    expect(total).toBe(0); \u002F\u002F Capped at 100%\n  });\n});\n```\n\n### Regression Testing\n- [x] Normal discount codes (under total)\n- [x] Exact match discount codes\n- [x] Excessive discount codes (over total)\n- [x] Multiple discount codes\n- [x] Expired discount codes\n- [x] Invalid discount codes\n- [x] Free shipping combinations\n- [x] Tax calculations with discounts\n\n## Changes Made\n\n### Modified Files\n- `src\u002Fservices\u002FOrderService.js` - Fixed discount calculation logic\n- `src\u002Fvalidators\u002FOrderValidator.js` - Added discount amount validation\n- `src\u002Fcontrollers\u002FOrderController.js` - Improved error messages\n- `client\u002Fsrc\u002Fcomponents\u002FCheckout.jsx` - Added client-side validation\n- `client\u002Fsrc\u002Futils\u002FpriceCalculator.js` - Frontend discount preview\n\n### Tests Added\n- `tests\u002Funit\u002FOrderService.test.js` - Discount edge cases\n- `tests\u002Fintegration\u002Fcheckout.test.js` - End-to-end checkout flow\n\n## Deployment Plan\n\n### Pre-Deployment\n- [x] Notify customer support team about fix\n- [x] Prepare FAQ for users who encountered issue\n- [x] Database cleanup script for failed orders (if needed)\n\n### Deployment\n- Low-risk deployment (backwards compatible)\n- No database migrations required\n- Can be deployed during business hours\n- Estimated downtime: 0 minutes (rolling deployment)\n\n### Post-Deployment Monitoring\n- Monitor order success rate (expect 2-3% increase)\n- Track discount code usage patterns\n- Alert on validation errors\n- Customer support ticket volume\n\n### Rollback Plan\nIf issues detected:\n```bash\ngit revert \u003Ccommit-hash>\nnpm run deploy:production\n```\n\n## Checklist\n\n- [x] Bug reproduced and documented\n- [x] Root cause identified\n- [x] Fix implemented and tested\n- [x] Unit tests added\n- [x] Integration tests added\n- [x] Manual testing completed\n- [x] Edge cases covered\n- [x] Error messages improved\n- [x] Documentation updated\n- [x] Customer support notified\n\n## Related Issues\n\nFixes #312\nRelated to #298 (discount validation improvements)\n\n## Additional Notes\n\n### Future Improvements\n- Add admin alert for excessive discount codes\n- Implement discount code usage analytics\n- Consider A\u002FB testing discount UI improvements\n\n### Known Limitations\n- Does not address stacking multiple discount codes (separate issue #315)\n- Minimum order total validation could be improved (tracked in #316)\n```\n\n### Refactoring Template\n\n```markdown\n## Summary\n\nRefactors the payment processing module to improve code maintainability, testability, and separation of concerns. No functional changes or breaking changes.\n\n## Motivation\n\nThe current payment processing code has become difficult to maintain due to:\n- Multiple payment providers mixed in single file (~1,200 lines)\n- Tight coupling between business logic and provider APIs\n- Difficult to test (requires mocking multiple external services)\n- Code duplication across payment methods\n- Hard to add new payment providers\n\n**Technical Debt**: This refactoring addresses item #45 in our technical debt register.\n\n## Refactoring Goals\n\n1. **Separation of Concerns**: Extract provider-specific logic\n2. **Testability**: Enable mocking and unit testing\n3. **Maintainability**: Reduce file size and complexity\n4. **Extensibility**: Make adding new providers easier\n5. **Type Safety**: Add TypeScript interfaces\n\n## Changes Overview\n\n### Before (Problematic Structure)\n```\nsrc\u002Fservices\u002F\n  └── PaymentService.js (1,200 lines)\n      ├── Stripe logic\n      ├── PayPal logic\n      ├── Square logic\n      └── Common logic (mixed)\n```\n\n### After (Improved Structure)\n```\nsrc\u002Fservices\u002Fpayment\u002F\n  ├── PaymentService.js (200 lines)      \u002F\u002F Orchestration layer\n  ├── PaymentProvider.interface.ts       \u002F\u002F Provider contract\n  ├── providers\u002F\n  │   ├── StripeProvider.js (150 lines)\n  │   ├── PayPalProvider.js (180 lines)\n  │   └── SquareProvider.js (160 lines)\n  ├── utils\u002F\n  │   ├── currencyConverter.js\n  │   └── paymentValidator.js\n  └── tests\u002F\n      ├── PaymentService.test.js\n      └── providers\u002F\n          ├── StripeProvider.test.js\n          ├── PayPalProvider.test.js\n          └── SquareProvider.test.js\n```\n\n## Technical Details\n\n### Payment Provider Interface\n\n```typescript\ninterface PaymentProvider {\n  \u002F\u002F Provider identification\n  readonly name: string;\n  readonly supportedCurrencies: string[];\n\n  \u002F\u002F Core payment operations\n  createPaymentIntent(amount: number, currency: string, metadata?: object): Promise\u003CPaymentIntent>;\n  capturePayment(paymentId: string): Promise\u003CPaymentResult>;\n  refundPayment(paymentId: string, amount?: number): Promise\u003CRefundResult>;\n\n  \u002F\u002F Customer management\n  createCustomer(customerData: CustomerData): Promise\u003CCustomer>;\n  attachPaymentMethod(customerId: string, paymentMethodId: string): Promise\u003Cvoid>;\n\n  \u002F\u002F Webhooks\n  verifyWebhookSignature(payload: string, signature: string): boolean;\n  handleWebhookEvent(event: WebhookEvent): Promise\u003Cvoid>;\n}\n```\n\n### Refactored Service Layer\n\n```javascript\n\u002F\u002F ✅ AFTER: Clean orchestration\nclass PaymentService {\n  constructor() {\n    this.providers = {\n      stripe: new StripeProvider(config.stripe),\n      paypal: new PayPalProvider(config.paypal),\n      square: new SquareProvider(config.square)\n    };\n  }\n\n  async processPayment(orderId, paymentMethod, amount, currency) {\n    const provider = this.getProvider(paymentMethod);\n\n    try {\n      \u002F\u002F Business logic\n      const order = await this.validateOrder(orderId);\n      const convertedAmount = await this.convertCurrency(amount, currency);\n\n      \u002F\u002F Delegate to provider\n      const result = await provider.createPaymentIntent(\n        convertedAmount,\n        currency,\n        { orderId, customerId: order.customerId }\n      );\n\n      \u002F\u002F Store transaction\n      await this.saveTransaction(orderId, result);\n\n      return result;\n    } catch (error) {\n      await this.handlePaymentError(error, orderId);\n      throw error;\n    }\n  }\n\n  getProvider(method) {\n    const provider = this.providers[method];\n    if (!provider) {\n      throw new Error(`Unsupported payment method: ${method}`);\n    }\n    return provider;\n  }\n}\n```\n\n## Benefits\n\n### Improved Testability\n\n```javascript\n\u002F\u002F ✅ Easy to mock providers\ndescribe('PaymentService', () => {\n  it('should process payment with selected provider', async () => {\n    const mockProvider = {\n      createPaymentIntent: jest.fn().mockResolvedValue({ id: '123' })\n    };\n\n    const service = new PaymentService();\n    service.providers.stripe = mockProvider;\n\n    await service.processPayment('order-1', 'stripe', 100, 'USD');\n\n    expect(mockProvider.createPaymentIntent).toHaveBeenCalledWith(\n      100,\n      'USD',\n      expect.objectContaining({ orderId: 'order-1' })\n    );\n  });\n});\n```\n\n### Reduced Complexity\n\n| Metric | Before | After | Improvement |\n|--------|--------|-------|-------------|\n| Cyclomatic Complexity | 45 | 8 | 82% ↓ |\n| Lines of Code (main file) | 1,200 | 200 | 83% ↓ |\n| Test Coverage | 45% | 87% | 93% ↑ |\n| Number of Files | 1 | 12 | Better organization |\n\n### Easier to Extend\n\nAdding a new payment provider now requires:\n\n```javascript\n\u002F\u002F 1. Create new provider class\nclass NewProvider implements PaymentProvider {\n  \u002F\u002F Implement interface methods\n}\n\n\u002F\u002F 2. Register in service\nthis.providers.newprovider = new NewProvider(config);\n\n\u002F\u002F That's it! No changes to existing code.\n```\n\n## Testing\n\n### Test Coverage\n\n- [x] All existing tests still passing (100% backwards compatible)\n- [x] New unit tests for each provider (87% coverage)\n- [x] Integration tests for payment flows\n- [x] Error handling scenarios\n- [x] Provider switching logic\n\n### Regression Testing\n\nExtensive testing performed:\n- [x] All payment methods tested in staging\n- [x] Refund flows verified\n- [x] Webhook handling tested\n- [x] Currency conversion edge cases\n- [x] Error scenarios and retries\n\n## Migration Notes\n\n### Backwards Compatibility\n\n✅ **100% backwards compatible**\n\nAll existing API interfaces remain unchanged:\n```javascript\n\u002F\u002F Old code still works\npaymentService.processPayment(orderId, 'stripe', 100, 'USD');\n```\n\n### Database Changes\n\nNone required - this is purely code reorganization.\n\n### Configuration Changes\n\nOptional: New config structure (old structure still supported):\n\n```javascript\n\u002F\u002F New recommended structure\n{\n  payment: {\n    providers: {\n      stripe: { apiKey: '...', webhookSecret: '...' },\n      paypal: { clientId: '...', clientSecret: '...' },\n      square: { accessToken: '...', locationId: '...' }\n    }\n  }\n}\n```\n\n## Code Quality Improvements\n\n### ESLint Results\n- Before: 47 warnings, 12 errors\n- After: 0 warnings, 0 errors\n\n### Type Safety\n- Added TypeScript interfaces for all provider contracts\n- Improved IntelliSense and autocomplete\n- Compile-time error detection\n\n### Documentation\n- [x] JSDoc comments added to all public methods\n- [x] README updated with new architecture\n- [x] Provider implementation guide created\n- [x] Migration guide for future providers\n\n## Performance Impact\n\n### Benchmarks\n\nNo performance regression detected:\n\n| Operation | Before | After | Change |\n|-----------|--------|-------|--------|\n| Payment creation | 245ms | 242ms | -1.2% |\n| Refund processing | 180ms | 178ms | -1.1% |\n| Webhook handling | 95ms | 93ms | -2.1% |\n\nBundle size impact:\n- Main bundle: +2KB (0.1% increase)\n- Code splitting enabled: Individual provider modules loaded on demand\n\n## Deployment Plan\n\n### Risk Assessment\n- **Risk Level**: LOW (refactoring only, no business logic changes)\n- **Rollback Complexity**: Easy (git revert)\n- **Testing Coverage**: High (87% test coverage)\n\n### Deployment Strategy\n1. Deploy to staging environment\n2. Run full regression test suite\n3. Monitor for 24 hours\n4. Deploy to production (rolling deployment)\n5. Monitor payment success rates\n\n### Monitoring\n- Track payment success\u002Ffailure rates\n- Monitor provider-specific metrics\n- Alert on any regression in processing times\n\n## Checklist\n\n- [x] All existing tests pass\n- [x] New tests added (87% coverage)\n- [x] Code review completed\n- [x] No functional changes\n- [x] Performance benchmarked (no regression)\n- [x] Documentation updated\n- [x] Type definitions added\n- [x] ESLint\u002FPrettier applied\n- [x] Backwards compatible\n\n## Future Work\n\nThis refactoring enables:\n- [ ] Add Google Pay provider (#401)\n- [ ] Implement payment retry logic (#402)\n- [ ] Add payment analytics dashboard (#403)\n- [ ] Optimize currency conversion caching (#404)\n\n## Related Issues\n\nAddresses technical debt item #45\nRelated to #389 (payment provider abstraction discussion)\n\n## Review Notes\n\n**Focus Areas for Reviewers**:\n- Architecture and design patterns\n- Provider interface completeness\n- Test coverage and scenarios\n- Migration path for new providers\n\n**Estimated Review Time**: 45-60 minutes (larger refactor)\n```\n\n## Usage Examples\n\n```\n@pr-template-generator\n@pr-template-generator --type feature\n@pr-template-generator --type bugfix\n@pr-template-generator --type refactor\n@pr-template-generator --include-screenshots\n@pr-template-generator --minimal\n```\n\n## PR Description Checklist\n\n### Essential Elements\n- [ ] Clear title following conventions\n- [ ] Summary of changes (what and why)\n- [ ] Type of change (feature, bugfix, refactor, etc.)\n- [ ] Testing performed\n- [ ] Breaking changes documented\n- [ ] Related issues linked\n\n### Context and Motivation\n- [ ] Problem statement\n- [ ] Why this approach was chosen\n- [ ] Alternatives considered\n- [ ] Impact on users\u002Fsystem\n- [ ] Business value delivered\n\n### Technical Details\n- [ ] Architecture changes explained\n- [ ] Key implementation decisions documented\n- [ ] Database schema changes (if any)\n- [ ] API changes (if any)\n- [ ] Performance implications\n\n### Testing and Quality\n- [ ] Unit test coverage\n- [ ] Integration tests\n- [ ] Manual testing steps\n- [ ] Edge cases considered\n- [ ] Regression testing performed\n\n### Documentation\n- [ ] Code comments added\n- [ ] API docs updated\n- [ ] User documentation updated\n- [ ] README changes (if needed)\n- [ ] Migration guide (if needed)\n\n### Deployment\n- [ ] Deployment plan outlined\n- [ ] Configuration changes documented\n- [ ] Environment variables updated\n- [ ] Migration scripts included\n- [ ] Rollback plan defined\n\n### Visual Changes\n- [ ] Screenshots included\n- [ ] Before\u002Fafter comparisons\n- [ ] Mobile screenshots\n- [ ] Accessibility tested\n- [ ] Browser compatibility verified\n\n### Collaboration\n- [ ] Specific reviewers assigned\n- [ ] Review focus areas highlighted\n- [ ] Questions for reviewers listed\n- [ ] Estimated review time provided\n- [ ] Related team members tagged\n\n## Best Practices\n\n### Writing Clear Descriptions\n\n**DO**:\n- Use bullet points for easy scanning\n- Include code examples for complex changes\n- Add visual aids (screenshots, diagrams, recordings)\n- Explain the \"why\" not just the \"what\"\n- Be specific about impacts and trade-offs\n- Link to relevant documentation\n- Call out areas needing extra attention\n\n**DON'T**:\n- Use vague descriptions (\"updated code\", \"fixed stuff\")\n- Assume reviewers have full context\n- Skip testing information\n- Forget to link related issues\n- Ignore breaking changes\n- Rush the description\n- Use jargon without explanation\n\n### For Reviewers\n\nHelp reviewers by:\n- Estimating review time\n- Highlighting complex areas\n- Providing test accounts\u002Fdata if needed\n- Including step-by-step testing guide\n- Asking specific questions\n- Explaining non-obvious decisions\n\n### For Complex PRs\n\nFor large or complex PRs:\n- Break into smaller PRs when possible\n- Provide architecture diagrams\n- Record video walkthrough\n- Schedule synchronous review session\n- Create detailed testing guide\n- Explain migration strategy thoroughly\n\n## Communication Tips\n\n### Tone and Style\n- Be clear and concise\n- Use active voice\n- Be respectful and collaborative\n- Acknowledge uncertainty\n- Ask for feedback\n- Explain trade-offs objectively\n\n### Screenshots and Videos\n\nWhen to include visuals:\n- **Always**: UI\u002FUX changes\n- **Recommended**: Complex workflows, architecture changes\n- **Optional**: Backend-only changes\n\nTools for screenshots:\n- Chrome DevTools device mode (mobile screenshots)\n- Annotated screenshots (use arrows, highlights)\n- GIF recordings for interactions (LICEcap, ScreenToGif)\n- Video recordings for complex flows (Loom, QuickTime)\n\n### Code Examples\n\nInclude code snippets for:\n- API usage examples\n- Migration steps\n- Breaking changes\n- Complex logic explanation\n- Before\u002Fafter comparisons\n\n## GitHub-Specific Features\n\n### Using Markdown Features\n\n```markdown\n# Syntax highlighting\n```javascript\nconst example = 'code';\n```\n\n# Task lists\n- [x] Completed task\n- [ ] Pending task\n\n# Tables\n| Column 1 | Column 2 |\n|----------|----------|\n| Data     | Data     |\n\n# Collapsible sections\n\u003Cdetails>\n\u003Csummary>Click to expand\u003C\u002Fsummary>\nHidden content here\n\u003C\u002Fdetails>\n\n# Mentions\n@username for people\n#123 for issues\n\n# Labels and metadata\nCloses #123\nFixes #456\nRelated to #789\n```\n\n### PR Templates in Repository\n\nCreate `.github\u002Fpull_request_template.md`:\n\n```markdown\n## Description\n\u003C!-- Describe your changes -->\n\n## Type of Change\n- [ ] Bug fix\n- [ ] New feature\n- [ ] Breaking change\n- [ ] Documentation update\n\n## Testing\n\u003C!-- Describe testing performed -->\n\n## Checklist\n- [ ] Tests added\n- [ ] Documentation updated\n- [ ] No breaking changes\n```\n\n## Notes\n\n- Customize templates to match your team's workflow\n- Keep descriptions up-to-date as PR evolves\n- Use PR description as documentation for future reference\n- Good descriptions reduce review time and improve quality\n- Include deployment and rollback plans for production changes\n- Screenshots are worth a thousand words for UI changes\n- Always link related issues and tickets\n- Ask for help when uncertain\n- Be thorough but concise\n- Update description if implementation changes during review\n",{"name":5,"description":7},"main","def8531e65114c0fca8fb8551c1871ee0eed705c","skills\u002Faiskillstore\u002Fmarketplace\u002Fcuriouslearner\u002Fpr-template-generator",24,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub","https:\u002F\u002Fskillshub.wtf","https:\u002F\u002Fgithub.com\u002FComeOnOliver","AI & Blockchain Engineer\r\n","2026-06-24 22:07:19",{"source":8,"skillName":5,"commands":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add ComeOnOliver\u002Fskillshub --skill pr-template-generator",{"tool":47,"command":48},"bunx","bunx skills add ComeOnOliver\u002Fskillshub --skill pr-template-generator",{"tool":50,"command":51},"pnpm","pnpm dlx skills add ComeOnOliver\u002Fskillshub --skill pr-template-generator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fcuriouslearner\u002Fpr-template-generator\u002FSKILL.md",true,[55],{"path":56,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":60},"skill-report.json","REFERENCE","参考文档",17568,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fcuriouslearner\u002Fpr-template-generator\u002Fskill-report.json",[62,76,86,95,101,108],{"skillNo":63,"name":64,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":72,"publishedAt":27},"01M6FKJN13GMG4KY57J3QD8GY5","model-hierarchy-skill","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzscole\u002Fmodel-hierarchy-skill\u002Fmodel-hierarchy-skill\u002FSKILL.md",[67],{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[73,74,75],"model","model hierarchy","model hierarchy skill",{"skillNo":77,"name":78,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":82,"publishedAt":27},"01M6FKJJJ6GCAMR4PPPRD12M5X","zoom-mcp","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-mcp\u002FSKILL.md",[81],{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},[83,84,85],"MCP","zoom","zoom mcp",{"skillNo":87,"name":88,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":27},"01M6FKJE3KYT3KPEZMEEHYKA6K","zoom-apps-sdk","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-apps-sdk\u002FSKILL.md",[],[92,93,94,84],"sdk","zoom apps sdk","apps",{"skillNo":96,"name":97,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":27},"01M6FKJ9EDH9Q5VWDF8HAJRSP0","windows","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwindows\u002FSKILL.md",[],[97],{"skillNo":102,"name":103,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":107,"publishedAt":27},"01M6FKJ666BEEFC3AE9GJ72Q93","whiteboard","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwhiteboard\u002FSKILL.md",[106],{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},[103],{"skillNo":109,"name":110,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":27},"01M6FKJ21WFCDGTJQ2Q91T9DVW","websockets","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwebsockets\u002FSKILL.md",[],[110]]