AGPL-3.0-only, and we actively welcome contributions to the CLI itself.
The best contribution path today is the open-source CLI project: providers, commands, tests, architecture, performance, and implementation-backed documentation.
The public docs site and marketing website are maintained by the Bridge team. External contributions are most valuable when they improve the CLI and the technical docs that stay close to that implementation.
What we would love help with
The highest-value contribution areas right now are:- new providers
- bug fixes
- tests and reliability improvements
- CLI ergonomics
- documentation updates tied directly to implemented behavior
- adding a new backend under
src/provider/ - tightening error handling or timeout behavior
- improving command output consistency
- expanding test coverage for filesystem or Postgres behavior
- updating docs in the same PR as a CLI change
Good first contribution areas
If you are looking for a practical starting point, these are usually strong first contributions:- small command UX improvements
- test gaps
- docs corrections that are clearly backed by code
- provider edge cases
- implementation cleanup that makes the codebase easier to extend
Contribution workflow
The current flow is straightforward:- Fork the repository
- Create a branch for your change
- Build and test the CLI locally
- Make the implementation change
- Update any affected docs in the same PR
- Open a pull request against
main
Local setup
Bridge is a Rust project with a provider-oriented architecture. The quickest local setup flow is:cli/ directory.
Project areas contributors should know
The main CLI code lives in:src/cli.rsfor the command-line definitionsrc/commands/for command implementationssrc/config.rsforbridge.yamlloading and env var expansionsrc/provider/for provider implementationstests/for CLI and provider integration tests
Expectations for pull requests
A strong Bridge PR usually includes:- one clear goal
- implementation changes that are easy to review
- tests for behavior changes
- docs updates when command, provider, or config behavior changes
- command syntax
- config behavior
- provider semantics
- output shape
- errors or timeouts
CLA and licensing
Before your first PR is merged, you must sign the Bridge CLA. The canonical CLA is here: In short:- you keep copyright to your own contribution
- you grant the project the rights needed for
AGPL-3.0-onlyand commercial licensing - you only need to sign once
Security issues
If you discover a security issue, do not open a public GitHub issue with exploit details. Report it privately to:hello@bridge.ls
- filesystem path traversal
- SQL injection and identifier handling
- credential exposure in output or logs
- dependency and CI supply-chain risk
Docs contributions
Docs contributions are welcome when they stay close to the CLI implementation. The most useful docs contributions are:- correcting command behavior
- updating config examples after a CLI change
- documenting a new provider
- clarifying real runtime limits or edge cases
Related pages
Development
Build Bridge locally, run tests, and understand the codebase layout.
Commands
See the command surface you may be improving when you work on the CLI.
Providers
See the current provider model and the behavior of filesystem and Postgres.
View the source
Open the repository, issues, releases, and project files on GitHub.