Best practices

The agent does its best work when you set it up well and ask well. None of this is required — it's the difference between a good result and a great one.

Give it context up front

The single biggest lever is rules. An AGENTS.md in your project that states the stack, conventions, and commands turns guesswork into precision. If you find yourself correcting the agent the same way twice, that correction belongs in AGENTS.md.

Point it at the right folder, too — the agent works in your current directory, so cd into the project (or pass --cwd) before you start.

Ask for outcomes, not keystrokes

Describe the goal and the constraints, and let the agent choose the steps:

Good: "Add a /health endpoint that returns { status: 'ok' }, and a test for it. Use the existing route style in src/routes/."
Less good: "Open src/routes/index.ts, go to line 40, add a function…"

Include what "done" looks like — the test that should pass, the behavior you expect — so the agent can check its own work.

Plan before big changes

For anything substantial, ask for the plan first. In the terminal UI, /plan <goal> produces a plan-only response you can review before the agent touches anything. It's cheaper to correct a plan than a diff.

Work in small steps

A focused request beats a sprawling one. "Refactor this one module and keep its tests green" gives the agent a tight loop it can verify. Chain small wins rather than asking for a rewrite in one shot — and commit as you go, so you always have a clean point to return to.

Let it verify its work

The agent is most reliable when it can run your tests and read the output. Make sure it knows the commands (put them in AGENTS.md), and ask it to run them: "make the change, then run npm test and fix anything that breaks."

Match the model to the task

Most work runs well on poolot-standard. Reach for poolot-pro when a task genuinely needs stronger reasoning, poolot-mini for light or high-volume work, and poolot-vision when the input includes images. See model tiers.

Use read-only mode when you just want answers

A headless lily run works in a read-only profile — perfect for "explain this", "where is X handled", or a review in a script, with no risk of changes. Reach for the interactive UI when you want the agent to make edits.

Keep memory and rules in their lanes

Put things that should always hold — standards, commands, conventions — in rules.
Let memory handle the incidental facts the agent picks up as it works.

Don't rely on memory for something a rule should guarantee.