agentleFS
LaoitdevOpenLaoitdevOpen/laoitdev-skills/skills/frontend/react-standard/SKILL.md

react-standard

Skill0 starsChanged 4 months agoMITView on GitHub

Core frontend coding standards for React + TypeScript projects using MUI, TanStack libraries, i18next, and Zod. Use this whenever writing any new component, hook, service, type, or utility — or when reviewing existing code for consistency. Covers naming conventions, file structure, TypeScript patterns, i18n, error handling, and import aliases.

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. About 0 are common, 3 are distinctive, and 15 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 15

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Always use useTranslation() for user-visible strings — never hardcode them.

    line 10
  2. Distinctive:

    Use named exports, not default exports, for everything except route components.

    line 11
  3. Very specific:

    Never use npm, yarn, or pnpm.

    line 28
  4. Very specific:

    All files are .ts or .tsx.

    line 52
  5. Very specific:

    Prefer type over interface for data shapes.

    line 53
  6. Very specific:

    Avoid any. Use unknown at system boundaries.

    line 54
  7. Very specific:

    Never as any unless wrapping a known incompatibility (e.g., TanStack Form generics).

    line 56
  8. Very specific:

    Use path alias @/ for absolute imports from src/:

    line 70
  9. Very specific:

    Prefer relative imports for intra-feature files.

    line 77
  10. Very specific:

    Always use useTranslation() — never hardcode user-visible strings.

    line 81
  11. Distinctive:

    Write no comments unless the WHY is non-obvious.

    line 110
  12. Very specific:

    Use sx prop for one-off styles.

    line 129
  13. Very specific:

    Prefer MUI responsive breakpoints: { xs: ..., sm: ..., md: ...

    line 130
  14. Very specific:

    Use elevation={0} with border on Cards for flat design.

    line 131
  15. Very specific:

    Use Container maxWidth="xl" for page-level containers.

    line 132
  16. Very specific:

    MUI Grid must use the size prop: Never put breakpoint props directly on <Grid> (xs, sm, md, lg, xl).

    line 138
  17. Very specific:

    Import from @mui/material — MUI v9 unified Grid, no separate Grid2 import:

    line 140
  18. Distinctive:

    Prefer shared components over re-implementing:

    line 164

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Frontend Coding Standards

Core Invariants (always enforced — never violate)

  • Always use useTranslation() for user-visible strings — never hardcode them.
  • Use named exports, not default exports, for everything except route components.
  • Route files live only in src/routes/ — never create route files inside features/.
  • Use bun for all package installation — never npm, yarn, or pnpm.
  • Use MUI Grid size prop for column sizing — never xs/sm/md/lg/xl props directly on Grid.

Package Manager

This project uses bun exclusively. Always use bun for all package operations:

bun add <package>          # install a dependency
bun add -d <package>       # install a dev dependency
bun install                # install all dependencies from lockfile
bun run <script>           # run a package.json script
bunx <cli>                 # run a package binary without installing globally

Never use npm, yarn, or pnpm.

Tech Stack

ConcernLibrary
UIMUI v9 (Material UI)
Tablesmaterial-react-table v3 (via shared DataTable wrapper)
Styling engine@emotion/react + @emotion/styled (required MUI peer deps)
RoutingTanStack Router (file-based)
Data fetchingTanStack Query v5
FormsTanStack Form v1
ValidationZod v4
i18ni18next + react-i18next
HTTPAxios (shared instance from @/core/api/axios.config)
DateDay.js (via MUI LocalizationProvider with AdapterDayjs)

MUI v9 requires both @emotion/react and @emotion/styled as peer dependencies. Always install them together:

bun add @mui/material @emotion/react @emotion/styled

TypeScript

  • All files are .ts or .tsx. No .js.
  • Prefer type over interface for data shapes; use interface only when extension is needed.
  • Avoid any. Use unknown at system boundaries; narrow before use.
  • Export types from the feature's types/index.ts or alongside the component.
  • Never as any unless wrapping a known incompatibility (e.g., TanStack Form generics).

Naming Conventions

  • Components: PascalCase (ElectricityList, SectionCard)
  • Hooks: camelCase prefixed with use (useElectricities, useCreateElectricity)
  • Services: camelCase object exported as const (electricityService)
  • Types: PascalCase (Electricity, ElectricityFilterParams)
  • Constants: SCREAMING_SNAKE_CASE for values, PascalCase for option arrays (ELECTRICITY_ENDPOINTS, USER_USING_TYPES)
  • Files: kebab-case (electricity.service.ts, useElectricities.ts)
  • Route files: live in src/routes/_layout/section/feature/ only — kebab-case directories, index.tsx for list, create.tsx for create, $paramId/index.tsx for detail, $paramId/edit.tsx for edit

Imports

Use path alias @/ for absolute imports from src/:

import { DataTable } from '@/shared/components/DataTable'
import { useSnackbar } from '@/core/context/SnackbarContext'
import { electricityService } from '../services'

Prefer relative imports for intra-feature files; use @/ for cross-feature or shared.

i18n

Always use useTranslation() — never hardcode user-visible strings.

const { t } = useTranslation()
// Usage
t('electricities.code')
t('common.save')

Translations live in the i18n config. Key structure: featureName.keyName or common.keyName.

Error Handling

  • API errors surface via useSnackbar() (showSuccess, showError).
  • Translate API errors with useAPIErrorTranslator() → translateError(error).
  • Form submit errors show inline via onError of useMutation.
const { showSuccess, showError } = useSnackbar()
const { translateError } = useAPIErrorTranslator()

mutation.mutate(data, {
  onSuccess: () => showSuccess(t('feature.updateSuccess')),
  onError: (error) => showError(translateError(error)),
})

Comments

Write no comments unless the WHY is non-obvious. Self-documenting names are preferred.

Component Shape

Functional components only. Named exports (not default exports) for everything except route components which can be inline functions.

// Named export - preferred
export function ElectricityList({ data, isLoading }: ElectricityListProps) { ... }

// Props interface above component
interface ElectricityListProps {
  data?: Electricity[]
  isLoading?: boolean
}

MUI Usage

  • Use sx prop for one-off styles; avoid inline style.
  • Prefer MUI responsive breakpoints: { xs: ..., sm: ..., md: ... }.
  • Use elevation={0} with border on Cards for flat design.
  • Use Container maxWidth="xl" for page-level containers.

MUI Grid

MUI v9: Grid2 is deprecated and removed. It has been merged into Grid. Always import Grid from @mui/material.

MUI Grid must use the size prop. Never put breakpoint props directly on <Grid> (xs, sm, md, lg, xl). Never use the legacy item prop. Never import or use Grid2.

Import from @mui/material — MUI v9 unified Grid, no separate Grid2 import:

import { Grid } from '@mui/material'
WrongCorrect
<Grid xs={12} md={6}><Grid size={{ xs: 12, md: 6 }}>
<Grid item xs={12} md={6}><Grid size={{ xs: 12, md: 6 }}>
import Grid2 from '@mui/material/Grid2'import { Grid } from '@mui/material'
<Grid md={10}><Grid size={{ md: 10 }}> or <Grid size={10}>

Container rows stay unchanged:

<Grid container spacing={3}>
  <Grid size={{ xs: 12, md: 6 }}>...</Grid>
  <Grid size={12}>...</Grid>
</Grid>

Shared Components

Prefer shared components over re-implementing:

  • DataTable — MRT wrapper for all data tables
  • SectionCard — Card with icon + title for detail pages
  • InfoRow — label/value pair inside SectionCard
  • OrganizationFilter — org hierarchy filter UI
  • ConfirmDialog / useConfirmDialog — confirmation modals
  • Form components via useAppForm (see frontend-tanstack-form skill)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.