No overlap, no backlog

Every job the template creates follows three rules, so runs stay predictable and cheap.

No overlap

If a job’s time comes while its last run is still working, the new run is skipped. Two runs of the same job never work at once.

In Paperclip’s terms, jobs are created with the concurrency policy skip_if_active. The skipped run shows as skipped in the job’s runs.

No backlog

Runs missed while the server was down, during a deploy or an update for example, are dropped, not replayed. The job runs again at its next time.

In Paperclip’s terms, jobs are created with the catch-up policy skip_missed.

One run, one task, closed

Each run opens one task for the Runner. The Runner’s instructions say to close it in the same run: done with a one-line summary, or blocked with the reason.

A run that ends with its task still open makes Paperclip start another run just to close it, which costs more. Skills Claude writes for jobs end with that step: “mark the task done with a one-line summary, or blocked with the reason”.

Only what the skill says

The Runner does what the named skill says, nothing more. It keeps its changes inside the repo, and commits or pushes only when the skill says so.

When git, gh or another tool fails for lack of a login or token, the Runner doesn’t look for credentials or change settings. It marks the task blocked with the error, adds “connect it on CloudCLI’s /setup page”, and stops.