Conciseness

The main body is dense and warning-driven with essentially zero explanation of concepts Claude already knows (no "what is serverless" padding; every line carries Netlify-specific facts like "60s execution, 20 MB response" and the ~4 KB env-var cap). The deduction is the appended ~70-line house-rules section where rules 5–13 restate warnings already given above (geo mocking, memory/vcpu, region, included_files, the 4 KB cap, cron UTC conversion, header scope), which is more than a minor trim candidate. This sits above the 3 anchor (mostly efficient) because the duplication reinforces facts rather than padding with known-concept explanation, but below the 5 anchor because those ~70 lines don't each earn their place.

Actionability

Nearly every function variant ships a complete, copy-paste-ready example with its file path in the code fence title ("netlify/functions/hello.mts", "netlify/functions/daily-digest.mts"), plus executable commands like `netlify dev --geo=mock --country=DE` and `netlify functions:invoke <name>` and runnable `netlify.toml` snippets. Common cases (minimal function, path routing, scheduled, background, identity check, legacy migration) are each covered end to end. The only placeholder is the streaming example's `messages: [/* ... */]`, which is inherent to the example; this matches the 5 anchor rather than the 4 anchor.

Workflow Clarity

The content is well-sequenced for its reference nature: modern default handler first, file locations, then a deliberately minimal first example ("No `config` export. Serves at `/.netlify/functions/hello`") before advanced config, with a dedicated "Local testing & deploy" section covering framework dev servers, `netlify dev`, and deploy via Git/CLI. Redeploy checkpoints are stated for env var, region, and runtime changes, and a diagnostic loop exists for background-flag version skew ("check and upgrade the local tooling"). It falls short of the 5 anchor because there is no explicit ordered write → test → deploy → verify-in-logs workflow with validation feedback loops; it stays above the 3 anchor because sequence and most checkpoints are present and no destructive/batch cap applies.

Progressive Disclosure

No bundle files exist and the body references none (only two external doc URLs), so there are zero nested-reference levels and nothing is buried; navigation is easy via ~15 clearly headed sections ordered from basics to legacy. This matches the 4 anchor (good structure, content mostly appropriately placed, minor organization gaps): the gap is that the single monolithic ~320-line file inlines material that could be split out (platform-event handler tables, region/memory reference detail, the legacy Lambda-compat section). It is above the 3 anchor — whose example is unstructured bulk with unclear references — because sectioning is clean and scannable, but below the 5 anchor, whose profile is a concise overview with well-signaled one-level references.

Specificity

The description opens with three concrete verbs ("Write, configure, and deploy Netlify serverless functions in TypeScript, JavaScript, or Go") and then lists many specific actions — "building streaming or AI-proxy responses, scheduling cron jobs, running long background jobs", "setting up rate limiting or region/memory config" — plus a concrete scope list ("file locations, the Request/Context/Response handler shape, path routing, config options, and local testing with netlify dev"). This matches the 5 anchor (multiple specific concrete actions, comprehensive coverage); it is above the 4 anchor because the gaps in coverage are negligible for the domain.

Completeness

It explicitly answers both questions: the "what" is "Write, configure, and deploy Netlify serverless functions in TypeScript, JavaScript, or Go" plus the "Covers..." scope sentence, and the "when" is an explicit "Use this when..." clause listing a dozen concrete trigger phrases. This is a direct match to the 5 anchor's pattern (clear what + explicit when with concrete triggers); the 4 anchor would require the when-clause to be less explicit or specific, which it is not.

Trigger Term Quality

Natural user phrasings are comprehensively covered: "adding an API endpoint or backend route", "adding a contact form handler", "wiring auth", "scheduling cron jobs", "reading environment variables and secrets", "netlify dev". These are the words a user would actually say when needing this skill, with synonym coverage (API endpoint/backend route; auth/Identity signup/login hooks; batch processing/scraping for background jobs). Not the 4 anchor: no commonly used natural term for this domain is missing — even the edge cases (user identity on private/team-login-protected apps, deploy or form events) are named.

Distinctiveness Conflict Risk

The niche is unambiguous — every capability and trigger is anchored to "Netlify serverless functions" (e.g., "identifying which Netlify user is calling a private or team-login-protected app", "reacting to deploy or form events"), so it would not fire for general Netlify deploys, static sites, or other platforms' functions. Distinct triggers and product-anchored language match the 5 anchor (clear niche, minimal conflict risk); it sits above the 4 anchor because even closely related skills (e.g., a general Netlify skill) would only marginally overlap.