Currently, there are a few bottlenecks across CI configuration, UI testing strategy, and documentation that make it difficult for community members to contribute effectively.
CI Failure on Fork PRs Due to Missing Vercel Secrets
Community contributions submitted from forks often cannot be merged because they don't have access to repository secrets for the build step. Because this build step happens after the PR is approved, it requires real keys to proceed.
As a result, maintainers are forced to manually close the community PR, recreate an in-repo branch with the exact same changes, and open a new PR just to allow CI to pass. This causes overhead for maintainers as well as loses attribution for community contributors.
Example: PR #3408 (from a fork) had to be closed and superseded by PR #3489 (an in-repo branch) explicitly because the fork branch could not access repository secrets for the Vercel build step.
Lack of Tooling for Local UI Testing
It is quite hard to test even basic UI changes locally because a fresh database starts completely empty. Because the product spans many complex surfaces (Organizations, Billing states, Cloud sessions), manually setting up realistic data structures in a local DB is a massive time sink.
Without accessible tooling to see how the interface handles real data, contributors are often forced to open PRs blindly instead of taking the time to thoroughly figure out and visually verify their changes.
A potential fix is to create a mock data script or pre-generated user profiles that have realistic usage covering all product areas. For example, a pre-configured developer profile could populate:
- 20+ active KiloClaw chat sessions
- 5+ active Cloud Agent sessions
- Realistic mock usage data logs
Onboarding & Environment Documentation Gaps
The current DEVELOPMENT.md file has two primary friction points for external developers:
- The guide is heavily macOS-focused, assuming the user has Homebrew and Xcode command-line tools installed, which leaves Linux and Windows users to guess what carries over and what doesn't
- The
.env.local.example environment block is quite long, and there is no documentation detailing what each variable actually does. Non-employees without access to vercel env pull have to figure out which keys are required for a basic boot and which ones are needed to test a specific product surface.
Potential fixes:
- Add inline comments next to keys in
.env.example explaining what they activate (e.g., # Required to access standard AI features via the OpenRouter proxy).
- Document a "Minimal Boot" profile so contributors know the absolute bare minimum variables needed to start the Next.js server locally without crashing.
My Personal Expierience
To give some context, I personally wanted to contribute to the cloud repo recently, but I faced these environment barriers and testing roadblocks. Because local setup and validation felt like a barrier for an outside developer, I ended up sticking to contributing to the main Kilo-Org/kilocode repository instead.
I want to clarify that this issue doesn't come from frustration, but instead from my love for this project. I want Kilo to succeed, and I believe that optimizing the open-source contributing experience is critical to Kilo's future.
Currently, there are a few bottlenecks across CI configuration, UI testing strategy, and documentation that make it difficult for community members to contribute effectively.
CI Failure on Fork PRs Due to Missing Vercel Secrets
Community contributions submitted from forks often cannot be merged because they don't have access to repository secrets for the build step. Because this build step happens after the PR is approved, it requires real keys to proceed.
As a result, maintainers are forced to manually close the community PR, recreate an in-repo branch with the exact same changes, and open a new PR just to allow CI to pass. This causes overhead for maintainers as well as loses attribution for community contributors.
Example: PR #3408 (from a fork) had to be closed and superseded by PR #3489 (an in-repo branch) explicitly because the fork branch could not access repository secrets for the Vercel build step.
Lack of Tooling for Local UI Testing
It is quite hard to test even basic UI changes locally because a fresh database starts completely empty. Because the product spans many complex surfaces (Organizations, Billing states, Cloud sessions), manually setting up realistic data structures in a local DB is a massive time sink.
Without accessible tooling to see how the interface handles real data, contributors are often forced to open PRs blindly instead of taking the time to thoroughly figure out and visually verify their changes.
A potential fix is to create a mock data script or pre-generated user profiles that have realistic usage covering all product areas. For example, a pre-configured developer profile could populate:
Onboarding & Environment Documentation Gaps
The current
DEVELOPMENT.mdfile has two primary friction points for external developers:.env.local.exampleenvironment block is quite long, and there is no documentation detailing what each variable actually does. Non-employees without access tovercel env pullhave to figure out which keys are required for a basic boot and which ones are needed to test a specific product surface.Potential fixes:
.env.exampleexplaining what they activate (e.g.,# Required to access standard AI features via the OpenRouter proxy).My Personal Expierience
To give some context, I personally wanted to contribute to the cloud repo recently, but I faced these environment barriers and testing roadblocks. Because local setup and validation felt like a barrier for an outside developer, I ended up sticking to contributing to the main
Kilo-Org/kilocoderepository instead.I want to clarify that this issue doesn't come from frustration, but instead from my love for this project. I want Kilo to succeed, and I believe that optimizing the open-source contributing experience is critical to Kilo's future.