Skip to main content

​
Will this be accepted?

Before you write code, check product fit:
  • Read PRODUCT.md — memory-first loop, one shared chat mind, trust over cleverness, integrations harness, taste floor.
  • Check the product invariant registry. Locked invariants (for example one shared transcript across notch and main chat) are binding; PRs that touch their paths must name the invariant ID.
  • Large or ambiguous features should start as a GitHub issue so maintainers can align on scope and direction before major implementation work begins.
Maintainers declining a PR for direction or taste will cite an invariant ID or open a proposed invariant the same week — so “project direction” stays written down, not tribal.

​
How to Contribute

1

Fork the Repository

Go to github.com/BasedHardware/Omi and click Fork.
2

Make Your Changes

Clone your fork, create a branch, and implement your changes.
3

Test Your Changes

Add focused tests and include the commands or manual steps you used to verify the change. Before pushing, draft the PR body and run scripts/pr-preflight --pr-body-file /path/to/draft-pr-body.md (use scripts/pr-preflight --suggest to get the paste-ready invariant ID block). Pre-push runs the same cheap contracts.
4

Create a Pull Request

Submit a PR and specify which issue it relates to. Name any product invariants your change affects.

​
Pull Request Quality

Good PRs are easy to review and come with evidence that the change works.
  • Bug fixes include the regression test that would have caught the bug.
  • Close the failure class. For a bug fix, describe the violated contract and the durable guard. If recent history contains the same cause, fix the shared boundary, state model, harness, compatibility check, or static contract rather than adding another call-site exception.
  • Small features can go straight to PR when they are well scoped: test the core path and the main error path, and describe any manual verification you did.
  • Large or ambiguous features should start as a GitHub issue so maintainers can align on scope and direction before major implementation work begins.
  • Show your verification. List the commands you ran and what they showed in the PR description. “It compiles” is not evidence — exercising the real user-facing path is.
  • Tests that run in CI must be hermetic — no live services, no network. Validation against a live service is welcome as extra evidence, but it can never be the only proof a PR works.
  • Behavioral tests execute production behavior. Source-string assertions are static tripwires only; they do not prove lifecycle, concurrency, or integration behavior.
  • Product invariants — if you touch paths listed on a locked invariant, name the ID (for example INV-CHAT-1) in the PR body.
  • Fast local PR contract check — draft the body, then run scripts/pr-preflight --pr-body-file /path/to/draft-pr-body.md. Use scripts/pr-preflight --suggest when you need the paste-ready invariant section. Once the branch has a PR, scripts/pr-preflight reads its current body automatically with gh (or set OMI_PR_BODY_FILE). Pre-push runs these same cheap contracts.

​
Contributing with an AI agent

Omi is built to be agent-friendly. If you use an AI coding agent, it will automatically pick up AGENTS.md at the repo root (plus per-component guides in backend/, app/, and desktop/macos/). The engineering standards there — especially the Definition of Done checklist — apply to your PR. Rules in that file about maintainer machines and landing on main directly don’t apply to fork-based contributions.

​
Documentation Contributions

Docs contributions are just as important as code contributions! Our docs are located in the GitHub docs folder and sync in real-time with docs.omi.me.
You can edit docs directly from GitHub: Fork the repo → click the edit icon → click “Preview” → create a pull request.

​
Contribution Rewards

Get rewarded for approved PRs with significant contributions:

1 PR

Free DevKit device (necklace or glasses, depending on contribution area)

2 PRs

$100 of transcription credits

5 PRs

$500 of transcription credits + special Contributor role in Discord

10 PRs

Trip to hang out with the Based Hardware team

​
What Qualifies as a Significant Contribution?

Something you spent 5+ hours on. Can be multiple smaller contributions that add up.
Either a new feature or a major bug fix.
Quality code with clear explanations, focused tests, and verification notes.
To claim your reward, email team@basedhardware.com with:
  • List of your contributions
  • Your address
  • Email and phone number
Get paid to improve AI wearables!

View Paid Bounties

Browse open issues with the “Paid Bounty” label

​
Bounty Rules

RuleDescription
Code must be mergedYour code must be merged into the master branch
EligibilityBounty eligibility is solely at our discretion
Locking a taskYou can “lock” a bounty task, but only after your first PR is merged
Claiming paymentEmail team@basedhardware.com with bounty link + PayPal account

​
No Bounties Available?

If there are no paid bounties available, you can suggest your own:
1

Browse Open Issues

Filter by open issues without the “bounty” label.
2

Suggest a Bounty

Comment on the issue and ping @josancamon19 or @kodjima33 with your bounty suggestion.

​
Get Started

GitHub Issues

Browse all open issues

Paid Bounties

View issues with bounties

Discord

Join the community

Documentation

Contribute to docs