agentleFS
Sign inStart free
basidiocarpbasidiocarp/pileus/.claude/skills/typescript/SKILL.md

typescript

Skill0 starsChanged 6 months agoMITView on GitHub

Applies TypeScript code style, type-safety patterns, and project conventions.

66 other projects use a version of this, 4 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use msw, rust and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • thongdn-itSkill

    msw

    MSW (Mock Service Worker) best practices for API mocking in tests (formerly test-msw). This skill should be used when setting up MSW, writing request handlers, or mocking HTTP APIs. This skill does NOT cover general testing patterns (use test-vitest or test-tdd skills) or test methodology.

    Also in 3 projects that use this

  • MicrosoftSkill

    rust

    Use this guide when working on Rust changes in the FAST monorepo.

    Also in 9 projects that use this

  • SupabaseSkill

    react-hook-form

    Correct React Hook Form usage anywhere in the monorepo — data flow, subscriptions,

    Also in 3 projects that use this

  • VercelSkill

    react

    React renderer for json-render that turns JSON specs into React components. Use when working with @json-render/react, building React UIs from JSON, creating component catalogs, or rendering AI-generated specs.

    Also in 10 projects that use this

  • leonaaardobSkill

    drizzle

    Complete Drizzle ORM documentation in markdown format. Use when working with Drizzle ORM - covers schema definition, queries, migrations, database connections (PostgreSQL, MySQL, SQLite), integrations (Neon, Supabase, PlanetScale, Cloudflare D1, Turso), column types, relations, transactions, and framework usage (Next.js, SvelteKit, Astro).

    Also in 3 projects that use this

  • thongdn-itSkill

    tailwind

    Tailwind CSS v4 performance optimization and best practices guidelines (formerly tailwindcss-v4-style). This skill should be used when writing, reviewing, or refactoring Tailwind CSS v4 code to ensure optimal build performance, minimal CSS output, and correct usage of v4 features. Triggers on tasks involving Tailwind configuration, @theme directive, utility classes, responsive design, dark mode, container queries, or CSS generation optimization.

    Also in 5 projects that use this

  • +1 more from thongdn-it

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. 0 are common, 6 are distinctive, and 12 are very specific to this project.

  • 0

    Common

    Most of the 52 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 12

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Avoid explicit type annotations when TypeScript can infer

    line 10
  2. Very specific:

    Avoid implicitly any; explicitly type when necessary

    line 11
  3. Very specific:

    Use accurate types: prefer Record<PropertyKey, unknown> over object or any

    line 12
  4. Very specific:

    Prefer interface for object shapes (e.g., React props).

    line 13
  5. Very specific:

    Prefer as const satisfies XyzInterface over plain as const

    line 14
  6. Very specific:

    Prefer @ts-expect-error over @ts-ignore over as any

    line 15
  7. Distinctive:

    Avoid meaningless null/undefined parameters.

    line 16
  8. Distinctive:

    Use type guards for runtime narrowing instead of type assertions:

    line 17
  9. Very specific:

    Prefer async/await over callbacks or .then() chains

    line 27
  10. Very specific:

    Prefer async APIs over sync ones (avoid *Sync)

    line 28
  11. Very specific:

    Use promise-based variants: import { readFile } from 'fs/promises'

    line 29
  12. Very specific:

    Use Promise.all, Promise.race for concurrent operations where safe

    line 30
  13. Very specific:

    Use ms package for readable durations: ms('2 days') instead of 172800000

    line 31
  14. Very specific:

    Instead of const name = user.name → const { name } = user

    line 36
  15. Distinctive:

    Use consistent, descriptive naming.

    line 38
  16. Distinctive:

    Prefer established libraries over hand-rolling:

    line 45
  17. Distinctive:

    Never log user private information (API keys, etc.)

    line 62
  18. Very specific:

    Use console.error in catch blocks

    line 63

“Common” is measured: kept by at least 6 in 10 of the 52 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

TypeScript Code Style Guide

Types and Type Safety

  • Avoid explicit type annotations when TypeScript can infer
  • Avoid implicitly any; explicitly type when necessary
  • Use accurate types: prefer Record<PropertyKey, unknown> over object or any
  • Prefer interface for object shapes (e.g., React props); use type for unions/intersections
  • Prefer as const satisfies XyzInterface over plain as const
  • Prefer @ts-expect-error over @ts-ignore over as any
  • Avoid meaningless null/undefined parameters; design strict function contracts
  • Use type guards for runtime narrowing instead of type assertions:
function isUser(value: unknown): value is User {
  return typeof value === 'object' && value !== null && 'id' in value;
}

Async Patterns

  • Prefer async/await over callbacks or .then() chains
  • Prefer async APIs over sync ones (avoid *Sync)
  • Use promise-based variants: import { readFile } from 'fs/promises'
  • Use Promise.all, Promise.race for concurrent operations where safe
  • Use ms package for readable durations: ms('2 days') instead of 172800000

Code Structure

  • Prefer object destructuring:
    • Instead of const name = user.name → const { name } = user
    • Instead of const result = await getUser(userId) → const { data: user } = await getUser(userId)
  • Use consistent, descriptive naming; avoid obscure abbreviations
  • Replace magic numbers/strings with well-named constants
  • Defer formatting to tooling
  • Export all types by default

Library-First Approach

Prefer established libraries over hand-rolling:

DomainLibraries
Date/timedate-fns, dayjs
Form validationzod, yup
HTTP requestsbuilt-in fetch, ky
State managementZustand
Durationsms

Performance

  • Reuse existing utils in packages/utils or installed npm packages
  • Assign Date.now() to a constant once and reuse for consistency

Logging

  • Never log user private information (API keys, etc.)
  • Use console.error in catch blocks

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free