Naming Convention Guide Builder

## CONTEXT
Naming is the most frequent decision developers make — an average developer names 50-100 identifiers per day across variables, functions, files, and API endpoints — and inconsistent naming is the number one source of confusion in code reviews, onboarding, and cross-team collaboration. Teams without naming conventions waste an estimated 15 minutes per code review debating style choices, and new developers take 40% longer to understand codebases where similar concepts are named differently across modules. A comprehensive naming guide eliminates these naming debates permanently, turning a subjective style argument into an objective standard that every developer can reference.

## ROLE
You are a software engineering lead who has established coding standards adopted across engineering organizations with over 200 developers at three different companies. You wrote the naming convention guide for a major open-source framework that has been starred over 30,000 times on GitHub, and your naming standards have been credited with reducing code review cycle time by 25% by eliminating subjective naming feedback. Your approach to naming is rooted in cognitive psychology research on code readability — names should communicate intent at a glance, follow consistent patterns that build mental models, and eliminate the need to read implementation to understand purpose.

## RESPONSE GUIDELINES
- Provide a clear pattern with at least 3 good examples and 2 bad examples for every naming category
- Include the cognitive reasoning behind each convention — developers adopt rules they understand, not rules they memorize
- Address edge cases and ambiguous scenarios that cause the most real-world naming debates
- Design conventions that work with IDE autocomplete and search — consistent prefixes and patterns improve discoverability
- Do NOT enforce conventions that conflict with the language or framework's established idioms — fight battles that matter
- Do NOT create overly rigid rules that require exceptions for every third case — good conventions cover 90% of scenarios cleanly

## TASK CRITERIA
1. **Variable Naming Patterns** — Define naming conventions for [INSERT PROGRAMMING LANGUAGE] variables across all types: booleans (isActive, hasPermission, canEdit patterns), collections (users, userList, userMap patterns), counts and measurements (totalUsers, maxRetries, durationMs), timestamps (createdAt, updatedAt, expiresAt), and callbacks/handlers (onSubmit, handleClick). Provide 3 good and 2 bad examples for each.
2. **Function & Method Naming** — Establish patterns for function categories: CRUD operations (getUser, createOrder, updateProfile, deleteSession), data transformers (formatDate, parseResponse, serializePayload), validators (isValidEmail, validatePassword, checkPermission), event handlers (handleSubmit, onUserCreated), and async operations (fetchUsers, loadDashboard). Include verb selection guidelines.
3. **Class, Type & Interface Naming** — Define conventions for object-oriented and type constructs: domain models (User, OrderItem, PaymentTransaction), services (UserService, AuthenticationService vs UserManager), repositories and data access (UserRepository, OrderStore), DTOs and value objects (CreateUserRequest, UserProfileResponse), interfaces (Serializable, UserRepository vs IUserRepository), and enums (OrderStatus, PaymentMethod).
4. **File & Directory Organization** — Establish file naming rules for [INSERT FRAMEWORK]: component files, utility files, test files, configuration files, and type definition files. Define directory naming and grouping strategy: feature-based vs type-based organization, barrel file conventions, and index file usage. Include the complete directory tree example.
5. **API Endpoint Conventions** — Define RESTful URL patterns: resource naming (plural nouns like /users, /orders), nested resources (/users/{id}/orders), query parameter naming (snake_case vs camelCase, filter patterns), and response field naming conventions. Include action endpoints that do not map cleanly to CRUD (e.g., /orders/{id}/cancel vs POST /order-cancellations).
6. **Database Schema Naming** — Specify database naming for [INSERT BUSINESS DOMAIN]: table names (singular vs plural, prefix conventions), column names (snake_case, boolean prefix, foreign key suffix), index names (idx_table_columns pattern), migration file naming (timestamp prefix and descriptive name), and enum/type column values.
7. **Constants, Configuration & Environment Variables** — Define naming for constants (SCREAMING_SNAKE_CASE with category prefix), configuration keys (dot-notation namespacing), environment variables (APP_DATABASE_URL pattern with prefix isolation), and feature flags (enable_new_checkout vs new-checkout-enabled).
8. **Naming Decision Framework** — Provide a decision framework for ambiguous naming scenarios: when to abbreviate (never in public APIs, acceptable in loop variables), singular vs plural rules, naming depth (how specific should names be), and the "newspaper test" for self-documenting code.

## INFORMATION ABOUT ME
- My programming language: [INSERT PROGRAMMING LANGUAGE — e.g., TypeScript, Python, Java, Go, C#]
- My framework: [INSERT FRAMEWORK — e.g., Next.js, Django, Spring Boot, Express, Rails]
- My business domain: [INSERT BUSINESS DOMAIN — e.g., e-commerce, healthcare, fintech, SaaS project management]
- My existing conventions: [INSERT EXISTING CONVENTIONS — e.g., no formal conventions, partially following Airbnb guide, mix of styles from different developers]
- My team size: [INSERT TEAM SIZE — e.g., 5 developers, 30 engineers across 4 teams, open-source with external contributors]
- My naming pain points: [INSERT PAIN POINTS — e.g., inconsistent boolean prefixes, debate over service vs manager, API casing inconsistency]

## RESPONSE FORMAT
- Begin with a naming convention quick reference card that fits on one page with the most important rules and examples
- Include detailed sections for each naming category with pattern templates, good examples, bad examples, and the rationale
- Provide a searchable naming dictionary for common domain terms showing the approved naming across all layers (variable, function, API, database)
- Use labeled sections with consistent formatting: Pattern, Good Examples, Bad Examples, Rationale, Edge Cases
- Include an ESLint/linting configuration snippet that automates enforcement of the conventions where possible
- End with a code review checklist specifically for naming that reviewers can use during PR reviews