CtrlK
BlogDocsLog inGet started
Tessl Logo

maple-onboarding-style

General OpenTelemetry onboarding style for Maple: native APIs, the business-span pattern, signal quality, inline keys, VCS resource attributes, LLM calls, and smoke checks.

60

Quality

69%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/maple-onboarding-style/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

68%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 exceptionally dense, high-signal style guide: nearly every sentence encodes a Maple-specific rule or semantic-convention key Claude would not otherwise know, backed by an executable reference pattern. Its main weakness is structural — it is a topic reference rather than a sequenced onboarding workflow, leaving step order and the smoke-check validation implicit and dependent on the external `maple-onboard` skill.

Suggestions

Add a short ordered overview at the top (1. bootstrap endpoint/key and resource attributes → 2. instrument business spans → 3. provider instrumentation for LLM calls → 4. smoke check) so the workflow is explicit rather than inferred from section order.

Make the smoke check a real validation loop — specify what failure looks like (no OTLP export attempt, duplicate processors, instrumentation version mismatch) and what to do about it — rather than a conditional suggestion to skip it.

Tighten the "Cost" paragraph (split the OpenRouter include-flag case into its own sentence) and merge the duplicate "do not invent parallel attributes" guidance into one place to earn the top conciseness anchor.

DimensionReasoningScore

Conciseness

The body is dense and imperative throughout — "Do not shell out to `git` from the running process", "skipping the SHA is fine, skipping the URL is not" — and adds only Maple-specific policy Claude would not know (session grouping by `maple_ai.session.id`, OpenInference double-recording, cost-attribute placement rules). Not a 5: the "Cost" paragraph is a long run-on covering many cases, and "do not invent parallel attributes" is stated twice (Naming and VCS sections).

4 / 5

Actionability

The business-span section gives a complete, copy-paste-ready TypeScript example with correct try/catch/finally structure, and later sections name exact keys (`vcs.repository.url.full`, `gen_ai.usage.cost`, `maple_ai.session.id`), env vars (`VERCEL_GIT_COMMIT_SHA`, `GITHUB_SHA`), and metric names (`llm.tokens.input`). Minor gaps keep it below 5: the exporter setup is deferred ("each language skill shows the exact shape") and the endpoint block is a placeholder (`maple_pk_…`) rather than executable init code.

4 / 5

Workflow Clarity

The content is organized by topic, not by an explicit onboarding sequence; the implied order (naming → endpoint/key → resource attributes → signals → LLM calls → smoke checks) must be inferred, and it references external workflow steps ("`maple-onboard` Step 0", "the Step 4 run") without mapping them. The single validation checkpoint — the smoke check — is real but conditional ("If it has none, skip it; the Step 4 run is enough") and has no fix-and-retry feedback loop.

3 / 5

Progressive Disclosure

A single, well-sectioned ~130-line file with clear headers and no nested or buried references; there are no bundle files (no references/, scripts/, or assets/), and nothing clearly belongs in a separate file at this size. Below 5 because it exceeds the under-50-line simple-skill threshold and the long LLM section (instrumentation choice, cost, conversations, redaction) is the one candidate that could split into a reference if the skill grows.

4 / 5

Total

15

/

20

Passed

Description

70%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 specific, well-scoped, distinctive description that accurately previews the body's coverage, weakened by the absence of any explicit "Use when…" trigger clause and by noun-list phrasing rather than action verbs. It would rarely mis-trigger, but relies on the user already knowing they are doing Maple OTel work.

Suggestions

Add an explicit trigger clause, e.g. ". Use when onboarding a repo to Maple OpenTelemetry, instrumenting spans/metrics/logs for Maple, or setting up OTel bootstrap and ingest keys." — this would raise completeness from 3 to 5.

Lead the topic list with verb forms or natural user phrases (instrumenting traces, setting ingest keys, forwarding logs, smoke-checking the bootstrap) so it reads as concrete actions rather than a noun index.

Add the natural synonyms users say — "tracing", "instrumentation", "OTel", "observability" — to widen trigger-term coverage.

DimensionReasoningScore

Specificity

The description enumerates seven concrete, domain-specific areas ("native APIs, the business-span pattern, signal quality, inline keys, VCS resource attributes, LLM calls, and smoke checks") that map one-to-one onto the body's sections. It falls short of the 5 anchor because these are topic nouns rather than verb-led concrete actions ("Extracts text…, fills forms…"), but well above the 3 anchor's "1-2 concrete actions".

4 / 5

Completeness

The "what" is clear (a Maple OTel onboarding style guide covering enumerated areas), but there is no "Use when…" clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines. The "when" is at best weakly implied by the word "onboarding".

3 / 5

Trigger Term Quality

It includes natural terms a user would say — "OpenTelemetry", "onboarding", "LLM", "VCS", "smoke checks" — giving good keyword coverage. Not a 5 because common variations and synonyms users would actually utter are missing: "tracing", "instrumentation", "OTel", "observability", "telemetry".

4 / 5

Distinctiveness Conflict Risk

"General OpenTelemetry onboarding style for Maple" carves out a clear niche — Maple-specific OTel onboarding — with distinct trigger terms (OpenTelemetry, Maple, VCS, smoke checks) and minimal risk of firing for an unrelated skill.

5 / 5

Total

16

/

20

Passed

Validation

100%

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
Reviewed

Table of Contents

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.