Skills

typescript-engineering: TypeScript Engineering Standards for Your AI Coding Assistant

A TypeScript engineering skill for AI coding assistants, best for consistent guidance on type safety, runtime validation, architecture, security, and testing. Prerequisites are copying the complete skill folder and having the host discover it correctly; whether the assistant has file or command side effects during execution is not stated in the evidence.

Official source · bluenzzz/typescript-engineering

Install

npx skills add bluenzzz/typescript-engineering

Who it's for

  • TypeScript developers who use AI coding assistants daily and want more consistent engineering guidance from their assistant on type safety, runtime validation, architecture, security, and testing.
  • According to official documentation, it works with hosts such as Codex, Claude Code, Copilot, Cursor, Antigravity, OpenCode, and Gemini CLI. Hosts discover it automatically via the skill's name and description, and it can also be invoked explicitly. It does not rely on session-start hooks, MCP servers, or mandatory subagents.
  • When it's not a fit: benefits are limited for non-TypeScript tasks. The official evidence does not state its support for non-English text, specific language versions, or specific frameworks — these are unknowns, so verify before use.
  • Installation prerequisite: the complete skill folder must be copied (copying only SKILL.md is not enough), otherwise the assistant cannot read the references inside. Keep only one installation route per host to avoid duplicate installations.

Your first try in 3 minutes

The recommended main path is installation via the skills CLI:

  1. Prerequisite: Node.js / npm available locally (able to run npx).
  2. Install: run the official command in a terminal:
npx skills add bluenzzz/typescript-engineering

The installer will use prompts to let you choose the target assistant and install scope (project or global). Pick as needed.

  1. Trigger a low-risk task: in your TypeScript project, ask your assistant for a read-only diagnostic task, e.g. reviewing the type safety or runtime validation design of a piece of code in your project. In Claude Code you can use the official explicit invocation: /typescript-engineering:typescript-engineering; other hosts can match automatically via the skill's name and description, or invoke it explicitly by name according to the host's own mechanism. If automatic selection doesn't happen, explicit invocation is more reliable.
  2. Success signal: the assistant cites the skill's engineering guidance (type safety, runtime validation, architecture, security, testing, etc.) when structuring its answer, which means the skill was discovered and is in effect. If automatic discovery doesn't occur, invoke it explicitly by name, and check that only one installation route was kept during installation.

About risk: the evidence does not state the side effects of the diagnostic review task itself (whether it reads/writes files, runs commands, or accesses the network) — that's an unknown; confirm your host's permission settings before allowing the assistant to operate. Secondary alternative: the repository root also provides a local install script node scripts/install-skill.mjs --target codex --project ../my-app, supporting the codex, claude, copilot, cursor, antigravity, opencode, or portable targets. It requires Node.js 24, copies the complete skill, refuses existing installations, and doesn't modify global settings. This is mentioned only as a secondary note, not as an equal alternative to the main path.

Use cases

Case 1: Reviewing server-side input validation code. Scenario: you've written TypeScript code that handles external requests and are unsure whether type assertions are masking runtime issues. Send the assistant this task: "Based on the typescript-engineering skill, review this module's type safety and runtime validation design." It will use the skill's guidance workflows on runtime validation and type safety to point out issues and suggest improvements. Expected result: an engineering review tailored to your current code, rather than a generic answer.

Case 2: Asking for architecture advice before a refactor. Scenario: you plan to split a module and want to confirm problems with the current structure first. Send the assistant this task: "Following typescript-engineering's architecture and testing guidance, evaluate this module's split plan." It will draw on the skill's architecture and testing content for the evaluation. What you can confirm is that the assistant's evaluation is based on the skill; the evaluation itself won't change any files unless your host's permissions allow the assistant to perform write operations — the evidence doesn't state this, so confirm the scope of actions with the assistant before proceeding.

Boundaries of use

  • Installation and running: the main path depends on npx/skills CLI and a Node.js environment; the local script route requires Node.js 24. The host discovers the skill via its name and description; if automatic discovery fails, invoke it explicitly.
  • Side effects and confirmation points: the evidence gathered here only shows that it is a reusable skill providing engineering guidance; it does not state whether it reads/writes files, runs commands, or accesses the network when executing tasks. Before using any action that changes project state, clarify side effects with the assistant and confirm. "Review/diagnostic" invocations are not necessarily zero-risk.
  • Installation differences by platform are preserved: CLI installation uses prompts to select the assistant and scope; the local script supports multiple targets, refuses duplicate installations, and doesn't change global settings. Whichever route you take, ensure the complete skill folder is copied and keep only one installation route per host.
  • Officially stated limitations: references must be readable (full copy); duplicate installations must be avoided.
  • Not yet confirmed: supported project text languages, specific framework version ranges, actual differences in automatic discovery across hosts, and file/network behavior during task execution are all undocumented — treat them as unknowns.