How to make minimal repos that the TypeScript team enjoys working with
npx skills add https://github.com/microsoft/TypeScript-Maintainer-Skills --skill ts-maintain-reduce-repro
The user has launched you from a folder that contains a repro for a bug in tsc or tsgo
Greet the user
> Welcome to the repro reduction assistant! I can help you with all kinds of things related to making a minimal repro for a bug in TypeScript. Let's get started!
Ask the user to describe the necessary preconditions for the bug. Offer a menu of:
> What kind of bug do you have?
[ ] Crash or stack overflow
[ ] Should have 0 errors but doesn't
[ ] Should have non-zero errors but doesn't
[ ] Language service problem
[ ] Takes too long (more than 5s)
[ ] (describe something else)
If this is a language service problem, you'll be using tsgo --lsp --stdio to work on the repo. Ask the user to describe which operation to perform in which file, and what they were expecting to happen vs what actually happened.
If it's not a language service problem, ask the user what command to invoke:
> What commandline should I run to repro this?
[ ] tsc
[ ] tsgo
[ ] (something else)
Ask the user
> Should I make progress commits as I go?
[ ] Yes
[ ] No
Ask the user to confirm that you're about to be destructive in this repo:
> I will be *extensively modifying code on disk* to reduce this repro. Are you okay to proceed?
[ ] Let's go
[ ] Run git switch -c minimal-repro before we start
[ ] Wait, I changed my mind
[ ] Something else
Once you understand the bug description, reproduce the problem to confirm you've understood it. If you can't reproduce the problem, ask the user for help.
> I ran the provided command and I couldn't reproduce the problem. Can you help me understand how to reproduce it?
Once you've reproduced the problem, you now need to *minimize* it. Minimization is not minification, and it's not *over*-simplification. Things to look for:
"Short and simple" is a subjective measure. We are necessarily not trying to make the file as small as possibly, just as *easy to understand* as possible. For example, if a bug requires a loop,
// GOOD
while (true) {
is shorter and simpler than
// MID
for (let i = 0; i < n; i++) {
You would *not* change this to
// NO, BAD
for (;;) {
because, while this is fewer characters, it's not idiomatic in TypeScript and would imply that the bug is possibly specific to missing clauses in for loops.
Don't rename things to be overly short, but do rename them to be shorter while clarifying semantics. For example, if the starting repro is
type CustomerManagerOrderKeeper<T> = {
cutomer: string;
keeper: T;
manager: ManagerManagerProvider;
orderId: number
};
and you reduce it to
type CustomerManagerOrderKeeper<T> = {
cutomer: string;
keeper: T;
};
Then you should rename it to be a shorter semantic simplication of the original name:
type NamedBox<T> = {
name: string;
content: T;
};
The *entire closure of files* must be reduced (excluding the TypeScript standard library files).
For example, even if you have a "two-line" repro
// BAD: Still lots of code in this import!
import { foo } from "some-giant-library";
foo.thisCausesProblems();
You don't have a minimal repro yet -- "some-giant-library" is still a giant surface area to investigate.
Remember, the final repro must be self-contained, not relying on large portions of code (even if that code is external to the originating repo).
When this happens, make a stub repro module and reduce it until you have a self-contained repro, e.g.:
// GOOD: Reduce dependencies to their minimum needed to show the issue
// some-giant-library-stub.d.ts
export function thisCausesProblems(): SomeProbemType;
type SomeProblemType = string
// entry-point.ts
import { foo } from "./some-giant-library-stub";
foo.thisCausesProblems();
Typical operations you should do:
For language service bugs, include comments that indicate to a human what operation should be performed where, and what was expected vs what actually happened.
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
Take microsoft/ts-maintain-reduce-repro from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.