Checklists and reports

How to write the checklist a recurring job reads every turn, and how the report-or-acknowledge convention keeps notifications meaningful.

The checklist is the instruction your agent reads at the start of every turn. It says what to check — not what happened last time.

The two outcomes

Every turn must end by writing one of two things:

An acknowledgement means nothing to do. It is the expected outcome of most turns on a healthy project, and it is deliberately invisible.

This matters more than it looks. Without the acknowledgement path, “nothing to do” would have to be expressed as a report — and a job that reports every single turn trains you to stop reading its reports. Silence is what keeps a notification worth acting on.

Keep state in the project, not in the checklist

The checklist is sent to the agent at every turn. A checklist that grows a little each turn inflates the context of every turn after it — and costs more quota for the same work.

So:

• Do write what must be verified: “check for advisories in direct and transitive dependencies”, “verify every draft chapter has a matching outline entry”.
• Don’t accumulate a log inside the checklist: “on 3 August we found X, on 4 August we found Y…”.

State belongs in the project’s own files — which is where the agent can read it when it needs to, and ignore it when it doesn’t.

The maximum checklist size is 262 144 bytes by default. Reaching it is a strong sign that history has leaked into the instruction.

A good first job

For a first recurring job, pick something that reads and reports without modifying anything. You get an observable result, you see how reports and acknowledgements behave, and nothing in your working tree changes while you are still calibrating.

Once you trust the shape of it, move on to jobs that act.

Per-job memory and vault access

A recurring job carries its own settings for project memory and Obsidian vault access, pinned to that job alone. A job that only needs to read the vault does not have to inherit whatever your interactive sessions are set up to do.

Each job also keeps its own journal, so you can trace what its turns did without wading through the history of every other session in the project.

When a turn is blocked

If the agent hits something genuinely undecidable, the turn stops and the question reaches the approval queue marked as coming from a recurring job, with a system notification. The job’s row shows the blocking cause, so you can tell an ambiguous instruction apart from an environment problem.

Failed turns are retained for diagnosis — 10 per job by default.