home / skills / duc01226 / easyplatform / fix-types

fix-types skill

safe

This skill helps you fix type errors across TypeScript projects by running typecheck utilities and resolving issues without using any.

npx playbooks add skill duc01226/easyplatform --skill fix-types

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

815 B

---
name: fix-types
description: "[Fix & Debug] ⚡ Fix type errors"
infer: true
---

Run `bun run typecheck` or `tsc` or `npx tsc` and fix all type errors.

## ⚠️ Anti-Hallucination Reminder

**Before modifying ANY code:** Verify assumptions with actual code evidence. Search for usages, read implementations, trace dependencies. If confidence < 90% on any change, investigate first or ask user. See `.claude/skills/shared/anti-hallucination-protocol.md` for full protocol.

## Rules
- Fix all of type errors and repeat the process until there are no more type errors.
- Do not use `any` just to pass the type check.

## IMPORTANT Task Planning Notes

- Always plan and break many small todo tasks
- Always add a final review todo task to review the works done at the end to find any fix or enhancement needed

Overview

This skill fixes TypeScript type errors across a codebase until no type errors remain. It runs the project type checker, analyzes errors, designs small, verifiable fixes, and iterates until clean. The process emphasizes evidence-driven changes and avoids using any as a shortcut.

How this skill works

The workflow runs the configured type checker (bun run typecheck, tsc, or npx tsc) to collect all type diagnostics. For each diagnostic it locates usages and implementations, verifies assumptions in code, and applies minimal typed fixes. It repeats type checking and fixes until zero type errors remain, then performs a final review.

When to use it

When type checking shows errors in CI or locally
Before merging pull requests that introduce new TS errors
When upgrading TypeScript or typings and new errors appear
During codebase cleanup to improve type safety
Before releasing to ensure no regressions from type changes

Best practices

Always verify assumptions by searching for usages and reading implementations before changing signatures
Break work into small, tracked TODOs and commit incremental fixes
Never add or keep any to silence errors; prefer precise types or generics
Prefer non-breaking changes first (narrow scopes, overloads, optional params) and run tests after each change
Add or update unit types and comments documenting why a signature changed
Include a final review task to re-run type checks, tests, and scan for unintended API changes

Example use cases

Fixing type errors after bumping TypeScript version from 3.x to 4.x
Resolving regressions introduced by new library typings (e.g., @types packages)
Converting loosely typed modules to stricter interfaces without runtime changes
Correcting function return types mismatched with callers
Cleaning up inferred any types revealed by stricter compiler options

FAQ

What if I’m not confident about a suggested type change?

Do not modify code blindly. Investigate usage sites, run tests, and ask the repository owner or the original author if necessary. If confidence is under 90%, create an investigation TODO and pause fixes.

Is it ever acceptable to use any to pass type checks?

No. Using any is prohibited except as a documented, temporary stopgap during investigation. Prefer narrower types, unions, generics, or unknown with guarded casts.