Thanks for contributing! Our standard for PR contributions is one PR = one change. This allows us to keep reviews fast and the repo history clean.
Pull requests should be well scoped and every one should do exactly one thing.
Fixing a bug that's part of the change you're making is fine but if you find yourself fixing something unrelated along the way, open a separate PR for it.
✅ Good: "Add Fireworks to the model provider list" — the provider config, its model options, and the doc line for it.
❌ Too broad: "Add a new provider, refactor the credential onboarding flow, and fix a typo in the README" — three unrelated changes. You should split these into three PRs.
Run these locally so you don't get surprised by CI:
pnpm run format
pnpm run lint
pnpm testformat and lint match the checks that run on every PR, and test runs the
Vitest suite.
- Clear title — a single sentence describing the one change, prefixed with a
Conventional Commits type such as
feat:,fix:, orchore:(e.g.feat: add Fireworks to the model provider list). - What and why — briefly explain what the PR does and the reason for it.
- How you tested it — describe the tests (unit or end-to-end) that verify your change works and doesn't break existing behavior. If you added or updated tests, note them here.
- Link an issue for anything non-trivial, so the change has context.
If you are an agent opening a PR in this repository, these rules are binding. Keep your change tightly scoped to a single concern. If a change you're about to make would violate anything in this document, stop and surface it to the human instead of proceeding.
PRs that bundle multiple unrelated changes may be closed with a request to split them into separate, tightly scoped PRs.