How do I install the Lock At The Chokepoint skill?

Run npx skillmds@latest add randommonicle/lock-at-the-chokepoint 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 Lock At The Chokepoint 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 Lock At The Chokepoint?

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 Lock At The Chokepoint free to use?

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

Who published Lock At The Chokepoint?

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

Lock At The Chokepoint by randommonicle

Name: Lock At The Chokepoint
Author: randommonicle

Lock At The Chokepoint

Serialise shared operations at the single module-level chokepoint every caller passes through, never in per-instance state — and cap fan-out there too. A check-then-act idempotency guard protects sequential retries but loses the race under concurrency. Triggers when adding a lock, in-flight guard, dedupe check, or rate cap where multiple callers, component instances, or loops can invoke the same shared operation, and when writing any internal retry or resume loop over a batch. Does not fire on recording the status of an external send — outbound-side-effect-idempotency owns send-then-record.

randommonicle Updated Sep 21, 2026

File contents

Lock at the chokepoint

Three incidents that cost real money: a per-hook syncing ref plus per-screen network listeners produced overlapping sync passes and every photo was analysed twice at doubled AI cost; ~30 concurrent vision calls fired unawaited and blew the provider's per-minute org limit; the server-side "already analysed?" check lost the race against its twin.

The rules

Serialise at the shared module-level function every caller passes through — a module-level in-flight promise, not per-instance state. Guards in hooks, screens, or components multiply with their instances and each copy believes it is alone.
A check-then-act guard is not a lock. Read-then-write ("is it already done? no → do it") protects sequential retries only; two simultaneous callers both pass the check. Prevent the duplicate at the source, or use an atomic claim (see outbound-side-effect-idempotency for the external-send variant).
Cap fan-out at the single upstream chokepoint rather than trusting callers not to burst. One concurrency gate in the shared client wrapper throttles the whole app under a provider limit; per-call politeness does not survive a loop.
Retry and resume loops: skip items already completed; classify failures transient (retry N, then give up) versus permanent (give up now); and give an unrecoverable item an escape hatch so it cannot wedge the queue — surfacing it as given up per honest-failure-surfacing, never retrying silently forever. A photo whose local file was gone once blocked an entire inspection's sync indefinitely.

What this skill does not do

It does not govern external send-then-record paths (outbound-side-effect-idempotency) or per-IP abuse caps on public endpoints (guard-the-spend-paths). It governs internal concurrency and fan-out.

Why

Concurrency bugs of this class bill you twice and rate-limit you once, and they are invisible in sequential testing — the duplicate cost only appears when two instances run at once. Evidence: ASH LESSONS_LEARNED 2026-06-04 (evening and later entries), 2026-05-27, and the CLAUDE.md Opus rate-limit lesson.

---name: lock-at-the-chokepointdescription: Serialise shared operations at the single module-level chokepoint every caller passes through, never in per-instance state — and cap fan-out there too. A check-then-act idempotency guard protects sequential retries but loses the race under concurrency. Triggers when adding a lock, in-flight guard, dedupe check, or rate cap where multiple callers, component instances, or loops can invoke the same shared operation, and when writing any internal retry or resume loop over a batch. Does not fire on recording the status of an external send — outbound-side-effect-idempotency owns send-then-record.---# Lock at the chokepointThree incidents that cost real money: a per-hook `syncing` ref plus per-screen networklisteners produced overlapping sync passes and every photo was analysed twice at doubled AIcost; ~30 concurrent vision calls fired unawaited and blew the provider's per-minute orglimit; the server-side "already analysed?" check lost the race against its twin.## The rules1. **Serialise at the shared module-level function every caller passes through** — a module-level in-flight promise, not per-instance state. Guards in hooks, screens, or components multiply with their instances and each copy believes it is alone.2. **A check-then-act guard is not a lock.** Read-then-write ("is it already done? no → do it") protects sequential retries only; two simultaneous callers both pass the check. Prevent the duplicate at the source, or use an atomic claim (see outbound-side-effect-idempotency for the external-send variant).3. **Cap fan-out at the single upstream chokepoint** rather than trusting callers not to burst. One concurrency gate in the shared client wrapper throttles the whole app under a provider limit; per-call politeness does not survive a loop.4. **Retry and resume loops**: skip items already completed; classify failures transient (retry N, then give up) versus permanent (give up now); and give an unrecoverable item an escape hatch so it cannot wedge the queue — surfacing it as given up per honest-failure-surfacing, never retrying silently forever. A photo whose local file was gone once blocked an entire inspection's sync indefinitely.## What this skill does not doIt does not govern external send-then-record paths (outbound-side-effect-idempotency) orper-IP abuse caps on public endpoints (guard-the-spend-paths). It governs internalconcurrency and fan-out.## WhyConcurrency bugs of this class bill you twice and rate-limit you once, and they areinvisible in sequential testing — the duplicate cost only appears when two instances run atonce. Evidence: ASH LESSONS_LEARNED 2026-06-04 (evening and later entries), 2026-05-27, andthe CLAUDE.md Opus rate-limit lesson.

Frequently asked questions