home / skills / next-friday / nextfriday-skills / nextfriday-naming

nextfriday-naming skill

safe

This skill enforces Next Friday naming conventions for variables, constants, files, hooks, and services to improve clarity and consistency.

npx playbooks add skill next-friday/nextfriday-skills --skill nextfriday-naming

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.5 KB

---
name: nextfriday-naming
description: Next Friday naming conventions for variables, constants, files, hooks, and services. Use when writing or reviewing code that involves naming identifiers.
user-invocable: false
---

# Next Friday Naming Conventions

Rules for naming variables, constants, and files.

## Variable Naming

### Boolean Prefix

Boolean variables must use prefixes: `is`, `has`, `should`, `can`, `did`, `will`

```typescript
// Bad:
const loading = true;
const visible: boolean = true;

// Good:
const isLoading = true;
const isVisible: boolean = true;
```

### Constant Case

Constants with primitive values use SCREAMING_SNAKE_CASE.

```typescript
// Bad:
const apiUrl = "https://api.example.com";
const maxRetries = 3;

// Good:
const API_URL = "https://api.example.com";
const MAX_RETRIES = 3;
```

### Meaningful Names

No lazy identifiers (`xxx`, `asdf`) or single characters (except `i`, `j`, `k`, `n`, `_`).

```typescript
// Bad:
const xxx = "value";
items.map((x) => x.id);

// Good:
const userName = "value";
items.map((item) => item.id);
```

### Service Functions

Async functions in `*.service.ts` use `fetch` prefix.

```typescript
// Bad: user.service.ts
export async function getUsers() {}

// Good: user.service.ts
export async function fetchUsers() {}
```

## File Naming

| File Type | Convention | Example |
| --------- | ---------- | ------- |
| .ts / .js | kebab-case | `user-service.ts` |
| .tsx / .jsx | PascalCase | `UserCard.tsx` |
| .md | SNAKE_CASE | `README.md` |
| *.hook.ts | `use` prefix | `useForm()` |

Overview

This skill captures the Next Friday naming conventions for variables, constants, files, hooks, and service functions. It provides clear, actionable rules you can apply when writing or reviewing code to keep identifier names predictable and meaningful. Use it to reduce ambiguity and improve consistency across a codebase.

How this skill works

The skill inspects identifier patterns and file names against a small set of rules: boolean prefixes, constant casing, meaningful identifier checks, async service function prefixes, and file-naming styles by extension. It flags violations and suggests the preferred form so you can quickly apply consistent changes. The guidance covers variables, constants, service functions, hooks, and common file types.

When to use it

When creating or refactoring variables and constants
During code reviews to enforce consistent naming
When naming service functions that perform async fetches
When adding new components, hooks, or utility files
When establishing or documenting team naming standards

Best practices

Prefix boolean variables with is, has, should, can, did, or will
Use SCREAMING_SNAKE_CASE for primitive constants (e.g., API_URL, MAX_RETRIES)
Avoid lazy or single-character names; prefer descriptive identifiers (exceptions: i, j, k, n, _)
Prefix async service functions in *.service.ts with fetch (e.g., fetchUsers)
Match file naming to type: kebab-case for .ts/.js, PascalCase for .tsx/.jsx, SNAKE_CASE for .md, and use use-prefix for hook files

Example use cases

Rename a generic flag like loading to isLoading before committing
Convert config constants to SCREAMING_SNAKE_CASE for clarity and discoverability
Review a service file and rename getX to fetchX for all async operations
Create component files as PascalCase (UserCard.tsx) and utilities as kebab-case (user-service.ts)
Implement hooks with a use prefix and appropriate filename (useForm in use-form.hook.ts)

FAQ

Why prefix booleans with words like is or has?

Prefixes make intent explicit and improve readability in conditionals and logs (e.g., if (isVisible) reads clearly).

When should I use SCREAMING_SNAKE_CASE vs camelCase?

Use SCREAMING_SNAKE_CASE for primitive constants meant to be immutable configuration or environment values; use camelCase for regular variables and function names.