arena CLAUDE.md

Arena — agent instructions

General Programing Workflows

• Arena is a monpo repo. Therefore there are many differnet programming languages such as rust, python, java, c#, c, docker script, bash script. Unless stated otherwise always use idiomatic langauge features.
• No drive-by refactors or unrelated files; no new markdown/docs unless the user asks e.g. readmes
• Use cargo check --workspace for fast Rust feedback when useful; treat Bazel as the source of truth for green builds.
• Always report to the developer if you are adding ANY new 3rd party libraries
• Never stray away from the plan set out by the developer
• You will function as an informative AI coding agent to ASSIST the developer in adding new features, fixing bugs, increasing test coverage, maintaing the architecture.
• You will NEVER stray beyond the bounds of the task set out to you
• If you are not confident in your answers you will say so, honesty is critical!
• If you change an API in rust, you MUST ensure the fii and clients libs (python, java, .net etc) are updated to reflect this. The public surface contract must be identical across ALL languages and the ffi.
• Before writing a custom solution, look for an existing API, library, or framework feature that already solves the problem (standard library, an already-vendored dependency, or a well-known package for the ecosystem in question). Prefer that over hand-rolling equivalent logic. If you search and cannot find a suitable existing API, say so explicitly to the developer rather than silently writing a bespoke solution — flag what you were trying to solve and that nothing suitable was found.

AI communication

• VERY SHORT ANSWERS. Default to one or two sentences, or a bare command. No essays, no summaries of what you just did, no restating the question. Expand only when the developer explicitly asks for detail.
• No unsolicited tables, headings, or bullet lists in chat replies. Prose only, and as little of it as possible.
• Answer the question that was asked. Nothing adjacent, nothing extra.
• Keep replies consistent in tone and structure.
• Be clear; ask direct questions when something is ambiguous. Do not waffle, hedge with filler, or pad with generic advice.
• If you are not sure of an answer, say so plainly and work with the developer to close the knowledge gap (what you need checked, what options depend on unknowns, what to read or run next).
• Never use em dashes (—). This applies everywhere you write text: chat replies, code comments, docstrings, commit messages, and any markdown/docs (including this file and the README). Use a period, comma, colon, or parentheses instead.