Skip to content
cccskills
FreePublished on GitHub

kwaa-typescript-best-practices

kwaa's TypeScript best practices. Use when reading or editing .ts or .tsx files.

The English summary is being prepared. Showing the original description.

moeru-ai/xsai664 stars(GitHub 664 + cccskills 0)

Run score Not tested

See how to install

Files included (3)

  • SKILL.md5.4 KB
  • agents/openai.yaml267 B
  • references/patterns.md6.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

TypeScript best practices

RuleSummary
Modern platformsPrefer ESM and standard JavaScript and Web APIs. Use the project's runtime targets. Avoid compatibility code for unsupported older runtimes.
Strict typesDo not add explicit or implicit any. Fix type errors without weakening compiler or lint rules. Use unknown for untrusted data.
Imports and exportsSeparate type-only imports from value imports. Mark type-only exports with export type. Prefer named exports.
Interfaces and aliasesPrefer interface for object contracts and extension points. Use type for unions, functions, and derived types. Prefer literal unions over enums. Avoid enum and namespace in runtime code.
Discriminated unionsKeep each state's required fields together. Prefer a type discriminant for new event types. Avoid boolean flags combined with unrelated optional fields.
Constructive modelingChoose data structures that exclude invalid combinations. Use tuples for pairs and discriminated unions for variants. Express constraints in the structure before adding runtime checks.
Derived typesDerive types from existing schemas and generated types. Use indexed access, keyof, typeof, and utility types. Use generics to express relationships between types.
Simplest sufficient typeRepeated !, assertions, or "should never happen" errors can reveal a missing type constraint. Strengthen the input type or allow absence in the return type.
ExhaustivenessUse never for impossible states. Add an exhaustive check when the return type and lint rules do not already catch missing cases.
satisfies and assertionsPrefer annotations or satisfies to check values against types. Use as const for literal inference. Allow assertions only for a proven condition or a type relationship TypeScript cannot express. Assertions do not validate external data.
Boundary validationParse external data once at the boundary. Trust the resulting types inside the program. Reuse validators and derive types from existing schemas. Do not define the same shape in a schema, an interface, and a guard.
NarrowingPrefer automatic narrowing with discriminants, in, typeof, or instanceof. Use reusable predicates next and assertions last. Keep single-use checks inline. Guards must check every condition their return type claims.
Arrow functionsPrefer const arrows and clear expression bodies. Use early returns and guard clauses. If the formatter permits, omit braces around single statements. Use function for generators or dynamic this.
Factories over classesPrefer functions, composition, and private closure state. Use classes when error identity, platform inheritance, framework integration, or prototype behavior makes the design clearer.
OwnershipKeep transformations pure. Local changes to data a function owns are fine. Accept readonly inputs and copy caller data before taking mutable ownership. Neither readonly nor object spread isolates nested objects.
Collection transformsUse map, filter, flatMap, and object entry methods for simple transformations. Use for...of or while for ordered work, early exits, or clearer accumulation. Avoid for...in.
Object argumentsPrefer options objects for optional behavior, ambiguous arguments, or APIs that need room to grow. A primary argument followed by options is fine.
Absence and defaultsUse ?? for defaults. Use == null when both null and undefined mean absence. Preserve valid false, 0, and empty strings. Define whether an undefined override preserves the default.
Web APIsPrefer Fetch, URL, Web Streams, and AbortSignal. Keep runtime-specific operations in adapters. Inject operations such as fetch when consumers or tests need to replace them.
CancellationForward abort signals and preserve their reasons. After cancellation, stop further side effects. Clean up resources on every exit path.
ConcurrencyUse Promise.all when independent operations must all succeed. Use Promise.allSettled when partial results are useful. Await ordered effects in a loop. If one operation rejects, Promise.all does not cancel the others.
Promise ownershipAvoid unnecessary async. Keep return await when a catch or finally block needs to observe completion. Handle rejected background promises. void alone does not handle rejection.
Error boundariesCatch errors only to recover, translate, add context, report, or clean up. Narrow caught unknown only as needed. Preserve causes. Rethrow unmatched errors unless the boundary converts all failures. Do not return a success value to hide failure.
Small modulesKeep helpers private and define public exports explicitly. Review files at 300 lines. Split at 600 unless keeping related code together is clearer. Exclude generated code and resources.
ReadabilityExtract helpers that name useful behavior. Avoid redundant wrappers. Comments explain why. Use brief TSDoc for public contracts without repeating types.
Real testsUse real platform objects, repeatable test data, and test doubles at external boundaries. Test affected contracts, input mutation, failures, and cancellation. Do not claim that a mocked integration was verified.

Examples: references/patterns.md.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.

The English summary is being prepared. Showing the original description.

moeru-ai/xsai664Updated Oct 26, 2026

Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.

The English summary is being prepared. Showing the original description.

moeru-ai/xsai664Updated Oct 26, 2026

arena

Free

Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.

The English summary is being prepared. Showing the original description.

moeru-ai/xsai664Updated Oct 26, 2026

Ask which skill or flow fits your situation. A router over the skills in this repo.

The English summary is being prepared. Showing the original description.

moeru-ai/xsai664Updated Oct 26, 2026

Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', or reviewing a small diff you don't trust.

The English summary is being prepared. Showing the original description.

moeru-ai/xsai664Updated Oct 26, 2026

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

The English summary is being prepared. Showing the original description.

moeru-ai/xsai664Updated Oct 26, 2026

See all skills by moeru-ai

Report a problem with this skill