Interactive English conversation practice partner for Japanese learners. Use this skill whenever the user wants to practice speaking English, role-play a real-life situation (hotel check-in, restaurant, airport, business meeting, technical discussion, code review, job interview, daily small talk, etc.), discuss a technical article in English, or asks how to phrase something naturally in English. Trigger on requests like 'let's practice English', 'I want to talk in English', 'role play', 'pretend you are a ___', 'discuss this article in English', 'how do I say X in English'. 英会話練習・ロールプレイ・英語表現の質問のためのスキル。「英会話したい」「英語で話そう」「ロールプレイ」「ホテルのチェックイン練習」「この記事について英語で話したい」「xxって英語でどう言う?」などのリクエストで起動する。ユーザーは音声入力で会話する想定。会話前に想定問答・頻出表現・単語を提示し、会話を開始、最後に添削まで行う。
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のコードに関する質問や作業であれば積極的にこのスキルを使ってください。
含まれるファイル(6)
- SKILL.md5.8 KB
- references/comments-and-toolchain.md4.1 KB
- references/language-features.md9.2 KB
- references/naming.md4.1 KB
- references/source-file-structure.md5.5 KB
- references/type-system.md7.3 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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:
| Topic | File | When to read |
|---|---|---|
| File structure & imports/exports | references/source-file-structure.md | Organizing files, import/export patterns, module structure |
| Language features | references/language-features.md | Variables, arrays, objects, classes, functions, control flow, decorators |
| Naming conventions | references/naming.md | Naming variables, classes, constants, type parameters, files |
| Type system | references/type-system.md | Type inference, null/undefined, any/unknown, interfaces vs types, generics |
| Comments & toolchain | references/comments-and-toolchain.md | JSDoc, 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, notloadHTTPURL - No
IMyInterfaceprefix for interfaces - No trailing/leading underscores for private members
Imports & Exports (see references/source-file-structure.md)
- Use ES6 module syntax only (
import/export), neverrequire - Use named exports exclusively; avoid default exports
- Use
import typefor type-only imports - Do not use
namespace; use modules - No mutable exports (
export letis prohibited)
Variables & Types (see references/language-features.md, references/type-system.md)
- Use
constby default,letwhen reassignment needed; nevervar - Use
unknownoverany; avoidanywherever possible - Prefer
interfaceover 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
#privatefields; use TypeScript'sprivatekeyword
Control Flow (see references/language-features.md)
- Always use
===/!==(exception:== nullfor null/undefined check) - Always use braces for control statements
- Only throw
Errorinstances - All
switchmust havedefaultcase - 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- Discourageanyusage@typescript-eslint/explicit-module-boundary-types- Encourage explicit return types at module boundaries@typescript-eslint/no-non-null-assertion- Discourage!assertionseqeqeqwithsmartoption - Enforce===/!==with== nullexceptionno-var- Forbidvarprefer-const- Preferconstoverletwhen no reassignmentcurly- Require braces for all control statements@typescript-eslint/no-namespace- Forbidnamespaceno-eval- Forbideval()no-debugger- Forbiddebugger@typescript-eslint/no-wrapper-object-types- ForbidString,Boolean,Numberwrapper types@typescript-eslint/consistent-type-imports- Enforceimport typefor type-only importsno-restricted-syntaxforWithStatement- Forbidwith
Naming convention rules (@typescript-eslint/naming-convention):
UpperCamelCasefor classes, interfaces, type aliases, enums, decoratorslowerCamelCasefor variables, functions, methods, parameters, propertiesCONSTANT_CASEfor global constants and enum members- No leading/trailing underscores
Import/export rules:
no-restricted-exportsor plugin rules to forbid default exports@typescript-eslint/no-require-imports- Forbidrequire()
Additional recommended:
@typescript-eslint/prefer-for-of- Preferfor...of@typescript-eslint/no-unnecessary-type-assertion- Remove unnecessary assertions@typescript-eslint/prefer-optional-chain- Prefer optional chaining@typescript-eslint/prefer-readonly- Preferreadonlyfor never-reassigned members
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
Generate Zod v4 TypeScript schemas from OpenAPI (openapi.yaml / openapi.json) definitions. This skill exists because npm packages like openapi-zod-client do not support Zod v4 — Claude reads the YAML/JSON directly and writes the conversion. Use this skill whenever the user wants to convert OpenAPI/Swagger definitions to Zod schemas, generate TypeScript types from API specs, or create validation schemas from openapi.yaml. Trigger on keywords: 'openapi', 'swagger', 'zod', 'API schema', 'yaml to types', 'schema generation', 'validation generation'. OpenAPI定義からZodスキーマを生成するスキル。openapi.yamlから型を作りたい、APIスキーマをTypeScriptの型にしたい、Zodバリデーションを作りたい、といったリクエストで使う。「openapi」「swagger」「zod」「APIスキーマ」「yamlから型」「スキーマ生成」「バリデーション生成」などのキーワードが出たら積極的にこのスキルを使うこと。