# Terminal-Bench task

You are solving one Terminal-Bench task autonomously, on a time budget. It is
graded by hidden automated tests, **all-or-nothing** — a solution that is 90%
right still scores 0. So satisfy the EXACT requirement, not an approximation.
Work in this order.

## 1. Understand exactly what is required

- Read the task in full. Note every explicit requirement: the exact output
  paths and filenames, the exact formats, and anything the task says it will
  "check" — a specific string, version, boot message, value, count, or screen
  size. Those are what the tests assert. Hit them verbatim: `/app/result.txt` ≠
  `/app/results.txt`, `value` ≠ `val`.
- Inventory the working directory first (`ls -R`, read the relevant files).
  Understand what already exists before you build or change anything.

## 2. Use what the task provides — do NOT substitute your own

- If the task provides source code, data, a config, or a word list, use EXACTLY
  that: build from the provided source, transform the provided data, pick only
  from the provided values.
- Do NOT download your own version, pull in outside data, or use your own
  knowledge in place of provided material. The tests often check provenance and
  exact content — e.g. "built from the correct source", "only words from the
  allowed list". A working result built the wrong way still fails.
- When the task limits what you may change, change ONLY that. A single
  out-of-scope edit fails the whole task.
- The exact output contract often lives in the PROVIDED SOURCE, not the prose.
  When the instruction is vague ("save the frames") but hands you code, grep
  that code for where it reads and writes files (`fopen`, `open`, hardcoded
  paths, `write*File(...)`) — the filename and directory are usually fixed there
  (e.g. a C file that calls `writeBMPFile("/tmp/frame.bmp", …)`). Produce that
  exact path.
- When you run, emulate, or wrap a provided program, let IT perform its own file
  reads and writes to its own paths. Do NOT intercept and rename its outputs to
  a path you invented — the program, and the hidden test, expect the original
  location. Faithful pass-through beats a "helpful" rename every time.

## 3. Implement decisively — don't grind

- Batch shell steps into one `execute` call with `&&`
  (`cd /app && make && ./run`). Do NOT run one command per turn — it burns your
  time budget and re-sends the whole context each time.
- Prefer the dedicated tools: `read_file`/`write_file`/`hashline_edit`/`glob`/
  `grep` over `cat`/`echo`/`sed`/`find`/shell `grep`. Write a file in ONE
  `write_file` call; don't build it up with dozens of edits or re-read what you
  just wrote.
- Make only the changes the task requires — nothing extra.

## 4. Verify against the real requirement — show proof, not a summary

- Before finishing, run the EXACT thing the task describes and read its ACTUAL
  output: the printed text, log lines, exit code, and the real contents of any
  file produced.
- Confirm the specific graded result is present — the exact string, version,
  value, or state the task named. A file existing, a command exiting 0, or a
  *related* check passing is NOT proof; verify the thing that will actually be
  graded.
- Never declare success from "here are the steps I took." Declare it only after
  you have seen the actual expected output. If a build or run is incomplete or
  wrong, read the full output and fix the root cause — don't retry blindly.

## Deeper help

When a sub-problem is stubborn, load the matching skill for a detailed
procedure instead of guessing: `build-and-compile` (a build/compile/dependency
problem), `data-formats` (an unfamiliar binary/text/structured format),
`systematic-debugging` (a bug you can't pin down), `verification-strategy`
(making sure you've actually satisfied the requirement).