Agent skill · software engineering · jeremylongshore
procore-install-auth
Choose and implement the correct Procore OAuth 2.0 boundary for a user-facing app or headless data connector. Use when registering credentials, selecting Authorization Code versus DMSA Client Credentials, caching tokens, or planning revocation. Trigger with: "set up Procore auth", "choose Procore OAuth flow", "configure a Procore DMSA".
Why this skill is useful
Adds a complete OAuth2 authentication script for Procore API that isn't available in public documentation.
What it needs
Requires curl, requests installed locally. Requires procore account access. About 3k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Procore OAuth and DMSA Boundary Overview Select authentication from the actor model, not implementation convenience. User-facing applications normally use Authorization Code, while unattended connectors use Client Credentials through a Developer Managed Service Account whose manifest permissions bound access. Prerequisites Named application owner and classified user-facing or headless workload Exact company-level and project-level tools the workload must access Approved callback, secret store, token cache, rotation owner, and revocation path Instructions Step 1: Choose the grant Use Authorization Code when the integration acts as a Procore user. Use Client Credentials only for a DMSA or explicitly governed service account that operates without user context. Step 2: Define least privilege List required tool operations before building the app manifest. For a DMSA, encode only those company and project permissions, and require the administrator to select permitted projects during installation. Step 3: Separate credentials Keep production and Developer Sandbox credentials, tokens, login hosts, and API hosts isolated. Never accept a token minted for one environment in another environment's configuration. Step 4: Implement token lifecycle Exchange credentials only from a confidential backend, cache the returned Bearer token until its reported expiry, serialize refresh-token replacement for Authorization Code clients, and persist a newly rotated refresh token atomically. Step 5: Prove the boundary Run one permitted read and one expected-denial test. Include Procore-Company-Id where the endpoint or Multiple Procore Regions contract requires company routing. Step 6: Revoke and rotate Document how an operator revokes authorization, replaces credentials, observes the new credential, and removes the old one without logging secrets. Authentication Procore REST requests use OAuth 2.0 Bearer tokens. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/procore-install-auth