clickup-multi-env-setup
Separate ClickUp development, staging, and production identities, Workspaces, callbacks, queues, and data with fail-closed guards. Use when one integration spans multiple environments. Trigger with "ClickUp environments", "ClickUp staging setup", or "ClickUp tenant isolation".
Allowed Tools
Provided by Plugin
clickup-pack
Production-grade Claude Code operator workflows for governed ClickUp integrations (24 skills)
Installation
This skill is included in the clickup-pack plugin:
/plugin install clickup-pack@claude-code-plugins-plus
Click to copy
Instructions
ClickUp Multi-Environment Isolation
Overview
Prevent a development process or callback from crossing into production merely because a shared token can access multiple Workspaces.
Prerequisites
- An environment matrix of OAuth apps or personal tokens, allowed Workspace IDs, callback URLs, queues, and secret references
- Separate non-production data and synthetic verification records
- Deployment and incident owners for every environment
Tool Discipline
Use Read, Glob, and Grep to inspect the repository, adapters, configuration names, tests, and evidence. Use WebFetch only for current official ClickUp documentation. Use Write or Edit after confirming the target file, Workspace boundary, and requested mode.
Current Contract
- OAuth users can authorize one or more Workspaces, so the application must enforce its own environment allow-list.
- Redirect URIs and webhook endpoints are environment-specific and HTTPS.
- Rate limits are per token; sharing a token also shares its budget and blast radius.
- v2 team IDs and v3 Workspace IDs must resolve to the same intended environment boundary.
Authentication
Use a personal token only for accountable individual/testing work or OAuth Authorization Code for a user-facing integration. Inject the token server-side through a governed secret reference, send it in Authorization, verify authorized Workspace IDs, and never print the token, OAuth client secret, or webhook secret.
Instructions
- Inventory every environment's credentials, app IDs, redirects, webhooks, queues, storage, and Workspace IDs.
- Remove shared credentials and assign an accountable owner and rotation path to each secret.
- Implement startup and per-request guards that compare environment and Workspace allow-lists.
- Namespace reconciliation keys, queues, metrics, and callback secrets by environment.
- Run offline cross-environment denial tests and bounded live identity/Workspace probes.
- Publish the matrix and fail deployment if any production boundary is ambiguous.
Approval Boundaries
Do not reuse production credentials or data in lower environments, authorize extra Workspaces silently, or copy production webhook secrets.
Output
Return the environment matrix, shared-boundary findings, guard/test results, live Workspace matches, and unresolved isolation risks.
Error Handling
| Condition | Response |
|---|---|
| One token spans conflicting environments | Disable writes and replace it with separated identities. |
| Workspace ID is not allow-listed | Reject the operation. |
| Callback points to another environment | Do not deploy or register the webhook. |
| Secret owner is unknown | Block promotion until ownership is assigned. |
Examples
The example below is a redacted operator receipt; it contains no task text, member data, credential, or webhook secret.
env=staging; workspace-match=yes; shared-secrets=0; cross-env-tests=pass; writes=disabled