typescript
Skill0 starsChanged 8 months agoMITView on GitHub
Enforces strict TypeScript guardrails whenever writing, reviewing, refactoring, or generating .ts/.tsx/.mts/.cts code. Applies automatically to any TypeScript task — creating functions, components, types, configs, utility libraries, or converting JS to TS. Catches violations like enum (use as const), any (use unknown), default exports, barrel files, empty catch blocks, var, @ts-ignore, missing return types, and non-readonly properties. Also triggers for tsconfig changes, React/JSX with TypeScript props, API clients, CLI tools, and code reviews mentioning type safety. If the file extension or code context is TypeScript, use this skill — even if the user doesn't say 'TypeScript' explicitly.
66 other projects use a version of this.
Adopted by
Most recently taken up by
- bbartling/open-fddtheir own version, first seen Nov 9, 2026
- TheLunchTrae/claude-code-configstheir own version, first seen Nov 8, 2026
- testdino-hq/google-styleguides-skillstheir own version, first seen Nov 8, 2026
- lobehub/lobehubtheir own version, first seen Nov 5, 2026
- its-ash/skillstheir own version, first seen Nov 1, 2026
- sentimony/skillstheir own version, first seen Nov 1, 2026
Used with
Projects with it also use msw, react-hook-form and 9 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-itSkillmsw
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
SupabaseSkillreact-hook-form
Correct React Hook Form usage anywhere in the monorepo — data flow, subscriptions,
Also in 3 projects that use this
VercelSkillreact
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
leonaaardobSkilldrizzle
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-itSkilltailwind
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
mfang0126Skilldevelopment
Full-stack development workflow skill. Guides the complete cycle from understanding requirements to shipping code via PR with Preview validation.
Also in 3 projects that use this
- +1 more from thongdn-it
Other versions66 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 66
- lobehub/lobe-chat★ 84ksame name
- lobehub/lobehub★ 84ksame name
- recharts/recharts★ 28ksame name
- ccusage/ccusage★ 19ksame name
- ryoppippi/ccusage★ 19ksame name
- scalar/scalar★ 16ksame name
- prowler-cloud/prowler★ 15ksame name
- microsoft/fast★ 9.7ksame name
- epicenter-md/epicenter★ 4.8ksame name
- EpicenterHQ/epicenter★ 4.8ksame name
56 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 1 is distinctive, and 7 are very specific to this project.
0
Common
Most of the 52 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 14
DO NOT: use enum. Use as const objects + inferred type instead.
- Very specific: line 24
DO NOT: use any. Use unknown with type guards to narrow.
- Very specific: line 28
DO NOT: use type assertions (as X) unless no alternative exists.
- Very specific: line 65
"noUncheckedIndexedAccess": true: when the project supports it. - Very specific: line 67
DO NOT: use @ts-ignore. Use @ts-expect-error with an explanation comment if suppression is truly needed.
- Very specific: line 69
DO NOT: use non-null assertions (!) unless provably safe.
- Distinctive: line 85
Discriminated unions over type predicates: when modeling variants.
- Very specific: line 111
Avoid
throwin library code: when possible. Prefer a Result pattern or explicit error returns:
“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.
Files
TypeScript Guardrails
These are hard rules. Check every piece of TypeScript you write, review, or modify against this list.
Types
- DO NOT use
enum. Useas constobjects + inferred type instead.// wrong enum Status { Active, Inactive } // correct const STATUS = { Active: 'active', Inactive: 'inactive' } as const; type Status = typeof STATUS[keyof typeof STATUS]; - DO NOT use
any. Useunknownwith type guards to narrow. - Prefer
typeoverinterfaceunless you need declaration merging,extends, orimplements. - DO NOT use type assertions (
as X) unless no alternative exists. Narrow with control flow instead. If unavoidable, add a comment explaining why.- Only exception:
as Record<string, unknown>inside type guards, to access properties on a narrowed object. No otherascasts — validate withtypeof,in, or equality checks. When checking membership in a const object, widen the array type toReadonlyArray<string>instead of casting the value:function isUser(value: unknown): value is User { if (typeof value !== 'object' || value === null) return false; const obj = value as Record<string, unknown>; // only acceptable assertion const validRoles: ReadonlyArray<string> = Object.values(USER_ROLE); return typeof obj.name === 'string' && typeof obj.role === 'string' && validRoles.includes(obj.role); // ↑ widen to ReadonlyArray<string> — do NOT cast obj.role as SomeType }
- Only exception:
- Use
satisfiesfor type-safe object literals where you want inference + validation.const config = { port: 3000, host: 'localhost' } satisfies ServerConfig; - Explicit return types on all exported functions.
Imports / Exports
- No barrel files (
index.tsre-exports) except designated package entry points. - Explicit import paths —
import { bar } from './utils/bar', notfrom './utils'. - No default exports except config files (
vite.config.ts,eslint.config.ts, etc.). Use named exports everywhere else. - ESM only —
import/export. Neverrequire()ormodule.exports.
Strict Mode
"strict": truein tsconfig — always. Do not loosen individual strict flags."noUncheckedIndexedAccess": truewhen the project supports it.- DO NOT use
@ts-ignore. Use@ts-expect-errorwith an explanation comment if suppression is truly needed. - DO NOT use non-null assertions (
!) unless provably safe. If used, add a comment explaining the proof.
Patterns
constby default.letonly when reassignment is needed. Nevervar.- Exhaustive switches — always include a
defaultcase with anevercheck:default: { const _exhaustive: never = value; throw new Error(`Unhandled case: ${_exhaustive}`); } - Discriminated unions over type predicates when modeling variants.
- Readonly by default — use
readonlyproperties,ReadonlyArray<T>,Readonly<T>. - No classes unless required by a framework (e.g., Angular, NestJS). Prefer functions + closures.
Naming
| Thing | Convention | Example |
| Files | kebab-case | user-service.ts |
| Types / Interfaces | PascalCase | UserProfile |
| Functions / variables | camelCase | getUserById |
| Constants | UPPER_SNAKE_CASE | MAX_RETRY_COUNT |
| Schema interfaces | <Name>Schema | UserSchema |
Error Handling
- Never swallow errors — no empty
catchblocks. Log, rethrow, or handle explicitly. - Typed errors — use custom error classes or discriminated union result types.
- Avoid
throwin library code when possible. Prefer a Result pattern or explicit error returns:type Result<T, E = Error> = { ok: true; value: T } | { ok: false; error: E };
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
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.

