maple-nodejs-style

Plain Node.js (Express, Fastify, Hono, Bun) OpenTelemetry style for Maple: NodeSDK + --import bootstrap, native @opentelemetry/api call sites, inline endpoint + ingest key, OTLP HTTP exporters.

Quality

78%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/maple-nodejs-style/SKILL.md

Quality

Content

90%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An excellent, dense style skill: executable end-to-end bootstrap code, pitfall-driven guidance that anticipates real failure modes (ESM hooks, Bun limitations, SDK version drift, logger bridging), and lean prose that assumes Claude's competence. The only structural improvements are an explicit verification step for data arrival and moving long-tail compatibility detail into a reference file.

Dimension	Reasoning	Score
Conciseness	Lean and efficient throughout: no explanation of what OpenTelemetry or tracing is, and every line carries non-obvious knowledge (Bun ignores Node's module hooks, 'console.* is not bridged', HTTP-only exporters to avoid native gRPC bindings). Comments inside code earn their tokens by encoding pitfalls, not restating the obvious.	5 / 5
Actionability	Fully executable, copy-paste-ready: a complete telemetry.ts, the run command 'node --import ./telemetry.js app.js', a concrete route-handler example with try/catch/finally and span status, and exact remediation code for the openai@4 ESM-hook conflict including the 'exclude' data payload. Common cases (Express route, shutdown signals, TypeScript loader choice) are all covered.	5 / 5
Workflow Clarity	The sequence is clear — write telemetry.ts, bootstrap with --import, match installed SDK versions, instrument handlers, bridge the logger — and it includes real error-recovery loops (startup failure after the ESM hook → exclude the incompatible package; wrong processor shape → check the installed .d.ts). Not 5 because there is no step to verify telemetry actually reaches the ingest endpoint, and the sequence is implicit rather than enumerated.	4 / 5
Progressive Disclosure	No bundle files exist, and the single-file body is well-sectioned (Bootstrap rules, Route handlers, Logs, Coexistence) with the essential bootstrap code inline where it belongs. Not 5 because the ~60-line setup block plus version-compatibility notes push past quick-scan territory; a references file for the version-shape matrix and per-logger bridging details would let SKILL.md stay a tighter overview.	4 / 5
	Total	18 / 20 Passed

Description

66%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A dense, specific, third-person description with strong natural framework keywords, but it lacks an explicit 'Use when...' trigger clause, which is its main structural gap. The comma-separated feature list is informative but reads more like a config summary than a capability-plus-trigger description.

Suggestions

Add an explicit trigger clause, e.g. 'Use when instrumenting a Node.js service (Express, Fastify, Hono, Bun) with Maple telemetry or when the user mentions OpenTelemetry, tracing, or observability for a Node app.'

Include the natural synonyms users say — 'tracing', 'telemetry', 'instrumentation', 'observability' — alongside 'OpenTelemetry' to improve trigger recall.

Briefly hint at the fuller scope covered by the body (log bridging, graceful shutdown, coexisting with Sentry/Datadog) so the description is not purely bootstrap-centric.

Dimension	Reasoning	Score
Specificity	Names several concrete capabilities — 'NodeSDK + --import bootstrap, native @opentelemetry/api call sites, inline endpoint + ingest key, OTLP HTTP exporters' — plus four named frameworks. Not a 5 because coverage is bootstrap-centric: log bridging, route-handler instrumentation guidance, and coexistence are not hinted at.	4 / 5
Completeness	The 'what' is clear (an OpenTelemetry style for Maple with a specific SDK bootstrap), but there is no 'Use when...' clause or equivalent explicit trigger guidance — the 'when' is only weakly implied by the framework list. Per rubric guidance, a missing explicit trigger clause caps completeness at 3; it is not 4 because no 'when' is present at all, and not 2 because the 'what' is concrete and specific.	3 / 5
Trigger Term Quality	Good natural-term coverage: 'Plain Node.js (Express, Fastify, Hono, Bun) OpenTelemetry' hits the frameworks a user would name. A few common phrasings users would naturally say are missing, e.g. 'tracing', 'telemetry', 'instrument my app', 'observability'.	4 / 5
Distinctiveness Conflict Risk	A clear niche — Maple-specific Node.js OpenTelemetry — with distinct technical triggers (OTLP, NodeSDK, ingest key). Not 5 because it does not disambiguate from sibling Maple styles for other stacks/languages (the body references 'maple-onboarding-style'), leaving minor overlap risk within the Maple skill family.	4 / 5
	Total	15 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: MapleTechLabs/maple
Path: skills/maple-nodejs-style/SKILL.md
Commit: 1a03fa7

Reviewed: 11 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.