Salesloft Contract CI

Overview

This skill keeps pull-request validation deterministic and secretless while retaining a separately authorized live smoke check. It prevents CI from creating people or cadence memberships as a connectivity test.

Prerequisites

• A repository with a test runner and identified HTTP adapter
• Sanitized success and failure fixtures
• Protected CI environment for any live credential
• Named owner for contract drift and smoke failures

Tool Discipline

Use Read, Glob, and Grep to inspect workflows, test commands, adapters, and secret references. Use WebFetch only for official Salesloft contracts. Use Write or Edit after confirming the CI file and repository conventions.

Current Contract

• Offline fixtures cover data, list metadata, singular error, field-keyed errors, and rate headers.
• Webhook tests sign exact raw bytes with SHA-1 HMAC and the fixture callback token.
• Untrusted fork workflows receive no Salesloft secret.
• The optional live lane performs one bounded read such as GET /v2/me and logs no response body.

Authentication

Store a least-privilege read credential only in a protected environment. Pin it to a non-production or explicitly approved team and rotate it through the owning Salesloft flow.

Instructions

1. Map required unit, contract, security, and static checks to CI jobs.
2. Run sanitized fixture tests on every pull request with no external dependency.
3. Assert secret redaction, tenant binding, pagination termination, bounded retries, and raw-body signature behavior.
4. Disable live jobs for fork-originated and untrusted events.
5. Run the live read-only smoke only after protected-environment authorization.
6. Make contract drift and live failures visible without leaking body or credential data.

Approval Boundaries

Do not expose repository secrets to fork code, print API responses, or perform Salesloft writes from the default CI lane. A new live environment or scope needs owner approval.

Output

Return workflow paths, trigger matrix, fixture coverage, secret boundary, live-lane guard, commands, results, and unresolved failures.

Error Handling

…

Salesloft Error Triage

Overview

This skill identifies the failing contract before changing code, scopes, or credentials. It retains structured error meaning while excluding Bearer values and sales-record payloads.

Prerequisites

• Method, path template, status, timestamp, and team alias
• Redacted request shape and response content type
• Auth flow, granted scopes, and acting-user role
• Rate headers and attempt count when present

Tool Discipline

Use Read, Glob, and Grep to trace request construction and response handling. Use WebFetch only for the exact official Salesloft contract. Use Write or Edit after the failure class is supported by evidence.

Current Contract

• Success data is under data; list metadata is under metadata.
• Salesloft documents a singular error for 403 and 404 responses.
• A 422 response uses a field-keyed errors object and can report multiple validation failures.
• A 429 should be evaluated with x-ratelimit-endpoint-cost and x-ratelimit-remaining-minute plus any retry guidance actually returned.

Authentication

Record only auth type, expiry state, scope names, and acting-user identity. Never capture an access token, refresh token, client secret, API key, or authorization code.

Instructions

1. Reproduce once with secrets and record values redacted before persistence.
2. Confirm base URL, method, path, content type, query encoding, and timeout.
3. Classify authentication, permission/visibility, missing resource, validation, rate, transport, or provider failure.
4. Compare the exact endpoint's required scope and allowed parameters with the request.
5. Apply the smallest correction and rerun a read-only or fixture proof first.
6. For writes, require payload approval and read-after-write verification.

Approval Boundaries

Do not rotate credentials, broaden scopes, change production data, or retry an uncertain write merely to test a theory. Escalate when the failure cannot be reproduced safely.

Output

Return a redacted symptom, evidence, failure class, smallest supported correction, safe verification, and escalation owner.

Error Handling

Salesloft Controlled Cadence Enrollment

Overview

This skill turns person resolution and cadence enrollment into one auditable workflow. It prevents demo writes, duplicate people, accidental owner changes, and enrollment into an unapproved cadence.

Prerequisites

• Approved Salesloft team, cadence ID, acting user, and business purpose
• people:read, required person-write scope when creation is approved, and cadences:read or write scope as documented
• Consent and contact-restriction policy for the target person
• A durable application correlation key and rollback owner

Tool Discipline

Use Read, Glob, and Grep to find person resolution, cadence, and CRM ownership code. Use WebFetch only for current official endpoint documentation. Use Write or Edit after the mutation boundary is approved.

Current Contract

• POST /v2/people requires either an email address or phone plus last name as a unique lookup basis.
• A person's do_not_contact and contact_restrictions affect permitted communication and cadence steps.
• POST /v2/cadence_memberships requires visible person_id and cadence_id values.
• Acting for a teammate is constrained by team-cadence ownership or Personal Cadence Admin permission.
• Cadence membership records are mutable and can represent later re-enrollment, not immutable event history.

Authentication

Use a tenant-bound Bearer credential with only the scopes needed for the chosen read or write steps. Prove team and acting-user identity before mutation.

Instructions

1. Confirm team, person lookup, approved cadence, acting user, consent state, and owned fields.
2. Search using only documented person filters and handle zero, one, or multiple candidates explicitly.
3. If no person exists, present the exact create payload and endpoint content type for approval.
4. Re-read the person and stop for do_not_contact, incompatible restrictions, or identity ambiguity.
5. Inspect current and historical cadence membership before adding a new membership.
6. Create one membership only after cadence visibility and acting-user permission are proven.
7. Read back the membership state and retain correlation, approval, and rollback evidence.

Approval Boundaries

Creating or updating a person and enrolling in a cadence are live CRM mutations. Require explicit target and payload approval; never bypass consent, contact restrictions, teammate permissions, or an ambiguous match.

Output

Return team, person resolution, consent checks, cadence and acting-user proof, proposed or executed mutation, read-after-write state, and roll…

Salesloft Cadence Outcome Reconciliation

Overview

This skill synchronizes cadence membership state and its documented engagement counts without relying on obsolete activity paths. It preserves mutable-record semantics and a restartable cursor.

Prerequisites

• A named team and destination dataset
• cadences:read plus any endpoint-specific read scope
• A durable microsecond-precision updated_at cursor
• A documented merge key and data-retention policy

Tool Discipline

Use Read, Glob, and Grep to inspect schemas, sync checkpoints, and consumers. Use WebFetch only for current Salesloft endpoint and polling documentation. Use Write or Edit after confirming the destination contract.

Current Contract

• GET /v2/cadence_memberships supports updated_at filters, sort_by=updated_at, direction, page, and per_page up to 100.
• A membership is mutable and reused when a person later returns to the same cadence.
• Current state includes processing, staged, active, scheduled, pending, completed, removed, reassigned, and archived outcomes.
• Documented counts include views, clicks, replies, calls, sent emails, and bounces.

Authentication

Use the explicit team credential with the minimum read scopes. Never mix cursors or destination partitions between teams.

Instructions

1. Define the destination key, accepted fields, retention window, and team partition.
2. Start from a durable cursor with a deliberate overlap window for equal timestamps.
3. Fetch memberships ordered by updated_at ascending with a bounded page size.
4. Upsert by stable membership ID and treat state and counts as replaceable snapshots.
5. Advance the cursor only after the destination transaction succeeds.
6. Deduplicate overlap records and compare source, processed, and committed counts.
7. Reconcile periodic samples against Salesloft and alert on gaps or backward cursors.

Approval Boundaries

Keep this workflow read-only in Salesloft. Do not infer immutable cadence episodes, individual email events, or user performance conclusions from aggregate membership counts alone.

Output

Return team partition, cursor interval, pages and endpoint cost, source/upsert/deduplicated counts, reconciliation result, and next durable cursor.

Error Handling

Salesloft API Capacity Tuning

Overview

This skill optimizes rate-budget consumption, not subscription pricing. It uses observed endpoint cost and business value to remove waste without losing records or hiding failures.

Prerequisites

• Named team, integration, time window, and business owner
• API Logs or application metrics for endpoint, page, status, and rate headers
• Current synchronization and retention requirements
• Baseline reconciliation results

Tool Discipline

Use Read, Glob, and Grep to inspect polling schedules, page traversal, caches, and retries. Use WebFetch only for official Salesloft rate and polling guidance. Use Write or Edit after an optimization is tied to measured waste.

Current Contract

• Salesloft currently starts with 600 cost per minute per team, subject to provider adjustment.
• Endpoint cost defaults to 1 but can change; measure x-ratelimit-endpoint-cost.
• Page indices above 100 cost more, reaching 30 points at page 501 and later.
• API Logs can group calls by integration, team, endpoint, response code, and rate usage.
• Webhooks do not replace every change feed; Salesloft documents cursor polling as the general incremental pattern.

Authentication

Use existing approved access to metrics and API Logs. Never create extra credentials to evade the shared team budget.

Instructions

1. Measure calls and cost by team, integration, method/path, page range, status, and retry reason.
2. Rank waste from deep pages, duplicate pollers, unchanged records, retry loops, and low-value fields.
3. Replace full scans with documented filters and durable updated_at cursors where supported.
4. Coordinate schedules across integrations and reserve recovery headroom.
5. Apply one bounded change and compare cost, lag, completeness, and freshness.
6. Keep only improvements that preserve reconciliation and service objectives.
7. Document any provider limit-adjustment request separately from application optimization.

Approval Boundaries

Do not claim dollar savings from rate-cost points, reduce required retention, drop records, or disable reconciliation without data-owner approval.

Output

Return baseline cost, ranked waste, proposed changes, expected capacity impact, measured result, correctness evidence, and remaining shared-budget risk.

Error Handling

Salesloft Redacted Debug Bundle

Overview

This skill produces a small evidence package that another engineer can use without receiving credentials or customer records. It separates observed facts from hypotheses.

Prerequisites

• Incident ID, owner, timeframe, environment, and expected behavior
• Approved output directory and retention period
• Access to application logs and, when authorized, Salesloft API Logs
• A redaction review owner

Tool Discipline

Use Read, Glob, and Grep to locate bounded logs, configuration keys, and version files. Use WebFetch only for current official Salesloft documentation. Use Write or Edit only for the approved redacted artifact.

Current Contract

• Capture method and path template, status, content type, latency, attempt count, and deployment revision.
• Capture auth type, expiry state, scope names, and team alias, never credential values.
• Capture x-ratelimit-endpoint-cost and x-ratelimit-remaining-minute when present.
• Salesloft API Logs can lag about five minutes and expose up to 10,000 calls or 14 days in the UI; absence is not immediate proof that no call occurred.

Authentication

Use existing approved access. The bundle must omit Authorization headers, refresh tokens, client secrets, API keys, callback tokens, cookies, raw bodies, and prospect fields.

Instructions

1. Freeze incident scope, UTC window, environment, and affected operation.
2. Collect only bounded application events for that window and correlation key.
3. Add redacted configuration names, dependency versions, and deployment revision.
4. Add response-envelope shape and rate metadata without record contents.
5. If authorized, compare API Logs by integration, team, endpoint, time, and status after the documented lag.
6. Scan the artifact for credential patterns and CRM fields, then record checksums.
7. Require a second review before external sharing.

Approval Boundaries

Do not archive full environment dumps, databases, raw HTTP payloads, or unrestricted logs. External sharing requires named reviewer approval and an expiry date.

Output

Return bundle path, file inventory, redactions, checksums, evidence timeline, hypotheses, missing evidence, reviewer, and deletion date.

Error Handling

Salesloft Integration Rollout

Overview

This skill deploys application code that calls Salesloft without assuming a particular cloud vendor. It separates process health, Salesloft connectivity, and CRM mutation correctness.

Prerequisites

• Immutable release SHA and target runtime
• Named Salesloft team, environment, release owner, and rollback owner
• Passing offline contract and security tests
• Approved secret references, callback URL, and canary plan

Tool Discipline

Use Read, Glob, and Grep to inspect deployment manifests, health checks, secret references, and rollback controls. Use WebFetch only for official Salesloft contracts. Use Write or Edit after the deployment target is confirmed.

Current Contract

• Inject Bearer credentials through the runtime secret system and bind them to one team.
• Process health is not proof of API auth or correct CRM mutation.
• A webhook receiver must preserve raw request bytes before parsing and verify SHA-1 HMAC.
• Team-wide rate consumption from other integrations can affect the rollout.
• Webhook subscription creation requires a valid OAuth token or API key and event-specific scopes.

Authentication

Deploy only an approved flow and least-privilege scope set. Prove credential-to-team mapping with a read-only identity request before enabling workers or webhooks.

Instructions

1. Pin SHA, image or artifact digest, target, team alias, and secret references.
2. Run deployment-config and offline contract checks before applying changes.
3. Deploy with workers and Salesloft writes disabled.
4. Prove health, TLS, and one bounded read-only Salesloft request.
5. Verify webhook raw-body handling and callback-token configuration without a real side effect.
6. Enable a tiny approved canary and reconcile every mutation.
7. Expand only while error, endpoint-cost, remaining-budget, queue, and reconciliation signals stay healthy.

Approval Boundaries

Do not create subscriptions, alter callback URLs, enable production writes, or broaden traffic without target-specific approval. Roll back when identity, signature, or reconciliation evidence fails.

Output

Return SHA/digest, target, team proof, config checks, smoke result, canary evidence, monitoring snapshot, rollout state, and rollback receipt.

Error Handling

Salesloft Verified First Read

Overview

This skill proves credential injection, team identity, HTTPS handling, and the Salesloft response envelope. It deliberately avoids creating a person or enrolling anyone in a cadence.

Prerequisites

• A named repository and non-production or explicitly approved team
• A scoped OAuth access token or customer API key
• A runtime with HTTPS, JSON parsing, and a bounded timeout
• Permission to read the authenticated identity

Tool Discipline

Use Read, Glob, and Grep to inspect the local HTTP wrapper, environment-variable names, and tests. Use WebFetch only for current official Salesloft documentation. Use Write or Edit after confirming the target implementation file.

Current Contract

• Base URL: https://api.salesloft.com/v2.
• Send the credential as a Bearer value; do not put it in a query parameter.
• Use the documented path without assuming every endpoint requires a .json suffix.
• Successful response bodies place returned data under data; list responses can also include metadata.

Authentication

Use a partner OAuth access token, approved private-app token, or customer API key appropriate to the integration. The proof must not request or exercise write scopes.

Instructions

1. Confirm repository, team alias, auth flow, secret source, and expected identity.
2. Configure an explicit base URL, Bearer injection, Accept header, and timeout.
3. Request GET /v2/me once without retries that could hide an auth failure.
4. Validate status, JSON content type, and the data envelope.
5. Compare only a safe team or user identifier with the expected target.
6. Add fixtures for success, 401, 403, and non-JSON responses.

Approval Boundaries

Do not create a demonstration person, change a cadence, or print the credential or raw identity payload. Stop if the returned team is not the approved target.

Output

Return redacted configuration, status, envelope assertion, expected-target match, fixture results, and the next authorized workflow.

Error Handling

Examples

The example below shows the minimum redacted evidence expected from a successful invocation of this operator w…

Salesloft Authentication Decision

Overview

This skill chooses an authentication boundary before code is written. It distinguishes partner authorization, customer API keys, and admin-enabled private client credentials instead of treating them as interchangeable.

Prerequisites

• A named repository, Salesloft team, and integration owner
• The integration type: partner, customer-owned, or private backend
• Approved callback URIs and minimum endpoint scopes
• A secret store that supports atomic token replacement

Tool Discipline

Use Read, Glob, and Grep to inspect existing auth code, environment schemas, and secret names. Use WebFetch only for current official Salesloft documentation. Use Write or Edit only after confirming the repository and auth design.

Current Contract

• API requests use Authorization: Bearer <credential> against https://api.salesloft.com/v2.
• Partners use OAuth; Salesloft does not approve partner applications that rely on API keys.
• Customer API keys act as the issuing user and must remain server-side.
• Client credentials are admin-enabled, private-use only, cannot be allowlisted, inherit the creating admin's permissions, expire after 7,200 seconds, and have no refresh token.
• Authorization-code refresh returns a new refresh token and revokes the old one, so replacement must be atomic.

Authentication

Use authorization code for user-authorized partner applications, client credentials only for an approved private server process, or a scoped API key for a customer-owned integration. Request only scopes required by the current endpoint reference.

Instructions

1. Inventory every Salesloft endpoint, caller, team boundary, and required scope.
2. Select one supported flow and document why it fits the integration type.
3. Register exact callback URIs or private-app settings in Salesloft Account.
4. Store client secrets, API keys, access tokens, and refresh tokens outside source and logs.
5. Implement Bearer injection plus expiry-aware refresh or reacquisition.
6. For authorization code, replace the access and refresh token together in one durable transaction.
7. Prove access with a bounded read such as GET /v2/me; never print the response body in CI.

Approval Boundaries

Do not broaden scopes, enable client credentials, create or revoke credentials, or change production callback URIs without the integration owner and Salesloft admin. Never expose a token in a command, URL, patch, log, or example.

Output

Return the integration type, chosen flow, scope matrix, secret references, rotation behavior, read-only proof, and unresolved administrator actions.

Erro…

Salesloft Local Contract Loop

Overview

This skill creates a fast local loop around realistic Salesloft envelopes, pagination, errors, and webhook signatures. Live CRM mutation is outside the default loop.

Prerequisites

• A named repository and test framework
• Sanitized fixtures containing no customer or prospect data
• A replaceable HTTP transport boundary
• Optional non-production read credential stored outside source

Tool Discipline

Use Read, Glob, and Grep to map the client, adapters, fixtures, and test commands. Use WebFetch only to recheck official Salesloft contracts. Use Write or Edit only inside the confirmed repository.

Current Contract

• Model successful responses with data and list metadata.
• Model 403/404 as a singular error, 422 as field-keyed errors, and 429 with current rate headers.
• Pagination begins at page 1; supported endpoints generally allow per_page from 1 through 100.
• Webhook fixtures must preserve exact raw bytes for SHA-1 HMAC verification.

Authentication

Tests inject a fake Bearer value and assert redaction. An optional live lane may use a read-only credential only when the target team is explicitly named.

Instructions

1. Identify the smallest HTTP adapter and every response shape the application consumes.
2. Add sanitized success fixtures for identity, paged lists, and empty pages.
3. Add deterministic 401, 403, 404, 422, 429, timeout, and non-JSON cases.
4. Add webhook fixtures with raw body bytes, event header, signature, and callback token.
5. Run unit and contract tests offline on every change.
6. Keep any live smoke lane opt-in, read-only, bounded, and disabled for untrusted forks.

Approval Boundaries

Never copy production responses into fixtures or use real tokens as placeholders. Do not enable live writes from a local test command.

Output

Return fixture inventory, contract assertions, commands run, pass/fail results, live-lane state, and any unsupported response shape.

Error Handling

Examples

The example below shows the minimum redacted evidence expected from a successful invocat…

Salesloft Sync Performance Tuning

Overview

This skill optimizes one measured Salesloft path without trading away completeness or tenant isolation. It treats deep pagination and uncontrolled concurrency as cost and correctness risks.

Prerequisites

• A named operation, team, dataset size, and service-level objective
• Baseline latency, pages, endpoint cost, remaining budget, retries, and lag
• Correctness assertions and replayable fixtures
• Durable cursor and destination transaction boundary

Tool Discipline

Use Read, Glob, and Grep to locate pagers, caches, concurrency, checkpoints, and metrics. Use WebFetch only for current official Salesloft contracts. Use Write or Edit after the baseline and target path are confirmed.

Current Contract

• Supported list endpoints generally page from 1 with up to 100 records per page.
• Deep page indices incur higher documented cost, so full scans degrade shared team capacity.
• Salesloft's efficient polling pattern sorts updated_at ascending and persists a microsecond-precision cursor.
• A production poller must handle overlap and duplicate processing safely.
• Actual response headers, not assumed request counts, measure endpoint cost.

Authentication

Use the existing tenant-bound read credential. Performance work must not broaden scopes or mix caches, cursors, or limiters between teams.

Instructions

1. Measure the slow path with record count, page count, p50/p95 latency, endpoint cost, remaining budget, and lag.
2. Confirm the endpoint's supported filters and sort fields.
3. Replace repeated deep scans with an updated_at cursor, ascending order, page size up to 100, and a deliberate overlap window.
4. Persist destination data and cursor atomically; deduplicate by stable resource ID and content fingerprint.
5. Add bounded per-team concurrency and cache only data with explicit freshness rules.
6. Load-test with fixtures, then run a bounded canary against an approved team.
7. Compare before/after performance and reconciliation counts before rollout.

Approval Boundaries

Do not raise concurrency, remove overlap, skip reconciliation, or cache prospect data beyond policy merely to improve latency.

Output

Return baseline, bottleneck, change, cursor and cache rules, rate impact, correctness comparison, canary result, and measured improvement.

Error Handling

Salesloft Production Go-No-Go

Overview

This skill binds production readiness to one release SHA and target environment. A checked box without evidence is not a passing gate.

Prerequisites

• Immutable release SHA and deployment target
• Named Salesloft team, integration owner, and rollback owner
• Passing fixture, contract, security, and failure-path tests
• Approved auth, data retention, monitoring, and incident policies

Tool Discipline

Use Read, Glob, and Grep to inspect release artifacts, tests, configuration, and runbooks. Use WebFetch only to reverify official Salesloft contracts. Use Write or Edit only for the approved release record or required fix.

Current Contract

• Authentication flow must match partner, customer, or private-app use and use least-privilege scopes.
• Request and response types must preserve documented envelope and endpoint-specific content types.
• Rate control must be team-wide and use the current endpoint-cost and remaining-minute headers.
• Webhook verification uses raw-body SHA-1 HMAC plus callback-token validation and durable deduplication.
• CRM writes require target, payload, read-after-write, and reconciliation evidence.

Authentication

Prove production credential availability and rotation without displaying secret values. Confirm callback URIs, team binding, scopes, and acting-user permissions.

Instructions

1. Pin SHA, environment, Salesloft team, owners, and change window.
2. Attach test results for envelope, pagination, auth, rate, webhook, and failure contracts.
3. Verify secret references, tenant isolation, logging redaction, and rotation drill.
4. Run a bounded read-only identity smoke check against the production team.
5. Validate dashboards for latency, status, endpoint cost, remaining budget, queue lag, and reconciliation.
6. Rehearse rollback or disablement and confirm data-repair ownership.
7. Record PASS, FAIL, or WAIVED per gate and issue a final go/no-go decision.

Approval Boundaries

Do not approve a release with an unowned failure, expired exception, missing rollback, or unverified production team. A canary write requires separate payload approval.

Output

Return release SHA, target, gate table, evidence links, exceptions and expiry, rollback proof, owners, and final decision.

Error Handling

Salesloft Team Rate Budget

Overview

This skill turns Salesloft rate limiting into measured team capacity. It accounts for other integrations and deep-page multipliers rather than treating request count as cost.

Prerequisites

• A named Salesloft team and integration owner
• Method/path/page inventory and recent response headers
• A shared per-team scheduler or limiter
• Replay-safe handling for any retried operation

Tool Discipline

Use Read, Glob, and Grep to locate pagers, retry loops, concurrency, and metrics. Use WebFetch only to confirm current official limits and endpoint costs. Use Write or Edit after the budget policy is approved.

Current Contract

• Salesloft currently documents a default team-wide limit of 600 cost per minute; Salesloft can adjust it by customer or team.
• Endpoint cost defaults to 1 but can change without endpoint deprecation.
• Page 101-150 costs 3, 151-250 costs 8, 251-500 costs 10, and 501+ costs 30.
• Observe x-ratelimit-endpoint-cost and x-ratelimit-remaining-minute instead of invented per-minute header names.
• Another integration on the same team can consume the shared budget.

Authentication

Use the existing team-bound Bearer credential. Do not evade a team limit by rotating credentials or applications.

Instructions

1. Instrument endpoint cost, remaining-minute value, page number, latency, status, and team alias.
2. Build a limiter keyed by team, not only process or credential.
3. Reserve headroom for interactive and recovery traffic.
4. Replace deep scans with endpoint-supported updated_at polling and durable cursors.
5. On 429, honor explicit server guidance when present; otherwise use bounded exponential backoff with jitter.
6. Retry reads and application-idempotent operations only; surface exhausted attempts.
7. Alert on sustained high endpoint cost or unexpected shared-budget depletion.

Approval Boundaries

Do not increase concurrency, request a provider limit adjustment, or replay uncertain writes without measured evidence and owner approval.

Output

Return team budget, observed header samples, endpoint/page cost distribution, limiter policy, retry bounds, headroom, and before/after measurements.

Error Handling

Salesloft Integration Reference Architecture

Overview

This skill maps Salesloft integration responsibilities into inspectable components and data flows. It treats tenant isolation, rate sharing, and reconciliation as architectural requirements rather than library details.

Prerequisites

• Business workflows, team topology, data classes, and service objectives
• Auth-flow and endpoint/scope inventory
• Hosting, queue, database, secret-store, and observability constraints
• Named service, security, data, and incident owners

Tool Discipline

Use Read, Glob, and Grep to inspect repository topology, boundaries, schemas, and deployment files. Use WebFetch only for official Salesloft contracts. Use Write or Edit after confirming the intended architecture artifact.

Current Contract

• Every request carries an explicit team context and tenant-bound Bearer credential.
• The client preserves endpoint-specific requests, response envelopes, pagination, and rate metadata.
• A scheduler coordinates the team-wide cost budget across workers and integrations.
• Incremental readers persist microsecond updated_at cursors with overlap and deduplication.
• Webhook ingress preserves raw bytes, verifies SHA-1 HMAC and callback token, then queues durable idempotent work.

Authentication

Model separate authorization-code, customer API-key, and private client-credentials lifecycles. Keep encrypted credentials and refresh state keyed by immutable Salesloft team identity.

Instructions

1. Map actors, Salesloft teams, trust zones, data classes, and all read/write flows.
2. Define tenant context at ingress and carry it through client, queue, cache, database, and logs.
3. Place auth resolution and refresh behind a serialized tenant-bound service.
4. Place request shaping, envelopes, paging, errors, and rate headers behind a narrow client.
5. Separate webhook receipt from processing and pair it with cursor-based reconciliation.
6. Define mutation ownership, idempotency, read-after-write, and repair workflows.
7. Add metrics and runbooks for auth, status, cost, remaining budget, lag, duplicates, and reconciliation.

Approval Boundaries

Do not centralize mutable global credentials, share tenant caches, accept webhooks before verification, or create a write path without ownership and repair controls.

Output

Return component and data-flow diagrams, tenant invariants, auth model, endpoint boundaries, rate scheduler, webhook/reconciliation design, failure modes, owners, and open decisions.

Error Handling

Salesloft Typed REST Adapter

Overview

This skill builds a narrow client around the endpoints an application actually uses. It avoids invented universal schemas, implicit tenant state, and unbounded recursive retries.

Prerequisites

• A repository with an identified HTTP boundary
• Endpoint, scope, request-format, and response-format inventory
• A tenant-to-credential resolver
• Fixture coverage for success and failure envelopes

Tool Discipline

Use Read, Glob, and Grep to inspect package versions, call sites, and generated types. Use WebFetch only for official endpoint contracts. Use Write or Edit after the adapter boundary is confirmed.

Current Contract

• Use https://api.salesloft.com/v2 and documented resource paths; do not force .json onto every path.
• Preserve data, metadata, error, and field-keyed errors as separate typed shapes.
• Pagination and filters are endpoint-specific; page numbers begin at 1 and deep pages consume more rate cost.
• Capture x-ratelimit-endpoint-cost and x-ratelimit-remaining-minute from every response that provides them.
• Use the request content type documented by the endpoint rather than assuming all writes are JSON.

Authentication

Resolve one Bearer credential from the explicit tenant context for every call. Never store a mutable global token or retry with another tenant's credential.

Instructions

1. Inventory exact methods, paths, scopes, query parameters, bodies, and consumed response fields.
2. Define typed success, list metadata, singular error, validation error, and rate-state models.
3. Centralize timeout, Bearer injection, content negotiation, and redacted error capture.
4. Implement an iterative page iterator that stops on metadata.paging.next_page or an empty page.
5. Retry only safe operations or explicitly idempotent application workflows with a bounded attempt budget.
6. Add contract fixtures before migrating callers behind the adapter.

Approval Boundaries

Do not synthesize request fields from examples, automatically fall back to v1, or retry CRM writes without an application idempotency rule and operator approval.

Output

Return endpoint inventory, type boundaries, auth resolver, pagination behavior, retry policy, fixture coverage, and remaining direct calls.

Error Handling

Salesloft Integration Security Boundary

Overview

This skill reviews how credentials, tenant context, prospect data, mutations, and webhook deliveries move through an integration. It produces remediations tied to evidence and named owners.

Prerequisites

• Architecture, data-flow, scope, and secret inventories
• Named Salesloft teams, environments, and data owners
• Current webhook subscription configuration
• Incident and credential-rotation procedures

Tool Discipline

Use Read, Glob, and Grep to inspect auth, logging, storage, routing, and signature code. Use WebFetch only for official Salesloft security contracts. Use Write or Edit only after the remediation target is confirmed.

Current Contract

• Every API credential is a Bearer secret and must remain server-side.
• Authorization-code refresh rotates the refresh token; client credentials have no refresh token.
• API keys act as the issuing customer user and are not the partner application path.
• x-salesloft-signature is a hex SHA-1 HMAC of the exact request body using callback_token as the key.
• Salesloft does not document a timestamp header in the general delivery-header contract, so do not invent timestamp replay verification.

Authentication

Bind each encrypted credential record to one Salesloft team, flow, scope set, environment, owner, and rotation state. Fail closed when tenant context is missing or mismatched.

Instructions

1. Trace credential acquisition, storage, decryption, refresh, injection, revocation, and audit events.
2. Verify least-privilege scopes against every used method and path.
3. Enforce explicit tenant context across queues, caches, jobs, logs, and database keys.
4. Redact Authorization, token, callback-token, email, phone, and CRM fields from diagnostics.
5. Verify webhook HMAC over exact raw bytes with equal-length constant-time comparison.
6. Validate the event type and callback token, then apply durable deduplication before side effects.
7. Test rotation, tenant-confusion, invalid-signature, deletion, and incident paths.

Approval Boundaries

Do not broaden scopes, export customer data, create or revoke credentials, delete Salesloft records, or rotate production secrets without named owner approval and rollback planning.

Output

Return tenant and data-flow findings, scope delta, secret lifecycle, webhook-verification result, redaction gaps, prioritized fixes, owners, and verification evidence.

Error Handling

Salesloft Contract Migration

Overview

This skill migrates the integration that actually exists. It does not assume a generic v1-to-v2 journey, API-key deprecation, or universal endpoint rename.

Prerequisites

• Current integration commit, dependencies, deployment topology, and owners
• Complete method/path/scope/request/response inventory
• Target official documentation and migration reason
• Sanitized fixtures, shadow environment, rollback, and reconciliation plan

Tool Discipline

Use Read, Glob, and Grep to inventory callers, auth, schemas, and compatibility code. Use WebFetch only for current official Salesloft documentation. Use Write or Edit after the migration boundary is approved.

Current Contract

• The current public reference exposes v2 and historical v1 surfaces; compatibility is endpoint-specific.
• Resource paths are documented without a universal .json requirement.
• Auth flow choice depends on integration type; API keys remain a customer path and client credentials remain private-use only.
• Rate costs and endpoint schemas can change independently of URL versioning.
• Cadence import, export, and membership contracts must be verified from their own endpoint pages.

Authentication

Treat auth migration as a separate reversible workstream. Preserve tenant binding and least privilege, and do not disable the old credential until the new path is proven and rollback is viable.

Instructions

1. Inventory every live method, path, query, content type, scope, response field, and retry assumption.
2. Diff each used contract against current official documentation and classify required changes.
3. Add failing fixtures for every intentional schema or behavior delta.
4. Implement an adapter or dual-read path instead of changing all callers at once.
5. Shadow reads and compare normalized results without duplicating writes.
6. Canary approved mutations with read-after-write and reconciliation evidence.
7. Cut over gradually, monitor rate and error signals, then remove compatibility code only after rollback expiry.

Approval Boundaries

Do not automatically fall back between API versions, convert auth flows, import cadences, or replay writes. Each live mutation and irreversible cleanup needs explicit approval.

Output

Return contract diff, affected callers, fixture results, shadow comparison, canary evidence, cutover state, rollback trigger, and cleanup date.

Error Handling

Salesloft Verified Webhook Processing

Overview

This skill accepts a delivery only after authenticating its exact bytes and subscription secret. It makes side effects idempotent even though the general delivery contract does not expose a timestamp replay header.

Prerequisites

• Approved HTTPS callback URL and event type
• Webhook subscription with a high-entropy callback token
• Raw-body access before JSON parsing
• Durable deduplication store and reconciliation owner

Tool Discipline

Use Read, Glob, and Grep to inspect body parsing, signature comparison, queues, and side effects. Use WebFetch only for current official Salesloft webhook documentation. Use Write or Edit after the handler boundary is confirmed.

Current Contract

• x-salesloft-event identifies the delivered event type.
• x-salesloft-signature is the hexadecimal SHA-1 HMAC of the exact response/request body using callback_token as the key.
• The callback token is also included in each event payload and should be validated.
• Failed deliveries are retried three additional times, 15 seconds apart.
• Subscription scopes vary by event type and must be checked in the current event table.

Authentication

Protect the callback token as a secret. Compute the expected HMAC from the exact raw body, decode hex safely, require equal lengths, and use constant-time comparison before parsing or queuing.

Instructions

1. Capture raw bytes and required headers before any middleware transforms the body.
2. Reject missing, malformed, unequal-length, or non-matching signatures.
3. Parse JSON only after signature success and validate the callback token and expected event type.
4. Derive a stable deduplication key from event type plus canonical business identifiers and payload digest.
5. Persist receipt and dedup state before acknowledging or dispatching side effects.
6. Process asynchronously with bounded retries and reconcile missed changes through API reads.
7. Test tampering, malformed hex, duplicate delivery, retry, queue failure, and rotated token behavior.

Approval Boundaries

Do not create or change a subscription, callback URL, event scope, or production token without owner approval. Reject unverifiable events rather than accepting them for debugging convenience.

Output

Return event type, signature and callback-token verdicts, dedup key, queue receipt, processing result, retry state, and reconciliation status without payload data.

Error Handling