Skip to content
Open
68 changes: 68 additions & 0 deletions AGENTS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
# Kroxylicious AI Agent Guidelines

This file provides guidance for AI coding tools, such as GitHub Copilot and Claude Code, when working in Kroxylicious repositories.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused. Is this file intended to be read by the AI, by the human, or both?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The AI tools.

Readme/developer guides are for humans. Agents.md is for them (thus the content might overlap but its intended for different audiences).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding of a .github repo is that it serves as the default for other repos in the org. This is most relevant for those files which GitHub treats specially (like CONTRIBUTING.md). AFAIK AGENTS.md is not on that list (but maybe it will be added in the future).

So I don't know quite how to interpret this file:

  • It is really intended to apply to all our other repos? Probably yes? But it's insufficient on its own to be useful.
  • If yes, then do we know agents will actually find it (especially if the user has not checked out this repo).
  • But if another repo has its own AGENTS.md file (which by the first point is necessary), won't that override this file (at least from a GitHub PoV).

It all just seems confusing how the various parties (AI, GitHub, Humans) are supposed to construct the full AGENTS.md context.


Contributors using AI tools must ensure the tools can access this file and any repository-specific `AGENTS.md` file.
Copy link
Copy Markdown

@fvaleri fvaleri Mar 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if I want to work on repo X I also need to go and manually copy this AGENTS.md file content from this repo? Not the best experience IMO and something people will probably skip.

Please also read the [Contributing Guidelines](./CONTRIBUTING.md), in particular the section on [Use of AI Assistance](./CONTRIBUTING.md#use-of-ai-assistance).

## Contribution Process

### DCO Sign-off

All commits must be signed off with the Developer Certificate of Origin (DCO).
Use `git commit -s` to add the sign-off automatically.
Comment on lines +10 to +13
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why repeat this here when it's mentioned in the CONTRIBUTING.md?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to think what this means. My understanding is that an AI cannot do the DCO signoff, because it's not a legal entity. I would also contend that it should not be signing off on behalf of the person which we're assuming to be in the loop.

So the instruction should be the a coding agent or AI should not be signing off. And then we need a complementart instruction in CONTRIBUTING.md telling the human that they need to review and sign off on their genAI's commits.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that a human sign-off is necessary. From a legal perspective, it provides a much safer layer of accountability.


### Assisted-by Trailer

Commits created with AI assistance must include an `Assisted-by` trailer identifying the tool and model.
Add the trailer to the commit message body after the sign-off:
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commits of this PR do not respect the policy as Assisted-by is added before Signed-off-by. Anyway, why do we need to specify the exact ordering?


```
<commit message>

Signed-off-by: Name <email>
Assisted-by: <Tool and model> <noreply@example.com>
Copy link
Copy Markdown

@PaulRMellor PaulRMellor Mar 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the tool email to use clear?
Would people know what to add there beyond a placeholder

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the agents file is for the llm and it will know what to put, I think.

```

### Commit Discipline

- Each commit must be atomic and represent a single logical change.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does 'atomic' mean in this context? It sounds like it has a technical meaning, but you don't explain what it is.

- Keep commits small enough to be reviewed in a few minutes.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we do this ourselves? I've been seeing some humongous PRs recently >5kLOC.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not great at it no, but the more nudges we have in the right direction the better.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO PR size is not a good indicator of the time it takes to review.

Suggestion:

Focus on making commits small enough to be reviewed quickly, though keep in mind that logical complexity matters more than line count.

- Commit messages should explain *why* the change was made, not *what* changed. Reviewers can see the code changes in the diff. Focus on the problem being solved, the reasoning, or the decision made.

### Pull Requests

- A pull request should address a single cohesive goal. Do not bundle unrelated changes together — each PR should tell a clear story that a reviewer can follow from start to finish.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we also want to say something about refactoring? Should they always be separate PRs or only when they hide the actual changes.

- Submit all changes as pull requests.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like it should be the first item in the list. Or I think it could be taken as read.

- At least one human [Committer](./COMMITTERS.md) must review and approve a pull request before it is merged.
Automated or AI-assisted reviews, such as security or style checks, can supplement human review but do not replace it.
The decision to merge is always made by human committers following the project's [decision making](./GOVERNANCE.md#decision-making) framework.
Comment on lines +37 to +39
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really a policy we're applying to committers. It's not relevant for non-committer contributors whether/how AI might be used in code review, nor the gating requirements. So I think we can take this out.

- PR descriptions must focus on the problem being addressed, the approach taken, and any trade-offs or alternatives considered. They must also note any AI tool involvement.
- Ensure all CI checks pass before requesting review.

### Conciseness

Be concise and efficient in all generated content.
Do not produce filler, boilerplate explanations, or unnecessary verbosity.
Stay focused on the goal at hand — reviewers' time is limited and every line should add value.

### Copyright and Licensing

Do not reproduce copyrighted material in generated code, documentation, or other content.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is actually subtle, and also highlights a way that our own IP handling could be better.

I'm not a lawyer, but my understanding the problem arises not from the reproduction of code that is copyrighted, but rather how that code is licensed. For example, I think it would be perfectly fine to copy code verbatim from Apache Kafka, because its license allows that, subject to things like preserving copyright information.

The improvement we could make concerns how we're enforcing source code copyright headers. Currently we insist that our header is used, and that header says "copyright Kroxylicious Authors", and has an ASL license. By insisting on that header we aren't able to copy ASL licensed code from other projects. But this problem comes from our own requirement to have that header, rather than being something that's actually legally necessary. IIRC Richard Fontana has said that copyright headers are not necessary, that copyright exists without them.

If you are aware of controls or configuration that reduce or remove the risk of reproducing copyrighted content, ensure they are active.
All contributions must be compatible with the project's [license](./LICENSE).
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also say something about the acceptable licenses of dependencies.


### Naming and Comments

Write code that is self-describing through clear naming and structure.
A well-chosen name is almost always better than a comment.
Names must convey intent and purpose, not implementation logic, which can become outdated as quickly as a stale comment.
Use comments for reasoning or constraints that good naming alone cannot convey, but if you find yourself reaching for a comment, first consider whether a rename would make it unnecessary.

## Technical Foundations

Kroxylicious is built with Java and [Apache Maven](https://maven.apache.org/).
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how relevant this line is to these guidelines, unless we want to say something about following maven build/test structure?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intent is just to trigger the LLM to look for the right things, but I've trade to make it actionable.

Use `mvn verify` to build and test unless the repository's `AGENTS.md` specifies otherwise.
Individual repositories typically include an `AGENTS.md` file with build commands, architecture details, coding conventions, and testing expectations.

When working on a specific repository, always prefer guidance from that repository's `AGENTS.md` over this file for technical matters.
42 changes: 42 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,11 @@ This project and everyone participating in it is governed by the [Code of Conduc
By participating, you are expected to uphold this code.
Any unacceptable behavior should be reported to [kroxylicious-admins@redhat.com](mailto:kroxylicious-admins@redhat.com).

## About the Project

Kroxylicious is a Java project built with [Apache Maven](https://maven.apache.org/).
Individual repositories include a `README.md` with context, build, and usage instructions.

## How can I contribute

You can contribute by:
Expand All @@ -31,10 +36,47 @@ in your pull request. Alternatively, to signoff a bunch of commits you can use `

All changes which are to be committed in project source control must be reviewed by at least one [Committer](COMMITTERS.md) before being merged.
If the change is being authored by someone who is a Committer, that change must be reviewed by at least one other Committer before being merged.
Automated or AI-assisted reviews, such as security or style checks, can supplement review but do not replace review by a Committer.
Committers make merge decisions following the project's [decision-making](./GOVERNANCE.md#decision-making) framework.
Pull requests must focus on a single goal and be sized for effective review.
We may close pull requests that are unfocused or too large to review effectively, and ask the contributor to break them into smaller, more reviewable changes.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"too large" is a big vague. It would be more helpful to the reader if we could explain what we mean in more concrete terms.


The GitHub teams `@kroxylicious/code-reviewers` and `@kroxylicious/doc-reviewers` can be used to request a PR review from contributors.

If you're willing to provide code and/or reviews to others then let one of the [project managers](PMs.md) know and we can add you to the relevant GitHub team.

## Use of AI Assistance

Contributors can use AI tools, such as LLMs and code assistants, when preparing contributions to Kroxylicious.
As with any tool, the contributor is responsible for the quality of the result and for understanding what they submit.

You are responsible for understanding your contribution and ensuring that it meets project standards, regardless of the tools used.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"You" is assumed to be a human. We're basically assuming that there's a human in the loop for opening the PR. That might be what we want, or not. But either way we should be explicit about what our expectations are.


### Requirements

* **You are the contributor.** When you sign off the [DCO](./DCO.txt), you certify the contribution as your own.
AI-generated or AI-assisted content does not change this obligation.
Comment on lines +57 to +58
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can be a bit clearer on this point: The project requires DCO on all commits. The DCO requires that signoff is done by a legal person. An AI is not a legal entity so it cannot sign off. When a person signs off on the commit they're taking responsibility for an AI assistance included in that commit.

* **Understand your contribution.** You must have a clear understanding of what your contribution does and why.
Do not submit code, documentation, or other content that you do not fully understand.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Do not submit code, documentation, or other content that you do not fully understand.
Do not submit code, documentation, or other content that you do not fully understand.
You should be able to answer reviewers' questions yourself, without recourse to AI.
In particular, do not waste the time of other contributors by being a proxy between reviewers and an AI.

* **Disclose AI usage.** If AI tools play a significant role in a contribution, note this in the pull request description.
Commits must include an `Assisted-by` trailer that identifies the tool and model used (for example, `Assisted-by: Claude Opus 4.6 <noreply@anthropic.com>`).
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I'm in two minds on this one. I see that by requiring this you're putting the onus on the human to own what they're pushing. But the fact is that some commits are going to be entirely generated by API, and actually Generated-by or Coauthored-by seem to be to be more appropriate.

Most AI coding tools can be configured to add this automatically — see the repository's `AGENTS.md` for details.
Using AI features in the same way as an IDE, such as code completion or spelling, does not require disclosure.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a bit meaningless. Something like claude code could be packaged as code complete (even moving between source files as needed, so that the human is just pressing tab repeatedly). Under this definition that would not require disclosure.

I think this is confusing the developer interaction with what we really care about (though to be honest, I don't think this document is super-clear about what exactly that is).

Disclosure is required when AI tools are used to generate substantial content such as functions, tests, documentation, or design approaches.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why should the project really care about AI usage in a design?

* **Ensure originality and licensing compliance.** AI-generated content must not reproduce copyrighted material.
You must verify that your contribution does not introduce intellectual property or licensing issues that are incompatible with the project's [License](./LICENSE). If your AI tool provides controls to reduce the risk of reproducing copyrighted content, make sure that they are enabled.
* **Meet the same quality bar.** AI-assisted contributions are reviewed to the same standard as any other contribution.
Code must be correct, maintainable, tested, and consistent with project conventions.
We may close pull requests where the contributor does not appear to understand the contribution they have submitted.
* **Be concise.** AI tools can generate content faster than reviewers can read it.
Contributions, PR descriptions, and issue comments should be clear, focused, and free of unnecessary detail.

### AGENTS.md

Individual repositories within the Kroxylicious organisation can include an `AGENTS.md` file.
These files provide AI tools with project-specific context such as build instructions, architecture, coding conventions, and testing expectations.
If you use an AI tool to help prepare a contribution, ensure that it can access the relevant `AGENTS.md` so that its output aligns with project conventions.

## I just have a question

If you encounter any issues while using Kroxylicious, you can get help using:
Expand Down