structured-logging-and-observability

Use this skill when building production services, pipelines, or automation that needs to be debugged, monitored, or audited. Add structured logs, metrics, and health checks before shipping any service.

Quality

78%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./memory_data/skills/structured-logging-and-observability/SKILL.md

Quality

Content

72%Weight 40%Scale 1-3

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

The body is admirably concise and well-organized for a short, single-purpose skill, but actionability and workflow clarity lag: metrics and health checks lack executable guidance, and there is no sequencing or verification step. Adding a minimal metrics/health snippet and a brief validate step would lift both dimensions.

Suggestions

Add a short executable example for exposing metrics (e.g. a Prometheus counter or a `/metrics` endpoint) so all three observability pillars have copy-paste-ready code.

Include a concrete health-check implementation snippet (e.g. a FastAPI/Flask `/health` handler) rather than only describing the endpoint.

Add one validation checkpoint, such as confirming structured logs emit valid JSON and `/health` returns 200 before shipping.

Dimension	Reasoning	Score
Conciseness	Lean and efficient with no explanatory padding of concepts Claude already knows; each line (log levels, metrics list, health endpoint, anti-pattern) earns its place. Not a 2 because there is no unnecessary explanation to tighten.	3 / 3
Actionability	Provides one fully executable structlog snippet and a concrete health endpoint, but metrics are only listed ("request rate, error rate, latency (p50/p95/p99), queue depth") with no code or command to expose them. Not a 3 because key implementation details for metrics and health checks are missing; not a 1 because the logging example is copy-paste ready.	2 / 3
Workflow Clarity	Categories (levels, structured logs, metrics, health) are listed but not sequenced into a process, and there are no validation checkpoints confirming logs are structured or the health endpoint responds. Not a 3 because no explicit sequence or verification steps are given; not a 1 because the individual components are clearly labeled.	2 / 3
Progressive Disclosure	Under 50 lines with no need for external references, organized into clear bold-labeled sections. Per the simple-skills note, this satisfies progressive disclosure without separate files. Not a 2 because organization is clean and self-contained.	3 / 3
	Total	10 / 12 Passed

Description

85%Weight 40%Scale 1-3

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 strong: it states concrete capabilities and an explicit use-trigger tied to a well-defined niche. Its main weakness is trigger-term coverage, which leans technical and misses common phrasings like "logging" or "monitoring."

Suggestions

Broaden trigger terms to include natural phrasings users actually say, e.g. "logging", "observability", "monitoring", or "add monitoring to a service".

Keep the concise "Use this skill when..." clause but ensure the trigger list mirrors the skill name's vocabulary so search/recall aligns.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — "Add structured logs, metrics, and health checks" — tied to a named domain (production services, pipelines, automation). Not the level below because it enumerates several specific capabilities rather than naming only a domain and a single action.	3 / 3
Completeness	Explicitly answers both what ("Add structured logs, metrics, and health checks") and when ("Use this skill when building production services..."). Not a 2 because the trigger clause is explicit rather than merely implied.	3 / 3
Trigger Term Quality	Includes relevant natural triggers ("building production services, pipelines, or automation that needs to be debugged, monitored, or audited") but omits common variations users would say like "logging", "observability", or "monitoring setup". Not a 3 because coverage of natural terms is incomplete.	2 / 3
Distinctiveness Conflict Risk	Occupies a clear niche (observability for production services/pipelines/automation) with distinct triggers unlikely to fire for unrelated skills. Not a 2 because the scope is sharply defined rather than broadly overlapping.	3 / 3
	Total	11 / 12 Passed

Validation

93%

Warnings & errors only

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

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: aiming-lab/MetaClaw
Path: memory_data/skills/structured-logging-and-observability/SKILL.md
Commit: 922caf3

Reviewed: 9 days ago

Table of Contents

Discovery Implementation Validation

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.