principle-make-operations-idempotent
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.
Install
npx skills add https://github.com/michael-denyer/pstack-claude/tree/main/plugins/pstack/skills/principle-make-operations-idempotent
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install michael-denyer-pstack-claude@llmmart
git clone https://github.com/michael-denyer/pstack-claude.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole michael-denyer/pstack-claude collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
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:
- What happens if this runs twice in a row?
- What happens if the previous run crashed at every possible point?
- 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.
Files (pstack-claude)
-
SKILL.md 1.3 KB
--- name: principle-make-operations-idempotent description: "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." user-invocable: false --- # 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.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.