home / skills / next-friday / nextfriday-skills / nextfriday-types

nextfriday-types skill

This skill enforces TypeScript patterns from Next Friday to standardize props, params, and return types for safer, clearer React code.

npx playbooks add skill next-friday/nextfriday-skills --skill nextfriday-types

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

2.1 KB

---
name: nextfriday-types
description: Next Friday TypeScript patterns for props, interfaces, and return types. Use when defining types or writing function signatures.
user-invocable: false
---

# Next Friday Types

Rules for TypeScript type definitions and annotations.

## React Props

### Props Suffix

Interfaces in component files must end with `Props`.

```tsx
// Bad: Card.tsx
interface Card {}

// Good: Card.tsx
interface CardProps {}
```

### Readonly Props

Component props must be wrapped with `Readonly<>`.

```tsx
// Bad:
const Card = (props: CardProps) => ...

// Good:
const Card = (props: Readonly<CardProps>) => ...
```

### No Inline Types

Use interface declarations, not inline types.

```tsx
// Bad:
const Card = (props: { title: string; onClick: () => void }) => ...

// Good:
interface CardProps {
  title: string;
  onClick: () => void;
}

const Card = (props: Readonly<CardProps>) => ...
```

## Function Parameters

### Named Param Types

Extract inline object types to named interfaces.

```typescript
// Bad:
function processData({ id, name }: { id: string; name: string }) {}

// Good:
interface ProcessDataParams {
  id: string;
  name: string;
}

function processData(params: ProcessDataParams) {}
```

### Destructuring Params

Use object destructuring for multiple parameters.

```typescript
// Bad:
function createItem(id: string, name: string, price: number, category: string) {}

// Good:
interface CreateItemParams {
  id: string;
  name: string;
  price: number;
  category: string;
}

function createItem(params: CreateItemParams) {}
```

## Return Types

### Explicit Return Types

Always specify return types on functions.

```typescript
// Bad:
function formatValue(value: number) {
  return value.toFixed(2);
}

// Good:
function formatValue(value: number): string {
  return value.toFixed(2);
}
```

## Quick Reference

| Rule | Pattern |
| ---- | ------- |
| Props suffix | `CardProps`, not `Card` |
| Readonly props | `props: Readonly<Props>` |
| No inline types | Use interfaces |
| Named param types | Extract to interfaces |
| Destructuring | `(params: Params)` not `(a, b, c)` |
| Explicit return | `: string`, `: Promise<Data>` |

Overview

This skill documents Next Friday TypeScript patterns for props, interfaces, and return types. It explains consistent naming, immutability, parameter handling, and explicit return typing to keep code predictable and type-safe. Use it as a quick reference when defining component props and function signatures.

How this skill works

The skill inspects common TypeScript patterns and prescribes small, opinionated rules: suffix component interfaces with Props, wrap props in Readonly, avoid inline object types, extract named parameter interfaces, prefer single object parameters, and always annotate function return types. Apply these rules as you write or review TypeScript code to standardize shape definitions and function signatures.

When to use it

Defining React component props in .tsx files
Writing or refactoring function parameter lists
Converting inline types to reusable interfaces
Enforcing immutability for component props
Adding or validating explicit function return annotations

Best practices

Name component interfaces with the Props suffix (e.g., CardProps).
Wrap component props with Readonly<> to signal immutability.
Avoid inline object types in signatures; declare interfaces instead.
Extract complex parameter objects into named interfaces and use a single params argument.
Always declare explicit return types, including Promise generics for async functions.

Example use cases

Refactoring a component from inline prop types to a CardProps interface wrapped in Readonly.
Replacing a long positional parameter list with a single CreateItemParams interface and destructuring.
Adding missing return annotations to utility functions to clarify public API types.
Standardizing a codebase so all component props follow a uniform naming and immutability pattern.
Defining typed parameters for service functions to improve IDE autocompletion and reduce bugs.

FAQ

Why suffix interfaces with Props?

Suffixing with Props makes component-related types explicit and prevents naming collisions with domain models.

Is Readonly<> required for props?

Yes—wrapping props in Readonly communicates immutability and prevents accidental mutations inside components.

When should I avoid extracting an interface?

For trivial one-off types used only once and unlikely to be reused, extraction can be optional, but prefer interfaces for clarity.