home / skills / vladimirbrejcha / ios-ai-skills / typescript
This skill helps you configure TypeScript, fix type errors, and adopt best practices with dayjs and type-safe tooling.
npx playbooks add skill vladimirbrejcha/ios-ai-skills --skill typescriptReview the files below or copy the command above to add this skill to your agents.
---
name: typescript
description: This skill should be used when the user asks to "configure TypeScript", "fix type errors", "use dayjs", "add type definitions", "set up React with TypeScript", mentions ".ts" or ".tsx" files, or asks about TypeScript best practices or TypeScript-specific tooling.
---
# TypeScript Skill
## Rules
Note that these are not hard-and-fast rules. If there's a good reason not to apply a rule, don't apply it.
### Alphabetical Order
Maintain alphabetical order for better readability and consistency:
- **Function parameters** - Order by parameter name
- **Object literal fields** - Sort by key name
- **Type definitions** - Arrange fields alphabetically
- **Class properties** - Order by property name
**Example (type definitions):**
```typescript
// bad
type User = {
name: string;
age: number;
email: string;
};
// good
type User = {
age: number;
email: string;
name: string;
};
```
### Biome
Use BiomeJS for linting and formatting JavaScript and TypeScript code. Look for a `biome.jsonc` file and, if it's not present, create it.
Exception: project already uses ESLint and Prettier.
### dayjs for date and time calculations
Use the `dayjs` library for date calculations. Avoid using the native JavaScript Date object.
**Example:**
```typescript
import dayjs from "dayjs";
const now = dayjs();
const tomorrow = now.add(1, "day");
```
### No `any` type
Never use the `any` type.
### Never return a value in `forEach` callbacks
**Example:**
```typescript
[].forEach(() => {
return 1; // bad
});
[].forEach(() => {
// good
});
```
**Another example:**
```typescript
[].forEach((item) => console.log(item)); // bad
[].forEach((item) => {
console.log(item); // good
});
```
### Prefer TypeScript over JavaScript
Use TypeScript for all new code.
### Prefer `type` instead of `interface`
Use `type` instead of `interface` for declaring types.
### Use `Number.isNaN` instead of `isNaN`
**Example:**
```typescript
const x = Number.isNaN(y); // good
const x = isNaN(y); // bad
```
### Comment Dividers
Use centered comment dividers for major section breaks:
**Format (80 chars total):**
```typescript
// -------------------------------------------------------------------------- //
// TITLE //
// -------------------------------------------------------------------------- //
```
**Rules:**
- Total width: 80 characters
- Title: UPPERCASE, centered with spaces
- Border line: dashes `-` filling the space between `// ` and ` //`
**When to use:**
- Major logical sections (imports, types, constants, main logic, exports)
- Separating distinct feature areas
- NOT for every function or small grouping
**Example:**
```typescript
// -------------------------------------------------------------------------- //
// IMPORTS //
// -------------------------------------------------------------------------- //
import { Effect } from "effect";
// -------------------------------------------------------------------------- //
// TYPES //
// -------------------------------------------------------------------------- //
type Config = {
name: string;
};
```
This skill helps configure and enforce TypeScript conventions, tooling, and common patterns across a project. It focuses on safe typing, consistent ordering, formatting and linting choices, and recommended libraries for common tasks like date handling. Use it to get a predictable, maintainable TypeScript codebase.
The skill inspects project files for TypeScript usage (.ts/.tsx), linting configs, and missing type definitions. It recommends or creates configurations (Biore/biome.jsonc when appropriate), applies rules such as avoiding any, preferring type aliases, and enforcing alphabetical ordering for fields and parameters. It also suggests using dayjs for date logic and provides style guidance like centered comment dividers.
Should I always use Biome instead of ESLint and Prettier?
Use Biome by default for linting/formatting, but keep existing ESLint + Prettier if the project already relies on them to avoid disruptive changes.
When is it acceptable to use any?
Only as a temporary stopgap during migration; add a TODO and a precise type as soon as possible to avoid drift.