clickup-common-errors
Analyze and diagnose ClickUp authentication, authorization, plan, request, pagination, throttling, webhook, and provider failures from redacted evidence. Use when a ClickUp integration fails or behaves inconsistently. Trigger with "ClickUp error", "ClickUp 429", or "diagnose ClickUp API".
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 Error Diagnosis
Overview
Classify the failure before changing code so authentication, workspace scope, plan gates, schema drift, and transient provider faults receive different remedies.
Prerequisites
- A redacted status code, ClickUp error code/message, endpoint version, and request shape
- The authorized Workspace ID, auth mode, and current plan facts from an owner
- Access to current ClickUp docs and status information
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_017can indicate a missing Authorization header; workspace authorization and revoked-token families have distinct codes.- Browser-side CORS failures require a server-side boundary, not a permissive token-bearing frontend workaround.
- A 429 is per token; inspect
X-RateLimit-Limit,X-RateLimit-Remaining, and UnixX-RateLimit-Reset. - Retry only bounded transient failures; do not retry malformed requests or permission denials.
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
- Capture the method, versioned path, status, ClickUp error code, response type, and sanitized headers.
- Confirm whether the caller uses a personal token or OAuth and whether the Workspace was authorized.
- Validate path parameters, JSON content type, endpoint version, pagination cursor/page, and plan eligibility.
- Separate 401/403, 404, 409-style state conflicts, 429, timeout, and 5xx classes.
- Reproduce with the smallest read-only request and compare against the official reference.
- Recommend the narrowest correction and record the post-fix probe.
Approval Boundaries
Do not regenerate credentials, reauthorize Workspaces, upgrade a plan, replay writes, or disclose task content merely to diagnose an error.
Output
Return failure class, evidence, likely cause, safe correction, retry decision, owner action, and verification result.
Error Handling
| Condition | Response |
|---|---|
| Evidence contains a token or work content | Stop, redact it, and rotate the exposed credential if necessary. |
| Workspace scope is unknown | Do not infer permission; obtain authorized Workspace facts. |
| 429 lacks usable reset data | Pause with bounded backoff and re-probe conservatively. |
| Provider status is degraded | Defer writes and retain the incident window. |
Examples
The example below is a redacted operator receipt; it contains no task text, member data, credential, or webhook secret.
status=401; code=OAUTH_017; class=auth-header; retry=no; correction=restore-server-secret-reference