CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/synthetic-monitor-author

Drafts a synthetic monitor configuration for one critical user journey - picks the platform (Datadog Synthetics, Pingdom, Checkly, New Relic, etc.), authors the scripted-transaction body (Playwright-style for browser checks; HTTP-step for API checks), wires the cadence (typical 1-15 min), defines per-step assertions (DOM presence, API status, response shape) and aggregate alert thresholds (consecutive-failure count + on-call routing). Use when a critical journey needs continuous-in-production verification per ISTQB-canonical shift-right ("a test approach to test a system continuously in production").

70

Quality

88%

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

Overview
Quality
Evals
Security
Files

Quality

Content

85%

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

A well-structured, actionable skill body with a clear sequenced workflow and clean progressive disclosure to a real reference file. The only weakness is the Overview's quoted definitional padding that explains concepts Claude already knows.

Suggestions

Trim the Overview: drop the quoted Wikipedia/ISTQB definitions of synthetic monitoring and shift-right, keeping only the one-line framing of what this skill builds.

Replace the citation-heavy sentences with a single lean sentence on why synthetic monitors are the shift-right primitive.

Leave the steps, tables, and code excerpts as-is — they are the body's strengths.

DimensionReasoningScore

Conciseness

The body is mostly lean with tables and code excerpts, but the Overview spends ~10 lines quoting definitions of synthetic monitoring and shift-right — concepts and citations Claude already knows — which the rubric explicitly penalizes as unnecessary explanation.

2 / 3

Actionability

Provides executable Playwright TS and YAML API excerpts, a concrete alert/CI config, cadence and platform tables, and a file tree — copy-paste-ready with full templates deferred to the reference file.

3 / 3

Workflow Clarity

A clear 8-step sequence from journey selection through as-code lifecycle, with the CI smoke check ('npx checkly test --reporter ci') before deploy serving as the validation checkpoint for this non-destructive authoring workflow.

3 / 3

Progressive Disclosure

Well-signaled one-level-deep references to references/monitor-templates.md (cited in Steps 3 and 4), with the bundle file present and matching the referenced path; full templates are correctly split out of the overview body.

3 / 3

Total

11

/

12

Passed

Description

85%

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, specific description with explicit 'what' and 'when' guidance and a clear niche. Its main weakness is a jargon-heavy trigger clause ('ISTQB-canonical shift-right') that is not a natural user utterance, and it lacks common everyday synonyms for synthetic monitoring.

Suggestions

Rewrite the 'Use when' trigger in plain user language (e.g., 'Use when a critical user journey needs uptime or availability monitoring in production') and drop the quoted ISTQB definition.

Add common natural synonyms users would actually say — 'uptime monitor', 'ping check', 'availability check', 'production health check'.

Keep the concrete action list; it is the strongest part of the description.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — 'picks the platform', 'authors the scripted-transaction body', 'wires the cadence', 'defines per-step assertions', and 'alert thresholds' — matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

Clearly answers both 'what' (the enumerated authoring actions) and 'when' via an explicit 'Use when a critical journey needs continuous-in-production verification' clause.

3 / 3

Trigger Term Quality

Includes relevant terms ('synthetic monitor', 'critical user journey', platform names) but the trigger clause leans on jargon ('ISTQB-canonical shift-right' plus a quoted definition) that a user would not naturally say, and omits common variations like 'uptime monitor' or 'ping check'.

2 / 3

Distinctiveness Conflict Risk

Occupies a clear niche — drafting synthetic monitor configs for critical journeys — distinct from sibling skills like feature-flag-experiment-validator and prod-canary-validator, with triggers unlikely to fire for the wrong skill.

3 / 3

Total

11

/

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.

Reviewed

Table of Contents