Here is a draft proposed by Nate Graham.

LLM usage

KDE follows a “human in the loop” principle: when using an LLM, a human
must be making decisions beyond mere prompting. The output must express
the operator’s unique humanity in some way.

So nobody in KDE should know you used an LLM — not because you’re
concealing it, but because the results are functionally
indistinguishable from what you could produce yourself.

How can you ensure that? Here are some examples:

Acceptable LLM usage

1. Create it yourself in the first place, with no LLM.
2. Write text that you want other people to read yourself in English,
   with no LLM.
3. Have an LLM make a rough draft or something, then you rewrite or
   refine it yourself.
4. Have an LLM find a bug, and then you verify that and fix it yourself.
5. Have an LLM fix a merge conflict in your patch, then you verify and
   push the result yourself.
6. Use an LLM to debug an issue and identify a bug, then report the bug
   yourself, with your own words.
7. Write text that you want other people to read yourself in your native
   language, and then machine-translate it (with no stylistic or tonal
   changes) into English.
8. Use an LLM to explain or teach you something you don’t understand,
   then test your new knowledge in the field to verify that it was correct
   and that you now have a new skill.

Prohibited

1. Don’t ask an LLM to write some English text, and copy-paste that into
   a chat or merge request description.
2. Don’t copy someone else’s response to you into an LLM, tell it to
   reply, and then copy-paste the output as a response to the other person.
3. Don’t submit “vibe-coded” changes you don’t understand and couldn’t
   make yourself.
4. Don’t disclose LLM usage as a way of trying to excuse the potential
   errors or poor quality of a contribution.
5. Don’t add “Assisted-by: [some LLM]” tags to your commits; it’s just
   free advertising for the LLM’s provider.