Add telemetry for detecting whether AI coding agents have Cloudflare skills installed

[dario-piotrowicz]

Wrangler now includes a currentAgentSkillsInstalled property in telemetry events that reports whether the current AI coding agent has Cloudflare skills present on disk. The value distinguishes between skills installed automatically by Wrangler ("automatic"), skills installed manually by the user ("manual"), no skills present (false), or no supported agent detected (null). Skill names are fetched from the GitHub Contents API with a 24-hour disk cache to avoid rate limits.

---

• Tests
  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: telemetry.md updated

A picture of a cute animal (not mandatory, but encouraged)

[changeset-bot]

🦋 Changeset detected

Latest commit: fbac658

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
wrangler	Minor
@cloudflare/vite-plugin	Patch
@cloudflare/vitest-pool-workers	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

✅ All changesets look good

[ask-bonk]

Now let me verify one concern I have: the changeset says minor for wrangler, but this is purely a telemetry change (no new user-facing feature or API). The PR description mentions it also bumps @cloudflare/vite-plugin and @cloudflare/vitest-pool-workers as patch — but the changeset file only mentions wrangler. The changesetbot shows those other bumps though, so they might come from dependency propagation. Let me check if minor is correct for a telemetry-only change.

Looking at the changeset rules: patch for bug fixes, minor for new features. This is arguably a new feature (new telemetry property), so minor is justifiable.

Let me now check one more thing — the sendCommandEvent path doesn't await currentAgentSkillsInstalled, but it does call dispatch() directly. Since dispatch() now returns Promise<void> | void instead of being void-only, and trackDispatch handles both cases, this is fine.

Let me look at the accepted: false case in the metadata — when the user declined, the metadata has accepted: false and no installFailed. In computeTelemetryCurrentAgentSkillsInstalled, the logic at line 524-529 checks metadata.accepted && isInDetectedAgents === true && !installFailedForAgent. If the user declined (accepted: false), this returns "manual". That makes sense — skills exist but weren't installed by wrangler (because the user said no, someone else put them there).

Now I've finished my analysis. Let me determine if there are actionable issues:

1. sendCommandEvent doesn't include currentAgentSkillsInstalled: This is an intentional design choice (avoids async overhead in the synchronous command event path). Not a bug.

2. amplitude_event_id ordering change: The event ID increment for adhoc events now happens asynchronously instead of synchronously. This is a subtle behavioral change but not a bug given adhoc events are explicitly "not tied to command events."

3. Potential issue with the sendAdhocEvent wrapping: When telemetryCurrentAgentSkillsInstalled() is memoised and already resolved, the .then() runs as a microtask, so it's nearly synchronous. When it's still pending (e.g., waiting on GitHub API), the entire event dispatch is delayed. This means telemetry events could be delayed until the GitHub fetch completes (or times out). The memoization helps, but the first call could still be slow.

Actually wait — let me think about issue #3 more carefully. The telemetryCurrentAgentSkillsInstalled() call could potentially make a network request to GitHub. If this is the first invocation and there's no cache, it calls fetchSkillNamesFromGitHub() which does fetch(SKILLS_REPO_CONTENTS_URL). This fetch has no timeout configured. If the GitHub API is slow or unreachable, the telemetry event dispatch would be blocked until that fetch resolves or the underlying TCP timeout kicks in. However, the process exit handler in index.ts races allMetricsDispatchesCompleted() against a 1-second timeout, so it wouldn't block process exit. The event would just be lost. This is the same behavior as the existing telemetry fetch to Sparrow, so it's consistent.

Actually, there IS a real issue here. The undici fetch call to GitHub has no timeout, but more importantly: even in the non-agent case (where detectAgenticEnvironment returns isAgentic: false), telemetryCurrentAgentSkillsInstalled() is called and awaited. In that case it returns null immediately (synchronously from the memoised promise after first microtask resolution). So this is fine — no network call for non-agent users.

For agent users, the GitHub API call runs in parallel with whatever the command is doing, and the telemetry event just includes the result when it's ready. The process exit timeout protects against it being too slow.

I think this PR is well-constructed. The code is clean, tests are comprehensive, and the error handling is solid. Let me double-check one potential concern with the readSkillsRepoCache — can cache.lastUpdate be undefined if the JSON is malformed? In that case, undefined + SKILLS_REPO_CACHE_TTL_MS = NaN, and NaN > Date.now() = false, which would correctly fall through to return undefined. So even malformed cache data is handled correctly.

Overall, this is a clean, well-tested PR. No actionable issues found.

LGTM

github run

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@14009

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@14009

miniflare

npm i https://pkg.pr.new/miniflare@14009

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@14009

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@14009

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@14009

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@14009

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@14009

@cloudflare/workers-utils

npm i https://pkg.pr.new/@cloudflare/workers-utils@14009

wrangler

npm i https://pkg.pr.new/wrangler@14009

commit: fbac658

[workers-devprod]

Codeowners approval required for this PR:

• ✅ @cloudflare/wrangler

Show detailed file reviewers

[workers-devprod]

Codeowners reviews satisfied