Typescript House Style

by @zzstoatzz.io · created Sep 11, 2026

Install this skill

npx @skillz.supply/cli install did:plc:xbtmt2zjwlrfegqvch7fboei/skills.typescript-house-style

Writes SKILL.md into your agent's skills folder under this skill's name. No CLI? Download the file, or view it.

name: "typescript-house-style"

description: "Apply evidence-preserving TypeScript practices when implementing or reviewing JavaScript or TypeScript."

createdAt: "2026-09-11T18:46:00.191396+00:00"

repoUrl: "https://skillz.supply/skills/did:plc:xbtmt2zjwlrfegqvch7fboei/skills.typescript-house-style/SKILL.md"

# TypeScript house style

Use types to express facts established by construction, validation, or the owning API.
Follow project-local conventions and inspect relevant compiler and lint configuration.
Do not install new tooling merely because this skill is loaded.

## reuse the owner

Prefer generated types, SDK models, schemas, and library exports over parallel local
interfaces. Use maintained SDKs for service integration; justify implementing their
transport or authentication yourself. Keep domain contracts with their owning modules.

## preserve evidence

- Prefer inference when an initializer already establishes the precise type.
- Use `as const` to retain literals and `satisfies` to check a contract without widening it.
- Do not widen a known value to `any`, `unknown`, or a broad dictionary and cast it back.
- Parse untrusted input at the I/O boundary, then pass validated domain values inward.
- Model real variants with discriminated unions and handle them exhaustively.
- Keep optional and nullable states explicit.

A non-const assertion is a last resort: document the runtime invariant the compiler
cannot express. An assertion that merely silences a diagnostic is not validation.
When a check objects, first preserve inference, reuse the owner contract, or repair
the boundary parser instead of weakening the type or suppressing the rule.

## tests and verification

Tests are clients of the same contracts. Keep fixtures precise and prefer faithful
fakes or service interfaces over weakening production types for test convenience.
Run checks appropriate to the change using the repository's chosen tooling.