CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/synthetic-monitor-author

Use when a critical user journey needs continuous checks in production, or monitor coverage was never derived from real usage. Writes a synthetic monitor for Datadog, Pingdom, Checkly or New Relic with browser or API steps, cadence, checks and alerts, and ranks unmonitored journeys from RUM data.

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

Quality

Content

77%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 delivers a well-sequenced, highly actionable workflow with verified one-level-deep references and explicit validation gates, capped by a useful anti-patterns table. Its main cost is token efficiency: redundant definitions, a duplicated cadence prose/table pair, and thrice-repeated locator advice inflate the body without adding guidance.

Suggestions

Collapse Step 5's opening paragraph and cadence table into a single table plus one sentence ("Default 5 min; match the cadence to the SLO budget") to remove the duplicated guidance.

Cut the Overview's Wikipedia and ISTQB definition quotes down to one line each (or drop them), since synthetic monitoring and shift-right are concepts Claude already knows.

State the accessibility-first-locator rule once (Step 3) and drop its verbatim repetition in monitor-templates.md and the anti-patterns table, replacing those with cross-references.

DimensionReasoningScore

Conciseness

The Overview quotes Wikipedia and the ISTQB glossary to define synthetic monitoring and shift right (concepts Claude already knows), Step 5 states the cadence guidance twice as prose then a near-duplicate table, and the accessibility-locator warning is repeated in Step 3, in monitor-templates.md, and as an anti-pattern row. Mostly efficient but with several instances that could be tightened fits anchor 3, not 4, since the redundancy goes beyond minor trimming.

3 / 5

Actionability

Concrete Playwright and YAML excerpts, exact CI commands ("npx checkly test --reporter ci", "npx checkly deploy --force"), real API endpoints ("GET /api/v1/synthetics/tests"), and a numeric scoring rubric make the guidance mostly executable. Minor gaps keep it below the fully copy-paste anchor: the inline browser check elides steps, configs are labeled "Checkly-style" approximations rather than exact schemas, and "runtimeId: 2024.02" is a version-stamped value; it is noticeably above the midpoint, so 4 rather than 3.

4 / 5

Workflow Clarity

A clear 8-step sequence with an explicit validation gate ("no RUM source, no gap analysis... halt and say so"), a pre-deploy CI smoke check, a feedback loop ("Feed the ranked gap list back into this step"), and an anti-patterns table as a checklist. This matches the anchor requiring explicit validation steps and feedback loops; not 4, since checkpoints are explicit rather than implicit.

5 / 5

Progressive Disclosure

Both referenced files (references/monitor-templates.md, references/rum-source-queries.md) exist, are one level deep with no nested references, and are clearly signaled at the point of use, with full templates and per-source queries appropriately externalized. Matches the clear-overview anchor with well-signaled one-level-deep references; not 4, since navigation and placement have no real gaps.

5 / 5

Total

17

/

20

Passed

Description

92%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 exemplary: it pairs an explicit "Use when" trigger clause with a concrete, platform-specific statement of what the skill does. Its only weakness is slightly narrow trigger vocabulary that omits common synonyms such as "uptime check" or "availability monitoring".

DimensionReasoningScore

Specificity

"Writes a synthetic monitor for Datadog, Pingdom, Checkly or New Relic with browser or API steps, cadence, checks and alerts, and ranks unmonitored journeys from RUM data" lists multiple specific concrete actions with named platforms and no coverage gaps. This matches the comprehensive anchor, not 4, since nothing significant is missing.

5 / 5

Completeness

"Use when a critical user journey needs continuous checks in production, or monitor coverage was never derived from real usage" explicitly answers when, and "Writes a synthetic monitor... and ranks unmonitored journeys from RUM data" explicitly answers what. Both are concrete and explicit, matching the top anchor; not 4, since the when clause is specific rather than generic.

5 / 5

Trigger Term Quality

Strong natural keywords ("synthetic monitor", "continuous checks in production", "critical user journey", "monitor coverage", "RUM data", plus four platform names), but common user phrasings like "uptime check", "health check", or "availability monitoring" are absent. Good coverage with a few natural terms missing fits anchor 4, not 5's comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

A clear niche (authoring synthetic monitors on named platforms plus RUM gap ranking) with distinct trigger phrases; only trivial overlap risk with general observability skills. Matches the clear-niche anchor; not 4, since no closely related skill would plausibly capture these triggers.

5 / 5

Total

19

/

20

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

On this page