Name: custom-metrics
Rating: 59.2 (1 reviews)
Author: launchdarkly

custom-metrics

Create, track, retrieve, update, and delete custom business metrics for configs. Covers full lifecycle: define metric kinds via API, emit events via SDK, and query results.

Quality

74%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

High

Do not use without reviewing

Fix and improve this skill with Tessl

tessl review fix ./skills/agentcontrol/custom-metrics/SKILL.md

Quality

Content

65%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.

Highly actionable, executable guidance with a clear lifecycle structure, weakened by inlined reference-grade material, redundant example sections, and no validation checkpoint before the destructive delete operation. Moving detail out of SKILL.md and adding a confirm-before-delete step would raise both structure scores.

Suggestions

Add a validation checkpoint before delete: retrieve the metric with get_metric() and confirm the key/name with the user (or check isNumeric/kind) before calling delete_metric().

Move the 'Common Tracking Patterns', 'Session Metrics Tracker', and per-operation API snippets into a references/ file (e.g., references/patterns.md, references/api.md), keeping SKILL.md as a concise lifecycle overview with one example per step.

Trim the Complete Workflow Example to the steps not already shown, or fold it into the per-step sections to remove duplication.

Dimension	Reasoning	Score
Conciseness	Prose is lean, but the 460-line body carries avoidable bulk: a Complete Workflow Example that re-invokes already-defined functions, four 'Common Tracking Patterns' functions, and a ~60-line SessionMetricsTracker class. This is more than minor trimming (anchor 4) but not heavily padded explanation (anchor 2).	3 / 5
Actionability	Every operation ships complete, executable Python with real endpoints, headers, and status-code branches (201/409/404/204) that print diagnostic output, plus a clear '{api_token}' substitution convention. The code is copy-paste ready and covers the common cases.	5 / 5
Workflow Clarity	The lifecycle table plus numbered sections 1-5 and the end-to-end example give a clear sequence with status-code feedback, but the destructive delete step has no pre-delete verification (the workflow example even shows delete_metric commented out). Per the judging guidelines, missing validation for destructive operations caps workflow clarity at 3.	3 / 5
Progressive Disclosure	The file has good section structure, but with no bundle files everything is inlined: API reference detail, tracking pattern recipes, and the SessionMetricsTracker belong in reference files. This fits 'some structure but content that should be separate is inline' rather than anchor 4's 'most content appropriately placed'.	3 / 5
	Total	14 / 20 Passed

Description

71%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, action-dense description that clearly states the full metric lifecycle, held back by a missing 'Use when' trigger clause and thin synonym coverage. Adding explicit trigger phrases and naming the platform would lift completeness and trigger-term quality.

Suggestions

Append a trigger clause such as 'Use when the user wants to create, update, or delete custom business metrics, instrument agent events, or query metric results for their LaunchDarkly configs.'

Add natural synonyms users would say (e.g., 'KPIs', 'business telemetry', 'measure/instrument events') to broaden trigger coverage.

Name LaunchDarkly explicitly in the description so it is distinguishable from generic metrics skills and conflicting siblings like built-in-metrics.

Dimension	Reasoning	Score
Specificity	The description lists five concrete CRUD actions ('Create, track, retrieve, update, and delete custom business metrics') and specifies the mechanism for each phase ('define metric kinds via API, emit events via SDK, and query results'), matching the comprehensive-coverage anchor. No gaps in the stated lifecycle remain.	5 / 5
Completeness	The 'what' is clearly and fully stated, but there is no 'Use when...' clause or equivalent trigger guidance, capping completeness at 3 per the judging guidelines. It is not a 4 because the 'when' is entirely absent rather than merely imprecise.	3 / 5
Trigger Term Quality	Natural terms like 'custom business metrics', 'track', 'events', and 'metric kinds' are present, but synonyms users might say (e.g., 'KPIs', 'measure', 'instrument', 'telemetry') are missing. Good coverage with a few natural terms absent fits anchor 4 rather than the comprehensive-synonym anchor 5.	4 / 5
Distinctiveness Conflict Risk	'Custom business metrics for configs' carves a mostly distinct niche (custom vs. built-in metrics), but the unnamed-platform word 'configs' and the generic 'metrics' leave minor overlap risk with sibling metric-related skills. Fits 'mostly distinct; minor overlap risk' rather than the minimal-conflict anchor 5.	4 / 5
	Total	16 / 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: launchdarkly/ai-tooling
Path: skills/agentcontrol/custom-metrics/SKILL.md
Commit: ef54971

Reviewed: 6 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.