idempotency-keyslisted

# Idempotency Keys (Opus) **Purpose**: Design the idempotency strategy for any state-changing operation — webhook handlers, payment endpoints, workflow steps, message-queue consumers. Decides: where the key comes from, where it's stored, for how long, what happens on collision, how it threads through downstream side effects. **Model**: Opus 4.7 ## When to invoke autonomously Invoke when: 1. **Designing a new endpoint with side effects** (charge, send, create, update). 2. **Hardening an existing endpoint** that's been hit by duplicate-processing bugs. 3. **Workflow step design** where the step calls a non-idempotent external API. 4. **Message queue consumer** that needs to survive replays. 5. **User asks "what's our idempotency strategy for X?"** — produce a concrete spec. **Don't invoke for**: - Read-only operations (no idempotency needed). - Workflows where the engine already guarantees exactly-once (Temporal workflows ARE idempotent by replay; activities still need it). ## Usage ``` /idempotency-keys design for [endpoint or operation] /idempotency-keys audit [path to handler] /idempotency-keys derive key from [payload shape] ``` ## Decision sequence The skill walks through six questions in order: ### Q1: Who supplies the key? ``` Who initiates this operation? ├─ External client (our SDK / direct caller) → client supplies UUID per logical action ├─ Webhook receiver → use provider's event ID (Stripe event.id, GitHub X-GitHub-Delivery, etc.) ├─ Message queue consume