clickup-multi-env-setup

v2026.09.24

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

GitHub
安装命令
npx skhub add jeremylongshore/clickup-multi-env-setup
Markdown
SKILL.md

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

  1. Inventory every environment's credentials, app IDs, redirects, webhooks, queues, storage, and Workspace IDs.
  2. Remove shared credentials and assign an accountable owner and rotation path to each secret.
  3. Implement startup and per-request guards that compare environment and Workspace allow-lists.
  4. Namespace reconciliation keys, queues, metrics, and callback secrets by environment.
  5. Run offline cross-environment denial tests and bounded live identity/Workspace probes.
  6. 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

ConditionResponse
One token spans conflicting environmentsDisable writes and replace it with separated identities.
Workspace ID is not allow-listedReject the operation.
Callback points to another environmentDo not deploy or register the webhook.
Secret owner is unknownBlock 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

Resources

发现
标签

此技能尚未发布标签。

版本
最新版本元数据

版本

v2026.09.24

发布时间

2026年9月24日

分类

未分类

许可证

MIT

源路径

skills/.curated/clickup-multi-env-setup

默认分支

main

最新提交

e5a6c3b

Tree SHA

c2dc8e8