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.
1---2name: typescript-guidelines3description: General rules4---56## General rules78- Do not add typecasts if not necessary. First make sure the cast is needed for9 proper typechecking. Then consider adding assertions or guards ensuring the10 value's type is correct.11- The type aliases should be used only when the type is really complex (multiple12 nested generic arguments, for example), or if the aliast name would provide13 useful information besides the variable's/parameter's name.14- If writing comments, do not mention code's history or how things _no longer_15 run, except as a cautionary tale to not repeat errors.1617## Documentation Comments1819- The docstrings should be created for exported, or non-obvious private20 entities.21- They goal is to understand what given entity _is_. Do not focus on how it is22 used, unless it is useful as an example to understand the entity itself. Do23 not mention details which are easily deduced from the name or code itself.24- They should not focus on implementation details, unless it may be somehow25 important to the dev using the entity (like time complexity).26- @file documentation should be a very short summary of module. The more27 detailed description should be on the main function/class defined in module.
Run npx skillmds@latest add enso-org/typescript-guidelines in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
General rules It is listed under Coding & Dev Tools on SkillMD.
This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
enso-org (@enso-org) published this skill. Their other Agent Skills are listed on their SkillMD profile.