Conversation
Added comprehensive CLAUDE.md files for the core library and all modules (dataframe-json, dataframe-arrow, dataframe-excel, dataframe-jdbc, dataframe-csv). These files provide guidance on module-specific details, public API descriptions, build commands, architecture, and tests, ensuring consistent documentation across the repository.
There was a problem hiding this comment.
Pull request overview
This PR adds module-scoped CLAUDE.md documentation across the Kotlin DataFrame repository to complement the root CLAUDE.md, providing contributors with consistent, module-specific guidance (APIs, architecture notes, build/test commands, and testing layouts).
Changes:
- Add new
CLAUDE.mdfiles forcoreand key I/O modules (dataframe-json,dataframe-arrow,dataframe-excel,dataframe-jdbc,dataframe-csv). - Expand
dataframe-arrow/README.mdwith a clearer description of Arrow IPC/Feather and Parquet (read-only) support. - Add detailed public API and testing notes per module, including binary-compat guidance where applicable.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
CLAUDE.md |
Adds repository-wide contributor guidance (build/test, architecture, KoDEx, constraints). |
core/CLAUDE.md |
Documents core module architecture, key types, API→impl conventions, codegen, and build specifics. |
dataframe-json/CLAUDE.md |
Documents JSON module purpose, public IO API, inference knobs, and tests. |
dataframe-arrow/README.md |
Clarifies Arrow IPC/Feather read/write support and Parquet read-only support. |
dataframe-arrow/CLAUDE.md |
Documents Arrow module API surface, implementation map, JVM flags, and tests. |
dataframe-excel/CLAUDE.md |
Documents Excel read/write API surface, dependencies, stability expectations, and tests. |
dataframe-jdbc/CLAUDE.md |
Documents JDBC module API, DbType pipeline/extension points, and test organization. |
dataframe-csv/CLAUDE.md |
Documents CSV/TSV/delimited IO API layout, implementation split, and tests/benchmarks. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| **JVM flag:** Arrow uses off-heap memory via `java.nio`, so the test task passes | ||
| `--add-opens java.base/java.nio=ALL-UNNAMED` (see `build.gradle.kts`). Downstream users on JDK 16+ need the same | ||
| `--add-opens` at runtime. |
| `@ExportAsHtml`). See `KODEX_KDOC_PREPROCESSING.md` and `KDOC_GUIDELINES.md`. | ||
|
|
||
| - `core:processKDocsMain` processes KDocs into `generated-sources`; `changeJarTask` makes `sources.jar` use those. | ||
| - **Do not hand-edit generated sources** (`*.Generated.kt`, `*$Extensions.kt`, generated HTML under |
There was a problem hiding this comment.
hallucination. There's no kt files in that folder
| @@ -0,0 +1,82 @@ | |||
| # CLAUDE.md | |||
There was a problem hiding this comment.
please rename them all to AGENTS.md and also add once in /docs and/or /samples
| integrations that now live in dedicated modules. | ||
| - **I/O modules** (each depends on `core`): `dataframe-csv`, `dataframe-json`, `dataframe-excel`, | ||
| `dataframe-arrow`, `dataframe-jdbc`. The root `dataframe` artifact re-exports Arrow/Excel/JDBC/CSV/JSON as `api`. | ||
| - **Integrations**: `dataframe-jupyter`, `dataframe-geo` → `dataframe-geo-jupyter`, `dataframe-openapi` → |
There was a problem hiding this comment.
also I/O modules but experimental
| Operations are annotated for the compiler / IntelliJ plugins (`@Refine`, `@Interpretable("…")`, `@AccessApiOverload`, | ||
| `@RequiredByIntellijPlugin`, from `annotations/`). Preserve these annotations when editing signatures. | ||
|
|
||
| ## Column selection DSL |
There was a problem hiding this comment.
Column(s) Selection DSL
Jolanrensen
left a comment
There was a problem hiding this comment.
Overall good additions! See comments
Introduced a detailed `AGENTS.md` file under `docs/StardustDocs` that guides documentation structure and editing rules for the documentation site. The new file explains WriterSide project setup, content organization, and auto-generation practices, ensuring consistency and clarity in further document collaboration.
There was a problem hiding this comment.
I don't think these are needed, right?
There was a problem hiding this comment.
plus it seems some places no longer have CLAUDE.md files and others have been turned into this. I would only keep AGENTS.md files and not clutter stuff with agent-specific files.
There was a problem hiding this comment.
No, you need, for now it's officially recommended practice (to have empty Claude.md with reference to Agents.md) it significantly reduces the number of ignoring these files from the Claude agent side
…`dataframe-jdbc` database support details.
|
Okay, good :) It seems there's still some modules lacking AGENTS.md files:
and maybe build(-settings)-logic, but those also have a comprehensive README.md already |
Added comprehensive CLAUDE.md files for the core library and all modules (dataframe-json, dataframe-arrow, dataframe-excel, dataframe-jdbc, dataframe-csv). These files provide guidance on module-specific details, public API descriptions, build commands, architecture, and tests, ensuring consistent documentation across the repository.
The problem: every time you start a session, Claude begins with zero memory of our project. It doesn't know how we build, which module does what, our code style, or our conventions. So it guesses — and guesses are often wrong or generic.
CLAUDE.md fixes that. It's a plain Markdown file with project instructions that Claude Code reads automatically at the start of every session. It's basically an onboarding doc — but for the AI. In it we write the things a new teammate would need to know:
how to build, lint, and run tests (exact commands);
what each module is and how the code is organized;
our code style and conventions;
hard rules ("don't hand-edit generated files", "don't point tests at prod DB").
Why one file per module? We put a general CLAUDE.md at the repo root, plus a smaller one inside big modules (core, dataframe-jdbc, dataframe-csv, dataframe-json, dataframe-arrow, dataframe-excel). When Claude works on files in, say, dataframe-jdbc/, it loads that module's file too — so it gets focused, relevant context instead of one giant document.
What we get out of it:
Consistency — the AI follows our conventions instead of inventing its own each time.
Fewer mistakes — it runs the right commands and doesn't touch things it shouldn't.
Less hand-holding — you don't have to re-explain the project in every chat.
It's just Markdown, in git — anyone can read and edit it in a PR. No special tooling.
In short: these files are how we teach the AI our project once, so it's useful from the first message instead of guessing.