Skip to main content
Welcome to the RTK contributor guide! We appreciate your interest in improving RTK. This guide will help you get started.

​
Code of Conduct

RTK follows standard open-source collaboration practices:
  • Be respectful: Treat all contributors with respect and professionalism
  • Be constructive: Provide helpful feedback and suggestions
  • Be patient: Everyone learns at different paces
  • Focus on facts: Technical discussions should be objective and evidence-based

​
Development Workflow

1

Fork and clone

Fork the RTK repository on GitHub and clone your fork locally:
2

Create a feature branch

Create a new branch for your changes:
3

Make your changes

Implement your feature or fix, following the Architecture and Testing guidelines.
4

Run quality gates

Before committing, run the full quality check pipeline:
All three checks must pass without warnings.
5

Commit your changes

Write clear, descriptive commit messages:
6

Push and create PR

Push your branch and create a pull request on GitHub:

​
Quality Gates

Every commit to RTK must pass three mandatory checks:

​
1. Formatting

Ensures consistent code style across the project. Run cargo fmt --all to auto-fix formatting issues.

​
2. Linting

Zero tolerance for clippy warnings. Fix all warnings before committing. Clippy catches:
  • Common mistakes and anti-patterns
  • Performance issues
  • Code complexity problems
  • Unsafe patterns

​
3. Testing

All existing tests must pass. New features require new tests (see Testing Guide).
Pre-commit hook: RTK includes a pre-commit hook that automatically enforces these checks. If the hook fails, fix the issues before committing.

​
Pull Request Process

​
Before Submitting

  • All quality gates pass (fmt, clippy, test)
  • New features have tests (60-90% token savings verified)
  • Documentation updated (README.md, CHANGELOG.md)
  • Manual testing completed (see Testing Policy)
  • Commit messages are clear and descriptive

​
PR Description Template

Provide a clear description of your changes:

​
Review Process

1

Automated checks

GitHub Actions runs security checks, builds, and tests on multiple platforms (macOS, Linux, Windows).
2

Security review

For PRs modifying critical files (runner.rs, tracking.rs, etc.), maintainers perform enhanced security review. See Security Guidelines.
3

Code review

Maintainers review your code for:
  • Correctness and functionality
  • Code quality and maintainability
  • Performance impact (<10ms startup time requirement)
  • Security considerations
4

Approval and merge

Once approved, maintainers will merge your PR. High-risk PRs require approval from 2 maintainers.
Performance regressions are release blockers. If your change affects startup time or memory usage, include benchmark results in your PR description.

​
Types of Contributions

​
Bug Fixes

  • Identify the bug with a minimal reproduction case
  • Write a failing test that demonstrates the bug
  • Fix the bug
  • Verify the test now passes
  • Update CHANGELOG.md

​
New Commands/Filters

See the Adding Commands Guide for detailed instructions on implementing new filters.

​
Documentation

  • Improve clarity and accuracy
  • Add examples and use cases
  • Fix typos and formatting
  • Keep documentation in sync with code

​
Performance Improvements

  • Benchmark before and after using hyperfine
  • Document performance gains in PR description
  • Ensure no regression in token savings

​
Getting Help

​
Recognition

All contributors are recognized in:
  • GitHub contributors page
  • CHANGELOG.md (for significant contributions)
  • Project README (for major features)
Thank you for contributing to RTK!