home / skills / next-friday / nextfriday-skills / nextfriday-best-practices

nextfriday-best-practices skill

safe

This skill helps you write and review Next.js TypeScript code by applying 41 best-practice rules across naming, style, imports, types, and React patterns.

npx playbooks add skill next-friday/nextfriday-skills --skill nextfriday-best-practices

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

Files (8)

SKILL.md

1.7 KB

---
name: nextfriday-best-practices
description: Next Friday coding standards - naming conventions, code style, imports, types, React/JSX patterns, Next.js rules. Use when writing or reviewing TypeScript/React/Next.js code.
user-invocable: false
---

# Next Friday Best Practices

Essential coding standards for Next Friday projects. This skill covers 41 rules across 7 topics.

## Topics

| Topic | Rules | Reference |
| ----- | ----- | --------- |
| Variable Naming | 5 | [variable-naming.md](variable-naming.md) |
| File Naming | 4 | [file-naming.md](file-naming.md) |
| Code Style | 13 | [code-style.md](code-style.md) |
| Imports | 3 | [imports.md](imports.md) |
| Types | 6 | [types.md](types.md) |
| React/JSX | 8 | [react-jsx.md](react-jsx.md) |
| Next.js | 2 | [nextjs.md](nextjs.md) |

## Quick Reference

When writing or reviewing code, ensure:

**Naming**
- Boolean variables use prefixes: `is`, `has`, `should`, `can`, `did`, `will`
- Constants use SCREAMING_SNAKE_CASE
- Files use kebab-case (.ts/.js), PascalCase (.tsx/.jsx), SNAKE_CASE (.md)

**Code Style**
- Use guard clauses with early returns
- Use async/await over .then() chains
- Use function declarations over arrow functions in .ts files
- Add blank lines after multi-line blocks and before return statements

**Imports**
- Use absolute imports, not relative with `../`
- Use `import type` for type-only imports

**Types**
- Props interfaces end with `Props` suffix
- Wrap component props with `Readonly<>`
- Always specify explicit return types

**React/JSX**
- Wrap lazy components in Suspense
- Extract inline objects in JSX to const variables
- Destructure props inside component body, not in parameters

**Next.js**
- Use `NEXT_PUBLIC_` prefix for client-side env vars
- No fallback values for env vars

Overview

This skill captures the Next Friday coding standards for TypeScript, React, and Next.js projects. It codifies naming, file conventions, code style, imports, typing, React/JSX patterns, and Next.js rules to keep code consistent and review-ready. Use it to enforce predictable, maintainable code across the team.

How this skill works

The skill inspects code and reviews changes against a compact set of rules covering naming, file formats, style, imports, types, component patterns, and environment handling. It highlights deviations and recommends concrete fixes, such as preferred prefixes for booleans, explicit return types, or converting relative imports to absolute paths. The guidance is practical and focused on small, high-impact adjustments.

When to use it

When writing new TypeScript, React, or Next.js components
During pull request reviews to enforce project conventions
When refactoring code to improve readability and consistency
When onboarding new team members to align coding style
Before merging changes that touch imports, types, or env vars

Best practices

Name boolean variables with is/has/should/can/did/will prefixes
Use SCREAMING_SNAKE_CASE for constants and kebab-case for script files
Prefer async/await and guard clauses with early returns for clarity
Use absolute imports and mark type-only imports with import type
Define Props interfaces with a Props suffix and wrap them in Readonly<>
Specify explicit return types and avoid inline objects in JSX

Example use cases

Reviewing a feature branch to ensure props interfaces and return types are explicit
Converting relative path imports to the project’s absolute import layout
Standardizing file names: .tsx components in PascalCase, helper .ts files in kebab-case
Refactoring a component to destructure props inside the body and extract inline JSX objects
Validating environment variable usage to ensure NEXT_PUBLIC_ prefix and no default fallbacks

FAQ

Should I always use function declarations instead of arrow functions?

Prefer function declarations in .ts files for top-level functions; use arrows where closure context or concise inline functions are appropriate.

What if an env var needs a fallback value?

Avoid embedding fallback defaults for runtime env vars; handle defaults explicitly at runtime or in configuration so their presence and origin remain clear.