home / skills / redisearch / redisearch / lint

lint skill

safe

/.skills/lint

This skill checks code quality and formatting before committing, guiding you to fix lint, clippy, and license issues.

npx playbooks add skill redisearch/redisearch --skill lint

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

955 B

---
name: lint
description: Check code quality and formatting before committing changes
---

# Lint Skill

Check code quality and formatting before committing changes.

## Usage
Run this skill to check for lint errors and formatting issues.

## Instructions

1. Run the lint check:
   ```bash
   make lint
   ```

2. If clippy reports warnings or errors, fix them before proceeding

3. Check formatting:
   ```bash
   make fmt CHECK=1
   ```

4. If formatting check fails, apply formatting:
   ```bash
   make fmt
   ```

5. If license headers are missing, add them:
   ```bash
   cd src/redisearch_rs && cargo license-fix
   ```

## Common Clippy Fixes

- **Document unsafe blocks**: Add `// SAFETY:` comment explaining why the unsafe code is sound
- **Use `#[expect(...)]`**: Prefer over `#[allow(...)]` for lint suppressions

## Rust-Specific Checks

For Rust-only linting:
```bash
cd src/redisearch_rs && cargo clippy --all-targets --all-features
```

Overview

This skill runs a pre-commit lint and formatting pipeline to catch code-quality issues before changes are committed. It targets the repository’s C codebase and included Rust components, ensuring consistent style, documented unsafe blocks, and license header presence. Use it to prevent regressions, maintain readability, and enforce contributor guidelines.

How this skill works

The skill executes the project’s lint targets and formatting checks, reporting compiler and linter warnings as well as formatting mismatches. For the Rust sub-crate it runs clippy across targets and features and can auto-fix license header problems. It returns actionable failures and suggests commands to fix issues locally.

When to use it

Before committing or opening a pull request to ensure no lint or formatting regressions.
After merging upstream changes to revalidate formatting and lints across the codebase.
During CI runs to gate commits or PRs with automated quality checks.
When preparing a release to ensure consistent headers, formatting, and lint-free code.

Best practices

Run the lint target locally first and fix all reported warnings and errors before committing.
Run the formatting check and apply automatic formatting when it fails, then re-run tests.
Document all unsafe blocks with a clear `SAFETY` explanation to satisfy linter requirements.
Prefer targeted linter expectations (e.g., expect annotations) rather than broad allows.
Keep license headers up to date; use the repository tooling to add missing headers in subprojects.

Example use cases

Developer runs the lint pipeline before opening a pull request to avoid CI failures.
Maintainer enforces a pre-merge check in CI to reject PRs with formatting diffs or clippy warnings.
Contributor fixes a code-review comment requiring clearer justification for an unsafe block.
Release engineer verifies that all files have license headers and consistent formatting before tagging.

FAQ

What commands should I run locally to reproduce checks?

Run the repository lint target and then the format checker; for the Rust crate run clippy across all targets and features and use the provided license-fix tool if headers are missing.

How do I handle linter warnings in Rust's unsafe blocks?

Add a concise `SAFETY:` comment explaining why the unsafe code is sound and adjust annotations to use expect-style suppressions when appropriate.