# Write React Code

> Use whenever a task writes or modifies React code, including JSX or TSX components, hooks, React tests, and React code snippets. Do not use for non-React JavaScript or standalone SCSS work.

- Skill: `legendarylinux/write-react-code` (Agent Skill)
- Install (CLI): `npx skillmds@latest add legendarylinux/write-react-code`
- Raw SKILL.md: https://api.skillmd.com/api/skills/legendarylinux/write-react-code/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: LegendaryLinux (https://skillmd.com/u/legendarylinux)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/legendarylinux/write-react-code

---


# Write React Code

Use this skill whenever React code is written or changed. Apply these conventions to new React code and to lines
touched by the task. Preserve unrelated code and follow an explicit user instruction when it conflicts with this
skill.

## General Rules

- Keep React, JSX, and SCSS under `src/`.
- Keep every line at or under 120 characters, including Markdown changed as part of the task.
- Do not introduce unused variables or unrelated formatting churn.
- Use 2 spaces for indentation and never use tabs in JavaScript, JSX, or SCSS.
- Use single quotes for JavaScript strings and terminate JavaScript statements with semicolons.
- Inspect nearby files before adding a new pattern. Reuse established shared components, SCSS modules, and mixins
  when they fit the requested behavior.

## Components And Files

- Put each React component in its own file.
- Declare function components as named exported arrow functions. Do not default-export function components.
- Use parentheses around destructured props and no spaces inside their braces.
- Put one blank line between imports and the component declaration.
- Allow an implicit return only for very small components such as route wrappers.
- Give feature or page components a root element with a kebab-case `id`.
- Give small reusable components a root element with a kebab-case class.
- If local styles are needed, create an adjacent, matching `Foo.scss` and import it from `Foo.js`.
- Do not create empty SCSS placeholders or use inline styles when adjacent or shared SCSS is appropriate.
- A JavaScript file whose primary purpose is a class must declare `class Foo` and end with `export default Foo;`.

```jsx
import React from 'react';
import './Foo.scss';

export const Foo = ({message}) => {
  return (
    <div id="foo">
      {message}
    </div>
  );
};
```

## Imports

Order imports without blank lines between groups:

1. React.
2. Router.
3. Third-party packages.
4. Project modules.
5. Adjacent styles.

- Do not put spaces inside named import braces.
- Import router primitives such as `Routes`, `Route`, `Navigate`, and hooks from `react-router`.
- Import DOM-specific components such as `Link` from `react-router-dom`.

```js
import React, {useEffect, useState} from 'react';
import {Route, Routes, useParams} from 'react-router';
import {Link} from 'react-router-dom';
import {LoadingScreen} from '../global/components/LoadingScreen';
import './Customer.scss';
```

## Component Body Order

Keep component bodies in this order:

1. Router hooks.
2. Context hooks.
3. State hooks.
4. Ref hooks.
5. Derived constants used by hooks or rendering.
6. Effects, with no-dependency effects before dependency-driven effects.
7. Helpers and event handlers.
8. Early returns.
9. Main JSX.

- Keep hooks at the top and dependency arrays explicit.
- Separate effects and functions with blank lines.
- Define state-dependent helpers and handlers as `const` arrow functions inside the component.
- Pass a named handler to JSX when no arguments need binding.
- Use an inline arrow only to bind arguments or perform a small direct state update.
- Do not extract a one-use expression solely to make it indirect. Extract reused or materially clearer logic.

## JavaScript Layout

- Put a space before `{` in functions and control flow and after control-flow keywords.
- Put spaces around binary operators and around `=` in default parameters.
- Use trailing commas in multiline objects and arrays.
- Keep short object literals inline with spaces inside their braces.
- Put multiline object properties and array items one per line.
- Use comments sparingly to explain intent, side effects, or non-obvious behavior.

```js
const loadData = (marker = null) => {
  if (marker) {
    request.marker = marker;
  }
};

const crumbs = [
  { text: 'Customers', path: '/customers' },
];
```

## JSX Layout

- Parenthesize JSX only when it spans multiple lines.
- Keep a readable simple element on one line.
- For a complex element, put one prop per line and the closing `>` on its own line.
- Self-close elements without children.
- Use anonymous fragments unless the fragment needs a `key`; use `React.Fragment` when it does.
- Do not extract render variables used once unless that materially improves readability.

For larger conditional sections, put the JSX braces on their own lines and use ternaries that return `null`.
Nested ternaries are acceptable only while readable. In multiline ternaries, place `?` after the condition and `:`
after the complete truthy branch.

```jsx
{
  hasAccess ?
    <FeaturePanel /> :
    null
}
```

## SCSS

- Scope page and feature styles under the component's root `id`.
- Scope reusable component styles under the component's root class.
- Use kebab-case selectors and avoid BEM unless the local file already establishes it.
- Use simple state classes such as `.active`, `.danger`, `.disabled`, and `.invalid` where appropriate.
- Use Sass `@use`, place all `@use` statements first, and leave one blank line after them. Do not use `@import`.
- Put a space before `{`, close braces on their own line, and separate sibling blocks with one blank line.
- Nest enough to preserve component scope, but avoid unnecessary depth.
- Nest pseudo-classes, state modifiers, and component-specific media queries under the selector they affect.
- Loosely order properties from structure and positioning, through size and spacing, to visual and type effects.
- Prefer established SCSS variables and mixins over hard-coded application colors or duplicated patterns.
- Put third-party overrides in the established overrides file rather than a component file.
- Do not treat an application's palette as an organization-wide brand palette.
- Comment only unusual browser behavior, third-party overrides, or non-obvious groupings.

```scss
@use '../global/mixins/colors';

#customer {
  display: flex;
  width: 100%;
  border: 1px solid colors.$border-color;

  .actions {
    display: flex;
    gap: 0.5rem;
  }

  @media (max-width: 600px) {
    .actions {
      flex-direction: column;
    }
  }
}
```

## Verification

- Run the narrowest relevant formatter, linter, and tests available to the changed code.
- Recheck import order, export shape, hook order, root selector matching, indentation, and the 120-character limit.
- Report checks that could not be run; do not claim unperformed verification.