clickup-cost-tuning

v2026.09.24

Reduce ClickUp integration cost and request load using measured traffic, pagination, cache policy, webhooks, and current plan facts. Use when forecasting or optimizing ClickUp operations. Trigger with "ClickUp cost", "reduce ClickUp requests", or "ClickUp plan sizing".

GitHub
安装命令
npx skhub add jeremylongshore/clickup-cost-tuning
Markdown
SKILL.md

ClickUp Integration Cost and Request Tuning

Overview

Optimize from observed request and feature usage without inventing prices or treating a plan upgrade as the default remedy.

Prerequisites

  • Per-endpoint request counts, latency, 429s, page depth, polling intervals, and cache hit rates
  • Current Workspace plan and feature-use facts supplied by an authorized owner
  • Freshness objectives and an approved data-retention policy

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

  • Rate limits are per token and currently vary by Workspace plan.
  • Get Tasks returns at most 100 tasks per page; wasteful full scans multiply requests.
  • Webhook delivery can replace polling but requires secure, durable event processing.
  • Some features and parameters are plan-gated; current commercial price must come from the account owner.

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. Measure requests by endpoint, token boundary, caller, result size, and business operation.
  2. Identify duplicate reads, empty pages, overbroad polling, retry storms, and unnecessary writes.
  3. Model pagination, conditional caching, webhook invalidation, and schedule consolidation.
  4. Quantify custom-field uses and plan-gated operations separately from API request volume.
  5. Compare alternatives against freshness, failure recovery, security, and owner-provided commercial facts.
  6. Implement one bounded change and verify request, latency, error, and staleness deltas.

Approval Boundaries

Do not change a paid plan, reduce required audit/data controls, create broad webhooks, or accept stale work data without owner approval.

Output

Return baseline and projected request volume, feature-use facts, optimization decisions, measured savings, freshness impact, and residual risk.

Error Handling

ConditionResponse
Pricing or plan facts are staleMark the financial estimate incomplete and obtain current account data.
Optimization increases stalenessRoll back or tighten invalidation.
429s persist after request reductionInspect token sharing and reset headers before considering plan changes.
Webhook replacement loses eventsRestore polling fallback and repair durable processing.

Examples

The example below is a redacted operator receipt; it contains no task text, member data, credential, or webhook secret.

window=14d; requests=-38%; p95=-12%; cache-hit=71%; 429=0; freshness-slo=pass; plan-change=no

Resources

发现
标签

此技能尚未发布标签。

版本
最新版本元数据

版本

v2026.09.24

发布时间

2026年9月24日

分类

未分类

许可证

MIT

源路径

skills/.curated/clickup-cost-tuning

默认分支

main

最新提交

e5a6c3b

Tree SHA

c2dc8e8