analytics-instrumentation

Add product analytics (BI) events to Opik features. Use when wiring events on the frontend, the backend, or the Python SDK - all three report through Segment to PostHog.

Quality

86%

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

Quality

Content

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

A highly actionable, information-dense skill: real paths, runnable code, justified don'ts, and an explicit local-verification loop for the Python SDK path. Its main weaknesses are the absence of verification steps for the frontend and backend paths and the monolithic single-file structure, where Python SDK internals and per-surface details would be better split into one-level-deep reference files.

Suggestions

Split the Python SDK "How it works" internals (thread/fork dedup rules, worker lifecycle, rule registration) into a one-level-deep reference file (e.g. references/python-sdk-internals.md), keeping the API and the 7-step add-an-event procedure inline in SKILL.md.

Add a short verification step to the frontend and backend "Adding a new event" sections (e.g. how to confirm the event reaches Segment/PostHog in a dev environment), mirroring the Python SDK's step 6.

Tighten the backend reactive-chain rationale ("Why offload" / "Why explicit identity") into a compact two-line rule with the code example, moving the deeper Guice-scope and JDBC-fallback explanation to a reference.

Dimension	Reasoning	Score
Conciseness	Nearly every token is codebase-specific knowledge Claude cannot know (exact file paths, scheduler-threading rationale, env-var semantics, PR references), with no padding about general concepts. It is not a 5 because several explanatory passages (e.g. the fork/spawn counting rules and the reactive-chain "Why offload"/"Why explicit identity" prose) could be stated more compactly.	4 / 5
Actionability	Concrete file paths, real API signatures, copy-paste-ready TypeScript/Java/Python snippets, and exact commands ("cd sdks/python && pytest tests/unit/analytics # 67 tests") cover all three surfaces. The few placeholders ("..." for the call site, "someDao.write(...)" in the reactive template) are explicitly justified pattern examples with explanatory comments, matching the top anchor.	5 / 5
Workflow Clarity	The frontend and Python SDK paths give clear numbered sequences, and the Python path includes an explicit validation checkpoint (step 6 "Verify it locally" with an HTTP-interception script plus a test-suite run). It falls short of 5 because the frontend and backend "Adding a new event" paths end without any verification step, and the backend path is organized by scenario rather than as a sequenced procedure.	4 / 5
Progressive Disclosure	The body is well-sectioned with clear headers, but at ~320 lines everything is inlined in SKILL.md with no bundle files. Content that clearly belongs in a reference file is inline — notably the Python SDK "How it works" internals (fork/spawn counting, dedup rules, worker lifecycle) and the per-surface file inventories. The structure is present and navigable, which keeps it above the minimal-structure anchor, but the missing split matches the "some structure, content that should be separate is inline" anchor.	3 / 5
	Total	16 / 20 Passed

Description

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

The description is strong: it explicitly answers what the skill does and when to use it, with concrete trigger surfaces and a distinctive pipeline reference. Its only weakness is slightly thin coverage of natural synonyms (tracking, telemetry, instrumentation) and a single-action framing rather than a fuller capability list.

Dimension	Reasoning	Score
Specificity	"Add product analytics (BI) events to Opik features" names the domain and a concrete action, and the three surfaces ("frontend, the backend, or the Python SDK") plus the Segment-to-PostHog pipeline give several specifics. It stays below a 5 because it describes one action (adding events) rather than a fuller inventory of concrete operations.	4 / 5
Completeness	The "what" is explicit ("Add product analytics (BI) events to Opik features") and the "when" is explicit with concrete trigger phrases ("Use when wiring events on the frontend, the backend, or the Python SDK"). This matches the top anchor: both questions answered clearly and explicitly.	5 / 5
Trigger Term Quality	Natural terms a user would say are present: "analytics", "BI", "events", "wiring events", "frontend", "backend", "Python SDK", plus ecosystem names (Segment, PostHog, Opik). A few natural synonyms like "tracking", "telemetry", or "instrumentation" are missing, keeping it below the comprehensive anchor.	4 / 5
Distinctiveness Conflict Risk	The description is scoped to Opik's specific analytics pipeline ("all three report through Segment to PostHog"), giving it a clear niche with distinct triggers and minimal overlap risk with generic analytics or instrumentation skills.	5 / 5
	Total	18 / 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: comet-ml/opik
Path: .agents/skills/analytics-instrumentation/SKILL.md
Commit: 657e319

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.