CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

posthog-analytics

PostHog analytics, event tracking, feature flags, dashboards

52

Quality

66%

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/posthog-analytics/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is a strong, highly executable reference with real copy-paste code for every major PostHog surface, and it stays focused on project-specific knowledge rather than generic tutorials. Its weaknesses are structural: it is a monolithic 950-line file with no reference files, the batch dashboard-creation workflow lacks any validation checkpoints, and there is enough duplication and teaching-of-known-conventions to warrant trimming.

Suggestions

Move the per-vertical dashboard checklists (~200 lines) and the core-events catalog into reference files (e.g. references/dashboards.md, references/events.md) linked one level deep from SKILL.md — the all-inlined monolith is what holds progressive_disclosure at 3.

Add validation checkpoints to the MCP dashboard workflow (e.g. verify the dashboard was created and the insight query returns rows before adding it to the dashboard), since batch-creating dashboards and insights without verification caps workflow_clarity at 3.

Cut the good/bad event-naming examples and the duplicated dashboard summaries (the Quick Reference table repeats the Project-Specific Dashboards section), and fix the Python snippet's missing 'import os' to tighten conciseness and close the actionability gap.

DimensionReasoningScore

Conciseness

Most of the body is concrete, project-specific code rather than padded explanation, but it could be noticeably tightened: the event-naming good/bad lists ('Too vague', 'Not snake_case', 'Not past tense') teach conventions Claude already knows, and dashboard guidance appears three times (per-vertical checklists, the MCP workflow, and the summary table). Between anchors 2 and 3 — the bulk is genuinely useful material, so it clears 'noticeably verbose' but not 'efficient'.

3 / 5

Actionability

Nearly all guidance is copy-paste-ready executable code covering install, init, identification, tracking, flags, sanitization, and E2E mocking across Next.js, React, Python, and Node. It stops short of anchor 5 due to minor gaps: the Python snippet uses os.environ without importing os, and the mcp_posthog_* calls in the dashboard workflow are illustrative pseudo-invocations rather than exact commands.

4 / 5

Workflow Clarity

The MCP dashboard workflow has a real numbered sequence ('First, check existing dashboards' through '4. Set up key funnels'), but no validation or verification checkpoints anywhere — nothing confirms a dashboard or insight was created correctly before proceeding. Since the workflow batch-creates multiple dashboards and insights, the rubric's cap for batch operations without validation applies, holding this at 3 rather than 4.

3 / 5

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/), so everything is inlined in a single ~950-line SKILL.md. Section headers do provide navigable structure (better than anchor 2's 'minimal structure'), but roughly 200 lines of per-vertical dashboard templates and the full event catalog are content that clearly belongs in separate reference files — exactly anchor 3's 'content that should be separate is inline'.

3 / 5

Total

13

/

20

Passed

Description

61%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 correctly identifies a distinct niche via the PostHog brand and covers the main capability areas with natural trigger keywords, but it is a keyword list rather than a sentence describing actions. Its biggest gap is the absence of any 'Use when...' trigger guidance inside the description itself, which caps completeness at the midpoint.

Suggestions

Add an explicit trigger clause to the description, e.g. 'Use when adding analytics, event tracking, feature flags, or dashboards with PostHog' — a missing 'Use when...' is what caps completeness at 3.

Rewrite the noun list as verb-phrased actions in third person, e.g. 'Implements PostHog event tracking, user identification, feature flags, and product dashboards', to lift specificity from a topic list to described capabilities.

Include natural synonyms users would say — 'product analytics', 'A/B testing', 'experiments', 'instrumentation' — so the description triggers on phrasings that never mention the exact keywords currently listed.

DimensionReasoningScore

Specificity

The description names the domain ('PostHog') and several concrete capability areas ('event tracking, feature flags, dashboards'), but they are presented as a bare noun list with no verb-phrased actions. It sits between anchor 2 (actions minimal) and anchor 4 (several specific actions described); the topic coverage is specific enough to clear the midpoint but no actions are actually described.

3 / 5

Completeness

The 'what' is clear (PostHog analytics, event tracking, feature flags, dashboards), but the description field contains no 'Use when...' clause or equivalent explicit trigger guidance — the when-to-use text lives in a separate frontmatter field outside the evaluated description. Per the rubric guideline, a missing 'Use when' clause caps completeness at 3.

3 / 5

Trigger Term Quality

'PostHog', 'analytics', 'event tracking', 'feature flags', and 'dashboards' are all natural terms a user would say when needing this skill, with the product name acting as a strong trigger. It falls short of anchor 5 because common synonyms and variations like 'product analytics', 'A/B testing', 'experiments', or 'instrumentation' are absent.

4 / 5

Distinctiveness Conflict Risk

Naming 'PostHog' pins a clear niche with minimal conflict risk against unrelated skills. It is not anchor 5 because the unqualified terms 'analytics' and 'dashboards' could still overlap with general analytics or BI skills when PostHog is not mentioned.

4 / 5

Total

14

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (957 lines); consider splitting into references/ and linking

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

14

/

16

Passed

Repository

alinaqi/maggy

Path

skills/posthog-analytics/SKILL.md

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.