busirocket-typescript-react-standards_skill
0
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill busirocket/agents-skills --skill busirocket-typescript-react-standards- SKILL.md2.3 KB
Overview
This skill defines strict TypeScript and React standards for maintainable codebases. It enforces one-thing-per-file, consistent type naming, and Next.js special-file export exceptions. Use it to keep types, components, and helpers predictable and easy to navigate during development or refactors.
How this skill works
The skill inspects .ts/.tsx files and validates file-level rules such as one exported symbol per module and no inline type or interface declarations in components, hooks, utilities, services, or route handlers. It recognizes Next.js special-file locations and allows documented exceptions (page/layout defaults and API route method exports). Rule files explain intent, show correct/incorrect samples, and link to required checks to run after changes.
When to use it
- Creating or refactoring .ts and .tsx files in a TypeScript React or Next.js project
- Moving inline types into a shared types/ directory to improve reuse and discoverability
- Enforcing consistent type naming and standardized result shapes across boundaries
- Working on Next.js app routes and pages where framework exceptions apply
- Running project hygiene or validation after meaningful changes
Best practices
- Keep exactly one exported symbol per file for your own modules to simplify imports and reviews
- Place shared shapes under types/<area>/ with one type per file and clear naming (Params, Result, Error, Props)
- Avoid barrel index.ts files that can hide real dependencies and complicate refactoring
- Never declare inline interface or type inside components, hooks, utilities, services, or route handlers
- Run the project’s standard checks (for example yarn check:all) after meaningful changes
Example use cases
- Refactor a component that contains inline request/response types by moving those types into types/ui/ComponentResult.ts
- Migrate a monolithic utils file into single-export helper modules to comply with one-thing-per-file
- Validate a Next.js app/page that must export a default component and metadata without breaking rules
- Apply uniform Result/ResultError shapes at API boundaries to ensure consistent error handling
- Audit a codebase to remove barrel exports and make dependency edges explicit
FAQ
Common exceptions include app/**/page.tsx and app/**/layout.tsx allowing a default export plus metadata helpers, and app/api/**/route.ts allowing multiple HTTP method exports and route config exports.
Why one exported symbol per file?
One export per file makes intent explicit, simplifies imports, reduces accidental coupling, and speeds code reviews and refactors.
Where should I put a small helper used only by one component?
If truly private to the component, keep it local but avoid placing type declarations inline; prefer moving any shared types to types/ and keep helpers separate from component logic when possible.
