Code Change Summarizer
Generate clear, structured pull request descriptions from code changes.
Workflow
1. Analyze Code Changes
Gather code changes:
- Git diff output
- Modified files list
- Commit messages
- Related issue numbers
Understand the changes:
- Read through all modified files
- Identify what changed (added/modified/removed/fixed)
- Understand the purpose of changes
- Note any patterns or themes
Categorize changes:
- Feature additions: New functionality
- Bug fixes: Issue resolutions
- Refactoring: Code improvements without behavior changes
- Documentation: Doc updates
- Tests: Test additions or modifications
- Dependencies: Package updates
- Configuration: Config or build changes
2. Create Initial Summary
Write a clear title:
Format: [Type] Brief description (max 72 characters)
Types:
feat:New featurefix:Bug fixrefactor:Code refactoringdocs:Documentationtest:Testschore:Maintenanceperf:Performancestyle:Code styleci:CI/CDbuild:Build system
Examples:
feat: Add user authentication with OAuth2fix: Resolve memory leak in data processorrefactor: Simplify error handling logic
Write summary paragraph:
- 2-3 sentences
- Explain what and why
- Use active voice
- Be concise and clear
Example:
This PR adds OAuth2 authentication to the user login system. The change
improves security by using industry-standard authentication and enables
single sign-on with external providers.
3. Document Changes
List changes by category:
Added:
- New features or functionality
- New files or components
- New API endpoints
Modified:
- Changed behavior or implementation
- Updated configuration
- Refactored code
Removed:
- Deprecated features
- Deleted files
- Removed dependencies
Fixed:
- Bug fixes
- Issue resolutions
- Error corrections
Example:
## Changes
### Added
- OAuth2 authentication flow
- User session management
- Login/logout endpoints
### Modified
- User model to include OAuth tokens
- Authentication middleware
- Database schema
### Fixed
- Session timeout not working correctly
- Memory leak in token refresh
4. Identify Breaking Changes
Check for breaking changes:
- API signature changes
- Removed functionality
- Changed behavior
- Configuration changes
- Database schema changes
- Dependency updates with breaking changes
Document each breaking change:
Format:
## Breaking Changes
⚠️ **[Breaking change description]**
**Impact:** [Who/what is affected]
**Migration Guide:**
1. [Step 1]
2. [Step 2]
**Before:**
```[language]
// Old code
After:
// New code
**Example:**
```markdown
## Breaking Changes
⚠️ **Authentication endpoint signature changed**
**Impact:** All API clients must update their authentication calls.
**Migration Guide:**
1. Update authentication endpoint from `/auth/login` to `/auth/oauth/login`
2. Include `provider` parameter in request body
3. Handle new response format with OAuth tokens
**Before:**
```javascript
POST /auth/login
{ "username": "user", "password": "pass" }
After:
POST /auth/oauth/login
{ "username": "user", "password": "pass", "provider": "google" }
### 5. Add Technical Details
**Explain implementation approach:**
- High-level technical approach
- Key algorithms or patterns used
- Important implementation details
**Document design decisions:**
- Why this approach was chosen
- Alternatives considered
- Trade-offs made
**Note architecture changes:**
- New components or modules
- Changed relationships
- Updated data flow
**Example:**
```markdown
## Technical Details
### Implementation Approach
Implemented OAuth2 using the Authorization Code flow with PKCE for enhanced
security. The authentication flow is handled by a new `AuthService` that
manages token exchange and refresh.
### Key Design Decisions
- **OAuth2 over SAML:** Chose OAuth2 for better mobile support and simpler
implementation
- **PKCE extension:** Added PKCE to protect against authorization code
interception attacks
- **Token storage:** Store refresh tokens in secure HTTP-only cookies
### Architecture Changes
- Added new `AuthService` layer between controllers and OAuth provider
- Introduced `TokenManager` for token lifecycle management
- Updated database schema to store OAuth provider information
6. Document Dependencies
List dependency changes:
Added dependencies:
- Package name and version
- Why it was added
- What it's used for
Updated dependencies:
- Old version → New version
- Why it was updated
- Any breaking changes
Removed dependencies:
- Package name
- Why it was removed
- What replaced it (if anything)
Example:
## Dependencies
### Added
- `passport@0.6.0` - OAuth2 authentication library
- `passport-google-oauth20@2.0.0` - Google OAuth2 strategy
### Updated
- `express@4.17.1` → `express@4.18.2` - Security patches and bug fixes
- `jsonwebtoken@8.5.1` → `jsonwebtoken@9.0.0` - Updated for Node 18 support
### Removed
- `bcrypt@5.0.1` - Replaced by OAuth2, no longer needed for password hashing
7. Provide Testing Instructions
Write step-by-step testing guide:
Format:
## Testing
### How to Test
1. [Setup step]
2. [Action to perform]
3. [Expected result]
4. [Edge case to verify]
### Test Coverage
- Added [X] unit tests
- Added [Y] integration tests
- Current coverage: [Z]%
### Manual Testing Checklist
- [ ] Test scenario 1
- [ ] Test scenario 2
- [ ] Test edge case 1
Example:
## Testing
### How to Test
1. Start the application: `npm start`
2. Navigate to `/login`
3. Click "Sign in with Google"
4. Complete OAuth flow in popup
5. Verify you're redirected back and logged in
6. Check that session persists after page refresh
### Test Coverage
- Added 15 unit tests for AuthService
- Added 8 integration tests for OAuth flow
- Current coverage: 87% (up from 82%)
### Manual Testing Checklist
- [ ] Google OAuth login works
- [ ] Session persists across page refreshes
- [ ] Logout clears session correctly
- [ ] Token refresh works when token expires
- [ ] Error handling for failed OAuth
8. Enhance with Context
Add security considerations:
- Security improvements made
- Security implications
- Vulnerabilities addressed
- Security review status
Add performance impact:
- Expected performance changes
- Benchmark results
- Optimization details
- Resource usage changes
Add architecture notes:
- Architectural patterns used
- System design changes
- Integration points
- Scalability considerations
Example:
## Security Considerations
### Improvements
- ✅ Implemented PKCE to prevent authorization code interception
- ✅ Store refresh tokens in HTTP-only cookies to prevent XSS
- ✅ Added rate limiting on authentication endpoints
- ✅ Validate OAuth state parameter to prevent CSRF
### Security Review
- [ ] Security team review pending
- [ ] Penetration testing scheduled
## Performance Impact
### Expected Changes
- Login time: ~500ms (OAuth redirect adds latency)
- Token validation: <10ms (cached in memory)
- Database queries: +2 per login (OAuth token storage)
### Optimizations
- Implemented token caching to reduce database hits
- Added connection pooling for OAuth provider requests
## Architecture Notes
### Patterns Used
- **Strategy Pattern:** Different OAuth providers (Google, GitHub, etc.)
- **Factory Pattern:** Token creation and validation
- **Middleware Pattern:** Authentication checks
### Integration Points
- Integrates with existing User model
- Hooks into session management middleware
- Compatible with existing authorization system
9. Add Documentation Notes
List documentation updates:
## Documentation
- [ ] Updated README with OAuth setup instructions
- [ ] Added API documentatio