How do I install the Outbound Side Effect Idempotency skill?

Run npx skillmds@latest add randommonicle/outbound-side-effect-idempotency in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Outbound Side Effect Idempotency safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Outbound Side Effect Idempotency?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Outbound Side Effect Idempotency free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Outbound Side Effect Idempotency?

randommonicle (@randommonicle) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Outbound Side Effect Idempotency by randommonicle

Name: Outbound Side Effect Idempotency
Author: randommonicle

Outbound Side Effect Idempotency

Code that performs an external side effect (email, SMS, payment, webhook) and then records its status must choose which failure harms the recipient less — lost or duplicated — and design for that. A read-then-write "already sent?" check is not a lock. Triggers when writing any send-then-record path or adding retry logic around an external send. Does not fire on internal batch retry loops with no external recipient — lock-at-the-chokepoint owns those.

randommonicle Updated Sep 21, 2026

File contents

Outbound side-effect idempotency

The genuine distributed-systems tradeoff hiding in every send-then-record path: "never lose it" and "never duplicate it" cannot both be absolute. A review-request sender kept fail-closed semantics (mark sent only after the provider accepted) and then had to confront the race that design leaves open: two concurrent passes both reading "not sent", both sending.

The rules

Decide which failure harms the recipient less, and design for that. A lost password reset is worse than a duplicate; a duplicate payment is worse than a retried one. The choice is per-path, explicit, and recorded.
Fail-closed for never-lose-it: mark sent only after the provider's 2xx. A pre-marked "sent" that then fails to send is a silent loss with a clean audit trail — the worst combination.
A read-then-write pre-check is not a lock. "Is it already sent? No → send" protects sequential retries only; concurrent callers both pass. True at-most-once needs an atomic claim: a sending state transition the row passes through, or a unique constraint the second sender violates.
When both properties matter and the claim state is deferred, make the residual case detectable: a conditional mark that records the race happened is the honest interim — you cannot yet prevent the double-send, but you will know about it instead of finding out from the recipient.

What this skill does not do

It does not govern internal retry loops with no external recipient (lock-at-the-chokepoint) and does not verify delivery (email-delivery-verification). It chooses and implements the failure semantics of the send itself.

Why

Every send-then-record path embodies this tradeoff whether or not its author noticed; the unexamined default is usually at-least-once with a silent-loss edge, which is the wrong choice for most recipient-facing sends. Evidence: ICC LESSONS_LEARNED L-021 and the reviewRequest fail-closed pattern; the same check-then-act race on an internal path in ASH LESSONS_LEARNED 2026-06-04 (shared evidence with lock-at-the-chokepoint).

---name: outbound-side-effect-idempotencydescription: Code that performs an external side effect (email, SMS, payment, webhook) and then records its status must choose which failure harms the recipient less — lost or duplicated — and design for that. A read-then-write "already sent?" check is not a lock. Triggers when writing any send-then-record path or adding retry logic around an external send. Does not fire on internal batch retry loops with no external recipient — lock-at-the-chokepoint owns those.---# Outbound side-effect idempotencyThe genuine distributed-systems tradeoff hiding in every send-then-record path: "never loseit" and "never duplicate it" cannot both be absolute. A review-request sender keptfail-closed semantics (mark sent only after the provider accepted) and then had to confrontthe race that design leaves open: two concurrent passes both reading "not sent", bothsending.## The rules- **Decide which failure harms the recipient less, and design for that.** A lost password reset is worse than a duplicate; a duplicate payment is worse than a retried one. The choice is per-path, explicit, and recorded.- **Fail-closed for never-lose-it**: mark sent only after the provider's 2xx. A pre-marked "sent" that then fails to send is a silent loss with a clean audit trail — the worst combination.- **A read-then-write pre-check is not a lock.** "Is it already sent? No → send" protects sequential retries only; concurrent callers both pass. True at-most-once needs an atomic claim: a `sending` state transition the row passes through, or a unique constraint the second sender violates.- **When both properties matter and the claim state is deferred, make the residual case detectable**: a conditional mark that records the race happened is the honest interim — you cannot yet prevent the double-send, but you will know about it instead of finding out from the recipient.## What this skill does not doIt does not govern internal retry loops with no external recipient(lock-at-the-chokepoint) and does not verify delivery (email-delivery-verification). Itchooses and implements the failure semantics of the send itself.## WhyEvery send-then-record path embodies this tradeoff whether or not its author noticed; theunexamined default is usually at-least-once with a silent-loss edge, which is the wrongchoice for most recipient-facing sends. Evidence: ICC LESSONS_LEARNED L-021 and thereviewRequest fail-closed pattern; the same check-then-act race on an internal path in ASHLESSONS_LEARNED 2026-06-04 (shared evidence with lock-at-the-chokepoint).

Frequently asked questions