Typescript
Keep LobeHub-style TypeScript edits aligned with strict typing, import hygiene, and async patterns before merge or during review.
Overview
typescript (LobeHub) is an agent skill most often used in Build (also Ship review) that enforces Lobe Chat TypeScript style, strict typing, and module patterns before edits land.
Install
npx skills add https://github.com/lobehub/lobe-chat --skill typescriptWhat is this skill?
- interface vs type guidance for props and unions
- `Record<PropertyKey, unknown>` instead of `any` or loose `object`
- `as const satisfies`, `@ts-expect-error` over `@ts-ignore`, and `import type` rules
- `async`/`await` with `Promise.all` and `for…of` preference over indexed loops
- No silent `.catch(() => fallback)` and module augmentation over `namespace`
Adoption & trust: 895 installs on skills.sh; 78.4k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are editing TypeScript in LobeHub and keep introducing `any`, wrong import splits, or patterns ESLint and reviewers reject.
Who is it for?
Solo maintainers of Lobe Chat forks or adjacent packages who want agent edits to match upstream style without re-reading CONTRIBUTING docs each session.
Skip if: Greenfield projects with no LobeHub dependency, or teams that only need generic TypeScript tutorials unrelated to this repo's ESLint rules.
When should I use this skill?
Any TypeScript file edit in LobeHub, or triggers like 'fix the type', 'why is this `any`', 'should this be interface or type', 'eslint type-import', 'ts-expect-error'.
What do I get? / Deliverables
Agent-produced TS changes follow LobeHub conventions—stricter types, correct `import type`, and review-ready error handling without silent catch fallbacks.
- Type-correct `.ts`/`.tsx` edits matching LobeHub conventions
- Review notes on interface vs type and import splits
- Refactors replacing unsafe `any` and silent catch fallbacks
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Primary shelf is Build because most invocations happen while editing `.ts`/`.tsx` application code. Lobe Chat is a React/TS frontend-heavy codebase; the guide governs UI and shared module typing conventions.
Where it fits
Implement a new chat UI component and need `interface` props plus `import type` for store types.
Extend server-side pipeline context types with `as const satisfies` on config objects.
PR review flags implicit `any` on API handlers—invoke the skill to apply `Record<PropertyKey, unknown>` patterns.
Harden error paths by removing silent `.catch(() => fallback)` after production log review.
How it compares
Repo-specific TS style contract—not a generic linter CLI or a test runner skill.
Common Questions / FAQ
Who is typescript (LobeHub) for?
Developers and solo builders working in the Lobe Chat monorepo who want coding agents to follow the project's TypeScript and type-import conventions.
When should I use typescript (LobeHub)?
Before any `.ts`/`.tsx` edit in LobeHub; during Ship code review when questioning `any` or `interface` vs `type`; when designing extensible types or fixing ESLint type-import violations.
Is typescript (LobeHub) safe to install?
It is documentation-only style guidance with no shell or network requirements; still review the Security Audits panel on this Prism page before trusting any third-party skill package.
SKILL.md
READMESKILL.md - Typescript
# TypeScript Code Style Guide ## Types and Type Safety - Avoid explicit type annotations when TypeScript can infer - Avoid implicitly `any`; explicitly type when necessary - Use accurate types: prefer `Record<PropertyKey, unknown>` over `object` or `any` - Prefer `interface` for object shapes (e.g., React props); use `type` for unions/intersections - Prefer `as const satisfies XyzInterface` over plain `as const` - Prefer `@ts-expect-error` over `@ts-ignore` over `as any` - Avoid meaningless null/undefined parameters; design strict function contracts - Prefer ES module augmentation (`declare module '...'`) over `namespace`; do not introduce `namespace`-based extension patterns - When a type needs extensibility, expose a small mergeable interface at the source type and let each feature/plugin augment it locally instead of centralizing all extension fields in one registry file - For package-local extensibility patterns like `PipelineContext.metadata`, define the metadata fields next to the processor/provider/plugin that reads or writes them ## Async Patterns - Prefer `async`/`await` over callbacks or `.then()` chains - Prefer async APIs over sync ones (avoid `*Sync`) - Use promise-based variants: `import { readFile } from 'fs/promises'` - Use `Promise.all`, `Promise.race` for concurrent operations where safe ## Imports - This project uses `simple-import-sort/imports` and `consistent-type-imports` (`fixStyle: 'separate-type-imports'`) - **Separate type imports**: always use `import type { ... }` for type-only imports, NOT `import { type ... }` inline syntax - When a file already has `import type { ... }` from a package and you need to add a value import, keep them as **two separate statements**: ```ts import type { ChatTopicBotContext } from '@lobechat/types'; import { RequestTrigger } from '@lobechat/types'; ``` - Within each import statement, specifiers are sorted **alphabetically by name** ## Code Structure - Prefer object destructuring - Use consistent, descriptive naming; avoid obscure abbreviations - Replace magic numbers/strings with well-named constants - Defer formatting to tooling - Prefer **named exports** over `export default` — keeps refactor renames and IDE auto-import in sync, and avoids the `default` re-naming drift you get with `import Foo from './foo'`. Reserve `export default` for files where the framework requires it (Next.js page/route/layout, React.lazy targets, config files like `vitest.config.ts`) - Before adding local helpers for common guards/parsing/normalization (record checks, string extraction, empty-string handling, timing helpers, JSON-safe utilities, etc.), search `packages/utils` first. If the helper already exists or clearly belongs there, import it from `@lobechat/utils` (or the relevant `@lobechat/utils/*` subpath) instead of duplicating tiny helpers across feature files. ## UI and Theming - Use `@lobehub/ui`, Ant Design components instead of raw HTML tags - Design for dark mode and mobile responsiveness - Use `antd-style` token system instead of hard-coded colors ## Performance - Reuse existing utils in `packages/utils` or installed npm packages - Query only required columns from database