Skip to main content

typescript-guidelines

Typescript coding guidelines and conventions. Use this skill whenever working on Typescript source files (.ts or .tsx) including Vue framework (.vue) — editing, creating, reviewing, or refactoring Typescript code. This includes any task involving Typescript: writing new modules, fixing bugs, adding features, code review, or answering questions about Typescript code in the project.

소스 정보

저장소
enso-org/enso
최근 소스 활동
2026년 5월 14일 18:28
감지된 SKILL.md 언어
영어
스타
7,443
포크
343

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
typescript-guidelines
description
Typescript coding guidelines and conventions. Use this skill whenever working on Typescript source files (.ts or .tsx) including Vue framework (.vue) — editing, creating, reviewing, or refactoring Typescript code. This includes any task involving Typescript: writing new modules, fixing bugs, adding features, code review, or answering questions about Typescript code in the project.
## General rules - Do not add typecasts if not necessary. First make sure the cast is needed for proper typechecking. Then consider adding assertions or guards ensuring the value's type is correct. - The type aliases should be used only when the type is really complex (multiple nested generic arguments, for example), or if the aliast name would provide useful information besides the variable's/parameter's name. - If writing comments, do not mention code's history or how things _no longer_ run, except as a cautionary tale to not repeat errors. ## Documentation Comments - The docstrings should be created for exported, or non-obvious private entities. - They goal is to understand what given entity _is_. Do not focus on how it is used, unless it is useful as an example to understand the entity itself. Do not mention details which are easily deduced from the name or code itself. - They should not focus on implementation details, unless it may be somehow important to the dev using the entity (like time complexity). - @file documentation should be a very short summary of module. The more detailed description should be on the main function/class defined in module.
GitHub에서 보기