# TS Style Review

> Review TypeScript code against the Google TypeScript Style Guide plus team conventions. Use when reviewing TS code for style, naming, imports, type usage, or quality.

- Skill: `browseros-ai/ts-style-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add browseros-ai/ts-style-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/browseros-ai/ts-style-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: browseros-ai (https://skillmd.com/u/browseros-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/browseros-ai/ts-style-review

---


# TypeScript Style Guide Review

When reviewing TypeScript code, check against these sections. For full rules and examples, see [google-ts-styleguide.md](google-ts-styleguide.md).

## 1. Source File Structure
- File order: copyright, `@fileoverview`, imports, implementation
- Use named exports only — no default exports
- Use ES6 modules — no `namespace`, no `require()`
- Prefer namespace imports for large APIs, named imports for frequently used symbols
- No mutable exports (`export let`) — use getter functions instead
- See [google-ts-styleguide.md](google-ts-styleguide.md) § 3. Source file structure

## 2. Variables & Literals
- `const` by default, `let` when reassigned, never `var`
- One variable per declaration
- Single quotes for strings, template literals for concatenation
- No `Array()` or `Object()` constructors
- See [google-ts-styleguide.md](google-ts-styleguide.md) § 4. Language features

## 3. Classes
- Use `readonly` for properties never reassigned after constructor
- Use parameter properties (`constructor(private readonly foo: Foo)`)
- No `public` keyword — TypeScript is public by default
- No `#private` fields — use `private` modifier
- No prototype manipulation
- See [google-ts-styleguide.md](google-ts-styleguide.md) § 4. Classes

## 4. Functions
- Prefer function declarations for named functions
- Arrow functions for callbacks and nested functions — never function expressions
- Use rest parameters, not `arguments`
- Use spread syntax, not `Function.prototype.apply`
- See [google-ts-styleguide.md](google-ts-styleguide.md) § 4. Functions

## 5. Control Flow & Error Handling
- Always use braces for control flow blocks
- Always `===` and `!==` (exception: `== null` for null/undefined check)
- `for...of` for arrays, never `for...in`
- Only throw `Error` instances (or subclasses), never strings
- All `switch` must have `default`, no fall-through
- See [google-ts-styleguide.md](google-ts-styleguide.md) § 4. Control structures

## 6. Naming
- `UpperCamelCase`: classes, interfaces, types, enums, decorators, TSX components
- `lowerCamelCase`: variables, parameters, functions, methods, properties
- `CONSTANT_CASE`: global constants, enum values
- Descriptive names — no ambiguous abbreviations
- Treat acronyms as words (`loadHttpUrl`, not `loadHTTPURL`)
- See [google-ts-styleguide.md](google-ts-styleguide.md) § 5. Naming

## 7. Type System
- Prefer `interface` over `type` alias for object shapes
- Use `unknown` over `any` — narrow with type guards
- Use optional (`?`) over `| undefined`
- `T[]` for simple types, `Array<T>` for complex
- No wrapper types (`String`, `Boolean`, `Number`) — use primitives
- No `@ts-ignore` or `@ts-nocheck`
- See [google-ts-styleguide.md](google-ts-styleguide.md) § 6. Type system

## 8. Schema & Type Definitions (Team Convention)
- Use **Zod** for defining schemas, then derive TypeScript types with `z.infer<typeof schema>`
- If types are **not shared** across files, define the Zod schema and inferred type at the **top of the same file** that uses them
- If types **are shared**, place them in a shared types/schemas module
- Example:
  ```ts
  import { z } from 'zod';

  const UserSchema = z.object({
    id: z.string(),
    name: z.string(),
    email: z.string().email(),
  });

  type User = z.infer<typeof UserSchema>;
  ```

## 9. Comments & Documentation
- `/** JSDoc */` for public API documentation
- `//` for implementation comments
- No type annotations in JSDoc — TypeScript handles types
- Mark deprecated code with `@deprecated`
- See [google-ts-styleguide.md](google-ts-styleguide.md) § 8. Comments and documentation