Agent skill · software engineering · jeremylongshore
salesforce-reliability-patterns
Build Salesforce integration reliability with idempotency, bounded retries, durable state, dead letters, reconciliation, backfill, and tested recovery. Use when designing resilient systems. Trigger with "harden Salesforce reliability".
Why this skill is useful
Provides specific implementation patterns for Salesforce reliability that the AI wouldn't reliably generate on its own.
What it needs
Requires jsforce, opossum, redis installed locally. Requires salesforce account access. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Salesforce Reliability and Recovery Patterns Overview Make every read, write, job, and event path safe under duplicate, delayed, partial, uncertain, throttled, and unavailable outcomes. Prerequisites Business invariants, sources of truth, operation classes, stable keys, ordering, latency, and recovery objectives Current Salesforce API, event, limit, error, job-result, and transaction contracts Durable queue and checkpoint stores, quarantine or dead-letter path, reconciliation, backfill, and owners Tool Discipline Use Read, Glob, and Grep to inspect approved repository and evidence files, WebFetch to re-check current first-party Salesforce documentation, and Write or Edit only for secretless plans, fixtures, configuration, and redacted receipts. Current Contract Salesforce synchronous, composite, bulk, and event surfaces have different transaction, result, retry, ordering, and recovery semantics. CDC can emit gap or overflow events; no transport removes the need for idempotency and reconciliation. Authentication Use separate minimum-permission principals for runtime, repair, and diagnostics. Protect tokens, payloads, checkpoints, dead letters, and repair tooling from unauthorized access and logging. Instructions 1. Classify each operation as read, create, update, upsert, delete, job, publish, or consume and define its invariant and stable key. 2. Document timeout, error, partial-result, transaction, limit, ordering, duplicate, replay, and retention semantics from current contracts. 3. Design idempotency through external IDs, request ledgers, deduplication keys, conditional state, or invariant checks appropriate to the operation. 4. Retry only classified transient failures with bounded attempts, jitter, budget, and circuit breaking; reconcile uncertain outcomes first. 5. Persist queue, job, checkpoint, schema, and dead-letter state durably with redaction, retention, and ownership. 6. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/salesforce-reliability-patterns