Descriptive, self-documenting naming in any language (TypeScript, bash, workflow YAML, Dockerfiles). Use this skill whenever naming or renaming an identifier, variable, constant, function, parameter, env var, workflow job, or Dockerfile ARG/ENV, or reviewing names for vagueness, abbreviations, or redundant type noise.
Installs into .claude/skills of the current project.
Are you the author of Naming Conventions?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/gaia-react-naming-conventions)
---
name: naming-conventions
description: Descriptive, self-documenting naming in any language (TypeScript, bash, workflow YAML, Dockerfiles). Use this skill whenever naming or renaming an identifier, variable, constant, function, parameter, env var, workflow job, or Dockerfile ARG/ENV, or reviewing names for vagueness, abbreviations, or redundant type noise.
model: haiku
---
# Naming Conventions
Follow Apple's Swift API Design Guidelines: names should be clear at the point of use, reading like prose. Favor long, descriptive names over short or abbreviated ones. Code should be readable without consulting documentation.
- **Functions and methods**: imperative verb phrases: `calculateProgressPercentageFromCompletedSets`, `processUserOnboardingProfile`
- **Parameters**: role, not type: `totalSeconds` not `n`, `emailAddress` not `s`
- **Variables**: what they hold: `restDurationInSeconds`, `submitButton`, `weightInputValue`
- **No abbreviations**: owned by `.claude/rules/no-abbreviations.md`
- **No redundant words**: `availableExercises` not `exerciseArray`, but don't sacrifice clarity for brevity
Casing is each language's own convention; for TypeScript, see the typescript skill.
> **Exception, React event handlers** follow `handle{Action}{Element}` from the react-code skill
> (e.g. `handleClickSave`, `handleChangeInput`), the `{Element}` is required, since a bare
> `handleClick` or `handleChange` trips `react-doctor/no-generic-handler-names`. The descriptive
> naming guidelines above apply to utilities, hooks, callbacks, and non-event-handler functions.
Read `references/examples.md` for extended BAD/GOOD examples of each naming pattern.
