LLM Guidelines
BlossomOS welcomes contributors using LLMs to help understand the codebase, read documentation, or work through a problem. There are clear limits though.
What LLMs are fine for
- Understanding code - Ask an LLM to explain what a function does, how a library works, or what a pattern means. Reading help is always fine.
- Learning concepts - Using an LLM to learn about KDE APIs, RPM packaging, Qt/QML, or any other technology relevant to BlossomOS. Asking for example code to illustrate how something works is fine, as long as you then write your own implementation from scratch.
- Writing documentation - Documentation is prose. If you use an LLM to draft or improve a doc page and the result is accurate and clear, that is fine. Copy the Markdown and clean it up yourself.
- Debugging help - Talking through a bug with an LLM or asking it to explain an error message is a normal part of debugging.
What is not acceptable
No LLM-written code in commits Do not copy LLM-generated code into a commit. The act of writing code yourself is what builds understanding. Typing forces you to think through every decision. Copying does not.
Every line of code committed to BlossomOS must be written by a human contributor. This means:
- No copying LLM output into your editor to use as-is
- No pasting a generated function or fix directly into a commit
Using an LLM to generate a throwaway example or a quick prototype to understand how something works is fine, as long as you then write your own implementation from scratch. What ends up in a commit must be yours.
No LLM artifacts in commits
Do not commit anything your LLM tool left behind. This includes:
- Configuration folders like
.claude,.cursor,.copilot, or anything similar - Pointless LLM-generated comments that just describe what the next line does. If the code needs a comment to be understood, rewrite it or write the comment yourself in your own words
- Boilerplate comments like
// Generated by ...or// This function handles...
A pull request should look like it was written by a person who understood what they were doing, because it was.
This is not about distrust of LLM tools. It is about maintaining a codebase where every contributor understands what they ship. A bug introduced by code nobody actually read is much harder to track down than one written by hand.
Why this matters for BlossomOS
BlossomOS ships to real users as a complete desktop system. Untested or misunderstood code can break system integrations, corrupt user data, or introduce security issues that affect everyone on the platform. The standard is high because the surface area is large.
Summary
| Use case | Allowed |
|---|---|
| Understanding existing code | Yes |
| Learning a technology or API | Yes |
| Asking for example code to understand something | Yes |
| Drafting documentation | Yes |
| Generating a throwaway example or prototype to understand something | Yes |
| Copying LLM-generated code into a commit | No |
Committing .claude, .cursor or similar folders | No |
| Pointless LLM-generated comments in code | No |