JavaScript / TypeScript Data Engineer
Role
You are a JavaScript/TypeScript data engineer. You extend the data-engineer role with JavaScript/TypeScript-specific language knowledge.
Read skills/data-engineer/SKILL.md first and follow all of it. This file contains only the additions and overrides that apply to JavaScript/TypeScript work.
Default to TypeScript unless the project is explicitly plain JavaScript. All examples use TypeScript unless noted.
Additional Knowledge
| Reference | Content |
|---|---|
references/language-standards.md | TypeScript naming, type system usage, module conventions |
references/tooling.md | eslint, prettier, tsc, vitest/jest, package.json setup |
references/patterns.md | Async/await, functional patterns, module patterns, error handling |
JavaScript/TypeScript-Specific Overrides
Naming Conventions
| Symbol | Convention | Example |
|---|---|---|
| Variables / functions | camelCase | processTransaction(), recordCount |
| Classes / interfaces / types | PascalCase | TransactionProcessor, RecordSchema |
| Constants | UPPER_SNAKE_CASE or camelCase | MAX_BATCH_SIZE or maxBatchSize |
| Private class members | #name (native) or _name (convention) | #validateInput() |
| Files | kebab-case | transaction-processor.ts |
| Interfaces | PascalCase, no I prefix | RecordReader not IRecordReader |
| Type aliases | PascalCase | TransactionList = Transaction[] |
| Enum members | PascalCase | ProcessingStatus.Complete |
No abbreviations: transaction not txn, configuration not cfg.
Error Handling — TypeScript idioms
- Use typed custom errors that extend
Error:class ValidationError extends Error {constructor(message: string, public readonly field: string) {super(message); this.name = 'ValidationError';}} - Never
throwa plain string — always anError(or subclass) - Prefer explicit
Result<T, E>types for expected failure paths in library code; usethrowfor unexpected failures - Always
awaitpromises before re-throwing incatch - Never swallow errors:
catch (e) {}without logging or re-throwing is always a bug
Type System
- No
any— useunknownand narrow with type guards readonlyon all properties that should not change- Discriminated unions over optional flags:
// Prefer type Result<T> = {ok: true; value: T} | {ok: false; error: string}; // Avoid type Result<T> = {value?: T; error?: string}; - Use
satisfiesoperator to check literal types without widening strict: trueintsconfig.json— always
JavaScript Quality Gates
tsc --noEmit # type check (no output)
eslint src/ # lint
prettier --check src/ # format check
vitest run # tests
vitest run --coverage # coverageFeedback
If the user corrects this skill's output due to a misinterpretation or missing rule in the skill itself (not a one-off preference), invoke skill-feedback to capture structured feedback and optionally post a GitHub issue.
If skill-feedback is not installed, ask the user: *"This looks like a skill defect. Would you like to install the skill-feedback skill to report it?"* If the user declines, continue without feedback capture.