- Home
- Skills
- Itou Daiki
- Easy Stat Edu
- Build Error Resolver
build-error-resolver_skill
- JavaScript
0
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill itou-daiki/easy_stat_edu --skill build-error-resolver- SKILL.md11.9 KB
Overview
This skill is a Build and TypeScript error resolution specialist that gets broken builds green quickly with minimal diffs. I focus on fixing compilation, type, import, dependency and configuration errors without making architectural changes. The goal is to restore a clean build fast and safely so development and deployment can proceed.
How this skill works
I run targeted diagnostics (npx tsc --noEmit, npm run build, eslint) to collect and categorize all errors. For each blocking error I apply the smallest safe change: add a missing type, fix an import, install a package, or adjust a config. After each change I re-run type checks and the build to ensure no new regressions. I document fixes concisely and keep changes minimal and scoped to the failing lines.
When to use it
- npm run build fails or exits non-zero
- npx tsc --noEmit reports type errors blocking progress
- Import or module resolution errors (Cannot find module)
- Configuration problems in tsconfig, webpack or Next.js
- Dependency/type declaration mismatches causing compile failures
Best practices
- Collect the full error set before fixing; prioritize blocking errors first
- Prefer adding a type annotation or null-check over broad refactors
- Use type assertions only as a last resort and document them
- Make one change per commit and re-run tsc after each change
- Avoid renaming or moving files unless required to fix resolution issues
Example use cases
- Fix implicit any errors by adding parameter types to functions
- Resolve missing module by correcting tsconfig paths or switching to relative imports
- Install missing packages and corresponding @types declarations to satisfy compiler
- Add optional properties or constraints to interfaces to match runtime data
- Adjust Next.js exports or split constants to avoid Fast Refresh full reloads
FAQ
No. I only make minimal, targeted changes required to resolve the errors. No architectural refactors or feature work.
How do you verify fixes?
I run npx tsc --noEmit and the project build (npm run build) and re-run eslint if it blocks the build. I ensure no new type or build errors are introduced.
What if a fix requires a breaking change?
I avoid breaking changes. If a required change affects API or architecture, I surface it as a recommendation and provide a minimal non-breaking workaround when possible.