agentsclimarketplace

Retry idempotency check

Skill thinkyou0714/claude-lab-skills/lab-automation-architecture/skills/retry-idempotency-check

THINK YOU LAB thinking-OS skills for Claude Code — reusable judgment/design/automation/communication skill packs (tech-agnostic, MIT)

Install
npx -y skills add thinkyou0714/claude-lab-skills --skill retry-idempotency-check

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

自動化フロー・API 呼び出しのリトライ設計とべき等性を確認する。同じ処理が複数回実行された場合に、データ破損・二重決済・重複挿入が起きないかを検証する。リトライ・再実行を伴う処理の設計時に使う。

SKILL.md

5.0 KB, as published. Nobody here has run it

Purpose

「リトライしたら二重に請求された」「同じデータが2行挿入された」を防ぐ。 べき等性の有無を確認し、リトライが安全に行えるフロー設計を保証する。

Use When

  • Webhook / API 呼び出しを含む自動化フローを設計する前
  • Stripe Webhook の処理ロジックを設計・レビューする場合
  • trigger-action-map の後に、リトライ安全性を確認したい場合
  • 「このフロー、二重実行されたらどうなる?」が気になる場合

Inputs

  • 対象フロー・処理: べき等性を確認する処理の説明
  • リトライのトリガー: どのような条件でリトライが発生するか
  • 外部 API: 呼び出す外部サービス（Stripe / Supabase / n8n 等）
  • データ変更の有無: DB への INSERT / UPDATE / DELETE が含まれるか

Output Contract

  1. 論点: このフローのべき等性で最も危険な箇所
  2. 根拠: その論点をそう判断した理由
  3. べき等性評価: 処理ステップ別の安全性確認
  4. 含意: べき等性の欠如が引き起こすビジネス・データへの影響
  5. 改善案: べき等キー・冪等性保証の実装方針
  6. 代替案: 別のリトライ設計・フォールバック方式
  7. 判断材料: リトライ設計の確定に必要な人間の判断事項

べき等性評価 フォーマット

ステップ処理内容べき等かリトライ安全か対応が必要な理由
1Yes/No/条件付きYes/No

Review Lens

  • 目的妥当性: べき等性確認が本来の安全性目的に対して有効か
  • 範囲の過不足: 外部APIへの副作用（メール送信・決済等）を全て確認したか
  • 中長期リスク: べき等キーの衝突・有効期限切れのリスク
  • LAB全体との整合性: Stripe Webhook のべき等性設計を含んでいるか
  • 非エンジニア理解可能性: 「同じ処理が2回起きても安全か」を説明できるか
  • 他LLM移植耐性: 設計が Claude 固有に依存していないか

Instructions

  1. フローの各ステップを「読み取り / 書き込み / 外部API呼び出し」に分類する
  2. 書き込み・外部API の各ステップにべき等性があるか確認する
  3. べき等キー（idempotency key）が必要な箇所を特定する
  4. Stripe Webhook は idempotency_key の実装を必ず確認する
  5. DB への INSERT は ON CONFLICT DO NOTHING または UPSERT を検討する
  6. リトライ回数・バックオフ方針を定義する（無限リトライは禁止）
  7. リトライが安全でない処理（メール送信等）の重複防止策を設計する

Guardrails

  • 「リトライしない」をフォールバックとして採用する場合は、失敗の検知方法を必ず含める
  • べき等キーの有効期限を「無期限」にしない
  • Stripe の二重請求は特に慎重に確認する（テスト環境で必ず検証）
  • 「おそらく大丈夫」でべき等性を確認済みにしない

LAB Cross-Check

観点状態備考
自動化フロー—n8n のリトライ設定と整合しているか
データ / 認証 / ログ—重複挿入・更新のリスクを DB 設計で防げているか
実装 / 運用フロー—リトライ失敗の検知・対応手順が存在するか
非エンジニア理解可能性—「安全に再試行できる」を説明できるか
会員共有 / 再利用耐性—べき等性チェックの枠組みが他フローに転用できるか
他LLM移植耐性—設計が Claude 固有に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

  • 要件: べき等性を保証する実装仕様（べき等キー・UPSERT 設計等）
  • 成功条件: 同一フローが2回実行されてもデータが重複しない状態
  • 失敗条件: 重複データ・二重請求が発生した場合の検知基準
  • 実行範囲: 修正してよいワークフロー・API ハンドラー・DB テーブル
  • 影響範囲: べき等性変更が波及する他の処理・テスト
  • ロールバック方針: 実装変更が失敗した場合の戻し方
  • コスト比較: べき等キー実装の工数 vs 二重実行リスクのコスト

Further Reading

  • trigger-action-map skill — フロー全体のリトライポイント確認
  • failure-point-review skill — リトライ失敗の障害パターン
  • monitoring-alert-design skill — リトライ失敗の監視・アラート

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.