CASSANDRA-21301: add AGENTS.md and CLAUDE.md#4734
CASSANDRA-21301: add AGENTS.md and CLAUDE.md#4734maoling wants to merge 2 commits intoapache:trunkfrom
Conversation
maoling
commented
Apr 12, 2026
- more details in the CASSANDRA-21301
|
|
||
| ## Environment | ||
|
|
||
| - Java 11 (default) or 17. |
There was a problem hiding this comment.
we support 21 in runtime now as well
| - Commit messages should reference the JIRA issue. Disclose that AI assistance was used in the PR description. | ||
|
|
||
| ``` | ||
| CASSANDRA-XXXXX: Brief description of the change |
There was a problem hiding this comment.
the format does not match the agreed commit message described in https://cassandra.apache.org/_/development/how_to_commit.html
|
|
||
| ```bash | ||
| # Run a single unit test class | ||
| ant testsome -Dtest.name=org.apache.cassandra.service.StorageServiceServerTest -Dtest.methods=testGetAllRangesEmpty |
There was a problem hiding this comment.
Differentiating how to run unit vs. integration could be useful. Though I think it's more likely that just adding a SKILL.md for running tests that has a distilled extraction of guidance from build.xml is probably the better way to do that.
So - maybe a quick example here + pointing to build.xml w/some string bread crumbs to know what to search for could be a decent 1st step.
There was a problem hiding this comment.
this is an area i feel we should have a script. For example the above is 100% wrong, and is what 90% of Cassandra dev use =D
CI uses testclasslist which has different JVM arguments, so if you test using testsome and it fails in CI you will struggle to figure out why... they are not the same!
We also have different test scopes and they have their own command or special flags... this is way too much to put in a agents file and really should just be a script to make it idiot proof (LLMs do stupid things, try to make this deterministic when possible)
| ## Build | ||
|
|
||
| ```bash | ||
| ant build # compile all classes (includes Accord submodule) | ||
| ant jar # build the main JAR | ||
| ant clean # remove locally created artifacts | ||
| ant realclean # remove entire build directory and downloaded artifacts | ||
| ``` |
There was a problem hiding this comment.
not a blocker for this PR at all, but i find its best to not let the harnest know / touch ant as its wasteful for tokens. Locally I have 2 scripts
ai-ci-test <test> -- runs the test and strips the output so its "success" *or* the failing task
ai-build -- `ant clean && ant build` but strips the output so its "success" or the failing task
| ant realclean # remove entire build directory and downloaded artifacts | ||
| ``` | ||
|
|
||
| Do NOT run `ant build` if you only need to verify a small change compiles. |
There was a problem hiding this comment.
how do you test compile then?
| ant testsome -Dtest.name=org.apache.cassandra.service.StorageServiceServerTest -Dtest.methods=testGetAllRangesEmpty | ||
| ``` | ||
|
|
||
| - When fixing a bug, first create a regression test that reproduces the failure, then implement the fix and verify. |
There was a problem hiding this comment.
not a blocker for this patch, but this is an area where skills can help. How to work with CQLTester, how to work with jvm-dtest, how to work with qt or stateful, how to work with the simulator; etc.
first create a regression test that reproduces the failure
do we have any example JIRA where this went well? I find claude makes really horrible tests. It will try to create a fake unit test that makes no sense then it defines success as it made the logic handle its test... but you actually go through Cassandra and everything is broken.
| ``` | ||
|
|
||
| - When fixing a bug, first create a regression test that reproduces the failure, then implement the fix and verify. | ||
| - Provide test(s) coverage for all new or modified code. |
There was a problem hiding this comment.
how? this is vague so LLMs are likely to make up random numbers; if we care about this (which we don't track) it should be deterministic
| ant check # runs checkstyle, RAT license check, and builds | ||
| ant checkstyle # checkstyle only |
There was a problem hiding this comment.
is there a reason the harness should use checkstyle vs check? the more we add the more likely it will do the wrong thing
| ## Code Style | ||
| Cassandra enforces style via Checkstyle (`ant checkstyle`). Key rules are included in `checkstyle.xml` file. | ||
| General style: | ||
| - 4-space indentation, no tabs. | ||
| - Braces on a new line below control statements (Allman style). | ||
| - Brace-less style for single-line control statements. | ||
| - Match existing code style in the file you are editing. | ||
| - All new files must include the Apache License 2.0 header. | ||
| - Concise English documentation is required for complex classes and methods; trivial ones may not require them. |
There was a problem hiding this comment.
Sadly this is misleading and the actual style guide is at https://cassandra.apache.org/_/development/code_style.html
The only way for a agent to know our style guide is to read that rule; and this is manual and lacking deterministic checks
There was a problem hiding this comment.
That style guide comes from the code right? We could just have a .md redirect pointing to that file for digging into specifics around style. Not sure when an LLM would be triggered to check that vs. just inferring from the local context from files.
There was a problem hiding this comment.
isn't this in the website project?
$ # in cassandra dir
$ fd code_s
$
There was a problem hiding this comment.
✓ ~/src/github/apache/cassandra-website git:(trunk) $ fd code_s
site-content/source/modules/ROOT/pages/development/code_style.adoc
| Co-authored-by: GitHub Copilot | ||
| Co-authored-by: Claude | ||
| Co-authored-by: gemini-code-assist | ||
| ``` |
There was a problem hiding this comment.
i don't think this is agreed to yet. Mick proposed in slack (informal) to use the Linux Kernal way of Assisted-by; as of this moment we don't have a syntax agreed to.
| Co-authored-by: gemini-code-assist | ||
| ``` | ||
|
|
||
| - Do NOT modify submodule references without understanding the implications. Submodule changes must be committed and pushed before the parent Cassandra commit. |
There was a problem hiding this comment.
do we need this comment? this tells the LLM to hack around Accord rather than make clean fixes. Why are we asking harnesses to own git?
| - 🚫 Never commit secrets, credentials, or API keys. | ||
| - 🚫 Never run the full test suite (`ant test`) — it takes hours. Run targeted tests only. | ||
| - 🚫 Never bypass Checkstyle violations without a suppression comment explaining why. | ||
| - 🚫 Never create summary or documentation files unless explicitly asked. |
There was a problem hiding this comment.
i feel like this should be removed; harnesses are better at maintaining docs than us humans... so actually making sure features are documented should be desired?
| - 🚫 Never bypass Checkstyle violations without a suppression comment explaining why. | ||
| - 🚫 Never create summary or documentation files unless explicitly asked. | ||
| - ⚠️ Ask before modifying the CQL grammar (`src/antlr/Cql.g`) — changes cascade widely. | ||
| - ⚠️ Ask before modifying `modules/accord/` — it is a separate repository. |
There was a problem hiding this comment.
this is a git thing, this tells the harness to hack when the proper solution is to update accord.
|
Broadly, LLM's aren't as good at being told what not to do vs. being told what to do. So we should try and err on the side of being "positively oriented" when possible. @dcapwell - do you have some scripts for the CI and testing stuff we could bundle in with this PR? |
|
yeah, i should be able to add the 3 scripts i use... |
There's some truth to this, but I think it's still useful to say what not to do. I've found in my own repos telling the LLM not to write mock-echo tests where it just verifies the mocked thing returns results, to be quite helpful. I think it helps a lot to provide the positive direction in addition to the negative. |
|
|
||
| ## Git Workflow | ||
| - Do NOT commit unless explicitly asked. | ||
| - Commit messages should reference the JIRA issue. Disclose that AI assistance was used in the PR description. |
There was a problem hiding this comment.
honestly I think we should remove this. Logically this is only needed if the committer pushes this on the author (many don't), and is done after the review.
For agent files you need them to work in 100% of sessions, and this section isn't applicable majority of the time.
For example, how does it learn the JIRA?, how does it learn the reviewers? how does it learn that a reviewer gave code feedback and should be be included as a co-author? what should the commit message be and is it in-sync with JIRA (we are required to push context to JIRA as a source of truth)?
|
going to push review branch in a second; here are example usage of the scripts |
| @@ -0,0 +1 @@ | |||
| @AGENTS.md No newline at end of file | |||
There was a problem hiding this comment.
this isn't a symlink in git, so when you checkout you get
$ cat CLAUDE.md
@AGENTS.md%
As is tradition, I communicated the tip of the iceberg on what was in my head. 😭 What I meant to get across: we should absolutely do both, but be aware that this is a current limitation so lean on the positive hard knowing they'll generally comply with that and then all caps "THE WORLD WILL END IF YOU DO THIS BAD THING" + copy/paste multiple times to tweak the attention mechanism and get it to maybe respect what we tell it not to do. So yeah - quite helpful, but understanding that the "mathematical vibe" is probably like 4:1 in terms of impact on saying what an LLM should do vs. what they should not in terms of their compliance. Plus it varies based on model too. Wild West. |
7318476 to
0e37a6e
Compare
|
Can you apply it? Don't worry about co authorship or attribution, thats something committers can do when merging
Is there anywhere these concerns are posted? Can you share a link? i get the vendor neutral aspect but also have to also grok with the fact only like 3-4 people in Cassandra don't use Claude Code; we are crazy people; and most new contributors are also likely using claude code. |
0e37a6e to
723b0af
Compare
|
|
@jmckenzie-dev @rustyrazorblade @netudima anything else you would like to see in the first iteration of this? cc @dcapwell |
| - Java 11 (default), 17, 21. | ||
| - Python 3 for `cqlsh` and dtests. | ||
| - Apache Ant >= 1.10 for all builds. Do NOT attempt to use Maven, Gradle, or any other build tool. Cassandra uses Ant exclusively. | ||
| - Do NOT attempt to install dependencies, you do not have Internet access |
There was a problem hiding this comment.
, you do not have Internet access
should remove this. Agents work best when they can fetch docs... so saying it can't do that will degrade experience.
Do NOT attempt to install dependencies should be fine, or you could expand if you want to Do NOT attempt to install dependencies, every dependency requires OSS community approval first
|
|
||
| - Java 11 (default), 17, 21. | ||
| - Python 3 for `cqlsh` and dtests. | ||
| - Apache Ant >= 1.10 for all builds. Do NOT attempt to use Maven, Gradle, or any other build tool. Cassandra uses Ant exclusively. |
There was a problem hiding this comment.
wonder if this will confuse claude to think to use ant rather than the scripts... will see i guess =D
| .build/sh/ai-ci-test org.apache.cassandra.service.StorageServiceServerTest | ||
| ``` | ||
|
|
||
| - `ai-ci-test` does NOT support method-level filtering — it runs the entire test class. |
There was a problem hiding this comment.
FYI; i have lived with this for years... telling claude this does not stop it from trying 80% of the time... tis a pain... but its a limitation with ant! In #4778 we could fix it as i made sure gradle supports method level
nothing to change in this patch, its just something i know opus still struggles with
| `.build/sh/ai-build` includes checkstyle validation. There is no need to run checkstyle separately. | ||
|
|
||
| ## Code Style | ||
| Cassandra enforces style via Checkstyle (run via `.build/sh/ai-build`). The official style guide is at https://cassandra.apache.org/_/development/code_style.html. Always defer to it when in doubt. |
There was a problem hiding this comment.
i wonder if claude will still fetch this given above we said there isn't network... i have this in my agent and its almost never fetched...
|
|
||
| ## Git Workflow | ||
| - Do NOT commit unless explicitly asked. | ||
| - Commit messages format. For example: |
There was a problem hiding this comment.
im still against this but will defer to others. How will claude know who is the reviewer? IMO this is a cassandra committer's concern and not something agents should worry about; just more chances for failure
There was a problem hiding this comment.
Assuming it can read the JIRA, it should be able to get both the feedback there, as well as the PR. I do that now with my projects.
There was a problem hiding this comment.
Assuming it can read the JIRA
We don't ship that capability yet. I have it in my commit process, its a simple API call that doesn't need auth, but there are tricky bits as the additional authors isn't a standard field, so very easy for agents to get this wrong.
Again, I am 100% against asking contributors to care about our commit message; this is a committer's issue to me (not every member agrees with my stance btw; its not a settled debate).
Also, agent files are for 100% of sessions, and this is needed after all review is done and you are ready to merge; aka its not needed for 100% of sessions so can cause issues.
dcapwell
left a comment
There was a problem hiding this comment.
I am ok with the file as is, and we can refine later on if we see issues. Ill leave to @jmckenzie-dev and @dk2k how they feel about all existing comments.
+1
Thanks for checking. I took a brief scan and I think @dcapwell has covered what I would have asked to address. It's a solid first pass and I expect to treat this as a living document more than we normally would, so I'm not concerned with having it be absolutely perfect. I think the biggest item that can be left to follow ups would be to improve the clarity around the code structure and the relationship between different core classes and their responsibilities. That can just as easily be a follow up. |
|
I have no objections |
|
Just bringing visibility. @driftx posted https://issues.apache.org/jira/browse/CASSANDRA-21301?focusedCommentId=18073143&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-18073143 with a -1 to having top level AGENTS.md and CLAUDE.md; so we can not merge until we resolve this feedback. |
|
At the time, I don't think AGENTS.md was on the table. That said I'll amend to -0, but do we really need both? |
Co-authored-by: David Capwell <dcapwell@gmail.com>
|
That's disappointing, but alright.
The inconsistency there suggests that perhaps nobody really knows what the correct track is yet, and I do think we'll see friction from this, but I am -0. |
