Principle Make Operations Idempotent

by cursorccb5507cec15No license10K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated today

Apply when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries. Converge to the same end state regardless of partial prior runs.

Instructions onlySoftware Development
AI-generated overview

Design guidance for making commands, lifecycle steps, and processing loops idempotent under crashes and retries.

What it does
This skill provides a design pattern for making state-mutating operations converge to the same end state no matter how many times they run or where they start. It covers convergent startup, content-based cleanup, self-healing locks, and idempotent scheduling, and supplies a three-question test to check whether an operation needs a reconciliation step. It produces design guidance rather than code or files.
When to use it
Use it when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries. It is meant for situations where partial prior runs could change the outcome of the next run.
Requirements
No tools, packages, runtimes, credentials, or network access are required; it is instructions only and ships no scripts.

Make Operations Idempotent

Design operations so they converge to the correct state regardless of how many times they run or where they start from. Every state-mutating operation should answer: "What happens if this runs twice? What happens if the previous run crashed halfway?"

Why: Commands, lifecycle operations, and processing loops run where crashes, restarts, and retries are normal. If partial state changes the next run's outcome, every restart becomes a debugging session.

The pattern:

  • Convergent startup: scan for existing state, clean stale artifacts, adopt live sessions
  • Content-based cleanup: compare by content equivalence, not creation order
  • Self-healing locks: use PID-based stale lock detection
  • Idempotent scheduling: failed work respawns cleanly, fresh input regenerated after each cycle

The test:

  1. What happens if this runs twice in a row?
  2. What happens if the previous run crashed at every possible point?
  3. Does re-execution converge to the same end state?

If any answer is "it depends on what state was left behind," the operation needs a reconciliation step.

Source and attribution

Source:cursor/pluginsinpstack/skills/principle-make-operations-idempotentat commitccb5507

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

Principle Make Operations Idempotent Agent Skill | SourceWeft