tech-stack:add-typescript-best-practices
Setup TypeScript best practices and code style rules in CLAUDE.md
- License 许可
- MIT
- 最近更新
- 2026-05-29
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- tech-stack:add-typescript-best-practices
- description
- Setup TypeScript best practices and code style rules in CLAUDE.md
- argument-hint
- Optional argument which practices to add or avoid
03 SKILL.md 正文
Setup TypeScript Best Practices
Create or update CLAUDE.md in with following content, <critical>write it strictly as it is<critical>, do not summaraise or introduce and new additional information:
## Code Style Rules
### General Principles
- **TypeScript**: All code must be strictly typed, leverage TypeScript's type safety features
### Code style rules
- Interfaces over types - use interfaces for object types
- Use enum for constant values, prefer them over string literals
- Export all types by default
- Use type guards instead of type assertions
### Best Practices
#### Library-First Approach
- Common areas where libraries should be preferred:
- Date/time manipulation → date-fns, dayjs
- Form validation → joi, yup, zod
- HTTP requests → axios, got
- State management → Redux, MobX, Zustand
- Utility functions → lodash, ramda
#### Code Quality
- Use destructuring of objects where possible:
- Instead of `const name = user.name` use `const { name } = user`
- Instead of `const result = await getUser(userId)` use `const { data: user } = await getUser(userId)`
- Instead of `const parseData = (data) => data.name` use `const parseData = ({ name }) => name`
- Use `ms` package for time related configuration and environment variables, instead of multiplying numbers by 1000
04 同仓库更多 Skills
writing-clearly-and-concisely
Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.
crafting-effective-readmes
Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.
wiki-architect
You are a documentation architect that produces structured wiki catalogues and onboarding guides from codebases.
readme
You are an expert technical writer creating comprehensive project documentation. Your goal is to write a README.md that is absurdly thorough—the kind of documentation you wish every project had.
ubiquitous-language
Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions "domain model" or "DDD".
technical-writing-style
Enforce clear, direct writing in software development documents including OKRs, PRDs, tech specs, architecture decision records (ADRs), git commit messages, PR descriptions, READMEs, changelogs, runbooks, incident postmortems, API docs, and onboarding guides. Trigger whenever a user asks to write, edit, revise, or review any of these document types. Also trigger when the user says writing "sounds like AI", "feels robotic", "needs polish", or asks to "make it sound more natural" in the context of technical or professional prose. Do not trigger for fiction, poetry, creative writing, academic papers, or legal documents unless the user explicitly asks for a more natural tone.