Name: built-in-metrics
Rating: 54.400000000000006 (1 reviews)
Author: launchdarkly

built-in-metrics

Instrument an existing codebase with LaunchDarkly config tracking. Walks the four-tier ladder (managed runner → provider package → custom extractor + trackMetricsOf → raw manual) and picks the lowest-ceremony option that still captures duration, tokens, and success/error.

Quality

60%

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/agentcontrol/built-in-metrics/SKILL.md

Quality

Content

62%

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

The body is a strong, dense operational guide with an excellent sequenced workflow and explicit verification feedback loops, but it keeps a large API method table inline while an unreferenced metrics-api.md sits orphaned alongside it, and it defers all complete code examples to references without a runnable example in the body.

Suggestions

Move the "Quick reference: tracker methods" table into metrics-api.md and link to it, removing the orphaned-reference issue and tightening the body.

Include at least one complete, copy-paste-runnable code block in the body (e.g. a minimal Tier-2 trackMetricsOf example) so the core task is actionable without opening a reference.

Link metrics-api.md from the body (or remove it if redundant) so every bundle file has a clear navigation path.

Dimension	Reasoning	Score
Conciseness	The body is information-dense and avoids explaining concepts Claude already knows, but the large inline "Quick reference: tracker methods" table (which the text itself says is mostly not used directly) overlaps with the unreferenced metrics-api.md and could be tightened or offloaded.	2 / 3
Actionability	It gives concrete API names, exact method signatures, and copy-paste-ready migration mappings (aiclient.config → completion_config), but every complete executable code example is deferred to the reference files, leaving the body without a full runnable example.	2 / 3
Workflow Clarity	A clear four-step sequence (explore → look up tier → implement → verify) with checklists in steps 1 and 4, and the verify step provides an explicit validation checkpoint with feedback loops for error recovery (e.g. the TTFT troubleshooting note).	3 / 3
Progressive Disclosure	Per-provider references are well-signaled and one level deep, but metrics-api.md exists in references/ with no navigation path to it from the body, and the inline tracker-methods table is content that should be separate — matching the score-2 anchor of inline material that belongs in a reference.	2 / 3
	Total	9 / 12 Passed

Description

57%

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

The description is specific and distinctive about its LaunchDarkly metrics-instrumentation niche, but it omits any explicit "Use when..." trigger guidance and leans on SDK jargon over natural user phrasings. It answers "what" well but leaves "when" only implied.

Suggestions

Add an explicit "Use when..." clause naming natural triggers, e.g. "Use when adding LaunchDarkly metrics tracking to an existing AI provider call, or when the user asks to instrument an agent/LLM call with duration, token, and success/error metrics."

Soften SDK-only terms ("four-tier ladder", "trackMetricsOf") in the description or pair them with natural phrasings ("metrics tracking", "instrument an LLM call") so the trigger terms match what a user would actually say.

Consider listing the concrete actions (audit the call site, pick a tracking tier, wire the tracker, verify the Monitoring tab) instead of only the single verb "Instrument" to lift specificity.

Dimension	Reasoning	Score
Specificity	Names the domain and a concrete action ("Instrument an existing codebase with LaunchDarkly config tracking") plus the metrics captured, but it is essentially one primary action with an approach description rather than a comprehensive list of multiple distinct concrete actions as in the score-3 anchor.	2 / 3
Completeness	It clearly answers "what" the skill does, but there is no "Use when..." clause or equivalent explicit trigger guidance for "when" to use it, which per the judging guidelines caps completeness at 2.	2 / 3
Trigger Term Quality	Some relevant keywords a user might say ("LaunchDarkly config tracking", "duration, tokens, and success/error") are present, but the description leans on SDK jargon ("four-tier ladder", "trackMetricsOf", "managed runner", "custom extractor") and misses common natural variations.	2 / 3
Distinctiveness Conflict Risk	It carves a clear niche (LaunchDarkly agent-metrics instrumentation) with specific terminology (config tracking, duration/tokens/success-error, the four-tier ladder) that is unlikely to trigger for the wrong skill.	3 / 3
	Total	9 / 12 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: launchdarkly/ai-tooling
Path: skills/agentcontrol/built-in-metrics/SKILL.md
Commit: add614f

Reviewed: 3 days 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.