Contributing

Contributors are welcome.

Usejarvis is still moving fast, and high-quality contributions are useful across the whole project: docs, bug fixes, workflows, sidecars, integrations, product polish, tests, and design.

Licensing

Usejarvis is source-available, not open source. The code is distributed under the Jarvis Source Available License 2.0 (based on RSALv2): you can read, use, modify, and redistribute it, but you cannot offer it or a modified version to third parties as a service. Read the LICENSE before contributing so you understand the terms your contribution lands under.

The daemon and dashboard are TypeScript (Bun); the sidecar is a Go program using cgo (webview, GTK/Cocoa overlays), so sidecar changes must compile for Linux and Windows in CI.

Good Ways to Contribute

Improve documentation
Reproduce and isolate bugs
Fix small focused issues
Add tests around existing behavior
Improve onboarding and setup clarity
Improve sidecar UX and observability
Suggest roadmap items or product direction

Where to Start

If you are new, the easiest places to start are:

Docs fixes
Small reproducible bug fixes
UI polish with clear before/after behavior
Developer experience improvements

Before You Open a PR

Try to make sure:

the change is scoped tightly
the problem statement is clear
the behavior is easy to review
the docs are updated when user-facing behavior changes

How to Contribute

1. Discuss the idea

Use one of these:

GitHub issues: https://github.com/vierisid/jarvis/issues
Discord: https://discord.gg/ytG2PHQ6rW

2. Fork and branch

Branch from main using a conventional prefix: feat/, fix/, docs/, refactor/, perf/, security/, infra/, or packaging/. CI auto-labels your PR from the branch name, and those labels drive the release changelog.

3. Make the change

Keep the change narrow and intentional. Smaller PRs are much easier to review and merge.

4. Run the checks

CI runs these on every push and PR, so run them locally first:

bun test
bunx tsc --noEmit
bun run scripts/check-no-ee-imports.ts
bun run scripts/check-migrations.ts

Enable the repo’s pre-commit hook with git config core.hooksPath .githooks to get the same gate locally. Note that the hook does not run Go: sidecar changes must additionally build for Linux and Windows (CI cross-compiles Windows via mingw-w64).

5. Open the PR

There is no PR template, so include these sections yourself:

what changed
why it changed
user impact
validation performed

Release notes are generated from PR labels (feature, bug, documentation, security, and so on), which come from your branch prefix. Add the skip-changelog label to keep a PR out of the release notes.

Docs Contributions

Docs contributions are especially welcome.

Good docs changes usually:

remove ambiguity
reduce setup confusion
explain real deployment mistakes
align the docs with the shipped product

If you notice something that is technically true but hard for users to understand, that is still a good docs problem to fix.

What Maintainers Usually Need

The most useful reports and PRs usually include:

exact error text
screenshots when relevant
current environment
whether Docker is involved
whether a reverse proxy is involved
what machine the daemon runs on
what machine sidecars or providers run on

Roadmap and Feature Ideas

If you want to suggest future product direction, also check:

/roadmap