CtrlK
BlogDocsLog inGet started
Tessl Logo

instrumenting-first-party-metrics

How to instrument PostHog's own Metrics product from PostHog-owned code — record counters, gauges, and histograms that land in posthog.metrics, the same way customers do. Use when adding application metrics in this monorepo (web, Celery, Temporal), when asked to push or ship metrics into posthog metrics, or when unsure whether the SDK in this environment supports posthog.metrics yet. Covers the environment decision (SDK-first per the public docs, OTel fallback when the SDK path is not available), the exact version gates per SDK, what is already wired internally, and how to validate metrics actually arrive.

75

Quality

92%

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

SKILL.md
Quality
Evals
Security

Quality

Content

85%

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

The body is highly actionable and clearly sequenced with strong validation, and its single-file organization is appropriate for a focused operational skill. Its main weakness is inline, time-sensitive version gates that will rot and are not quarantined in a deprecated/old-patterns section.

Suggestions

Quarantine the exact version numbers (7.23.0 / 5.43.0 / ~1.399.0) in a dedicated, clearly-labeled 'Version gates (verify, don't assume)' block or an 'old patterns' section so rot is contained and the core steps stay evergreen.

Add a one-line maintenance note near the version gates flagging them as time-sensitive and pointing to the canonical source (lockfile / changelog) to re-check, so future drift is cheap to correct.

Consider moving the dense 'Dev/test gotchas' and unit-test details in Step 4 into a short referenced section if the file grows, keeping the main validate flow scannable.

DimensionReasoningScore

Conciseness

The body is largely lean and high-signal, but time-sensitive version numbers (posthog-python 7.23.0, posthog-node 5.43.0, posthog-js ~1.399.0) sit inline in Step 2 rather than in a quarantined 'old patterns'/'deprecated' section, which the rubric flags as a conciseness penalty; not level 3 because of this rot-prone inline content, not level 1 because nothing pads basic concepts Claude already knows.

2 / 3

Actionability

Provides fully executable, copy-paste-ready code for both the SDK and OTel paths plus concrete commands (grep against pyproject.toml, bin/verify-metrics-pipe, SQL and MCP tool names) and named reference call sites, matching the top anchor.

3 / 3

Workflow Clarity

A clear four-step sequence (identify environment → version gate → instrument → validate) culminates in an explicit validation step with arrival checks and unit-test guidance, giving the feedback loop the top anchor rewards; not capped at 2 because validation is present and prominent.

3 / 3

Progressive Disclosure

No bundle files exist and all content is genuinely core operational procedure organized under clear section headers with no nested deferrals; the monorepo file paths referenced are concrete anchors, not 'go read this' indirection, so the well-organized single-file structure fits the top anchor for a focused skill.

3 / 3

Total

11

/

12

Passed

Description

100%

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, uses natural third-person trigger language, and answers both what and when with an explicit Use-when clause. It carves out a distinct niche unlikely to collide with other skills.

DimensionReasoningScore

Specificity

Names multiple concrete actions — "record counters, gauges, and histograms that land in posthog.metrics" — matching the anchor that lists several specific concrete actions rather than vague language.

3 / 3

Completeness

Explicitly answers both what ("instrument PostHog's own Metrics product... record counters, gauges, and histograms") and when via an explicit "Use when..." clause, satisfying the top anchor; not level 2 because the when-trigger is stated outright rather than implied.

3 / 3

Trigger Term Quality

Natural trigger phrasing a user would actually say — "adding application metrics", "push or ship metrics into posthog metrics" — gives good coverage of the terms customers/developers use, not just internal jargon.

3 / 3

Distinctiveness Conflict Risk

A tight niche — "PostHog's own Metrics product from PostHog-owned code" with monorepo-specific triggers (web, Celery, Temporal) — makes accidental triggering of unrelated skills unlikely.

3 / 3

Total

12

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
PostHog/posthog
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.