Contributing
How to set up a dev environment, run tests, get a release out, and add docs. The four pages here are everything you need to make and ship a change.
Pages
| Page | Read when |
|---|---|
| Development setup | Before your first PR — toolchain, repo layout, common workflows |
| Testing strategy | Before adding tests — what each test layer (unit / integration / E2E) is for |
| Release flow | When you want to know how your merged PR becomes a published release |
| Documentation guide | When adding or editing pages on this docs site |
Reading order
For a first-time contributor:
- Development setup — get the build green locally.
- Testing strategy — write the right kind of test for your change.
- Open the PR. The CI on
nextdoes the rest. - Release flow — read this once so you know how betas and stable releases differ.
For a docs-only PR, skip straight to Documentation guide.
Branching model in one paragraph
next is the integration branch — every merge produces a X.Y.Z-beta.N release on the BRAT channel. main is the stable branch — promotion via a release/X.Y.Z PR cuts a stable release on the Obsidian Community Plugins channel. Conventional Commits are enforced; non-conformant PRs are rejected by commitlint. Full details in CONTRIBUTING.md and Release flow.
See also
CONTRIBUTING.md— canonical short-form contributor reference (kept in sync with these pages)- Release & deploy pipeline — system view of what CI does behind the release flow
- Protocol evolution — the rules a wire-protocol change must follow