
fix-errors
Fix compilation errors, linting issues, and test failures in the warp Rust codebase. Covers presubmit checks, WASM-specific errors, and running specific tests. Use when the user hits build errors, clippy or fmt failures, test failures, or needs to run or interpret presubmit before a PR.
- Installs
- 28.5K
- Last 24h
- +27
- Trending rank
- #4615
- Security
- Pass
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/warpdotdev/common-skills --skill fix-errors- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads fix-errors automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
Security audits
Independent scans of the skill's instructions and bundled files.
SKILL.md
The instructions your agent reads when the skill is triggered.
fix-errors
Fix compilation errors, linting issues, and test failures in the warp Rust codebase.
Overview
This skill helps resolve common issues encountered during development, including:
- Compilation errors (unused imports, type mismatches, etc.)
- Linting failures (clippy warnings)
- Formatting violations
- WASM-specific errors
- Test failures
Fix the reported failure with the narrowest useful command. Do not turn a targeted repair into repeated full-workspace validation.
Full Presubmit
Run the full presubmit only when the user, task, or approved spec explicitly requires it:
./script/presubmit
This runs formatting checks, linting, and all tests. It is intentionally broader and more expensive than the default implementation workflow.
Individual Checks
Run checks separately when debugging specific issues:
Rust formatting:
cargo fmt -- --check
Clippy (full workspace):
cargo clippy --workspace --all-targets --tests -- -D warnings
WASM Clippy:
cargo clippy --target wasm32-unknown-unknown --profile release-wasm-debug_assertions --no-deps
Objective-C/C/C++ formatting:
./script/run-clang-format.py -r --extensions 'c,h,cpp,m' ./crates/warpui/src/ ./app/src/
All tests:
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo nextest run -p warp_completer --features v2
Doc tests:
cargo test --doc
Running Specific Tests
Single package:
cargo nextest run -p <package_name>
Filter by test name:
cargo nextest run -E 'test(<substring>)'
Specific package with filter:
cargo nextest run -p <package_name> -E 'test(<substring>)'
With output (no capture):
cargo nextest run -p <package> --nocapture
Common Error Types
Unused Imports
Remove unused use statements identified by the compiler.
Unused Constants
Remove constants that are defined but never used.
Unknown Imports
Add the correct use statement for undefined types. Search the codebase to find the correct module path.
Type Mismatches
Update function calls to pass arguments of the correct type. Common fixes:
- Use
.as_str()instead of.clone()when a&stris expected - Use
&valuewhen a reference is needed - Use
.to_string()whenStringis expected but&stris provided
Struct Field Changes
When a struct adds/removes fields, update all places where it's constructed or destructured:
- Struct initialization
- Pattern matching (
match,if let) - Destructuring assignments
Function Signature Changes
When a function adds a new parameter, update all call sites to provide the new argument:
- For
boolparams: passtrueorfalsebased on context - For
Option<T>params: passNoneas default orSome(value)if needed
Enum Variant Changes
When adding a new enum variant, update exhaustive match statements:
- Add a new match arm with appropriate handling
- Mirror the implementation pattern of similar variants
Incorrect Trait Implementation
Fix trait implementations that return the wrong type or don't satisfy trait bounds.
WASM-Specific Errors
WASM builds (wasm32-unknown-unknown target) don't support filesystem operations. Code that uses filesystem APIs must be gated behind the local_fs feature flag.
Common WASM errors:
- Dead code warnings for code only used in non-WASM builds
- Unused code that's only relevant when
local_fsis available - Tests that require filesystem access
Fixes:
Gate tests behind local_fs:
#[test]
#[cfg(feature = "local_fs")]
fn test_find_git_repo_with_worktree() {
// Test that uses filesystem operations
}
Conditionally allow dead code for types only used when local_fs is enabled:
#[cfg_attr(not(feature = "local_fs"), allow(dead_code))]
#[derive(Clone, EnumDiscriminants, Serialize)]
pub enum ExampleType {
// Variants only used when local_fs is enabled
Variant1,
Variant2,
Variant3,
}
WASM errors are discovered by running:
cargo clippy --target wasm32-unknown-unknown --profile release-wasm-debug_assertions --no-deps
Best Practices
Before fixing:
- Read the full error message to understand the root cause
- Check if multiple errors are related (fixing one may resolve others)
- For trait/type errors, verify you understand the expected vs actual types
- For WASM errors, check if code needs to be gated behind
local_fs
When fixing:
- Fix one error type at a time when there are multiple issues
- Run the smallest applicable
cargo checkwhen it helps resolve compiler errors; do not repeat broad checks without a relevant code change - For WASM errors, run WASM clippy to verify the fix
- For complex changes, run relevant tests after fixing
After fixing:
- Run the relevant
cargo nextesttests and fix the code until they pass - Run the applicable Clippy invocation and fix its findings; return to affected tests only when a fix materially changes behavior
- Run
./script/formatonce after all other code changes are complete - Do not rerun tests or Clippy after formatting, and do not add a full presubmit run, unless explicitly required
- If you only fixed a formatting failure and made no behavioral code change, rerun only the formatter
FAQ
What does the fix-errors skill do?
Fix compilation errors, linting issues, and test failures in the warp Rust codebase. Covers presubmit checks, WASM-specific errors, and running specific tests. Use when the user hits build errors, clippy or fmt failures, test failures, or needs to run or interpret presubmit before a PR.
How do I install fix-errors?
Run npx skills add https://github.com/warpdotdev/common-skills --skill fix-errors in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/fix-errors/ (personal) or .claude/skills/fix-errors/ (project).
Which AI agents can use fix-errors?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is fix-errors safe to install?
Security partners have reviewed it: Gen Agent Trust Hub passed; Socket passed; Snyk passed. As with any skill, read the SKILL.md and bundled scripts before installing.
Who maintains fix-errors?
It is published by warpdotdev in warpdotdev/common-skills. It has 28,544 recorded installs.
More from warpdotdev/common-skills
review-pr
warpdotdev/common-skills
Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like prdiff.txt and prdescription.txt and producing machine-readable review output instead of posting directly to GitHub.
spec-driven-implementation
warpdotdev/common-skills
Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves. Use when starting a significant feature, planning agent-driven implementation, or when the user wants product and tech specs checked into source control.
write-product-spec
warpdotdev/common-skills
Write a PRODUCT.md spec for a significant user-facing feature in Warp, focused on detailed behavior and validation. Use when the user asks for a product spec, desired behavior doc, or PRD, wants to define feature behavior before implementation, or when the feature is substantial or behaviorally ambiguous enough that a written spec would improve implementation or review.
write-tech-spec
warpdotdev/common-skills
Write a TECH.md spec for a significant Warp feature after researching the current codebase and implementation constraints. Use when the user asks for a technical spec, implementation plan, or architecture doc tied to a product spec.
resolve-merge-conflicts
warpdotdev/common-skills
Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context. Use when a merge, rebase, cherry-pick, or stash pop stops on conflicts, when git status shows unmerged paths, or when files contain conflict markers.
implement-specs
warpdotdev/common-skills
Implement an approved feature from PRODUCT.md and TECH.md, keeping specs and code aligned in the same PR as implementation evolves. Use after the product and tech specs are approved and the next step is building the feature.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work