agentleFS
Sign inStart free
timmo001timmo001/skills/types-enforce-ts/SKILL.md

types-enforce-ts

Skill2 starsChanged todayApache-2.0View on GitHub

TypeScript type-safety guidance. Use when editing or reviewing `.ts`, `.tsx`, `.mts`, or `.cts` files.

We split this skill into the rules it gives an agent

18 rules. About 0 are common, 13 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when reviewing or editing TypeScript code:

    line 11
  2. Distinctive:

    Prefer stricter and more precise types over broader types.

    line 14
  3. Very specific:

    Avoid introducing any, unsafe double assertions, or blanket suppressions.

    line 16
  4. Distinctive:

    Prefer narrowing and type guards over non-null assertions and forced casts.

    line 18
  5. Distinctive:

    Keep inferred types when they are already clear and stable.

    line 19
  6. Very specific:

    Do not add explicit return annotations such as : void when the return type is obvious from a local implementation.

    line 20
  7. Distinctive:

    Remove unnecessary casts and non-null assertions where safe.

    line 21
  8. Distinctive:

    Add minimal annotations for function params or returns when clarity or safety improves.

    line 22
  9. Distinctive:

    Prefer explicit, narrow types.

    line 26
  10. Distinctive:

    Remove unnecessary intermediate variables and one-off aliases when clarity is maintained.

    line 27
  11. Distinctive:

    Prefer typing parameters at the signature level when it improves safety or clarity, and rely on inference when types are already clear.

    line 29
  12. Distinctive:

    Avoid casting later at value access points when signature-level typing or narrowing is clearer.

    line 30
  13. Distinctive:

    If project generic helpers exist, prefer concrete generic types over ad-hoc casts and loosely typed objects.

    line 31
  14. Very specific:

    Prefer top-level annotations and satisfies over type assertions when possible.

    line 32
  15. Very specific:

    Do not introduce local aliases only to satisfy TypeScript narrowing (const params = this._params, const data = this._data) if direct guards …

    line 33
  16. Distinctive:

    Keep control flow simple without changing established logic unless explicitly requested.

    line 34
  17. Very specific:

    Do not use the non-null assertion operator (!) unless it is strictly required and justified by existing project guidance.

    line 35
  18. Distinctive:

    Do not add unnecessary comments or abstractions.

    line 36

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

TypeScript Type Safety

Applies only to TypeScript files such as .ts, .tsx, .mts, and .cts.

Use this skill when reviewing or editing TypeScript code:

  • Preserve runtime behavior and public API shape unless the user asked otherwise.
  • Prefer stricter and more precise types over broader types.
  • Reuse or extend existing local types instead of creating duplicate one-off types.
  • Avoid introducing any, unsafe double assertions, or blanket suppressions.
  • Replace any with concrete types or unknown plus narrowing.
  • Prefer narrowing and type guards over non-null assertions and forced casts.
  • Keep inferred types when they are already clear and stable.
  • Do not add explicit return annotations such as : void when the return type is obvious from a local implementation; keep them only for exported APIs, overloads, recursive functions, interface conformance, or genuinely clarifying contracts.
  • Remove unnecessary casts and non-null assertions where safe.
  • Add minimal annotations for function params or returns when clarity or safety improves.
  • Align generics, unions, and nullability with real data flow.
  • For Lit lifecycle methods that receive changed properties (shouldUpdate, willUpdate, update, firstUpdated, updated), prefer changedProperties: PropertyValues<this> for strict typing.
  • For Lit lifecycle methods that need to handle protected or private changed properties, use changedProperties: PropertyValues (without <this>) instead of forcing PropertyValues<this>.
  • Prefer explicit, narrow types.
  • Remove unnecessary intermediate variables and one-off aliases when clarity is maintained.
  • Inline one-time-use values when clarity is maintained.
  • Prefer typing parameters at the signature level when it improves safety or clarity, and rely on inference when types are already clear.
  • Avoid casting later at value access points when signature-level typing or narrowing is clearer.
  • If project generic helpers exist, prefer concrete generic types over ad-hoc casts and loosely typed objects.
  • Prefer top-level annotations and satisfies over type assertions when possible.
  • Do not introduce local aliases only to satisfy TypeScript narrowing (const params = this._params, const data = this._data) if direct guards and property access typecheck cleanly.
  • Keep control flow simple without changing established logic unless explicitly requested.
  • Do not use the non-null assertion operator (!) unless it is strictly required and justified by existing project guidance.
  • Do not add unnecessary comments or abstractions.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free