with one click
typescript-check
TypeScript type checking via tsc --noEmit with actionable error output.
Menu
TypeScript type checking via tsc --noEmit with actionable error output.
Detect documentation drift against filesystem state.
Learning system interface: stats, search, graduate learnings. Backed by learning.db (SQLite + FTS5).
Structured multi-phase workflows: review, debug, refactor (tidy up, clean up, untangle messy code, reorganize without changing behaviour), deploy, create, research, and more.
People operations workflows — recruiting pipeline, performance reviews, compensation analysis, offer drafting, interview prep, onboarding, org planning. Use when managing hiring pipelines, writing performance reviews, analyzing compensation, drafting offers, or planning organizational changes.
Detect stale TODOs, unused imports, and dead code.
Unified voice content generation pipeline with mandatory validation and joy-check. 13-phase pipeline: LOAD, GROUND, STATS-CHECKPOINT, GENERATE, HOOK-GATE, VALIDATE, REFINE, VARIETY-GATE, JOY-CHECK, ANTI-AI, CLOSE-GATE, OUTPUT, CLEANUP. Use when writing articles, blog posts, or any content that uses a voice profile. Use for "write article", "blog post", "write in voice", "generate content", "draft article", "write about".
| name | typescript-check |
| description | TypeScript type checking via tsc --noEmit with actionable error output. |
| user-invocable | false |
| allowed-tools | ["Read","Bash","Grep","Glob"] |
| agent | typescript-frontend-engineer |
| routing | {"triggers":["TypeScript check","tsc noEmit","type check TypeScript","tsc errors","TypeScript type validation"],"category":"code-quality","pairs_with":["vitest-runner","code-linting"]} |
This skill validates TypeScript code by running tsc --noEmit and parsing errors into structured, actionable reports organized by file. It is a read-only validation step (does not modify code) that implements a linear workflow: locate config → execute compiler → parse output → present results.
Use this skill when validating TypeScript code before commits, after refactors, or checking for type regressions. Do not use for linting, test execution, runtime errors, or projects without tsconfig.json.
Locate tsconfig.json in the project. This step is mandatory—never skip it. tsc without a tsconfig.json falls back to default settings, missing project-specific configuration like paths, strict mode, and compiler targets.
ls tsconfig.json 2>/dev/null || ls */tsconfig.json 2>/dev/null
If no tsconfig.json exists, stop and inform the user. Do not proceed without configuration.
Why: Running without tsconfig.json produces unreliable results that don't match the project's actual settings.
Execute the TypeScript compiler in type-check-only mode using --noEmit:
npx tsc --noEmit 2>&1
Capture the exit code:
Do not install TypeScript or dependencies. If TypeScript is not installed, inform the user and suggest npm install typescript --save-dev. This is a read-only skill—never modify package.json or run installation commands.
Why: --noEmit prevents generating .js files and gives you a clean type-only report. The exit code tells you definitively whether compilation succeeded.
For each error line in the tsc output, extract:
Group errors by source file and sort by line number. This helps users fix issues systematically rather than jumping randomly through the codebase.
Why: Users need actual file paths, line numbers, and error codes to fix issues. Suppressing or summarizing this information (e.g., "5 errors found") makes errors unsolvable.
Format output using this structure. Always show the full exit code and complete error details:
=== TypeScript Type Check ===
Status: PASS / FAIL (N errors)
Errors by File:
---------------
src/components/Button.tsx
Line 15:3 TS2322 Type 'string' is not assignable to type 'number'
Line 28:10 TS2339 Property 'foo' does not exist on type 'Props'
src/utils/helpers.ts
Line 5:1 TS7006 Parameter 'x' implicitly has an 'any' type
Summary: N files, M errors
Never present type errors as context for auto-fixing without explicit user request. Type check is a validation step—the user may want to review errors, may disagree with a fix approach, or may have a different solution in mind.
Why: Including the exit code and full output gives users all the context they need to make informed decisions about fixes.
Cause: No TypeScript configuration in the project root or specified path.
Solution:
--project path/to/tsconfig.jsonCause: TypeScript is not installed as a project dependency.
Solution:
npm install typescript --save-devCause: Node.js toolchain is not installed or not in PATH.
Solution:
node --versionnpm exec tsc -- --noEmitCause: Project has nested or monorepo structure with multiple TypeScript configurations.
Solution:
--project path/to/specific/tsconfig.jsonWhy explicit error handling matters: tsc may fail silently, produce incomplete output, or exit unexpectedly. Capturing and reporting the actual error lets the user understand what went wrong and how to fix it.
| Flag | Purpose |
|---|---|
--noEmit | Type check only, do not generate .js files |
--project path | Use specific tsconfig.json |
--skipLibCheck | Skip type checking .d.ts files (faster on large projects) |
--incremental | Use incremental compilation (faster for repeat runs) |
--strict | Enable all strict type checks |