attio-deploy-integration
Plan and execute a staged deployment for an external Attio REST integration with secret injection, contract tests, read-only smoke evidence, canary writes, and rollback. Use when releasing Attio-backed services. Trigger with "deploy Attio integration", "Attio rollout", or "Attio release plan".
Allowed Tools
Provided by Plugin
attio-pack
Attio CRM integration pack with 18 operator skills
Installation
This skill is included in the attio-pack plugin:
/plugin install attio-pack@claude-code-plugins-plus
Click to copy
Instructions
Attio Integration Rollout
Overview
This skill releases application code that calls Attio's REST API. It uses progressive evidence so a bad schema mapping, scope, or retry policy is caught before broad CRM mutation.
Prerequisites
- A versioned application artifact and tested configuration
- Environment-specific Attio workspace and secret references
- A disposable canary record or approved read-only smoke path
- Defined rollback owner, trigger, and previous artifact
Tool Discipline
Use Read, Glob, and Grep to inspect deployment manifests, secret names, health checks, migrations, and rollback commands. Use WebFetch only for current official Attio documentation. Use Write or Edit after the rollout target and approval boundary are confirmed.
Current Contract
- Inject tokens from the deployment platform; never bake them into images or manifests.
- Validate object and list schemas in the target workspace before enabling writes.
- Keep read and write traffic controls separate because Attio publishes different limit tiers.
- A successful process health check is not proof that CRM mutations are correct.
Authentication
Use the target environment's least-privilege single-workspace token or tenant-specific OAuth token. Confirm workspace identity and required endpoint scopes before canary traffic.
Instructions
- Compare artifact, configuration, secret references, workspace alias, and endpoint set with the approved release record.
- Run offline contract and redaction tests on the exact artifact.
- Deploy with Attio writes disabled and perform a bounded read-only smoke request.
- Confirm current object/list attributes and pagination behavior in the target workspace.
- Enable one idempotent or reversible canary write, then read it back.
- Expand traffic gradually while watching 4xx, 429, 5xx, latency, duplicate writes, and queue age.
- Roll back on a declared trigger and verify both application and CRM state.
Approval Boundaries
Production writes, token rotation, schema changes, and cleanup of canary data require exact target display and owner approval. Do not roll forward through unexplained validation or authorization failures.
Output
Return artifact identity, environment checks, read smoke, canary evidence, traffic stage, observed metrics, rollback status, and residual risks.
Error Handling
| Condition | Response |
|---|---|
| Workspace identity is uncertain | Stop before enabling traffic. |
| Schema differs from staging | Disable writes and reconcile mappings. |
| 429 rate increases | Hold or reduce traffic and honor Retry-After. |
| Canary is not reversible | Do not use it; choose a safer proof. |
Examples
Input:
artifact=release-sha; environment=production; writes=initially-disabled
Expected handoff:
read-smoke=pass; canary=verified; expansion=approved; rollback=ready
This result binds the rollout decision to the tested artifact and rollback path.