CtrlK
BlogDocsLog inGet started
Tessl Logo

review-observability

Review a change for observability. Use as one lens in a code review run.

46

Quality

47%

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 ./code-review-lens-creator/evals/tune-noisy-lens/inputs/review-lenses/review-observability/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%Scale 1-5

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

This skill is well-structured and concise for a review lens, with clear sections covering scope, method, and reporting. However, it lacks actionable specifics—there are no examples of observability gaps, no sample review comments, and no concrete patterns to look for (e.g., missing structured logging fields, absent error-rate metrics, missing trace context propagation). The skill tells Claude what to care about but not what good or bad looks like.

Suggestions

Add 2-3 concrete examples of observability gaps with sample review comments (e.g., 'This HTTP handler has no request logging—recommend adding structured log with method, path, status, and latency').

Provide specific patterns to check for in each scope area: e.g., for Logging—structured fields, error context, PII avoidance; for Metrics—latency histograms, error counters; for Tracing—span creation, context propagation.

Include an example diff snippet showing a before/after of an observability gap and the expected review output format.

DimensionReasoningScore

Conciseness

The content is fairly lean and doesn't over-explain concepts Claude already knows. Minor verbosity in the Threshold section ('observability gaps are cheap to fix at review time and expensive later') is motivational rather than instructional, but overall it's efficient.

4 / 5

Actionability

The skill provides only high-level direction ('consider the observability of each function') without concrete examples of what good/bad observability looks like, what specific log patterns to look for, what metrics to recommend, or example review comments. It tells Claude what to think about but not how to execute.

2 / 5

Workflow Clarity

There is a rough sequence (read diff → assess → report with severity levels), but the steps are loosely defined. The Reporting section provides some structure (summary, critical vs minor, recommendations), but there are no explicit checkpoints or a clear ordered workflow for conducting the review.

3 / 5

Progressive Disclosure

This is a simple, single-purpose skill under 50 lines with no need for external references. The content is well-organized into clear sections (Scope, Method, Threshold, Reporting) that are easy to navigate.

5 / 5

Total

14

/

20

Passed

Description

37%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 too terse and vague to effectively guide skill selection. While it identifies the domain (observability in code review), it lacks concrete actions, natural trigger terms, and explicit guidance on when to select this skill. The phrase 'one lens in a code review run' hints at a multi-skill workflow but doesn't help Claude understand what specific observability concerns this skill addresses.

Suggestions

Add concrete actions the skill performs, e.g., 'Checks for proper logging, metrics instrumentation, tracing spans, and alerting coverage in code changes.'

Expand trigger terms to include natural synonyms users would say: 'logging', 'metrics', 'tracing', 'monitoring', 'instrumentation', 'alerts'.

Make the 'when' clause more explicit, e.g., 'Use when reviewing code changes for observability concerns, or when the user asks about logging, monitoring, or instrumentation in a pull request.'

DimensionReasoningScore

Specificity

Names the domain ('observability' in code review) but the action 'review a change' is generic and no concrete actions are listed (e.g., check logging, verify metrics, inspect tracing).

2 / 5

Completeness

The 'what' is weakly stated ('review a change for observability') and the 'when' is present but vague ('as one lens in a code review run'). The 'when' clause doesn't provide concrete trigger phrases and instead describes a workflow context.

3 / 5

Trigger Term Quality

Contains 'observability' and 'code review' which are relevant but somewhat niche. Missing natural trigger terms users would say like 'logging', 'metrics', 'tracing', 'monitoring', 'alerts', or 'instrumentation'.

2 / 5

Distinctiveness Conflict Risk

The mention of 'observability' as a specific lens provides some distinctiveness, but 'review a change' and 'code review' are broad enough to overlap with other code review skills. The phrase 'one lens in a code review run' suggests it's part of a suite, which helps somewhat but doesn't clearly delineate boundaries.

3 / 5

Total

10

/

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.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
tesslio/product-plugins
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.