| name | intercom-multi-env-setup |
| description | Configure Intercom across development, staging, and production workspaces.
Use when setting up multi-environment deployments, configuring per-environment
access tokens, or implementing workspace isolation.
Trigger with phrases like "intercom environments", "intercom staging",
"intercom dev prod", "intercom environment setup", "intercom workspace isolation".
|
| allowed-tools | Read, Write, Edit, Bash(aws:*), Bash(gcloud:*), Bash(vault:*) |
| version | 1.6.0 |
| license | MIT |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| tags | ["saas","support","messaging","intercom"] |
| compatibility | Designed for Claude Code |
Intercom Multi-Environment Setup
Overview
Configure separate Intercom workspaces for development, staging, and production with environment-specific access tokens, webhook URLs, and safety guards. This skill establishes a single config loader, an environment-aware client factory, per-platform secret storage, and production guards so the same codebase behaves correctly in every environment.
The full step-by-step code lives in references/implementation.md; this file carries the workflow and the Step 1 skeleton so you can follow it end to end, then drill into the reference for depth.
Prerequisites
- Separate Intercom workspaces (or at minimum, separate apps in Developer Hub)
- Secret management solution (Vault, AWS Secrets Manager, GCP Secret Manager)
- CI/CD pipeline with environment variable support
Environment Strategy
| Environment | Workspace | Token Type | Data | Webhooks |
|---|
| Development | Dev/sandbox workspace | Dev access token | Test data | localhost via ngrok |
| Staging | Staging workspace | Staging token | Seed data | staging.example.com |
| Production | Production workspace | Production token | Real data | api.example.com |
Instructions
Work through six steps. Read the Step 1 skeleton below to see the shape of the config, then open references/implementation.md for the complete code of every step.
- Environment Configuration — a single
loadConfig() reads NODE_ENV and merges shared secrets with per-environment defaults (debug, cache TTL, rate-limit concurrency). Skeleton below.
- Environment-Aware Client Factory — a lazily-initialised
getClient() that throws a clear, environment-named error when the token is missing.
- Secret Management by Platform — store tokens in git-ignored
.env.<environment> files locally and in GitHub Actions, AWS Secrets Manager, GCP Secret Manager, or HashiCorp Vault in CI/prod.
- Production Safety Guards — an
EnvironmentGuard with requireProduction() / preventProduction() so destructive jobs can never fire in the wrong workspace.
