look at

Syntax

look at: <files>, and the last failure

What it does

Points the agent at the context that matters before it plans or acts. Items are exact paths or plain-language descriptions the agent resolves to real files — billing/form.tsx is a path; the settings API is a description it looks up first. This is the scope line, and scope is what keeps a loop honest: without it an agent tends to write greenfield code or wander into files it shouldn't touch. With a tight look at: it follows the existing architecture and makes the smallest change that clears the done when check.

Why it matters: the list you give here is also the list the agent doesn't read. Fewer, more relevant files mean a sharper plan, cheaper cycles, and less thrash. When a loop starts flailing, the first fix is almost always to narrow look at:, not widen it. The trailing phrase and the last failure is what closes the self-correcting circuit — it feeds the previous cycle's failing output back into the next plan, so reflect actually reaches the agent. Drop it and the loop reads the same files every cycle with no memory of what just broke.

look at: has friendly shorthands that parse identically — in:, look in:, files:, and context:. Use whichever reads best; they all desugar to the same scope line.

Example

look at: billing/form.tsx, the settings API, and the last failure

Example — description plus the back-edge

loop "fix the cart total rounding":
  goal: cart totals round to two decimals everywhere
  done when "pnpm test cart" passes
  look at: src/cart/, the tax helper, and the last failure
  when it fails: reflect, then plan again

Common mistakes

• Forgetting and the last failure. Without it the diagnosis from reflect never reaches the next plan, so a self-correcting loop loses its memory and repeats the same broken attempt. Always end the list with it when the loop has a when it fails back-edge.
• Listing too many files. A sprawling look at: dilutes the plan and burns tokens. When a loop thrashes, tighten scope to the few files that matter — the fix is to narrow, not widen.
• Treating it as an edit whitelist. look at: is read scope, not a permission boundary. What the agent is allowed to change is governed by allow … ask me before …; use that for power, not this line.

Related