split-component
Skill927 starsChanged 2 days agoApache-2.0View on GitHub
Split a bloated React component file into multiple co-located files following Ketcher project conventions. Use when: a component file has grown too large; it mixes constants, utility functions, and subcomponents in one file; you want to improve maintainability by separating concerns. Produces: ComponentName.constants.ts, ComponentName.utils.ts, SubComponentName.tsx — all co-located flat in the same folder, with a barrel index.ts. A ComponentName.types.ts may be created for shared domain types, but component props interfaces always stay local to their component file.
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Read the target file and categorise its top-level declarations:
- Distinctive: line 41
Create a file only if it will contain at least one item:
- Distinctive: line 92
Remove the extracted constants, utilities, and sub-components
- Distinctive: line 93
Add imports from the new files
- Very specific: line 95
Keep Props unexported unless it is used outside the folder
- Very specific: line 99
Run npm run test:types and eslint (npx eslint <component folder>) on the component folder, and fix any issues found.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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.
Files
Split Component
Splits a large component file into multiple co-located files following Ketcher project conventions.
File Layout (Ketcher conventions)
| Content | File | Example |
| Main component | ComponentName.tsx | ColorPicker.tsx |
| Constants | ComponentName.constants.ts | ColorPicker.constants.ts |
| Utilities & helpers | ComponentName.utils.ts | ColorPicker.utils.ts |
| Sub-components | SubComponentName.tsx (flat, sibling) | ColorSlider.tsx |
| CSS module | ComponentName.module.less | ColorPicker.module.less |
| Barrel export | index.ts | index.ts |
| Shared domain types | ComponentName.types.ts (optional) | ColorPicker.types.ts |
| Props / interfaces | Stay local in the component file | — |
A .types.ts file may be created for types shared across multiple files in the folder (domain types, enums, utility types). Component props interfaces are NOT placed there — they live in the same file as the component that owns them.
Steps
1. Analyse the source file
Read the target file and categorise its top-level declarations:
- Constants — module-level
constvalues (arrays, numbers, strings) - Utilities — pure functions that contain no JSX and use no React hooks
- Sub-components — functions/arrow functions that return JSX (other than the main component)
- Shared domain types — types/enums used across multiple files in the folder →
ComponentName.types.ts - Props interfaces — stay in place in their component file, do not move
- Main component — stays in the original file
2. Create only the files that are needed
Create a file only if it will contain at least one item:
ComponentName.constants.ts
// license header
export const MY_CONSTANT = ...;
export const MY_ARRAY = [...];ComponentName.utils.ts
// license header
import { MY_CONSTANT } from './ComponentName.constants'; // if needed
export function myHelper(...) { ... }
export function anotherHelper(...) { ... }SubComponentName.tsx (one file per sub-component)
// license header
import { ... } from 'react';
import classes from './ParentComponent.module.less'; // reuses the parent CSS module
interface SubComponentNameProps { // interface stays local to this file
...
}
function SubComponentName({ ... }: SubComponentNameProps) {
...
}
export default SubComponentName;index.ts
// license header
export { default } from './ComponentName';4. Update the main file
- Remove the extracted constants, utilities, and sub-components
- Add imports from the new files
- Merge split
Props+CallPropsinto a single interface if they were separate - Keep
Propsunexported unless it is used outside the folder
5. Check for errors
Run npm run test:types and eslint (npx eslint <component folder>) on the component folder, and fix any issues found.
Pay special attention to:
import typeinstead ofimportfor type-only imports (@typescript-eslint/consistent-type-importsenforces it)
What NOT to do
- ❌ Do not put component props interfaces in
ComponentName.types.ts— props stay in their component file - ❌ Do not extract functions that use React hooks (
useState,useCallback, etc.) into utils - ❌ Do not create a
components/sub-folder for simple sub-components — they live flat alongside the parent - ❌ Do not rename CSS classes or modify the
.module.lessfile - ❌ Do not add
exportto props interfaces unless they are consumed outside the folder
In this repository24 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- add-localstorage-settingSkill
- codebase-designSkill
- code-reviewSkill
- commitSkill
- create-releaseSkill
- create-verification-skillSkill
- diagnosing-bugsSkill
- generate-autotestsSkill
- ketcher-flowSkill
- ketcher-prSkill
- maintain-verification-skillSkill
- openspec-apply-changeSkill
- openspec-archive-changeSkill
- openspec-exploreSkill
- openspec-proposeSkill
- openspec-sync-specsSkill
- openspec-update-changeSkill
- prepare-releaseSkill
- review-prSkill
- tddSkill
- verify-ketcherSkill
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
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.

