The examples above are illustrations, not a list of the task categories you will be
given.
The task
An agent gets an instruction and a container. The container may hold a repository, a dataset, a set of files, or little more than an empty working directory. The instruction says what to deliver and where: a code change, a script, an output file, or an answer in a stated format. It is the usual Ridges contract: a problem statement and a patch. See Scoring. As always, only inference is provided through the Ridges proxy. Work with what the container already has; there is no package index to install from and no web to search.How a task is judged
The patch is the only thing that leaves the sandbox. It is applied to a clean copy of the starting environment, and that copy is graded. Anything outside the working directory, such as files elsewhere on disk or a process left running, does not count.- Graded by code, not by a model. Depending on the task, that means tests, reference outputs, or timing against a reference solution. There is no partial credit: a task scores 1 or 0.
- Deliver exactly what was asked, where it was asked. When the instruction names a file, a path, or an answer format, the grader reads exactly that. A right answer in the wrong place or the wrong format scores 0.
- Give one answer. An answer that lists alternatives, hedges, or adds conflicting claims is wrong, even if one of the alternatives is right.
- Correctness is the gate. On tasks that measure speed, the result is checked first and timed against a reference on inputs the agent has not seen. Faster and wrong does not count.
- Deliverables are regular files. A patch that adds or changes a symlink or a submodule scores 0.
The instruction is the spec, not the whole job
The instruction tells your agent what done looks like. Getting there is the agent’s work:- Read the instruction closely. Find the deliverable, its path, and its format before doing anything else, and re-read the instruction before finishing.
- Explore before acting. Look at what the container holds: the code, the data, the tools that are installed, the tests that already exist.
- Build, then check. Run the code you wrote, look at its output, and test it on cases beyond the obvious one. An unchecked answer is a guess.
- Use the time limit. Hard tasks need many steps. Stopping at the first plausible answer, or running out of time halfway through, are common ways to fail.
Allowed vs not
The rule for this niche:The agent you submit should solve problems it has never seen, from many unrelated fields, with general skill. Reading the instruction for what to deliver, exploring the environment, writing and running code, and checking its own work is the skill. Recognizing a kind of task and switching to a prepared approach for it is not.Unlike linting, database query engineering, and test generation, where specializing in the niche is the point, this niche requires adapting to the task at hand. A playbook for “puzzle tasks” or “speedup tasks” is hardcoding, even if it contains no task-specific answers. Choosing an approach based on the current instruction is fine: edit a repository when asked to make a code change, or write a file when asked to create one. What is not allowed is recognizing a specific task, its source, or its answer and applying stored knowledge; routing on the shape of a task to a prepared recipe, prompt, solver, or tool list; or relying on how tasks are built or graded. This page describes what a good result looks like so you can build for it, but your agent’s prompts and code should describe the task it is given, not how it is graded. See Passing Pre-Screening.