naming-conventions

name	naming-conventions
description	Naming rules for this repo. Use when creating or renaming variables, functions, stores, folders, routes, and screen files so names match the existing domain-first patterns.

Naming conventions

Use this skill when choosing or refactoring names. Follow the repo's domain-first naming style instead of inventing generic or verb-first names.

Core rule

• Prefer noun + verb naming for variables and functions when possible.
• Put the domain noun first and the action second.
• Good examples: profileInit, profileSet, profileClear, profileLogout, learnersInit, themeLoadedSet, apiLoadedSet.
• Avoid vague verb-first names like setProfileDataNow, handleLearner, processBook, or doUpdate when a concrete domain noun is known.

Use repo vocabulary

• Reuse nouns that already exist in the codebase: profile, auth, learner, learners, book, books, series, page, toast, theme.
• Keep naming aligned with routes, folder names, stores, and generated API models.
• If the UI says learner, do not rename the same concept to student in code unless the feature already does that consistently.

Variables and state

• Local state should be specific and readable: loading, learnerLoading, showCropper, learnerImage, nameValue.
• Setter functions should mirror the state noun: setLoading, setLearnerImage, setShowCropper.
• Booleans should read clearly as state: loading, apiLoaded, themeLoaded, showCropper.

Functions and actions

• Name functions by domain plus action: learnerGet, learnerUpdate, learnerImageUpdate, profileInit, profileUpdateImage.
• Store actions should keep the same domain noun across the store: profileSet, profileClear, profileInit.
• Use consistent action verbs across related features: get, set, clear, init, update, create, delete, logout.

Stores and components

• Stores use PascalCase plus Store: ProfileStore, AuthStore, LearnerStore.
• Components use PascalCase and usually reflect domain plus role: LearnerUpdateContent, ProfileHeader, DashboardScreen.
• Reusable helpers should be named for what they return or do, not how they are implemented.

Files and folders

• Route folders and screen files use kebab-case.
• Name folders and files by domain first, then action or role.
• Existing patterns include learner-update/, profile-update/, admin-book-create/, sign-in/, and password-reset/.
• Screen decomposition files commonly use {feature}.tsx, {feature}-header.tsx, {feature}-content.tsx, and helper files like _learner.actions.ts or _book.store.ts.

What to avoid

• Avoid generic names like data, item, thing, temp, value, or result when the real domain noun is available.
• Avoid mixing synonyms for the same concept inside one feature.
• Avoid abbreviations unless they are already established in the repo or platform API.
• Avoid naming that hides side effects; for example, prefer profileLogout over a vague name like resetUserState if the function actually logs the user out.

Quick checks before finalizing a name

• Does the name start with the domain noun?
• Does the action verb describe what it really does?
• Does the noun match the folder, route, store, or API model already used nearby?
• Would another agent understand the purpose without opening the implementation?