Thanks for your interest in contributing.
Small fixes can go straight to a PR. Examples:
- typo fixes
- broken links
- small documentation improvements
- obvious bug fixes with a clear test or reproduction
For anything larger, please open an issue first and describe what you want to change before starting implementation. This includes:
- new features, commands, or subcommands
- changes to existing command behavior
- changes to flags, arguments, defaults, or output format
- larger refactors
This helps us confirm the direction, avoid duplicate work, and keep the project maintainable.
A draft PR is welcome if it helps explain the idea, but feature PRs should generally be discussed before they are reviewed or merged.
When opening a PR, please include:
- what changed
- why it changed
- how it was tested
- any related issue or discussion
Please keep PRs focused. Smaller PRs are easier to review and merge.
Before submitting, run the relevant checks locally. Add or update tests for bug fixes and new behavior.
Maintainers may ask for changes, suggest a different direction, or decline a PR if the approach was not discussed beforehand. That is not personal; it is how we keep the project consistent and sustainable.