Tool-Generated Content Policy

1. Purpose

Contributors use many tools to produce their work, and the capabilities of those tools have expanded significantly with the arrival of AI coding assistants. KiCad welcomes the use of any development tools, but our lead development team has limited time and energy for review. This policy clarifies expectations around tool-generated contributions so that everyone can be productive while maintaining the trust between submitters and reviewers that keeps KiCad development healthy.

Do not modify this document without the consent of the project leader. All changes to this document require approval.

2. Core Principle

There must be a human in the loop. The contributor is always the author and is fully accountable for everything they submit. Contributors must review all tool-generated code or text before asking the lead development team to review it, and must be able to answer questions about their work during review.

3. Scope

3.1 Out of Scope

These guidelines do not apply to tools that make trivial modifications to existing content, such as spelling and grammar corrections, identifier completion, purely mechanical transformations like variable renaming, or reformatting with clang-format. Even when your tool use falls outside this scope, consider whether disclosing it would help reviewers evaluate your contribution.

3.2 In Scope

These guidelines apply when a meaningful amount of content in a contribution was not written by a person but was instead created by a tool. This includes code, merge request descriptions, design proposals, comments and feedback on merge requests, documentation, library contributions (symbols, footprints, 3D models), and issue reports.

If a tool was used to find a problem addressed by a change, that should also be noted. This gives credit where it is due and helps fellow developers discover useful tools.

Some examples of in-scope use:

  • A coding assistant generated a new function in your patch.

  • A .cpp file was originally generated by a coding assistant and then cleaned up by hand.

  • The commit message or MR description was generated by handing the patch to a generative AI tool.

  • Text was translated from another language by a machine translation tool.

If in doubt, choose transparency and assume these guidelines apply.

4. Guidelines

4.1 Understand Your Submission

Read the existing contribution guidelines, particularly the Commit Message Format Policy and the Code Style Policy. Their rules have not changed. You are expected to understand your entire submission as well as the subsystems that it affects and be prepared to respond to review comments on any part of it. If you are unable to do so, do not submit the changes.

4.2 Be Transparent

When making a contribution, be transparent about the origin of content in your MR description and commit messages. Useful information includes:

  • What tools were used.

  • Which portions of the content were affected by those tools.

  • If code was largely generated from a short set of prompts, include those prompts. For longer sessions, summarize the prompts and the nature of the resulting assistance.

  • How the submission was tested and what tools were used for testing.

When tool-generated content is a substantial part of the contribution, note this in your commit message using a trailer:

Assisted-by: <tool name>

4.3 Write MR Descriptions Yourself

It is strongly recommended that contributors write merge request descriptions themselves. Using tools for translation or copy-editing is fine, but the description should explain the motivation, implementation approach, expected impact, and any open questions to the same extent as a contribution made without tool assistance.

4.4 No Autonomous Agents

Agents that take action in KiCad’s digital spaces (GitLab, the developers mailing list, Discord) without human review and approval are not permitted. Automated review tools that publish comments without human review are also not allowed. An opt-in tool that keeps a human in the loop is acceptable.

5. Starter Issues

AI tools must not be used to fix issues labelled starter or Good first issue. These issues exist as learning opportunities for new contributors to get familiar with the codebase. Whether you are a newcomer or not, automating the process of fixing these issues squanders the learning opportunity and does not add value to the project. Using AI tools to fix starter issues is forbidden.

6. Red Flags and Reviewer Discretion

The lead development team reviews every contribution on its merits. The following characteristics are red flags that may lead to a contribution being rejected without detailed review:

  • Needlessly verbose or boilerplate-heavy descriptions that obscure the actual change.

  • Content that is not internally coherent or is self-contradictory.

  • Demonstrated misunderstanding of what the existing code does, what the new code does, or the purpose of the change.

  • A volume of submissions disproportionate to the contributor’s demonstrated understanding of the codebase.

These are red flags regardless of whether tools were involved. It is fine to not be fully confident in a proposed change, but this should be disclaimed in the MR itself.

6.1 Lead Developer Response

As with all contributions, the lead development team has discretion to decide how to handle a contribution. They may treat it like any other, reject it outright, review it with extra scrutiny or at lower priority, ask the contributor to explain how the code works, or ask for an alternative approach instead of suggesting specific code changes.

A contribution should always be worth more to the project than the time it takes to review it. If a contribution does not appear to meet this bar, a reviewer should respond with:

This MR doesn't appear to comply with our policy on tool-generated
content. Please see our Tool-Generated Content Policy:
https://dev-docs.kicad.org/en/rules-guidelines/tool-generated-content/

If a contribution remains low quality after the contributor has been given the opportunity to improve it, the lead development team may close the MR or lock the conversation.

Note that repeatedly submitting low-quality contributions may lead to a contributor’s future contributions being deprioritized for review.

7. Copyright

Contributors are responsible for ensuring that they have the right to contribute code under the terms of the KiCad project license (GPL-3.0-or-later). Using AI tools to regenerate copyrighted material does not remove the copyright. Contributors are responsible for ensuring that such material does not appear in their contributions. Use of a tool that checks for and removes or properly attributes copyrighted material is a minimum best practice for anyone using AI tools to assist with contributions.

Contributions found to violate this policy will be removed.

8. Growing Our Community

New contributors are encouraged to start with small contributions they can fully understand, and to gradually work their way up to larger changes as they gain knowledge of the codebase. Learning involves taking small steps, getting feedback, and iterating. Passing reviewer feedback directly to an LLM without engaging with it yourself does not build the understanding needed to sustain our community.

We want KiCad to remain welcoming and open to contributors who are willing to invest time and effort to learn and grow. Growing our contributor base helps sustain the project over the long term, and that growth depends on real human engagement with the code, the review process, and the community.

9. Attribution and References

This policy was informed by the work of several open source communities: