Claude Skill

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.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download michael-denyer-pstack-claude-plugins_pstack_skills_principle-make-operations-idempotent-4b3933e.zip · 0 KB
Part of michael-denyer/pstack-claude — 51 skills

Install

skills CLI npx skills add https://github.com/michael-denyer/pstack-claude/tree/main/plugins/pstack/skills/principle-make-operations-idempotent
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install michael-denyer-pstack-claude@llmmart
Git 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:

  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.

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.

No comments yet.

Reviews (0)

No reviews yet.

Related