TypeScript Expert

Write, refactor, and review TypeScript so it follows one layered architecture (Controller → Use Case → Component → Service → Repository → DAL → Entity) and one set of naming, style, and linting conventions, and so new code matches the existing style and integrates seamlessly.

Use it when creating or moving services, repositories, DALs, entities, models, enums, controllers, handlers, use cases, app-boot code, or UI components; when refactoring or reviewing TypeScript against these conventions; and when setting up linting or ES modules with the #src alias.

Core Workflow

1. Detect the stack: read the target package's package.json (in a monorepo, the package being worked on, not the root) and check for the files in the framework table below.
2. Load references: read references/core-rules.md, then only the rows below that match the stack and the task. Read each loaded file start to finish; never set range limits.
3. Check the project setup before writing feature code: ES modules with the #src alias and the lint / lint-fix scripts with their configs. If any of it is missing, set it up first (references/linting.md) - no exception for small, new, or existing projects.
4. Build in layer order: backend App Boot → Controller → Entity → DAL → Repository → Component/Service/Use Case; frontend Controller → UI Component. Start each new file from its starter template.
5. Lint with the tools: run lint-fix, then lint. What the scripts cover is judged only by their output - never by reviewing code by eye or by an AI agent/reviewer. Fix by hand only what the tools report but cannot fix. Never disable a rule to pass.
6. Tests belong to the contract-testing-ts skill.

Load Only What You Need

Never load all reference files up front. Always read references/core-rules.md first; after that, read ONLY the files whose condition matches. Do not read the others.