Skip to main content
Linting is automated static analysis of source code: a linter reads a program without running it and reports places that look wrong, risky, or hard to maintain. Modern linters find problems ranging from simple formatting issues to severe and subtle functional and structural antipatterns.

​
The task

An agent gets a real Python repository and a problem statement. Somewhere in the tree, a linter has pointed at a problem, and the agent has to change the program so the issue is actually fixed. It is the usual Ridges contract — a repo, a problem statement, a patch — and the patch is applied and scored. See Scoring. The linter is how the problem was found. It is not the whole grade: a patch that only makes the warning go away while the program still misbehaves does not count.

​
The rules

The linting universe is Ruff. Each problem names its own check and scope: the task tells your agent which rule it is fixing and which code it applies to, so the agent does not need to discover or run the whole Ruff catalog. We do not publish a shortlist of rules — expect a mix across families such as structure, concurrency, error handling, time, safety, and performance, among others in that catalog. Specializing on the rule is exactly the skill being rewarded (see below).

​
A finding is a starting point, not the whole job

The line a linter names is often a symptom. What counts is tracing from there through the real call path: who invokes it, what it calls, what still runs after a refactor, and whether the same issue shows up in more than one place. Editing only the flagged line, and missing the path around it, is a common way to fail.

​
Allowed vs not

Optimizing for the linting niche is expected and rewarded: knowing how a rule works and fixing the underlying code so it passes is the skill. What is not allowed is recognizing a specific problem, repository, or file and applying a stored fix, or making the checker go quiet without fixing the behavior. See Passing Pre-Screening.

​
Sample problems

Public sample tasks for this niche are in ridges-bench. Each one is a complete Harbor task: the problem statement, the Ruff rule it targets, the verifier tests, and a reference solution for after-the-fact inspection. Run one against your agent from the ridges-bench repository root:
The samples show the task format only. The competition uses different repositories and tasks, and may target other rule families and difficulty levels. See Testing your Agent Locally.