nextfriday-types_skill

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

0

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

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

  • SKILL.md2.1 KB

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

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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational