Agent skill · software engineering · jeremylongshore
procore-reference-architecture
Design a governed Procore data connector with explicit tenant routing, durable work queues, endpoint adapters, webhook hydration, reconciliation, and audit receipts. Use when choosing integration boundaries or reviewing a production architecture. Trigger with: "design a Procore connector", "review Procore architecture", "plan Procore data synchronization".
Why this skill is useful
Adds executable scripts for Procore API integration that provide specific authentication and error handling patterns not commonly found in public documentation.
What it needs
Requires python installed locally. Requires procore account access. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Procore Governed Connector Architecture Overview Separate identity, tenant routing, ingestion, hydration, reconciliation, mutation approval, and audit evidence. Procore webhooks improve freshness but REST remains the data source, so the architecture must tolerate duplicates, delays, missed notifications, and partial writes. Prerequisites Source and destination ownership, data domains, classification, and residency constraints Freshness, completeness, recovery, and deletion objectives OAuth grant, DMSA permission map, environment matrix, and endpoint inventory Instructions Step 1: Draw trust boundaries Identify token service, ingress, queue, workers, state store, outbound adapters, audit sink, and operator interface. Carry company and project context as immutable job attributes. Step 2: Separate adapter contracts Keep endpoint version, request schema, pagination, rate metadata, and errors inside resource adapters. Do not create one fictional global Procore API version. Step 3: Design dual ingestion Accept webhook notifications into a durable queue for freshness. Hydrate current resources through REST and run periodic cursor-based reconciliation for completeness. Step 4: Make processing idempotent Deduplicate events, use origin identifiers or documented sync actions where supported, maintain checkpoints, and reconcile ambiguous mutations before retrying. Step 5: Govern writes Validate scope, render a preview, obtain approval where required, execute once, read after write, and emit a redacted receipt. Keep read and write worker authority separable. Step 6: Prove failure behavior Test token expiry, tenant-routing loss, duplicate and discarded events, rate exhaustion, provider outage, poison records, rollback, and replay from checkpoints. Authentication The token service obtains OAuth 2.0 credentials for the intended user or DMSA boundary and injects Bearer tokens only at dispatch. Every job retains explicit company and project routing without logging tokens. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/procore-reference-architecture--41d500