Skip to main content
Thank you for contributing to Lyzr’s open-source projects. This guide covers the development setup, contribution workflow, and standards for Control Plane, GitAgent, and OpenGAP.

​
Which repo?

ProjectRepository
GitAgentopen-gitagent/gitagent
OpenGAPopen-gitagent/opengap

​
Before you start

  • Search existing issues before opening a new one.
  • For significant changes, open an issue first to discuss the approach before writing code; this saves everyone time.
  • Small fixes (typos, broken links, documentation) can go straight to a PR.

​
Development setup

​
Control Plane

git clone https://github.com/LyzrCore/langship
cd langship
npm install
cp .env.example .env        # add your LLM API key
npm run dev                 # start development server
npm test                    # run tests

​
GitAgent

For contribution guidelines, setup instructions, and coding standards, refer to the GitAgent Contributing Guide.

​
OpenGAP

For contribution guidelines, setup instructions, and coding standards, refer to the OpenGAP Contributing Guide.

​
Branch naming

feat/short-description      # new feature
fix/short-description       # bug fix
docs/short-description      # documentation only
chore/short-description     # tooling, deps, config
Examples: feat/canary-deployment, fix/otel-span-missing, docs/sdk-reference

​
Commit messages

Follow Conventional Commits: 
feat: add canary deployment strategy
fix: resolve missing OTEL span on session end
docs: add SDK reference page
chore: upgrade typescript to 5.4
Breaking changes: add ! after the type and include BREAKING CHANGE: in the commit body.

​
Pull request checklist

Before submitting a PR, confirm:
  • Tests pass locally (npm test or pytest)
  • New functionality has tests
  • Documentation updated (if the change affects user-facing behavior)
  • CHANGELOG.md entry added under [Unreleased]
  • No secrets, API keys, or credentials in the diff
  • PR description explains why the change is needed, not just what it does

​
What gets merged

We merge PRs that:
  • Fix a confirmed bug
  • Add a feature discussed and approved in an issue
  • Improve documentation meaningfully
  • Add test coverage for untested paths
We close PRs that:
  • Add features without prior discussion
  • Introduce new dependencies without clear justification
  • Change behavior without tests
  • Duplicate existing functionality

​
Review timeline

Maintainers aim to review PRs within 5 business days. If you haven’t heard back in a week, leave a comment on the PR.

​
Good first issues

New contributor? Look for issues labeled good first issue. These are scoped to be completable without deep codebase knowledge and have clear acceptance criteria.

​
Getting help

Stuck on something contribution-related? Ask in #open-source on Discord or leave a comment on the relevant GitHub issue.