typescript-conventionslisted

Conventions for TypeScript in this house style. The point is not to be comprehensive — it is to settle the handful of decisions that otherwise get made differently every time and then cost a reviewer an argument. ## The first rule: match what is already there Read before writing. If the project already picked a schema library, a test runner, a state manager, a file layout, or an export style, **that choice wins over anything in this skill**. A codebase with two idioms for one job is worse than a codebase with one mediocre idiom, because every reader now has to know which files follow which. These are the defaults for greenfield code and the tiebreaker when the codebase is genuinely silent. They are not a licence to refactor what exists. If an existing convention looks wrong, say so in one line and keep matching it — changing it is its own task with its own review. ## Which reference to read | Working on | Read | | ---------- | ---- | | React components, pages, hooks, client state, forms | `references/react.md` | | Fastify routes, plugins, services, migrations, server setup | `references/fastify.md` | | Shared types, utils, config, anything stack-neutral | This file alone | Read only the half you need — both reference files assume the shared rules below. ## Type discipline **`strict: true`, and no `any`.** When a type is genuinely unknown, use `unknown` and narrow it. `unknown` forces the check that `any` skips, which is the whole point. An `any` that reaches a shared