mcpField
P
principle-make-operations-idempotent

principle-make-operations-idempotent

github.com/q-qp-pDevelopment146 installsUpdated 2w ago
Repository

About principle-make-operations-idempotent

principle-make-operations-idempotent is a guidance skill for designing commands, lifecycle operations, and processing loops that can be safely retried. It emphasizes reconciling actual state with the goal so repeated runs converge consistently.

Key features

  1. 01Design for safe repeated execution
  2. 02Reconcile current state with the goal
  3. 03Account for crashes at each step
  4. 04Detect stale artifacts from prior runs

Use cases

  1. 01Making a command safe to rerun after failure
  2. 02Designing restartable lifecycle operations
  3. 03Checking whether partial writes need reconciliation

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/q-qp-p/pstack --skill principle-make-operations-idempotent

After installing, type/principle-make-operations-idempotentin Claude Code to confirm it loaded.

Details

From the project README

Make Operations Idempotent

Design operations so they converge to the correct state regardless of how many times they run or where the previous run stopped. 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 idea: derive each step from the state that exists, not from what the previous run meant to do. Read the current state, compare it to the goal, and apply only the difference. A step written this way is safe to repeat, because a repeat finds nothing left to do.

Anything a run leaves behind, such as a lock, a temporary file, a half-written record, or a claimed job, must be recognizable as stale by the next run. Judge staleness by evidence that stays true wherever the previous run could have stopped, not only in the common case. A marker that the next run cannot judge turns every crash into manual cleanup. For example, write to a temporary path and rename it into place, or compare artifacts by content instead of by creation order.

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.

Comments

Markdown supported