tommyxchow/ai
Overview
This skill captures a personal TypeScript/React code-style guide that expresses naming, formatting, TypeScript rules, React patterns, and review severity labels. It is concise and opinionated to drive consistent code authoring, reviews, and linting/formatting configuration across projects.
How this skill works
The skill provides explicit formatting rules (Prettier settings), ESLint expectations, naming conventions, and TypeScript/React patterns to follow. When invoked it returns the preferred rule, a brief rationale, and, for larger changes, a short summary with trade-offs and recommended next steps.
When to use it
- Writing new TypeScript or React components and hooks
- Reviewing pull requests or providing code review feedback
- Refactoring existing code to improve readability or correctness
- Setting up or validating linting and formatting configurations
- Designing component or state-management APIs
Best practices
- Prefer the simplest viable solution; prioritize readability over cleverness
- Lead with the answer, then provide concise explanation and trade-offs for bigger changes
- Use 2-space indent, single quotes, no semicolons, named exports, and auto-organized imports
- Use precise TypeScript types, strict mode, inline type imports, and exhaustive switch checks
- Favor derived/declarative state; avoid useEffect unless for side effects or external sync
- Keep components functional, co-locate related code, and include usage examples for new APIs
Example use cases
- Authoring a new React component: apply PascalCase, named export, Prettier and ESLint rules, and include a usage example
- Reviewing a PR: label findings as critical/major/minor, prefer minimal diffs, and suggest simpler alternatives when appropriate
- Refactoring state: move from useState to Context or Zustand only when patterns repeat or scale requires it
- Configuring tooling: enable prettier-plugin-organize-imports, prettier-plugin-tailwindcss, and consistent-type-imports in ESLint
- Implementing API handlers: use Zod for tRPC input validation and return type-safe responses
FAQ
Named exports improve discoverability, make refactors safer, and pair better with automatic import organization.
When is using any acceptable?
Only when a precise type is infeasible; document the reason and scope, and prefer incremental typing afterwards.