# Pull Request
## Description
<!-- Provide a brief description of the changes in this PR -->
## Type of Change
<!-- Mark the type of change with an "x" -->
- [ ] 🐛 Bug fix (non-breaking change that fixes an issue)
- [ ] ✨ New feature (non-breaking change that adds functionality)
- [ ] 💥 Breaking change (fix or feature that causes existing functionality to change)
- [ ] 📚 Documentation update
- [ ] 🔧 Refactoring (code improvement without changing functionality)
- [ ] 🔒 Security fix
- [ ] ⚡ Performance improvement
- [ ] 🧪 Test improvements
## Related Issues
<!-- Link to related issues using keywords like "Fixes #123" or "Closes #456" -->
Fixes #
Relates to #
## Changes Made
<!-- Describe the specific changes made in this PR -->
-
-
-
## Testing
<!-- Describe how you tested your changes -->
### Test Coverage
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
- [ ] Test coverage meets the 75% threshold
### Manual Testing
- [ ] I have tested the changes manually
- [ ] The CLI tools work as expected
- [ ] MCP server integration works correctly
**Test Details:**
<!-- Describe your manual testing process -->
## Code Quality
- [ ] My code follows the style guidelines of this project (ruff, black, isort)
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] My changes generate no new warnings
- [ ] All linting checks pass (mypy, ruff, black)
## Security
- [ ] I have considered security implications of my changes
- [ ] Security scans pass (bandit, semgrep)
- [ ] No sensitive information is exposed in logs or error messages
- [ ] Input validation is properly implemented where applicable
## Documentation
- [ ] I have made corresponding changes to the documentation
- [ ] README.md is updated if user-facing functionality changed
- [ ] Code comments are clear and helpful
- [ ] API documentation is updated if applicable
## Breaking Changes
<!-- If this is a breaking change, describe what breaks and how users should adapt -->
**Breaking Change Details:**
- What breaks:
- Migration path:
- Compatibility notes:
## Performance Impact
<!-- Describe any performance implications -->
- [ ] No performance impact
- [ ] Performance improvement
- [ ] Performance regression (justified by functionality gain)
**Performance Notes:**
## Deployment Notes
<!-- Any special considerations for deployment -->
- [ ] No special deployment requirements
- [ ] Requires configuration changes
- [ ] Requires database migration
- [ ] Requires environment variable updates
## Screenshots/Examples
<!-- If applicable, add screenshots or code examples -->
## Checklist
<!-- Ensure all items are completed before requesting review -->
### Before Review
- [ ] All automated checks pass (CI pipeline)
- [ ] Code is properly formatted and linted
- [ ] Tests are written and passing
- [ ] Documentation is updated
- [ ] Security considerations addressed
### For Reviewers
- [ ] Code quality and style
- [ ] Test coverage and quality
- [ ] Security implications
- [ ] Performance impact
- [ ] Documentation completeness
- [ ] Breaking change assessment
## Additional Notes
<!-- Any additional information for reviewers -->
---
**Review Guidelines for Maintainers:**
1. **Code Quality**: Ensure code follows project standards and is well-documented
2. **Security**: Review for security implications and validate security scan results
3. **Testing**: Verify adequate test coverage and test quality
4. **Compatibility**: Check for breaking changes and backward compatibility
5. **Performance**: Assess performance impact of changes
6. **Documentation**: Ensure user-facing changes are properly documented
