runtime-cache skill: limits table says 64 tags per Runtime Cache item; Vercel's docs and observed behavior both say 128

skills/runtime-cache/SKILL.md (line 251 on main) states:

The Runtime Cache row appears to be wrong — the limit is 128, matching the CDN row.

Evidence

Vercel documentation. vercel.com/docs/runtime-cache § Limits and usage gives Tags per item | 128 tags. The same figure appears at vercel.com/docs/caching/runtime-cache. Both fetched 2026-07-19.

Observed behavior. Two 'use cache: remote' entries deployed on Vercel, differing only in tag count:

• 121 tags — entry stored and served normally
• 131 tags — write rejected, surfacing as Error: invalid response from cache for […]: 400

A cap of 64 would have rejected the 121-tag entry. The boundary sits between 121 and 131, consistent with 128 and inconsistent with 64.

Impact

The limit is enforced by rejecting the write, so an entry that exceeds it silently never stores while the render, the types, and every other check continue to look healthy. A threshold derived from 64 therefore misjudges the safe ceiling in the direction that hides the failure rather than surfacing it.

Because skills installed through npx skills are content-tracked in skills-lock.json, and both skills update and skills experimental_install overwrite local file changes without conflict, the figure can only be corrected here.

Suggested fix

Change the Runtime Cache row to 128. If the two rows are intended to capture a real distinction between the Runtime Cache and CDN layers, stating what that distinction is would help — as written the table implies the limits differ, while the runtime-cache documentation gives a single figure of 128 for tags per item.

Open skills/runtime-cache/SKILL.md around line 251 and compare the Runtime Cache limits table with the linked Vercel documentation. Change the Runtime Cache tags-per-item value from 64 to 128, clarify the distinction between the Runtime Cache and CDN rows if needed, and verify the table matches the cited limits.