Contributing to CLIAI
Thank you for your interest in contributing to CLIAI! We welcome contributions from the community and are excited to see what you'll bring to the project.
๐ Getting Started
Prerequisites
- Rust 1.70 or later
- Git
- Ollama (for testing AI functionality)
Development Setup
-
Fork and Clone
git clone https://github.com/yourusername/cliai.git cd cliai -
Install Dependencies
cargo build -
Set up Ollama (for testing)
# Install Ollama curl -fsSL https://ollama.ai/install.sh | sh # Pull a test model ollama pull mistral -
Run Tests
# Unit tests cargo test # Integration tests with AI cargo run -- test --quick
๐ฏ How to Contribute
Reporting Issues
- Use the GitHub Issues page
- Search existing issues before creating a new one
- Include detailed reproduction steps
- Provide system information (OS, Rust version, etc.)
Suggesting Features
- Open a GitHub Discussion first
- Describe the use case and expected behavior
- Consider implementation complexity and maintenance burden
Code Contributions
-
Create a Feature Branch
git checkout -b feature/your-feature-name -
Make Your Changes
- Follow the existing code style
- Add tests for new functionality
- Update documentation as needed
-
Test Your Changes
# Run all tests cargo test # Test with real AI (requires Ollama) cargo run -- test --categories "your-test-category" # Check formatting cargo fmt --check # Run clippy cargo clippy -- -D warnings -
Commit Your Changes
git add . git commit -m "feat: add amazing new feature" -
Push and Create PR
git push origin feature/your-feature-name
๐ Code Style Guidelines
Rust Code Style
- Use
cargo fmtfor consistent formatting - Follow Rust naming conventions
- Add documentation comments for public APIs
- Use
clippysuggestions to improve code quality
Commit Messages
We follow the Conventional Commits specification:
feat:- New featuresfix:- Bug fixesdocs:- Documentation changesstyle:- Code style changes (formatting, etc.)refactor:- Code refactoringtest:- Adding or updating testschore:- Maintenance tasks
Examples:
feat: add support for custom AI providers
fix: resolve command validation edge case
docs: update installation instructions
test: add integration tests for file operations
๐๏ธ Project Structure
Understanding the codebase:
src/
โโโ src/
โ โโโ main.rs # CLI interface and entry point
โ โโโ lib.rs # Library exports
โ โโโ agents/ # AI orchestration
โ โ โโโ mod.rs # Main orchestrator
โ โ โโโ profiles.rs # AI model profiles
โ โโโ config.rs # Configuration management
โ โโโ context.rs # System context gathering
โ โโโ execution.rs # Command execution
โ โโโ validation.rs # Command validation
โ โโโ providers.rs # AI provider implementations
โ โโโ history.rs # Chat history
โ โโโ performance.rs # Performance monitoring
โ โโโ error_handling.rs # Error handling
โ โโโ logging.rs # Privacy-preserving logging
โ โโโ test_suite.rs # Testing framework
โโโ Cargo.toml # Dependencies and metadata
โโโ README.md # Project documentation
โโโ CONTRIBUTING.md # This file
๐งช Testing Guidelines
Unit Tests
- Write tests for all public functions
- Use descriptive test names
- Test both success and error cases
- Mock external dependencies when possible
#![allow(unused)] fn main() { #[cfg(test)] mod tests { use super::*; #[test] fn test_command_validation_success() { // Test implementation } #[test] fn test_command_validation_failure() { // Test implementation } } }
Integration Tests
- Test real AI interactions when possible
- Use the built-in test suite for comprehensive testing
- Add new test categories for new features
Performance Tests
- Monitor performance impact of changes
- Use the built-in performance monitoring
- Add benchmarks for critical paths
๐ Security Considerations
Command Safety
- All command generation must go through validation
- New validation rules should be thoroughly tested
- Consider security implications of new features
Privacy Protection
- Never log user commands or prompts in production
- Ensure debug mode requires explicit consent
- Review data handling in new features
AI Provider Security
- Validate all AI responses
- Implement proper error handling for AI failures
- Consider rate limiting and abuse prevention
๐ Documentation
Code Documentation
- Document all public APIs with rustdoc comments
- Include examples in documentation
- Explain complex algorithms and design decisions
User Documentation
- Update README.md for user-facing changes
- Add examples for new features
- Update configuration documentation
๐ Recognition
Contributors will be recognized in:
- GitHub contributors list
- Release notes for significant contributions
- README acknowledgments section
โ Questions?
- Open a GitHub Discussion
- Check existing issues and discussions
- Reach out to maintainers
๐ Pull Request Checklist
Before submitting your PR, ensure:
- Code follows project style guidelines
-
All tests pass (
cargo test) - New functionality includes tests
- Documentation is updated
- Commit messages follow conventional format
- No sensitive information is included
- Performance impact is considered
- Security implications are reviewed
Thank you for contributing to CLIAI! ๐