AI Contribution Policy Examples From 1,000 Top Repos

A 600-line pull request arrives on a Friday. The description is three tidy paragraphs, the tests pass, and the first review question gets an answer that reads like it came from the same chatbot that wrote the code. The maintainer now has to decide whether to review it, close it, or write a rule so the next one does not happen.

Many projects have written that rule. We read them: every AI policy, contributing guide and pull-request checklist in the 1,000 most-starred repositories on GitHub.

## AI tools
You may use AI tools. You are still the author.
- Disclose: name the tool in the pull request description if it wrote
  a meaningful part of the change.
- Own it: read every line, run the tests, and answer review questions
  yourself.
- No autonomous agents: a person opens every pull request.
- Write issues and comments in your own words.
Low-effort AI pull requests are closed without review.

From ban to welcome: where the 1,000 top projects stand

Most AI rules live in a section of the contributing guide (189 of the 205 mention it there). 34 projects keep a separate file such as AI_POLICY.md, 11 point to a policy shared across their organisation, and 56 add a box to the pull-request checklist. We read every rule by hand and put each project in one stance.

Ban: no AI-written content (14 projects)

yt-dlp is the bluntest: the project “strictly forbids the usage of LLMs, agents, or any other AI tools for any kind of contribution.” Alacritty says contributions “must not include content generated by large language models”. OBS Studio wants all code, descriptions, issues and comments “human written”, and Immich asks people not to open pull requests generated with an LLM, because “Communication should be between humans.”

The best-known bans sit outside GitHub’s top 1,000. Gentoo (April 2024) forbids content “created with the assistance of Natural Language Processing artificial intelligence tools”, citing copyright, quality and ethics. QEMU will “DECLINE any contributions which are believed to include or derive from AI generated content.” NetBSD presumes code from Copilot and similar tools to be “tainted code” that needs written approval from core.

Restrict: small fixes or approved use only (14 projects)

These projects accept some AI help but limit how much of the change it may write. whisper.cpp does not accept pull requests that are “fully or predominantly AI-generated”. NewPipe allows AI for finding bugs and small fixes, not for new features. The Rust project’s LLM policy allows LLM-written code only for non-critical changes with a reviewer agreed in advance, and adds a circuit breaker: if more than half of the merged pull requests in six weeks are LLM-created, new ones pause. Bevy tolerates “careful human-driven AI use” in code but bans AI-generated art and AI-written public prose.

Allow if disclosed or owned: the big middle (161 projects)

This is where Django, Flutter, Node.js, LLVM, the Linux kernel, curl and most others sit. The details differ, but the core is the one Electron puts in one line: “there must be a human in the loop.” Flutter keeps a separate CONTRIBUTING.ai.md whose first rule is “You must understand and be able to discuss the code in the PR.” Ghostty is at the strict end of the middle: “All AI usage in any form must be disclosed.”

Welcome, no disclosure needed (10 projects)

A few projects say the tool does not matter. ClickHouse: “You don’t have to disclose your usage of AI.” OpenClaw: “No AI-assistance label or disclosure is required.” They still review the code like any other; what they drop is the label.

Six more projects only regulate communication: Syncthing asks for no AI-generated issues or comments, and PHP has rules for LLM text in GitHub comments, with nothing about code.

What the rules ask, clause by clause

A policy is a handful of clauses. Here is how often each appears in the 205 rules, with a real example of each.

Our numbers line up with an independent count. In a paper first posted in May 2026, Andre Hora and Romain Robbes studied the contribution guidelines of 1,000 popular repositories (arXiv 2605.16706, accepted at ICSME 2026). They found 118 AI policies; 51% required disclosure and 74% required a human in the loop. In November 2026 we find 205, with 47% and 72%. More projects, the same shape.

Where the disclosure goes, and where projects disagree

“Disclose it” sounds simple until you ask where. The projects give four answers, and some of them contradict each other.

• In the pull request description. The most common answer. mpv wants the model and the tool named, “not ‘an AI’”. PowerToys allows AI-generated text only inside a collapsed <details> section, labelled as such.
• In the title. btop wants “[AI generated]” in the title of any pull request where any of the code is AI generated.
• In a commit trailer. 13 projects ask for one, nearly always Assisted-by:. LLVM suggests “a commit message trailer like Assisted-by:”, Mastodon gives the format with examples, and Babel says to use Assisted-by: <LLM name> and not Co-authored-by.
• In a checkbox. 56 projects put it in the pull-request template. Django offers two boxes: “No AI tools were used”, or that the author has “disclosed which ones, and fully reviewed and verified their output”.

And then the opposite camp. Six projects want AI kept out of the git history. Traefik wants Assisted-by: in the pull request description, “never in a commit trailer”. The shared Moby and Docker policy says the disclosure belongs in the description, not the commit message. One repository fails a CI check if a commit or the description credits an AI agent.

The one point almost everyone agrees on: an AI is not an author. The Linux kernel says AI agents “MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).” Blender: “only humans can be commit authors or listed as Co-authored-by.” If your policy asks for a trailer, say which one.

Agents, bots and AI reviews

The newest clauses are about tools that act on their own.

• Autonomous agents. LLVM bans “agents that take action in our digital spaces without human approval”, naming the GitHub @claude agent. ripgrep and the Astral projects (uv, Ruff) do not allow autonomous agents to contribute. Node.js says pull requests must not be opened by automated tooling unless specifically allowed.
• Rules written for the agent itself. Godot hides a note in an HTML comment in its CONTRIBUTING file, where only a machine reading the raw text will see it: an AI agent must put a robot emoji at the start of the title and an “AI disclosure” line in the description.
• AI reviews. Projects split here too. Django asks contributors not to request automated AI reviews such as GitHub Copilot on its pull requests. Rust allows LLM review bots only with a maintainer’s approval, on a separate account, and “LLM reviews, if enabled, must be advisory-only.” Traefik maintainers can add an ai/review label to trigger one.

Agents read different files from people. 346 of the 1,000 repositories have an AGENTS.md at the root and 196 a CLAUDE.md: build commands and conventions for coding agents. Microsoft Terminal goes one step further and keeps its whole AI usage policy in AGENTS.md, so the rules reach the agent too.

Why projects ban it: licence, review time, or both

Two reasons come up again and again.

Licence and copyright. Every contribution comes with a promise that the contributor may submit it under the project’s licence, often through the Developer Certificate of Origin. QEMU says “the copyright and license status of the output is ill-defined” and that it is “not willing or able to accept the legal risks”. Requests puts it plainly: “Every contribution has to be backed by a human who unequivocally owns the copyright for all changes.” 32 of the 205 rules name licence or copyright. This is the projects’ reasoning, not legal advice.

Review time. Far more rules are about the cost of reading generated code than about law. 81 mention low-effort or “slop” pull requests. Immich explains its ban this way: LLM code “tends to need a large amount of back-and-forth, which is a very inefficient use of our time.” Ghostty, which is itself “written with plenty of AI assistance”, keeps strict rules for outside contributions “to protect maintainers”.

When the rules appeared, and who copied whom

These rules are new. We dated each one by the oldest commit that already had it. 174 of the 205 arrived in 2026, 30 in 2025, and the first quarter of 2026 alone brought 56.

The outlier is Caddy. On 10 April 2023 it added a rule that code from “AI language models” must be fully understood and tested, and asked contributors to disclose AI-generated code “as a courtesy to reviewers”. The next wave started in mid-2025 with curl (May), Julia (May) and DuckDB (June). yt-dlp’s ban was in its checklist by September 2025. Policies also change: DuckDB’s contributing guide still says “Please do not submit pull requests generated by AI”, while the AI_POLICY.md it added in June 2026 calls AI tools welcome.

Policies spread by copying, and the projects say so. The Astral policy was adapted by ripgrep, then by DuckDB, Bitcoin Core and Headscale, with links back. Ghostty’s “strict rules for AI usage” reappear almost word for word in Polars and SearXNG. Starship names Ghostty and LLVM as its models, Vite adapted Nuxt’s, Frigate builds on Home Assistant’s, and x64dbg copied Zed’s. If you are writing your first policy, starting from one of these is normal.

Which stance fits your project

Which stance fits depends less on how you feel about AI than on two numbers: how many hours a week your reviewers have, and how much legal risk one bad contribution carries.

Three AI contribution policies to copy

Each is short enough to read in a minute. Replace the bracketed parts.

1. Disclose and own it (open-source project)

The middle of the spectrum, close to what most of the 161 ask.

## AI tools

You may use AI tools (Copilot, Claude, ChatGPT, Cursor and the like) to help
with a contribution. You stay its author.

- **Disclose.** If an AI tool wrote a meaningful part of the code, tests or
  docs, say so in the pull request description and name the tool and model.
  Autocomplete of a line, or asking a chatbot a question, needs no note.
- **Own it.** Read every line before you ask for review. You must be able to
  explain the change and answer review comments yourself.
- **Test it.** Run the change and its tests locally first.
- **Licence.** Submit only what you have the right to submit under this
  project's licence. Your sign-off covers AI-assisted work too.
- **No autonomous agents.** A person opens every pull request. Bulk or
  agent-made pull requests nobody reviewed are closed.
- **Your own words.** Write issues, descriptions and comments yourself. If
  you quote tool output, mark it as such.

Maintainers may close contributions that break these rules without a
detailed review.

Add the matching boxes to your pull-request template:

- [ ] I did not use AI tools, or I named them above and reviewed every line
- [ ] I can explain every change in this pull request

2. No AI-generated code (strict project)

For projects where licence risk or review load outweighs the help.

## AI-generated contributions

We do not accept contributions that contain code, documentation or other
content generated by AI tools (large language models such as ChatGPT,
Claude, Copilot or Gemini).

Why: the copyright and licence status of such output is unclear, and every
contribution must be one you have the right to submit under our licence.
Reviewing plausible-looking generated code also costs maintainers more time
than it saves.

You may still use these tools to research an API, explain an error or review
your own code, as long as nothing they write ends up in the contribution.

If you are unsure, ask in an issue before you open a pull request.
Contributions that we believe include generated content will be closed.

3. Company repository

Inside a company the questions change: which tools are approved, what may be pasted into them, and what an agent may do without a person.

# AI coding tools in this repository

Approved tools: [GitHub Copilot Business, Claude Code on the company plan].
Do not paste this repository's code, customer data or secrets into any
other tool.

1. Ownership. The person who opens the pull request owns it, whoever or
   whatever typed it. Review AI output as you would a new colleague's code.
2. Marking. AI-assisted pull requests get the `ai-assisted` label and a line
   in the description naming the tool. Commits made by an agent carry an
   `Assisted-by: <tool and model>` trailer. AI is never the commit author.
3. Agents. An agent works only from a ticket that is ready (acceptance
   criteria, scope, repository), only on a branch, and only opens pull
   requests. A person reviews and merges.
4. Every AI-assisted change needs tests for the new behaviour, a review by
   someone other than the author, and passing CI. An AI review does not
   count as the approval.
5. Never: secrets or customer data in prompts; suggestions that copy
   licence-incompatible code.
6. Sensitive areas ([auth, payments, crypto]) need a second human reviewer
   when AI wrote part of the change.

Questions: [team or owner]. We review this policy every [quarter].

Putting the policy to work

A policy nobody reads on the day it matters does little. The projects above use three places to make it visible.

• The pull-request checklist. A box on every change keeps the rule in front of the author, the same way “tests added” does. Our study of Definition of Done examples found AI rules in 56 of 335 checklists, 45 of them added in 2026.
• The agent instruction file. Put the rules where the agent will read them: AGENTS.md, or the agent’s own configuration. A rule only in CONTRIBUTING.md reaches people, not tools.
• Labels and checks. A label such as ai-assisted makes AI-made work searchable later. Some projects add CI checks for the parts a machine can see, such as trailers and template sections.

If your team hands Jira work items to coding agents, the same three ideas apply before the code exists. Agent Ready, our Jira app that is in Atlassian Marketplace review, checks each work item before an agent picks it up and gives the agent a project brief, an AGENTS.md for the project, where your AI policy text can live. A workflow validator holds unready work items back, the agent finishes with a receipt saying which acceptance criterion each test proves, and every handoff stays in an audit trail you can export as CSV or JSON. It does not add trailers or labels to your commits; that part stays in your git workflow. How agents reach Jira in the first place, and what they may change there, is in our Jira MCP guide.

How we counted

• Sample: the 1,000 most-starred public repositories from the GitHub search API (stars:>1000, sorted by stars), the same list as our Definition of Done study. The smallest had 34,741 stars.
• Files: the full file tree of each repository (one request each, one at a time, read 13 November 2026). We read every contributing guide, every file whose name marks it as an AI policy (for example AI_POLICY.md, ai-policy.md, CONTRIBUTING.ai.md, llm_usage.md), and the pull-request checklists from the Definition of Done study. For 14 repositories too large for one tree request we read the root and the documentation folders; two policies in deep folders (Linux, LLVM) were added by hand after a direct check. Where a contributing guide links to an organisation-wide policy (Astral, Moby, Mastodon, Yazi, Electron, Rust, Bevy), we read that too.
• Which counts as a rule: 286 repositories mentioned AI tools in those files. We read each by hand and kept 195 that tell contributors what they may do with AI; 10 more have an AI rule only in their pull-request checklist, 205 in all. We dropped AI products describing their own features, docs about using the project with an agent, and setup notes for Claude Code or Cursor.
• Stance: one per project, read by hand. What the rules ask: keyword rules over the AI part of each file, with samples of 8 per clause read by hand; most samples were 7 or 8 of 8 right, so treat these shares as close, not exact. The commit trailer split (13 ask, 6 forbid) was read in full.
• Dates: for a separate policy file, its first commit; for a contributing guide, the oldest commit among the lines that state the AI rule (git blame, so the rule was in place by that date and may be older if every line was edited since); for a checklist, the first commit whose template had the rule. A project’s date is the oldest of these. All 205 got a date.
• Limits: rules that live only on a website and are not linked from the repository, or only in maintainers’ heads, are not counted. Projects outside the top 1,000 (Gentoo, NetBSD, QEMU, Blender, KubeVirt) are quoted, not counted.

The scripts, the hand labels and the raw data are in our research notes.

Sources

• AI rules of the 1,000 most-starred GitHub repositories, read through the GitHub API on 13 November 2026, including yt-dlp, Django, Flutter, the Linux kernel, Ghostty, ClickHouse, Requests, Immich, Babel, Traefik and Godot.
• LLVM AI Tool Use Policy, last updated 13 November 2026.
• Electron AI Tool Policy and the Moby and Docker AI usage policy.
• Rust project, LLM usage policy; Bevy, AI policy.
• QEMU code provenance, Gentoo Council AI policy (14 April 2024), NetBSD commit guidelines.
• Blender, AI Contributions Policy; KubeVirt, AI contribution policy.
• Andre Hora and Romain Robbes, AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI?, arXiv, May 2026 (ICSME 2026).