fix-build-errors
Use when a build, compilation, or type-check fails — diagnose the error, identify root cause, and apply the minimal fix to get green
Best use case
fix-build-errors is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when a build, compilation, or type-check fails — diagnose the error, identify root cause, and apply the minimal fix to get green
Teams using fix-build-errors should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/fix-build-errors/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How fix-build-errors Compares
| Feature / Agent | fix-build-errors | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when a build, compilation, or type-check fails — diagnose the error, identify root cause, and apply the minimal fix to get green
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Fix Build Errors ## When to Use - Build or compilation fails after code changes - CI pipeline reports build failures - TypeScript, ESLint, or other static analysis errors - Dependency resolution failures after package updates - Build works locally but fails in CI (or vice versa) ## Prerequisites - Access to the build command and its output - The project's build toolchain is installed - Source control so you can compare against a known-good state ## Workflow ### 1. Capture the Full Error Output ```powershell # Run the build and capture output — use task agent to keep context clean npm run build 2>&1 | Out-String ``` Or use the `task` agent for long builds: ```text task agent_type: "task" prompt: "Run 'npm run build' and report all errors" ``` ### 2. Categorize the Errors Read errors from **top to bottom** — later errors are often caused by earlier ones. | Error Type | Example | Typical Fix | |-----------|---------|-------------| | **Import/Module** | `Cannot find module 'x'` | Install dependency, fix path | | **Type** | `Type 'string' not assignable to 'number'` | Fix type annotation or cast | | **Syntax** | `Unexpected token` | Fix syntax error, check for missing brackets | | **Lint** | `no-unused-vars` | Remove unused variable or disable rule | | **Config** | `Invalid tsconfig option` | Fix config file | | **Dependency** | `Peer dependency not met` | Install or update package | ### 3. Fix the Root Cause (Not Symptoms) ```powershell # Find the first error — it's usually the root cause npm run build 2>&1 | Select-String "error" | Select-Object -First 5 # Navigate to the file and line # Use view tool to see context around the error ``` For import errors: ```powershell # Check if the module exists glob pattern="**/*moduleName*" # Check if it's installed npm ls module-name 2>&1 ``` For type errors: ```powershell # See the full type definition grep -rn "interface|type" --include="*.ts" -A 5 src/ | Select-String "TypeName" ``` ### 4. Apply the Fix Use `edit` for surgical changes to specific lines: ```text edit path: "src/broken-file.ts" old_str: "const x: string = 42;" new_str: "const x: number = 42;" ``` ### 5. Verify the Fix ```powershell # Rebuild — should succeed now npm run build 2>&1 | Select-Object -Last 10 # Run tests to ensure the fix didn't break behavior npm test 2>&1 | Select-Object -Last 10 ``` ### 6. Handle Cascading Errors If fixing one error reveals more: 1. Rebuild after each fix 2. Address new errors from top to bottom 3. If the error count isn't decreasing, you may be fixing symptoms — step back and find the root cause ## Examples ### Missing Dependency ```powershell # Error: Cannot find module 'lodash' npm install lodash npm install --save-dev @types/lodash # for TypeScript npm run build ``` ### TypeScript Strict Mode Errors After Upgrade ```powershell # Find all strictNullChecks errors npx tsc --noEmit 2>&1 | Select-String "possibly 'null'" | Measure-Object -Line # Fix them one file at a time, starting with leaf modules (no imports from your code) npx tsc --noEmit 2>&1 | Select-String "possibly 'null'" | Select-Object -First 3 ``` ### CI vs Local Mismatch ```powershell # Check Node/npm version differences node --version npm --version # Check for OS-specific path issues grep -rn "\\\\" src/ --include="*.ts" # Windows backslashes in code # Check for missing environment variables grep -rn "process.env" src/ --include="*.ts" | Select-String -NotMatch "NODE_ENV" ``` ## Tips - **Fix the first error first** — many later errors are caused by earlier ones - Use `task` agent to run builds — it returns brief output on success, full output on failure - After fixing, always run the full test suite, not just the build - If a dependency update caused the break, check its changelog for breaking changes - For persistent issues, compare against the last known-good commit: ```powershell git --no-pager log --oneline -10 git --no-pager diff <last-good-commit> -- src/ ``` - Keep `tsconfig.json` / build configs in source control so you can diff changes
Related Skills
verification-before-completion
Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.
using-git-worktrees
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
triage
Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.
to-issues
Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice
sprint-workflow
Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.
sprint-retro
Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.
security-audit
Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.
release
Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.
prompt-optimizer
Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.
outside-voice
Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice
llm-wiki
Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance
interview-me
Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.