How do I install the Run Tests skill?

Run npx skillmds@latest add coralogix/run-tests in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Run Tests safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Run Tests?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Run Tests free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Run Tests?

coralogix (@coralogix) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Run Tests by coralogix — Agent Skill

Name: Run Tests
Rating: 4.2 (5 reviews)
Author: coralogix

Run Tests

Use this skill when the user asks to "run tests", "test this", "check if tests pass", "cargo test", "run clippy", "lint this", "check formatting", "cargo fmt", "CI checks", "verify changes", "does this pass tests", "run the full check", "pre-commit check", or wants to verify that code changes are correct. Use this even when the user says something like "make sure this works" or "check for issues" in the context of code changes.

coralogix 7a3b7dd 3.3 KB Updated Sep 10, 2026

File contents

Run Tests & Verify

How to run tests, lint, and verify changes in the cx CLI. This skill covers running only - for writing new tests, see the add-command skill.

Quick Reference

Command	What it does
`cargo test`	Run all unit + integration tests
`cargo test <name>`	Run tests matching a name substring
`cargo test -- --ignored`	Run integration tests (filesystem-dependent, skipped by default)
`cargo fmt --check`	Check formatting (no changes)
`cargo fmt`	Auto-fix formatting
`cargo clippy --locked -- -D warnings`	Lint with warnings-as-errors
`cargo build`	Verify compilation

Full CI Check

This is the exact sequence CI runs on every PR. Run it before committing or creating a PR:

cargo fmt --check && cargo clippy --locked -- -D warnings && cargo test --locked

The --locked flag ensures the lockfile is respected - this matches .github/workflows/test.yml and lint.yml exactly. CI runs tests on Ubuntu, macOS, and Windows.

What to Run After a Change

Pick the right level of verification based on what changed:

Any .rs file - cargo test + cargo clippy --locked -- -D warnings
Formatting only - cargo fmt --check (or cargo fmt to auto-fix)
Cargo.toml - full CI check (dependency changes affect everything)
API types (src/commands/<cmd>/api.rs) - run that command's tests first (cargo test alerts, cargo test dataprime), then the full suite
Test files only - cargo test <relevant_test_name>

Running Specific Tests

Target tests efficiently instead of running the entire suite:

cargo test alerts - all tests with "alerts" in the name
cargo test --test dataprime - only the tests/dataprime/ integration test binary (input + output + query)
cargo test --test dataprime input - only the input submodule of that binary
cargo test config::tests - only the tests in the config module
cargo test metrics::tests - only metrics formatting tests

Interpreting Failures

Clippy warnings - treated as errors via -D warnings. Fix every warning before committing. Common ones: unused variables, unnecessary clones, missing error handling.

Format failures - run cargo fmt to auto-fix. These never need manual intervention.

Deserialization test failures - usually means struct field names don't match JSON keys. Check that #[serde(rename_all = "camelCase")] is on response types and that #[serde(default)] is on Vec fields (the API sometimes omits empty arrays).

Compilation errors in tests - likely caused by changing a public function signature. Check callers in both src/ and tests/ directories.

Integration test failures (--ignored) - these depend on filesystem state (~/.cx/ config directory). They may fail if the local environment isn't set up. This is expected in CI where no config exists.

---name: run-testsdescription: Use this skill when the user asks to "run tests", "test this", "check if tests pass", "cargo test", "run clippy", "lint this", "check formatting", "cargo fmt", "CI checks", "verify changes", "does this pass tests", "run the full check", "pre-commit check", or wants to verify that code changes are correct. Use this even when the user says something like "make sure this works" or "check for issues" in the context of code changes.---# Run Tests & VerifyHow to run tests, lint, and verify changes in the `cx` CLI. This skill covers running only - for writing new tests, see the `add-command` skill.## Quick Reference| Command | What it does ||---------|-------------|| `cargo test` | Run all unit + integration tests || `cargo test <name>` | Run tests matching a name substring || `cargo test -- --ignored` | Run integration tests (filesystem-dependent, skipped by default) || `cargo fmt --check` | Check formatting (no changes) || `cargo fmt` | Auto-fix formatting || `cargo clippy --locked -- -D warnings` | Lint with warnings-as-errors || `cargo build` | Verify compilation |## Full CI CheckThis is the exact sequence CI runs on every PR. Run it before committing or creating a PR:```bashcargo fmt --check && cargo clippy --locked -- -D warnings && cargo test --locked```The `--locked` flag ensures the lockfile is respected - this matches `.github/workflows/test.yml` and `lint.yml` exactly. CI runs tests on Ubuntu, macOS, and Windows.## What to Run After a ChangePick the right level of verification based on what changed:- **Any `.rs` file** - `cargo test` + `cargo clippy --locked -- -D warnings`- **Formatting only** - `cargo fmt --check` (or `cargo fmt` to auto-fix)- **`Cargo.toml`** - full CI check (dependency changes affect everything)- **API types (`src/commands/<cmd>/api.rs`)** - run that command's tests first (`cargo test alerts`, `cargo test dataprime`), then the full suite- **Test files only** - `cargo test <relevant_test_name>`## Running Specific TestsTarget tests efficiently instead of running the entire suite:- `cargo test alerts` - all tests with "alerts" in the name- `cargo test --test dataprime` - only the `tests/dataprime/` integration test binary (input + output + query)- `cargo test --test dataprime input` - only the `input` submodule of that binary- `cargo test config::tests` - only the tests in the `config` module- `cargo test metrics::tests` - only metrics formatting tests## Interpreting Failures**Clippy warnings** - treated as errors via `-D warnings`. Fix every warning before committing. Common ones: unused variables, unnecessary clones, missing error handling.**Format failures** - run `cargo fmt` to auto-fix. These never need manual intervention.**Deserialization test failures** - usually means struct field names don't match JSON keys. Check that `#[serde(rename_all = "camelCase")]` is on response types and that `#[serde(default)]` is on `Vec` fields (the API sometimes omits empty arrays).**Compilation errors in tests** - likely caused by changing a public function signature. Check callers in both `src/` and `tests/` directories.**Integration test failures (`--ignored`)** - these depend on filesystem state (`~/.cx/` config directory). They may fail if the local environment isn't set up. This is expected in CI where no config exists.

Frequently asked questions