packages/kilo-docs/pages/contributing/index.md
{% callout type="info" %}
New versions of the VS Code extension and CLI are being developed in Kilo-Org/kilocode (extension at packages/kilo-vscode, CLI at packages/opencode). If you're looking to contribute to the extension or CLI, please head over to that repository.
{% /callout %}
Kilo Code is an open-source project that welcomes contributions from developers of all skill levels. This guide will help you get started with contributing to Kilo Code, whether you're fixing bugs, adding features, improving documentation, or sharing custom modes.
There are many ways to contribute to Kilo Code:
Setting Up the Development Environment is described in details on the Development Environment page.
Before diving into the code, we recommend reviewing the Architecture Overview to understand how the different components of Kilo Code fit together.
feature/new-tool-support or fix/browser-action-bug)docs/ prefix (e.g., docs/improve-mcp-guide)git checkout -b your-branch-name
# For documentation changes:
git checkout -b docs/your-change-description
AI and coding agents are welcome in Kilo contributions. Contributors still own the work they submit: you must personally understand the change, test it appropriately, be able to explain the diff, and understand how it interacts with the affected package and the rest of the repo.
When using an agent, start it from the repository root so the root AGENTS.md is available. If you work in a package with its own guidance, check and follow the package-specific AGENTS.md or contributor docs too.
Maintainers may close PRs that appear to be submitted without credible contributor ownership or understanding, including AI-assisted work that has not been meaningfully reviewed by the contributor.
User-facing changes (features, fixes, breaking changes) require a changeset file so the update shows up in the next release notes. Run the interactive tool, or create the file by hand:
bunx changeset add
Or create .changeset/<slug>.md manually:
---
"kilo-code": minor
---
Short description of the change for the changelog.
Guidelines:
patch for bug fixes, minor for new features, major for breaking changes.publish.yml workflow, which generates changelog entries for the GitHub release notes.Skip the changeset only for internal refactors, CI tweaks, test-only changes, or docs that do not affect users.
packages/sdk/js/ with ./script/generate.ts after changing server endpoints.bun run script/extract-source-links.ts after adding or changing guarded URLs in packages/kilo-vscode/, packages/kilo-vscode/webview-ui/, or packages/opencode/src/.packages/opencode/ files, keep Kilo changes small and mark Kilo-only edits with // kilocode_change for a single line or // kilocode_change start / // kilocode_change end for a block. Do not add these markers inside kilocode-named paths.Use the current Bun commands in the Development Environment guide for repo-level, CLI, backend/API, VS Code extension, and docs checks.
Key reminders:
bun test from the repo root. The root test script intentionally exits with failure so tests run from the package that owns them.bun dev serve and curl-based requests../script/generate.ts from the repo root after changing server endpoints.bun run extension.Before marking a PR ready for review, include testing evidence in the PR template. See Testing Evidence for Pull Requests for the full standard, including docs/config-only verification and blocked command fallback requirements.
Contributor guidance exists to protect maintainer review time and keep reviews focused on work that is ready to evaluate.
Follow the issue-first policy by linking the relevant issue when you open a PR. Use Fixes #123, Closes #123, or equivalent linked issue wording so reviewers can see the problem statement, discussion, and intended scope before reviewing the code change.
Push your changes to your fork:
git push origin your-branch-name
Go to the Kilo Code repository
Click "New Pull Request" and select "compare across forks"
Select your fork and branch
Fill out the PR template with:
Keep the description focused on context reviewers cannot infer from the diff. Skip file-by-file summaries, placeholders, and other filler.
Maintainers may close or decline review of PRs presented as review-ready at their discretion when they lack linked issue context, a clear what/why explanation, credible testing evidence, credible contributor ownership of AI-assisted work, or relevant UI proof for visual UI changes.
When a PR is close to this bar, addresses important work, or would benefit from further shaping, maintainers may ask for specific fixes instead of closing or declining review. Contributors may reopen or resubmit once the PR meets the documented bar.
Please keep the issue and PR trackers useful for maintainers and contributors. Do not submit batches of agent-generated, untested, or weakly reviewed PRs.
Keep concurrent PRs focused and limited. As a rule, open no more than three PRs at a time, especially if you are a new contributor. Prioritize high-impact or high-priority issues first instead of opening many speculative fixes. If a contributor opens a large batch of low-value or duplicative PRs, maintainers may close the batch and ask the contributor to choose one PR to reopen, focus, and bring up to the documented review bar before submitting more.
For issues, do not mass-create tickets through automation or agents. Search existing issues first, open issues only when you have enough context for someone to act, and prioritize the most important reports instead of filing every possible finding. Maintainers may close duplicate, low-signal, automated, or weakly reviewed issues without action.
Maintainers may close issues or PRs that disregard the contribution guide, bypass required context, or lack credible contributor ownership of AI-assisted work. Repeated disregard of this contribution guide, or high-volume automated or agent-generated tracker spam across issues or PRs, may result in maintainers blocking the responsible account.
Kilo has bug bounties. To be eligible, make sure your GitHub account is connected in your Kilo account.
The Kilo Marketplace is a community-driven repository of agent tooling that extends Kilo Code's capabilities. You can contribute:
To contribute:
Follow the documentation for Custom Modes, Skills, or MCP Servers to create your resource
Test your contribution thoroughly
Submit a pull request to the Kilo Marketplace repository
For larger features, we write engineering specs to align on requirements before implementation. Check the Feature Proposals section to see planned features and learn how to contribute specs.
Documentation improvements are highly valued contributions:
Follow the documentation style guide:
/docs/ for internal links (except within the same directory).md extensions in linksTest your documentation changes and run the docs site locally from the repo root:
bun run --filter @kilocode/kilo-docs test
bun run --filter @kilocode/kilo-docs build
bun run --filter @kilocode/kilo-docs dev
For manual validation, preview the affected page and check changed links and rendered content.
Submit a PR with your documentation changes
When participating in the Kilo Code community:
If you need help with your contribution:
All contributors are valued members of the Kilo Code community. Contributors are recognized in:
Thank you for contributing to Kilo Code and helping make AI-powered coding assistance better for everyone!