agentleFS
warpdotdevwarpdotdev/common-skills/.agents/skills/fix-errors/SKILL.md

fix-errors

Skill630 starsChanged 22 days agoMITView on GitHub

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.

11 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use add-policy, auto-perf-optimize and 8 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • OpenCortexIDESkill

    add-policy

    Use when adding, modifying, or reviewing VS Code configuration policies. Covers the full policy lifecycle from registration to export to platform-specific artifacts. Run on ANY change that adds a `policy:` field to a configuration property.

    Also in 4 projects that use this

  • MicrosoftSkill

    auto-perf-optimize

    Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.

    Also in 4 projects that use this

  • MicrosoftSkill

    chat-customizations-editor

    Use when working on the Chat Customizations editor — the management UI for agents, skills, instructions, hooks, prompts, MCP servers, and plugins.

    Also in 4 projects that use this

  • +7 more from microsoft

The file

Show its rules and text

We split this skill into the rules it gives an agent

21 rules. 0 are common, 12 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run the full presubmit only when the user, task, or approved spec explicitly requires it:

    line 23
  2. Distinctive:

    Run checks separately when debugging specific issues:

    line 33
  3. Very specific:

    Remove unused use statements identified by the compiler.

    line 91
  4. Distinctive:

    Remove constants that are defined but never used.

    line 94
  5. Very specific:

    Add the correct use statement for undefined types.

    line 97
  6. Distinctive:

    Update function calls to pass arguments of the correct type.

    line 100
  7. Very specific:

    Use .as_str() instead of .clone() when a &str is expected

    line 101
  8. Very specific:

    Use &value when a reference is needed

    line 102
  9. Very specific:

    Use .to_string() when String is expected but &str is provided

    line 103
  10. Distinctive:

    When a struct adds/removes fields, update all places where it's constructed or destructured:

    line 106
  11. Distinctive:

    When a function adds a new parameter, update all call sites to provide the new argument:

    line 112
  12. Very specific:

    When adding a new enum variant, update exhaustive match statements:

    line 117
  13. Distinctive:

    Add a new match arm with appropriate handling

    line 118
  14. Distinctive:

    Read the full error message to understand the root cause

    line 165
  15. Distinctive:

    Check if multiple errors are related (fixing one may resolve others)

    line 166
  16. Very specific:

    Run the smallest applicable cargo check when it helps resolve compiler errors.

    line 172
  17. Very specific:

    Run the relevant cargo nextest tests and fix the code until they pass

    line 177
  18. Distinctive:

    Run the applicable Clippy invocation and fix its findings.

    line 178
  19. Very specific:

    Run ./script/format once after all other code changes are complete

    line 179
  20. Distinctive:

    Do not rerun tests or Clippy after formatting, and do not add a full presubmit run, unless explicitly required

    line 180
  21. Distinctive:

    If you only fixed a formatting failure and made no behavioral code change, rerun only the formatter

    line 181

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “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

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 &str is expected
  • Use &value when a reference is needed
  • Use .to_string() when String is expected but &str is 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 bool params: pass true or false based on context
  • For Option<T> params: pass None as default or Some(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_fs is 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 check when 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 nextest tests 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/format once 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

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.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.