Code Quality

This skill enforces TypeScript and React code quality standards across all app code. It gates common issues like file size limits, arrow functions, zero-any policies, stable React keys, and proper component boundaries so your codebase stays clean and reviewable.

npx skills add Rugved1652/vayu-ui/code-quality

Apply these rules to all app code. Follow folder-structure for file placement and design-system for tokens, styling, and compound component patterns.

Hard Gates

Formatting

Use Prettier consistently:

• Single quotes
• 2-space indentation
• 100 character line width
• Trailing commas, ES5 compatible
• Semicolons enabled

React Rules

• Use unique, stable IDs for list key props. Avoid array indexes when a list can add, remove, reorder, filter, or update.
• Use useMemo for expensive calculations and useCallback for callbacks whose identity causes needless child re-renders; do not memoize trivial code.
• Keep components pure: render JSX from props/state only; do not mutate objects, arrays, globals, props, or external variables during render.
• Never call component functions directly. Render with JSX: <MyComponent />, not MyComponent().
• Separate container and presentational responsibilities: containers manage state, data fetching, mutations, effects, and orchestration; presentational components receive props and render UI.
• Use semantic HTML first: button, form, label, nav, main, section, header, table, etc. Add ARIA only when native semantics are insufficient.
• Avoid dangerouslySetInnerHTML. If unavoidable, sanitize before rendering and isolate the usage in a small reviewed component.
• Avoid inline styles. Use CSS modules, styled components, Tailwind/design-token classes, or the project styling pattern.

TypeScript Rules

• Do not use any in source, tests, utilities, or type helpers.
• Prefer precise domain/API types from types/ and inferred Zod types from validation schemas.
• Use unknown for untrusted input, then narrow before use.
• Type exported values, hook returns, API responses, event handlers, and component props.
• Avoid non-null assertions unless the invariant is proven nearby.

Component Rules

• Keep primitives in ui/components/; use compound components in primitives or where API ergonomics require composition.
• Keep domain forms, modals, drawers, popovers, cards, and sections in containers/.
• Keep reusable non-domain app UI in components/.
• Extract repeated logic into hooks/utilities only when reuse or clarity is real.
• Prefer clear prop names over boolean clusters; use variants/enums when states are mutually exclusive.

Review Checklist

• File is in the right folder and under the 400-line cap.
• All functions are arrow functions.
• No any, hardcoded design values, inline styles, unsafe HTML, or unstable keys.
• Page/container/presentational boundaries are respected.
• Formatting matches Prettier config.
• Semantic HTML and accessibility are handled.
• Design tokens and Vayu composition rules are used.
• Data, API, schema, and table logic follow the folder-structure skill.

Anti-Patterns

• Named function declarations or directly invoked components.
• any, index keys for mutable lists, magic numbers, hardcoded strings shared across features, raw colors, custom shadows, or arbitrary radii.
• Fetching data or mutating state inside presentational components.
• page.tsx or container files growing beyond 400 lines.
• Inline table columns, inline schemas, inline API calls, or business logic inside JSX.
• Styling with the style prop when the project has CSS modules, styled components, Tailwind, or token classes.
• Putting WS hooks in root hooks/ instead of ws/hooks/.