CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

adding-product-alerting

Recommended repo-engineering guide when adding alerting to a PostHog product or extending the shared alerts platform. Routes lifecycle state machines, AlertPolicy, destinations, HogFunction dispatch, email, fixed-cadence and calendar scheduling, insight evaluation, the AlertWizard, and shared alert editor components. Use for product alert implementations, shared destination types, lifecycle or scheduling options, advanced alert settings, and platform alert infrastructure. Not for configuring alerts in an existing product.

69

Quality

87%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

—

The risk profile of this skill

SKILL.md
Quality
Evals
Security

Quality

Content

85%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 well-engineered overview: crisp routing, numbered invariants with exact module paths, and an end-to-end test sequence with explicit checkpoints and recovery behavior. The main costs are a duplicated reference listing and total deferral of implementation examples to the (unverifiable) reference files.

Suggestions

Remove one of the two duplicate navigation surfaces: the Reference appendix repeats the four links already given in the Route-first table, so keep only one (or make the appendix cover topics the table cannot route).

Add one minimal inline example — e.g., a stub AlertPolicy or a product-adapter apply_outcome signature — so the core adopt/extend workflow is actionable without first opening a reference file.

Name where the compatibility matrix and lifecycle instrumentation should live (owning file or module), so the end-to-end section's 'keep one explicit compatibility matrix' directive is directly executable.

DimensionReasoningScore

Conciseness

The body is dense and prescriptive and assumes competence (names "products/alerts/backend/facade/lifecycle.py" and "apply_outcome" with no basic-concept explanations), but the "Reference appendix" re-lists the exact four links already present in the "Route first" table's Read column — a trimmable duplication. Above anchor 3 (no unnecessary explanations, just one redundancy); below anchor 5 (that duplicate table does not earn its tokens).

4 / 5

Actionability

Concrete anchors throughout — exact module paths ("products/alerts/backend/facade/scheduling.py"), contract names ("CheckInput", "AlertPolicy"), and a copy-paste-ready instruction ("Please check in with **#project-alerts** before implementation") — but all implementation detail is deferred to the referenced files with no inline example or stub for the core workflow. Above anchor 3 (guidance is specific and executable at the routing/invariant level, not pseudocode); below anchor 5 (no inline example covering the common adopt/extend case).

4 / 5

Workflow Clarity

The end-to-end verification path is a numbered sequence with explicit checkpoints ("Read the alert back and confirm the destination is visible", "records a clear failure"), plus error-recovery behavior ("Restore the pre-check outcome when production fails"), a review checklist of six dimensions, and guardrails like "Never treat an empty match as success without recording why it was empty". Matches anchor 5; anchor 4 would require these checkpoints to be implicit or partially missing, which they are not.

5 / 5

Progressive Disclosure

The "Route first" table gives a per-request Read pointer and the appendix maps topics to files — well-signaled, one-level-deep references with detail appropriately split out of the overview. Note: the four referenced files (adopting/frontend/extending/architecture .md) are not present in the provided bundle, so the links could not be verified; per rubric guidance the score reflects the reference structure as written. Anchor 4 ('minor organization gaps') does not fit — both navigation surfaces are clear and consistent.

5 / 5

Total

18

/

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.

A strong description: explicit what and when with concrete trigger phrases, a comprehensive enumeration of the platform surfaces it routes, and an explicit out-of-scope clause. The only room for improvement is adding natural synonym triggers and more distinct action verbs.

DimensionReasoningScore

Specificity

"Routes lifecycle state machines, AlertPolicy, destinations, HogFunction dispatch, email, fixed-cadence and calendar scheduling, insight evaluation, the AlertWizard, and shared alert editor components" enumerates many concrete platform surfaces, but the distinct action verbs are thin — essentially one routing action ("Recommended repo-engineering guide... Routes...") applied to many objects. Above anchor 3 (coverage far exceeds 1-2 actions) but below anchor 5, which expects multiple distinct concrete actions rather than comprehensive topic listing with few verbs.

4 / 5

Completeness

Explicitly answers what ("Recommended repo-engineering guide when adding alerting to a PostHog product or extending the shared alerts platform") and when ("Use for product alert implementations, shared destination types, lifecycle or scheduling options...") with concrete trigger phrases, and adds a negative-scope clause ("Not for configuring alerts in an existing product"). Clearly anchor 5; anchor 4 would require the 'when' to be less explicit than this 'Use for...' enumeration.

5 / 5

Trigger Term Quality

"Use for product alert implementations, shared destination types, lifecycle or scheduling options, advanced alert settings, and platform alert infrastructure" gives good natural coverage ("adding alerting", "destinations", "scheduling", "alert settings"), but common variations a user might say — "alert rules", "notifications", or specific destination names — are absent. Above anchor 3 (keywords are well-matched, not just 'some relevant'); below anchor 5 (synonym coverage is not comprehensive).

4 / 5

Distinctiveness Conflict Risk

Clear niche (PostHog repo-side alert engineering) with distinct engineering-side triggers, and the explicit exclusion "Not for configuring alerts in an existing product" fences off the nearest sibling skills (alert authoring/configuration). Anchor 4 ('minor overlap risk with closely related skills') undersells it — the main overlap is explicitly excluded rather than merely small.

5 / 5

Total

18

/

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

relative_links

Relative link issues: 9 missing

Warning

referenced_paths_exist

Referenced path issues: 9 missing

Warning

Total

14

/

16

Passed

Repository

PostHog/posthog

Path

.agents/skills/adding-product-alerting/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.