elastic-ramen
AGENTS.md19 starsChanged 8 months agoMITView on GitHub
Prefer single word names for variables and functions. Only use multiple words if necessary. THIS RULE IS MANDATORY FOR AGENT WRITTEN CODE. Reduce total variable count by inlining when a value is only used once. Avoid unnecessary destructuring. Use dot notation to preserve context. Prefer const over let. Use ternaries or early returns instead of reassignment. Avoid else statements. Prefer early returns. Use snake_case for field names so column names don't need to be redefined as strings.
We split this AGENTS.md into the rules it gives an agent
19 rules. About 0 are common, 13 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈13
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 3
ALWAYS USE PARALLEL TOOLS WHEN APPLICABLE.
- Distinctive: line 6
Prefer automation: execute requested actions without confirmation unless blocked by missing info or safety/irreversibility.
- Distinctive: line 12
Keep things in one function unless composable or reusable
- Very specific: line 13
Avoid try/catch where possible
- Very specific: line 14
Avoid using the any type
- Distinctive: line 15
Prefer single word variable names where possible
- Very specific: line 16
Use Bun APIs when possible, like Bun.file()
- Distinctive: line 18
Prefer functional array methods (flatMap, filter, map) over for loops.
- Distinctive: line 22
Prefer single word names for variables and functions.
- Distinctive: line 28
Use single word names by default for new locals, params, and helper functions.
- Distinctive: line 30
Do not introduce new camelCase compounds when a short single-word alternative is clear.
- Distinctive: line 31
Before finishing edits, review touched lines and shorten newly introduced identifiers where possible.
- Distinctive: line 58
Avoid unnecessary destructuring.
- Very specific: line 71
Prefer const over let. Use ternaries or early returns instead of reassignment.
- Very specific: line 85
Avoid else statements. Prefer early returns.
- Distinctive: line 103
Use snake_case for field names so column names don't need to be redefined as strings.
- Distinctive: line 123
Avoid mocks as much as possible
- Distinctive: line 124
Test actual implementation, do not duplicate logic into tests
- Very specific: line 129
Always run bun typecheck from package directories (e.g., packages/opencode), never tsc directly.
≈ “Common” is an estimate: at least 1 in 5 of the 36,368 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
- To regenerate the JavaScript SDK, run
./packages/sdk/js/script/build.ts. - To rebuild the opencode package, run
bun run script/build.tsfrompackages/opencode. This requires full network access (required_permissions: ["full_network"]). - ALWAYS USE PARALLEL TOOLS WHEN APPLICABLE.
- The default branch in this repo is
dev. - Local
mainref may not exist; usedevororigin/devfor diffs. - Prefer automation: execute requested actions without confirmation unless blocked by missing info or safety/irreversibility.
Style Guide
General Principles
- Keep things in one function unless composable or reusable
- Avoid
try/catchwhere possible - Avoid using the
anytype - Prefer single word variable names where possible
- Use Bun APIs when possible, like
Bun.file() - Rely on type inference when possible; avoid explicit type annotations or interfaces unless necessary for exports or clarity
- Prefer functional array methods (flatMap, filter, map) over for loops; use type guards on filter to maintain type inference downstream
Naming
Prefer single word names for variables and functions. Only use multiple words if necessary.
Naming Enforcement (Read This)
THIS RULE IS MANDATORY FOR AGENT WRITTEN CODE.
- Use single word names by default for new locals, params, and helper functions.
- Multi-word names are allowed only when a single word would be unclear or ambiguous.
- Do not introduce new camelCase compounds when a short single-word alternative is clear.
- Before finishing edits, review touched lines and shorten newly introduced identifiers where possible.
- Good short names to prefer:
pid,cfg,err,opts,dir,root,child,state,timeout. - Examples to avoid unless truly required:
inputPID,existingClient,connectTimeout,workerPath.
// Good
const foo = 1
function journal(dir: string) {}
// Bad
const fooBar = 1
function prepareJournal(dir: string) {}Reduce total variable count by inlining when a value is only used once.
// Good
const journal = await Bun.file(path.join(dir, "journal.json")).json()
// Bad
const journalPath = path.join(dir, "journal.json")
const journal = await Bun.file(journalPath).json()Destructuring
Avoid unnecessary destructuring. Use dot notation to preserve context.
// Good
obj.a
obj.b
// Bad
const { a, b } = objVariables
Prefer const over let. Use ternaries or early returns instead of reassignment.
// Good
const foo = condition ? 1 : 2
// Bad
let foo
if (condition) foo = 1
else foo = 2Control Flow
Avoid else statements. Prefer early returns.
// Good
function foo() {
if (condition) return 1
return 2
}
// Bad
function foo() {
if (condition) return 1
else return 2
}Schema Definitions (Drizzle)
Use snake_case for field names so column names don't need to be redefined as strings.
// Good
const table = sqliteTable("session", {
id: text().primaryKey(),
project_id: text().notNull(),
created_at: integer().notNull(),
})
// Bad
const table = sqliteTable("session", {
id: text("id").primaryKey(),
projectID: text("project_id").notNull(),
createdAt: integer("created_at").notNull(),
})Testing
- Avoid mocks as much as possible
- Test actual implementation, do not duplicate logic into tests
- Tests cannot run from repo root (guard:
do-not-run-tests-from-root); run from package dirs likepackages/opencode.
Type Checking
- Always run
bun typecheckfrom package directories (e.g.,packages/opencode), nevertscdirectly.
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 28,693 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository8 other files it gives its agents.
- packages/opencode/AGENTS.mdAGENTS.md
- packages/opencode/test/AGENTS.mdAGENTS.md
- elastic-cli-usageSkill
- elasticsearch-esqlSkill
- observability-rcaSkill
- slo-managementSkill
- agents-sdkSkill
- cloudflareSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

