TypeScript prompts for ChatGPT, Claude and Codex

The best TypeScript prompts paste the exact compiler error, the code and your tsconfig settings, and forbid the shortcuts (any, as casts, !) that make errors disappear without fixing them. Below are 12 TypeScript prompts for ChatGPT, Claude, Claude Code and Codex covering type errors, type design, generics, stricter compiler settings and keeping types honest at runtime.

For general jobs such as explaining code, writing a regex or a commit message, see the coding prompts. For plain JavaScript concerns like async code, the DOM and bundles, see the JavaScript prompts. The prompts here are about the type system.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{ts_version:the version in my package.json}} means the model should assume that version unless you change it.

Three habits make the answers better:

• Paste the whole error. TypeScript errors are nested. The last line of a long error usually names the real mismatch, and a model that only sees the first line guesses.
• Share your compiler settings. The same code can pass or fail depending on flags. The TSConfig reference explains that strict turns on a whole family of checks, and warns that future versions may add stricter checks under that flag.
• Ban the escape hatches. Tell the model not to use any, as or ! unless it explains why each one is safe. Otherwise the fastest "fix" is to silence the checker.

In an agent, name the files and ask it to run your type checker after each change.

How do you fix TypeScript type errors with AI?

1. Explain a type error

For the long, nested errors that are hard to read. Asking for the explanation first stops the model from patching the symptom.

I get this TypeScript error. Explain it in plain language before fixing it.

Error (full text):
{{error}}

Code it points to:
{{code}}

Relevant tsconfig options: {{tsconfig:strict is on}}

1. Which two types don't match, and where each one comes from.
2. Why TypeScript considers them incompatible.
3. The smallest fix that keeps the types correct. Do not use any, a type
assertion (as) or a non-null assertion (!).
4. If the error points to a real bug, say what would go wrong at runtime.

2. Remove any and unsafe casts

For files where any and as crept in. The list of remaining casts is what you review.

Remove every use of any, every type assertion (as) and every non-null
assertion (!) from this TypeScript file where possible.

- Where the type is truly unknown, use unknown plus a type guard.
- Where a value can be null or undefined, handle it explicitly.
- Infer types where TypeScript can, and add annotations only on exported
functions and public APIs.

Do not change runtime behavior. After the code, list each cast you could
not remove and why it is safe.

{{code}}

3. Convert a JavaScript file to TypeScript

For migrating one file at a time. Asking for the questions it had to guess keeps the types from being invented.

Convert this JavaScript file to TypeScript for a project with
{{tsconfig:strict mode on}}.

- Write types from how the code is actually used, not from names.
- Prefer type aliases and interfaces that callers can import.
- Keep the same exports and runtime behavior.

After the code, list every type you had to guess, with the question I
should answer to confirm it.

{{code}}

How it is called elsewhere (optional):
{{call_sites}}

How do you design better types?

4. Model states with a discriminated union

For objects with flags like isLoading, error and data that can contradict each other. The TypeScript handbook shows how narrowing on a shared literal property lets the compiler know which member you have, and how never catches missing cases.

This type allows combinations that should be impossible:

{{type}}

Rewrite it as a discriminated union with a {{discriminant:status}} field so
each state only has the fields that make sense for it. Then:
- Update this code to use the new type: {{code}}
- Add a switch with an exhaustive check that assigns the value to a never
variable in the default branch, so adding a state later causes a compile
error.
- List the impossible states the old type allowed.

5. Write a generic function or utility type

For helpers that lose type information, so callers end up casting. Ask for examples that should fail, not just ones that pass.

Write a generic TypeScript {{kind:function}} that {{description}}.

Requirements:
- Callers should not need type assertions.
- Constrain type parameters only as much as needed, and say why each
constraint exists.
- Keep it readable: if a conditional or mapped type gets hard to follow,
explain it line by line.

Show three calls that should compile with their inferred types, and three
that should fail to compile with the error each one gives.

6. Check a config object with satisfies

For config objects and lookup tables where an annotation makes types too wide. The TypeScript 4.9 release notes describe satisfies as letting you "validate that the type of an expression matches some type, without changing the resulting type of that expression."

This object is annotated with a wide type, so I lose the specific keys and
values when I use it:

{{code}}

Rewrite it using satisfies (and as const if it helps) so TypeScript still
checks it against {{type:the existing type}} but keeps the literal types.
Show one line that compiles now but didn't before, and one typo the check
still catches. Tell me if my TypeScript version, {{ts_version:the version in my package.json}}, is too old for satisfies.

How do you make a TypeScript codebase stricter?

7. Turn on strict mode in stages

For older projects with hundreds of errors. Turning flags on one at a time keeps each pull request reviewable.

I want to turn on strict in this project. Current tsconfig:

{{tsconfig}}

Output of the type checker with strict on, or a summary of it:
{{errors}}

Plan the migration flag by flag within the strict family. For each flag:
what it checks, roughly how many of my errors it causes, and the common
fix pattern. Order the flags from least to most work, and suggest how to
split the work into pull requests of about {{pr_size:50}} errors each.

8. Adopt noUncheckedIndexedAccess

The noUncheckedIndexedAccess option adds undefined to reads through index signatures, which catches real bugs but adds many errors. It is not part of strict.

I turned on noUncheckedIndexedAccess and got errors like these:

{{errors}}

Code:
{{code}}

For each error, decide whether it is a real bug (the key or index may not
exist) or a false alarm (the code already guarantees it exists). Fix real
bugs with an explicit check. For false alarms, restructure the code so the
check is not needed, for example by iterating instead of indexing. Use !
only as a last resort and explain each one.

9. Upgrade TypeScript

For version bumps that break the build. Release notes list breaking changes; the model's job is to map them to your errors.

I am upgrading TypeScript from {{from:5.x}} to {{to:the latest version}}.

New errors after the upgrade:
{{errors}}

Relevant tsconfig:
{{tsconfig}}

Group the errors by cause. For each group, name the change in the new
version that likely causes it, show the fix, and say whether a tsconfig
option could defer it. Tell me which claims I should confirm in the
official release notes, and do not guess version numbers you are unsure of.

How do you keep TypeScript types honest at runtime?

10. Validate data at the boundary

Types disappear at runtime, so JSON from an API or a form is unchecked until you check it. This prompt puts the check in one place.

This data comes from {{source:an HTTP API response}} and is used as if it
matches this type:

{{type}}

Write a validator using {{library:no library, just type guards}} that turns
unknown input into this type or returns a list of errors with the field
path for each. The TypeScript type should come from the validator, or be
checked against it, so the two cannot drift apart. Include five invalid
inputs and the error each one produces.

11. Type an API client from examples

For untyped endpoints where you have sample responses. Asking which fields are optional catches the field that is missing one time in fifty.

Write TypeScript types and a typed fetch wrapper for these endpoints.

Endpoints and sample responses:
{{samples}}

- Mark a field optional only if the samples or docs show it can be missing,
and list fields I should confirm.
- Model error responses as a separate type, not as optional fields on the
success type.
- Return a result type that forces callers to handle errors.

12. Write type tests

For library code and shared utilities where a type change can break callers without a runtime failure. The TypeScript 3.9 release notes explain that // @ts-expect-error suppresses an error, and reports when there is no error to suppress.

Write type-level tests for this exported TypeScript API using
{{tool:plain .ts files checked by tsc with ts-expect-error comments}}.

{{code}}

Cover: inferred return types for common calls, calls that must not
compile (wrong argument types, missing fields), and edge cases such as
empty arrays, unions and optional properties. One check per behavior, with
a comment saying what it protects.

What should you check before you accept the answer?

AI-written TypeScript tends to fail in the same few ways, so check these every time:

• Run the type checker yourself. A model can't compile your project unless it is an agent that runs the command. Ask an agent to paste the output.
• Search the diff for escape hatches. Look for any, as, ! and @ts-ignore that weren't there before.
• Check runtime behavior, not just types. A type fix can change logic, especially when it adds a default value or an early return.
• Read the catch blocks. With useUnknownInCatchVariables, part of the strict family, the caught value is unknown, so the code should check it before using it as an Error.

Turn your favorite one into a skill

When one of these prompts becomes a daily habit, make it a skill so Claude Code or Codex uses it automatically. The type error and "remove any" prompts are good first candidates. Paste one into the free SKILL.md generator, which needs no sign-up, and it becomes a valid SKILL.md. For component work, the React prompts pair well with these, and the unit test prompts cover runtime tests.

To keep prompts like these close, save them in Kipt. Your library lives as Markdown in a private GitHub repo you own, each blank stays fillable when you copy, and Cmd+K finds any prompt by name or tag.