agentsclimarketplace

Google ts styleguide

Skill ouka-lab/Skills/skills/google-ts-styleguide

Google TypeScript Style Guide reference for writing, reviewing, and refactoring TypeScript code. Use this skill whenever you are writing TypeScript code, reviewing TypeScript code, refactoring TypeScript, configuring ESLint or linter rules for TypeScript, or when the user asks about TypeScript coding conventions, naming conventions, type system best practices, or import/export patterns. Also trigger when the user mentions 'Google style', 'gts', 'TypeScript style guide', or asks 'how should I name this', 'should I use interface or type', 'how to handle null/undefined' in a TypeScript context. TypeScriptを書く・レビューする・リファクタリングする、ESLintの設定をする、「命名規則」「型の使い方」「import/exportのルール」「interfaceとtypeどっち」「anyを使っていい?」「nullチェックどうする」「Google式」「コーディング規約」「スタイルガイド」などの質問にも対応します。TypeScriptのコードに関する質問や作業であれば積極的にこのスキルを使ってください。From its SKILL.md

Install
npx -y skills add ouka-lab/Skills --skill google-ts-styleguide

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.8 KB, as published. Nobody here has run it

Google TypeScript Style Guide Reference

Google TypeScript Style Guide に基づくコーディングリファレンスです。TypeScriptの実装・コードレビュー・リファクタリング・ESLint設定時に、Googleのコーディング規約に準拠するために使います。

How to use this reference

This guide is organized into topic-specific reference files. Read the relevant file based on the current task:

TopicFileWhen to read
File structure & imports/exportsreferences/source-file-structure.mdOrganizing files, import/export patterns, module structure
Language featuresreferences/language-features.mdVariables, arrays, objects, classes, functions, control flow, decorators
Naming conventionsreferences/naming.mdNaming variables, classes, constants, type parameters, files
Type systemreferences/type-system.mdType inference, null/undefined, any/unknown, interfaces vs types, generics
Comments & toolchainreferences/comments-and-toolchain.mdJSDoc, comments, @ts-ignore rules, conformance

Quick Reference: Most Common Rules

These are the rules that come up most frequently. For details, read the corresponding reference file.

Naming (see references/naming.md)

  • Classes/Interfaces/Types/Enums: UpperCamelCase
  • Variables/functions/methods/properties: lowerCamelCase
  • Global constants & enum values: CONSTANT_CASE
  • Treat acronyms as words: loadHttpUrl, not loadHTTPURL
  • No IMyInterface prefix for interfaces
  • No trailing/leading underscores for private members

Imports & Exports (see references/source-file-structure.md)

  • Use ES6 module syntax only (import/export), never require
  • Use named exports exclusively; avoid default exports
  • Use import type for type-only imports
  • Do not use namespace; use modules
  • No mutable exports (export let is prohibited)

Variables & Types (see references/language-features.md, references/type-system.md)

  • Use const by default, let when reassignment needed; never var
  • Use unknown over any; avoid any wherever possible
  • Prefer interface over type literal aliases
  • Simple arrays: T[]; complex element types: Array<{...}>
  • Prefer optional (field?) over | undefined

Functions & Classes (see references/language-features.md)

  • Prefer function declarations for named functions
  • Use arrow functions for callbacks, not function expressions
  • Mark never-reassigned properties as readonly
  • Use parameter properties in constructors
  • No #private fields; use TypeScript's private keyword

Control Flow (see references/language-features.md)

  • Always use ===/!== (exception: == null for null/undefined check)
  • Always use braces for control statements
  • Only throw Error instances
  • All switch must have default case
  • Explicitly end statements with semicolons (no ASI reliance)

ESLint/Linter Configuration Guide

When configuring ESLint or other linters for Google TypeScript style compliance, enforce these core rules:

Must enable:

  • @typescript-eslint/no-explicit-any - Discourage any usage
  • @typescript-eslint/explicit-module-boundary-types - Encourage explicit return types at module boundaries
  • @typescript-eslint/no-non-null-assertion - Discourage ! assertions
  • eqeqeq with smart option - Enforce ===/!== with == null exception
  • no-var - Forbid var
  • prefer-const - Prefer const over let when no reassignment
  • curly - Require braces for all control statements
  • @typescript-eslint/no-namespace - Forbid namespace
  • no-eval - Forbid eval()
  • no-debugger - Forbid debugger
  • @typescript-eslint/no-wrapper-object-types - Forbid String, Boolean, Number wrapper types
  • @typescript-eslint/consistent-type-imports - Enforce import type for type-only imports
  • no-restricted-syntax for WithStatement - Forbid with

Naming convention rules (@typescript-eslint/naming-convention):

  • UpperCamelCase for classes, interfaces, type aliases, enums, decorators
  • lowerCamelCase for variables, functions, methods, parameters, properties
  • CONSTANT_CASE for global constants and enum members
  • No leading/trailing underscores

Import/export rules:

  • no-restricted-exports or plugin rules to forbid default exports
  • @typescript-eslint/no-require-imports - Forbid require()

Additional recommended:

  • @typescript-eslint/prefer-for-of - Prefer for...of
  • @typescript-eslint/no-unnecessary-type-assertion - Remove unnecessary assertions
  • @typescript-eslint/prefer-optional-chain - Prefer optional chaining
  • @typescript-eslint/prefer-readonly - Prefer readonly for never-reassigned members

Keep looking

Skills are one crate of 628,971. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.