Naming Rules for the Billing Team's Friday Release

The billing change that exposes a naming problem

Your team is preparing a Friday release. You ask a coding agent to add a function that finds unpaid invoices. It produces working code, but names the function fetch_unpaid_invoices. Nearby functions use names such as listPaidInvoices and getInvoiceById.

Nothing is necessarily broken. Still, someone must rename the function, update its callers, and explain the convention during review. Multiply that small correction across files, tests, and pull requests, and naming becomes a recurring cost.

Teaching an agent your naming conventions means giving it explicit, reusable instructions about those choices. You are usually not retraining the underlying model. You are supplying project context that the agent can consult while working.

A small naming rulebook beats a long style essay

Start with the decisions reviewers repeatedly correct. For a TypeScript billing service, the first version might contain these rules:

• Use camelCase for functions and variables, such as listUnpaidInvoices.
• Use PascalCase for types and classes, such as InvoiceSummary.
• Use kebab-case for source filenames, such as invoice-service.ts.
• Begin boolean names with is, has, or can, such as isOverdue.
• Use get for a single item and list for a collection. These verbs describe the result, not whether it comes from a database or an API.
• Spell out customer in application code; do not shorten it to cust.

The last two rules are especially useful because they capture team decisions that a general-purpose agent cannot reliably guess. Standard formatting is easy to infer. Local vocabulary is not.

Examples make ambiguous rules concrete

A rule such as “use descriptive names” leaves too much room for interpretation. Pair it with a preferred example, a rejected alternative, and a short reason.

For example: “Use listUnpaidInvoices, not fetchInvoiceData. The function returns multiple invoices filtered by payment status; its name should communicate both facts.”

Add exceptions where they matter. Your database might use customer_id while TypeScript uses customerId. Tell the agent to preserve database column names and translate them at the application boundary. Otherwise, a well-intentioned cleanup can accidentally change a schema or external contract.

Keep examples small and internally consistent. Three representative examples are more useful than twenty copied from unrelated parts of an aging repository.

Repository instructions put the rules near the work

Save the rulebook in version control so teammates can review changes and agents can reuse it. Use the instruction mechanism your coding tool supports: Codex supports AGENTS.md, Claude Code uses CLAUDE.md, and Gemini CLI uses GEMINI.md by default. Loading behavior and directory scope differ, so check your tool's documentation.

If several tools serve the same repository, maintain one canonical naming document and make each tool's instructions point to it. Explicitly tell the agent to read that document before editing; do not assume a referenced file is automatically loaded.

Separate repository-wide defaults from package-specific exceptions. State that explicit local rules override general defaults, and ask the agent to flag conflicts rather than invent a compromise.

A small task tests whether the instructions work

Before handing over a large feature, give the agent a narrow assignment: “Add a function that lists unpaid invoices. Read the naming rules first, follow adjacent code where it agrees with those rules, and avoid unrelated renames.”

Review the result for naming, not just correctness. If the agent chooses an unexpected name, ask which instruction or existing example informed it. That can reveal an unclear rule, a conflicting file, or instructions the agent never read.

Turn measurable rules into checks where practical. A linter can enforce some casing and naming patterns; a human reviewer still needs to judge whether a name accurately describes its purpose. Instructions improve consistency, but they do not guarantee compliance.

The same naming rules can travel between agents

Keep team conventions in the repository rather than tied to one model. For teams using different coding tools, RelayVano is worth considering: its pay-as-you-go relay works with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs. Sign up for RelayVano if that flexibility fits your workflow.

For the Friday release, success is modest and measurable: fewer naming corrections, no accidental contract changes, and a short rulebook that the next developer can understand too.