القائمة
React component file conventions covering structure ordering, one-component-per-file, and splitting bloated components. Use when writing or reviewing React components.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Generate a commit message from staged changes and let the user review before committing. Use when the user wants to commit changes or create a git commit.
Generate a GitHub pull request title and body from the current branch and let the user review before creation. Use when the user wants to create a pull request.
Investigate any topic by querying multiple external sources (web, official docs, GitHub, MCP servers). Use whenever a question requires information not already in the working context, including library behavior, API specifications, error diagnostics, version comparisons, or general factual lookup.
himari is ncaq's rio-like custom Haskell Prelude. Import it with a single `import Himari`, never `import Himari.Prelude` or other submodules directly. Use when writing or reviewing Haskell code in a project that depends on the himari package.
Prefer the most specific built-in method over general-purpose ones in TypeScript/JavaScript. Use includes over indexOf, some over filter().length, find over filter()[0], flatMap over map().flat(), at(-1) over length-based access, startsWith/endsWith/includes over indexOf on strings, structuredClone over JSON round-trip. Use when writing or reviewing code that searches, tests, transforms arrays, objects, or strings.
Avoid for loops (C-style, for...of, for...in) in TypeScript/JavaScript. Prefer higher-order Array methods like map, filter, find, some, every, reduce. Use when writing or reviewing loops or iteration over arrays, objects, Map, Set, or String.
| name | react-component-convention |
| description | React component file conventions covering structure ordering, one-component-per-file, and splitting bloated components. Use when writing or reviewing React components. |
| user-invocable | false |
すべてのコンポーネントファイルは、上から順に次の流れで構成します。
sva/cva/cssなどのstyled-system呼び出しtype Props = ...やinterface Props { ... }export const Foo: React.FC<Props> = ...やexport function Foo(props: Props): React.ReactElement { ... }import群は当然この前に置きます。 純粋な振る舞いだけのコンポーネントならデザイン定義は省略可能ですが、 それ以外で順序の入れ替えは認めません。
理由: 「見た目」「インターフェース」「振る舞い」の責務分離をファイル内の縦方向で表現することで、 コンポーネントを読むときの認知の階段を一定に保つため。
1つのファイルの中にexport/非exportを問わずコンポーネントを2つ以上書かないでください。
ファイル内で再利用される小さなコンポーネントが必要になった場合は、必ず別ファイルに切り出します。
切り出した先のファイル名はIDEのQuick Openで識別しやすい名前にし、
index.tsxやindex.tsといった汎用名を新規作成しないでください。
既存のindex.tsxを大幅に書き換える場合も、
リファクタリングの一環として適切なファイル名にリネームします。
例外として、他のコンポーネントのrender propに渡すためのごく小さなコンポーネントは、
その場で定義することを許容します。
<DataGrid renderRow={...} />やcolumns[i].render、
react-hook-formのControllerのrenderなどが該当します。
ただし次の条件をすべて満たすこと。
例:
// DataGridのrenderRowに渡すための行コンポーネント。このファイル内でしか使わない
const DeviceRow: React.FC<{ device: Device }> = ({ device }) => (
<tr>
<td>{device.id}</td>
<td>{device.name}</td>
</tr>
);
ファイル内で複数回使う場合、それなりの行数がある場合、 呼び出し側から渡される関数でなく通常のJSXの一部として使っている場合などは、 必ず別ファイルに切り出してください。
「関数の始まりからJSXが登場するまでに30行程度かかっている」状態は、 コンポーネントが過剰な責務を持っている兆候です。 次のいずれかの方法で責務を逃します。
ただし、JSX自体が長くなることは必ずしも悪ではありません。 判定すべきは「行数」ではなく「認知負荷」です。 次のような状態は危険信号として扱ってください。
逆に、整然と並んだ単純な要素列が長いだけであれば、無理に分割する必要はありません。 「他人がこのコンポーネントを上から下まで一気に読めるか」を基準にしてください。