P PasteCode
Regel

KI-Codierungsregeln für TypeScript-Strict-Projekte

AGENTS.md-Regeln für TypeScript Strict-Mode-Projekte, die jegliche Typen eliminieren, Narrowing-Muster erzwingen und verhindern, dass Agents Code kompilieren, der zwar funktioniert, aber falsch ist.

CursorClaude CodeCodexWindsurf TypeScriptNext.js
.md .json Aktualisiert 8. Juni 2026

Legen Sie dies als AGENTS.md im Stammverzeichnis Ihres Repos ab. TypeScript Strict Mode ist nur so nützlich wie die Regeln, die verhindern, dass Agents ihn mit any-Casts und @ts-ignore-Kommentaren umgehen.

AGENTS.md

AGENTS.md
# Project Rules — TypeScript Strict
## TypeScript configuration
- `strict: true` is set in `tsconfig.json`. This enables `noImplicitAny`,
`strictNullChecks`, `strictFunctionTypes`, `strictBindCallApply`,
`strictPropertyInitialization`, and `noImplicitThis`. Do not disable any of these.
- `noUncheckedIndexedAccess: true` is enabled. Array indexing returns `T | undefined`.
Always check array access results before using them.
- `exactOptionalPropertyTypes: true` is enabled. Do not assign `undefined` to an
optional property — omit the property instead.
## Hard rules — no exceptions
- NEVER use `any`. Use `unknown` for values of uncertain type and narrow them
before use. The single exception is third-party library types that are themselves
typed as `any` — wrap and re-export with a proper type.
- NEVER use `as T` type assertions unless you add a comment explaining why the
compiler cannot infer the type and why the assertion is safe. Prefer type guards.
- NEVER use `@ts-ignore` or `@ts-expect-error` without a comment on the same line
explaining the exact reason. If you find yourself using these, refactor instead.
- NEVER use non-null assertion (`!`) on values that could genuinely be null/undefined
at runtime. Write an explicit check or use optional chaining (`?.`).
- NEVER widen a type unnecessarily. If a function returns `string`, type it as
`string` — not `string | undefined` just to avoid a null check.
## Type design conventions
- Model domain errors with discriminated unions, not thrown errors or `null`.
Return `{ ok: true; value: T } | { ok: false; error: string }` from fallible
operations instead of relying on catch at the call site.
- Prefer `type` aliases for unions and intersections; use `interface` for object
shapes that may be extended. Be consistent within a file.
- Generic constraints should be as narrow as possible: `T extends string` instead of
`T extends unknown` when you only use string operations on `T`.
- Export only what callers need. Keep internal implementation types unexported unless
there is an explicit reason to expose them.
## Narrowing and runtime validation
- All external data (API responses, form input, `JSON.parse` output, URL params) must
be validated at the boundary with Zod or a type guard before being used as a typed
value. Never cast external data with `as MyType` without validation.
- Use `satisfies` to validate object literals against a type without widening:
`const config = { ... } satisfies Config` instead of `const config: Config = { ... }`
when you need to preserve literal types.
- Exhaustiveness checks in `switch` statements: add a `default: assertNever(x)` arm
where `assertNever` is `(x: never) => never` — this catches unhandled union members
at compile time when the union is extended.
## Definition of done
- `tsc --noEmit` passes with zero errors.
- `grep -r 'as any\|: any\|@ts-ignore\|@ts-expect-error' src/` returns zero results
(or every hit has an approved justification comment).
- ESLint with `@typescript-eslint/no-explicit-any` and `@typescript-eslint/no-unsafe-*`
rules enabled passes.
- No `!` non-null assertions on values that come from external data or optional fields.

Warum diese Regeln

  • Kein as T ohne Kommentar ist die wichtigste Regel nach dem Verbot von any. Typbehauptungen sind die primäre Methode, mit der Agents TypeScript-Fehler „beheben“, ohne sie tatsächlich zu beheben — der Code kompiliert, aber die Laufzeit-Typgarantie ist verloren. Das Erzwingen einer schriftlichen Begründung zwingt Agents dazu, zu überlegen, ob die Behauptung tatsächlich sicher ist.
  • Validieren Sie externe Daten an der Grenze verhindert die häufigste Klasse von Laufzeit-Typfehlern in TypeScript-Anwendungen. Agents, die eine typisierte API-Antwort sehen, vertrauen oft der Typannotation, ohne zu prüfen, ob sie beim Abruf validiert wurde. Das führt zu Apps, bei denen die TypeScript-Typen Lügen sind, die sauber kompilieren, aber unvorhersehbar abstürzen.

Geeignet für

  • Produktions-TypeScript-Codebasen mit strict: true, bei denen Typsicherheit eine erstklassige Qualitätsanforderung ist — insbesondere solche, die Benutzerdaten, Finanztransaktionen oder externe API-Integrationen verarbeiten.

Nicht geeignet für

  • Schnelles Prototyping oder Skripte, bei denen strenge Typsicherheit mehr Aufwand als Nutzen bringt — verwenden Sie strict: false und ein leichteres Regelwerk für Wegwerfcode.