enforcing-typescript-standards — hacktoberfest enforcing-typescript-standards, community, hacktoberfest, ide skills, hacktoberfest2022, hacktoberfest2023, nodejs, postgres

v1.0.0

About this Skill

Essential for TypeScript Development Agents requiring strict code quality enforcement and standards compliance. Enforces the projects core TypeScript standards including explicit typing, import organization, class member ordering, and code safety rules. ALWAYS apply when creating, modifying, or reviewing any Ty

# Core Topics

bigalorm bigalorm
[9]
[2]
Updated: 2/27/2026

Killer-Skills Review

Decision support comes first. Repository text comes second.

Reference-Only Page Review Score: 7/11

This page remains useful for operators, but Killer-Skills treats it as reference material instead of a primary organic landing page.

Original recommendation layer Concrete use-case guidance Explicit limitations and caution Locale and body language aligned
Review Score
7/11
Quality Score
48
Canonical Locale
en
Detected Body Locale
en

Essential for TypeScript Development Agents requiring strict code quality enforcement and standards compliance. Enforces the projects core TypeScript standards including explicit typing, import organization, class member ordering, and code safety rules. ALWAYS apply when creating, modifying, or reviewing any Ty

Core Value

Enables automated enforcement of explicit typing, import organization, class member ordering, and code safety rules for Node.js and PostgreSQL TypeScript projects. Provides comprehensive static analysis capabilities for maintaining enterprise-grade code standards.

Ideal Agent Persona

Essential for TypeScript Development Agents requiring strict code quality enforcement and standards compliance.

Capabilities Granted for enforcing-typescript-standards

Automating code style enforcement in CI/CD pipelines
Refactoring existing code to meet TypeScript standards
Validating new TypeScript code against project-specific rules
Organizing imports and class member structure automatically

! Prerequisites & Limits

  • TypeScript-specific (.ts/.tsx files only)
  • Requires project-specific configuration for custom rules
  • Node.js environment dependency

Why this page is reference-only

  • - The underlying skill quality score is below the review floor.

Source Boundary

The section below is imported from the upstream repository and should be treated as secondary evidence. Use the Killer-Skills review above as the primary layer for fit, risk, and installation decisions.

Curated Collection Review

Reviewed In Curated Collections

This section shows how Killer-Skills has already collected, reviewed, and maintained this skill inside first-party curated paths. For operators and crawlers alike, this is a stronger signal than treating the upstream README as the primary story.

After The Review

Decide The Next Action Before You Keep Reading Repository Material

Killer-Skills should not stop at opening repository instructions. It should help you decide whether to install this skill, when to cross-check against trusted collections, and when to move into workflow rollout.

Labs Demo

Browser Sandbox Environment

⚡️ Ready to unleash?

Experience this Agent in a zero-setup browser environment powered by WebContainers. No installation required.

Boot Container Sandbox

FAQ & Installation Steps

These questions and steps mirror the structured data on this page for better search understanding.

? Frequently Asked Questions

What is enforcing-typescript-standards?

Essential for TypeScript Development Agents requiring strict code quality enforcement and standards compliance. Enforces the projects core TypeScript standards including explicit typing, import organization, class member ordering, and code safety rules. ALWAYS apply when creating, modifying, or reviewing any Ty

How do I install enforcing-typescript-standards?

Run the command: npx killer-skills add bigalorm/bigal/enforcing-typescript-standards. It works with Cursor, Windsurf, VS Code, Claude Code, and 19+ other IDEs.

What are the use cases for enforcing-typescript-standards?

Key use cases include: Automating code style enforcement in CI/CD pipelines, Refactoring existing code to meet TypeScript standards, Validating new TypeScript code against project-specific rules, Organizing imports and class member structure automatically.

Which IDEs are compatible with enforcing-typescript-standards?

This skill is compatible with Cursor, Windsurf, VS Code, Trae, Claude Code, OpenClaw, Aider, Codex, OpenCode, Goose, Cline, Roo Code, Kiro, Augment Code, Continue, GitHub Copilot, Sourcegraph Cody, and Amazon Q Developer. Use the Killer-Skills CLI for universal one-command installation.

Are there any limitations for enforcing-typescript-standards?

TypeScript-specific (.ts/.tsx files only). Requires project-specific configuration for custom rules. Node.js environment dependency.

How To Install

  1. 1. Open your terminal

    Open the terminal or command line in your project directory.

  2. 2. Run the install command

    Run: npx killer-skills add bigalorm/bigal/enforcing-typescript-standards. The CLI will automatically detect your IDE or AI agent and configure the skill.

  3. 3. Start using the skill

    The skill is now active. Your AI agent can use enforcing-typescript-standards immediately in the current project.

! Reference-Only Mode

This page remains useful for installation and reference, but Killer-Skills no longer treats it as a primary indexable landing page. Read the review above before relying on the upstream repository instructions.

Upstream Repository Material

The section below is imported from the upstream repository and should be treated as secondary evidence. Use the Killer-Skills review above as the primary layer for fit, risk, and installation decisions.

Upstream Source

enforcing-typescript-standards

Install enforcing-typescript-standards, an AI agent skill for AI agent workflows and automation. Review the use cases, limitations, and setup path before...

SKILL.md
Readonly
Upstream Repository Material
The section below is imported from the upstream repository and should be treated as secondary evidence. Use the Killer-Skills review above as the primary layer for fit, risk, and installation decisions.
Supporting Evidence

Enforcing TypeScript Standards

Enforces the project's core TypeScript standards including explicit typing, import organization, class member ordering, and code safety rules.

Triggers

Activate this skill when the user says or implies any of these:

  • "write", "create", "implement", "add", "build" (new TypeScript code)
  • "fix", "update", "change", "modify", "refactor" (existing TypeScript code)
  • "review", "check", "improve", "clean up" (code quality)
  • Any request involving .ts or .tsx files

Specific triggers:

  • Creating a new .ts or .tsx file
  • Modifying existing TypeScript code
  • Reviewing TypeScript code for compliance

Core Standards

Type Safety

  • Explicit return types: Prefer explicit return types when practical; omit when inference is obvious and adds no clarity
  • Explicit member accessibility: Class members require public, private, or protected
  • Type-only imports: Use import type for types: import type { Foo } from './foo.js'
  • Sorted type constituents: Union/intersection types must be alphabetically sorted
  • Only throw Error objects: Never throw strings or other primitives
  • Avoid any and type assertions: Prefer proper typing over any or as casts; use them only when truly necessary
  • Type JSON fields explicitly: Use Record<string, unknown> or specific interfaces for JSON data, never any
  • Use Number() for conversion: Prefer Number(value) over parseInt(value, 10) or parseFloat(value)
  • Reuse existing types: Before defining a new interface, search for existing types that can be reused directly, extended, or derived using Pick, Omit, Partial, or other utility types

Alternatives to Type Assertions

Before using as, try these approaches in order:

  1. Proper typing at the source
  2. Type guards (typeof, instanceof)
  3. Type narrowing through control flow
  4. Custom type predicate functions
  5. Discriminated unions
ts
1// Bad 2const user = data as User; 3 4// Good 5function isUser(data: unknown): data is User { 6 return typeof data === 'object' && data !== null && 'id' in data; 7} 8if (isUser(data)) { 9 // data is now typed as User 10}

Import Organization

  • Import order: built-in → external → internal → parent → sibling → index (alphabetized within groups)
  • No duplicate imports: Consolidate imports from the same module
  • Newline after imports: Empty line required after import block

Class Member Ordering

  1. Signatures (call/construct)
  2. Fields: private → public → protected
  3. Constructors: public → protected → private
  4. Methods: public → protected → private

Code Style

  • Simplicity over cleverness: Straightforward, readable code is better than clever one-liners
  • Early returns: Use guard clauses to reduce nesting; return early for edge cases
  • Nullish coalescing: Prefer ?? over || for defaults (avoids false positives on 0 or '')
  • Optional chaining: Use ?. for safe property access
  • Match existing patterns: Follow conventions already established in the codebase
  • Meaningful identifiers: Names must be descriptive (exceptions: _, i, j, k, e, x, y)
  • Function declarations: Use function foo() not const foo = function()
  • Prefer const: Use const unless reassignment is needed
  • No var: Always use const or let
  • Object shorthand: Use { foo } not { foo: foo }
  • Template literals: Use `Hello ${name}` not 'Hello ' + name
  • Strict equality: Use === except for null comparisons
  • One class per file: Maximum one class definition per file
  • Avoid reduce: Prefer for...of loops or other array methods for clarity
  • Functions over classes: Prefer exported functions over classes with static methods (unless state is needed)
  • No nested functions: Define helper functions at module level, not inside other functions
  • Immutability: Create new objects/arrays instead of mutating existing ones

Naming Conventions

  • Enum members: Use PascalCase (e.g., MyValue)
  • No trailing underscores: Identifiers cannot end with _

Comments

  • No redundant comments: Never comment what the code already expresses clearly
  • No duplicate comments: Don't repeat information from function names, types, or nearby comments
  • Meaningful only: Only add comments to explain why, not what — the code shows what it does

Boolean Expressions

  • Prefer truthiness checks: Use implicit truthy/falsy checks over explicit comparisons
  • Exception: Use explicit checks when distinguishing 0/'' (valid values) from null/undefined is semantically important

Testing

  • Minimize mocking: Avoid mocking everything; use real implementations and data generators when available
  • Test real behavior: Testing mocks provides little value — test actual code paths
  • Don't be lazy: Write thorough tests that cover edge cases, not just happy paths

Error Handling

  • Specific error types: Prefer specific error types over generic Error when meaningful
  • Avoid silent failures: Don't swallow errors with empty catch blocks
  • Handle rejections: Always handle promise rejections
  • Let errors propagate: Don't catch errors just to re-throw or log — let them bubble up to error handlers

Negative Knowledge

Avoid these antipatterns:

  • console.log() statements in production code
  • eval() or Function() constructor
  • Nested ternary operators
  • await inside loops when Promise.all would be simpler (sequential awaits are fine when order matters or parallelism adds complexity)
  • Empty interfaces
  • Variable shadowing
  • Functions defined inside loops
  • @ts-ignore without explanation (use @ts-expect-error with 10+ char description)
  • Comments that restate the code: // increment counter above counter++
  • Comments that duplicate type information: // returns a string when return type is : string
  • Commented-out code (delete it; use version control)
  • Verbose boolean comparisons: arr.length > 0, str !== '', obj !== null && obj !== undefined
  • Disabling linter rules via comments (fix the code instead)
  • Overuse of any type or as type assertions
  • Over-mocking in tests instead of using real implementations or data generators
  • Empty catch blocks that silently swallow errors
  • Using || for defaults when ?? is more appropriate
  • Deep nesting when early returns would simplify
  • Catching errors just to re-throw or log them
  • Nested function definitions inside other functions
  • Mutating objects/arrays instead of creating new ones
  • TOCTOU: Checking file/resource existence before operating (try and handle errors instead)
  • Classes with only static methods (use plain functions instead)
  • Duplicating existing interfaces instead of reusing or deriving with Pick/Omit/Partial

Verification Workflow

  1. Analyze: Compare the code change against these TypeScript standards
  2. Generate/Refactor: Write or modify code to comply with all rules above
  3. Simplify: Review for opportunities to simplify — prefer clear, straightforward code over clever solutions
  4. Review naming: Verify variable and function names still make sense in context after changes
  5. Build: Verify types compile without errors (e.g., npm run build or npx tsc --noEmit)
  6. Lint: Run npm run lint to confirm compliance before completing the task

Examples

Comments Examples

ts
1// Standard 2// Retry with exponential backoff to handle transient network failures 3async function fetchWithRetry(url: string, attempts = 3): Promise<Response> { 4 for (let i = 0; i < attempts; i++) { 5 try { 6 return await fetch(url); 7 } catch { 8 await sleep(2 ** i * 100); 9 } 10 } 11 throw new Error(`Failed after ${attempts} attempts`); 12} 13 14// Non-Standard 15/** 16 * Fetches data from a URL with retry logic 17 * @param url - The URL to fetch from 18 * @param attempts - Number of attempts (default 3) 19 * @returns A Promise that resolves to a Response 20 */ 21async function fetchWithRetry(url: string, attempts = 3): Promise<Response> { 22 // Loop through attempts 23 for (let i = 0; i < attempts; i++) { 24 try { 25 // Try to fetch the URL 26 return await fetch(url); 27 } catch { 28 // Wait before retrying 29 await sleep(2 ** i * 100); 30 } 31 } 32 // Throw error if all attempts fail 33 throw new Error(`Failed after ${attempts} attempts`); 34}

Boolean Expressions Examples

ts
1// Standard 2if (myArray.length) { 3} 4if (myString) { 5} 6if (myObject) { 7} 8if (!value) { 9} 10 11// Non-Standard 12if (myArray.length !== 0) { 13} 14if (myArray.length > 0) { 15} 16if (myString !== '') { 17} 18if (myObject !== null && myObject !== undefined) { 19} 20if (value === null || value === undefined) { 21}

Early Return Examples

ts
1// Standard 2function processUser(user: User | null): Result { 3 if (!user) { 4 return { error: 'No user provided' }; 5 } 6 if (!user.isActive) { 7 return { error: 'User is inactive' }; 8 } 9 return { data: transform(user) }; 10} 11 12// Non-Standard 13function processUser(user: User | null): Result { 14 if (user) { 15 if (user.isActive) { 16 return { data: transform(user) }; 17 } else { 18 return { error: 'User is inactive' }; 19 } 20 } else { 21 return { error: 'No user provided' }; 22 } 23}

Functions Over Classes Examples

ts
1// Standard 2export function calculateTotal(items: Item[]): number { 3 return items.reduce((sum, item) => sum + item.price, 0); 4} 5 6export function formatCurrency(amount: number): string { 7 return `$${amount.toFixed(2)}`; 8} 9 10// Non-Standard 11export class Calculator { 12 static calculateTotal(items: Item[]): number { 13 return items.reduce((sum, item) => sum + item.price, 0); 14 } 15 16 static formatCurrency(amount: number): string { 17 return `$${amount.toFixed(2)}`; 18 } 19}

No Nested Functions Examples

ts
1// Standard 2function transformItem(item: Item): TransformedItem { 3 return { id: item.id, name: item.name.toUpperCase() }; 4} 5 6async function processItems(items: Item[]): Promise<TransformedItem[]> { 7 return items.map(transformItem); 8} 9 10// Non-Standard 11async function processItems(items: Item[]): Promise<TransformedItem[]> { 12 function transformItem(item: Item): TransformedItem { 13 return { id: item.id, name: item.name.toUpperCase() }; 14 } 15 return items.map(transformItem); 16}

Immutability Examples

ts
1// Standard 2function addItem(items: Item[], newItem: Item): Item[] { 3 return [...items, newItem]; 4} 5 6function removeItem(items: Item[], id: string): Item[] { 7 return items.filter((item) => item.id !== id); 8} 9 10function updateItem(items: Item[], id: string, updates: Partial<Item>): Item[] { 11 return items.map((item) => (item.id === id ? { ...item, ...updates } : item)); 12} 13 14// Non-Standard 15function addItem(items: Item[], newItem: Item): Item[] { 16 items.push(newItem); 17 return items; 18} 19 20function removeItem(items: Item[], id: string): Item[] { 21 const index = items.findIndex((item) => item.id === id); 22 items.splice(index, 1); 23 return items; 24}

Error Propagation Examples

ts
1// Standard 2async function getUser(id: string): Promise<User> { 3 return userService.findById(id); 4} 5 6// Non-Standard 7async function getUser(id: string): Promise<User> { 8 try { 9 return await userService.findById(id); 10 } catch (error) { 11 console.error(error); 12 throw error; 13 } 14}

TOCTOU Examples

ts
1// Standard 2async function readConfig(path: string): Promise<Config> { 3 try { 4 const content = await readFile(path, 'utf-8'); 5 return JSON.parse(content); 6 } catch (error) { 7 if (isNotFoundError(error)) { 8 return defaultConfig; 9 } 10 throw error; 11 } 12} 13 14// Non-Standard 15async function readConfig(path: string): Promise<Config> { 16 if (await fileExists(path)) { 17 const content = await readFile(path, 'utf-8'); 18 return JSON.parse(content); 19 } 20 return defaultConfig; 21}

Type Reuse Examples

ts
1// Given an existing type 2interface User { 3 id: string; 4 email: string; 5 name: string; 6 passwordHash: string; 7 createdAt: Date; 8 updatedAt: Date; 9} 10 11// Standard - derive from existing type 12type PublicUser = Omit<User, 'passwordHash'>; 13type UserSummary = Pick<User, 'id' | 'name'>; 14type UserUpdate = Partial<Pick<User, 'email' | 'name'>>; 15 16// Non-Standard - duplicating fields that already exist 17interface PublicUser { 18 id: string; 19 email: string; 20 name: string; 21 createdAt: Date; 22 updatedAt: Date; 23} 24 25interface UserSummary { 26 id: string; 27 name: string; 28} 29 30interface UserUpdate { 31 email?: string; 32 name?: string; 33}

Related Skills

Looking for an alternative to enforcing-typescript-standards or another community skill for your workflow? Explore these related open-source skills.

View All

openclaw-release-maintainer

Logo of openclaw
openclaw

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞

333.8k
0
AI

widget-generator

Logo of f
f

Generate customizable widget plugins for the prompts.chat feed system

149.6k
0
AI

flags

Logo of vercel
vercel

The React Framework

138.4k
0
Browser

pr-review

Logo of pytorch
pytorch

Tensors and Dynamic neural networks in Python with strong GPU acceleration

98.6k
0
Developer