attio-deploy-integration

v2026.09.24

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".

GitHub
安装命令
npx skhub add jeremylongshore/attio-deploy-integration
Markdown
SKILL.md

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

  1. Compare artifact, configuration, secret references, workspace alias, and endpoint set with the approved release record.
  2. Run offline contract and redaction tests on the exact artifact.
  3. Deploy with Attio writes disabled and perform a bounded read-only smoke request.
  4. Confirm current object/list attributes and pagination behavior in the target workspace.
  5. Enable one idempotent or reversible canary write, then read it back.
  6. Expand traffic gradually while watching 4xx, 429, 5xx, latency, duplicate writes, and queue age.
  7. 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

ConditionResponse
Workspace identity is uncertainStop before enabling traffic.
Schema differs from stagingDisable writes and reconcile mappings.
429 rate increasesHold or reduce traffic and honor Retry-After.
Canary is not reversibleDo 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.

Resources

发现
标签

此技能尚未发布标签。

版本
最新版本元数据

版本

v2026.09.24

发布时间

2026年9月24日

分类

未分类

许可证

MIT

源路径

skills/.curated/attio-deploy-integration

默认分支

main

最新提交

e5a6c3b

Tree SHA

c2dc8e8