project-observability-analyzer

Analyze projects and recommend observability integration. Use when adding observability to projects Claude Code works on.

Quality

56%

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 ./skills/project-observability-analyzer/SKILL.md

Quality

Content

50%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 is concise and the discovery-to-generation workflow is well sequenced, but it stops at high-level description: no executable instrumentation code or commands, no validation checkpoints for the batch file generation, and the Framework Templates section is an empty stub. It reads as an outline rather than executable guidance.

Suggestions

Add executable snippets for at least the primary path — a real docker-compose-with-app.yml excerpt, an otel-instrumentation.js sample, and the Winston→Loki config — instead of only listing filenames.

Insert a validation checkpoint into the workflow (e.g. 'Verify detected framework against package manifests before generating files' and 'Confirm generated docker-compose.yml validates with docker compose config').

Either fill in each Framework Templates entry with framework-specific integration steps or split them into one-level-deep reference files (e.g. templates/express.md) and link them with 'See …'.

Dimension	Reasoning	Score
Conciseness	The body is lean and bullet-driven with no padding or explanations of concepts Claude already knows; the only minor inefficiency is the intro line restating the description, which keeps it just below the every-token-earns-its-place anchor.	4 / 5
Actionability	The workflow gives high-level hints (named frameworks, named output files like docker-compose.yml and otel-instrumentation.js) but contains no executable code or commands and the Framework Templates section is empty, matching the minimal-concrete-guidance / missing-specific-steps anchor rather than the pseudocode anchor above.	2 / 5
Workflow Clarity	The 7 steps are clearly sequenced (discover → detect → recommend → generate), but there are no validation or verification checkpoints for the batch file-generation step, which caps workflow clarity at 3 per the destructive/batch-operation rule.	3 / 5
Progressive Disclosure	Existing sections are cleanly delineated, but the Framework Templates section is a bare stub listing four frameworks with no content and no reference files behind them, a navigation gap worse than the minor-organization-gaps anchor.	3 / 5
	Total	12 / 20 Passed

Description

62%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 cleanly answers both what and when with an explicit 'Use when' trigger and a distinct observability niche, but its actions stay high-level and it leans on a single keyword/trigger phrase without synonyms. It is solid but one notch below exemplary on specificity and trigger coverage.

Suggestions

Swap the generic 'Analyze projects' for concrete actions, e.g. 'Scan project structure, detect frameworks and existing logging, and recommend OTEL/Prometheus instrumentation'.

Broaden trigger terms to include natural synonyms users say: monitoring, telemetry, metrics, logs, tracing, APM — e.g. 'Use when adding monitoring, logging, tracing, or observability to a project'.

Add a second trigger condition covering user-mentions phrasing, e.g. 'or when the user asks to set up metrics, logs, or tracing'.

Dimension	Reasoning	Score
Specificity	It names the observability domain and two actions ("Analyze projects" and "recommend observability integration"), but "Analyze projects" is generic and tells nothing about what is analyzed, so it sits at the 1-2-concrete-actions-but-not-comprehensive anchor rather than the multi-action anchors above.	3 / 5
Completeness	Both halves are explicit — "Analyze projects and recommend observability integration" answers what, and "Use when adding observability to projects Claude Code works on" answers when — but the when clause offers only a single trigger scenario rather than the multiple concrete trigger phrases of the top anchor.	4 / 5
Trigger Term Quality	The phrase "adding observability" supplies the key natural keyword a user would say, but no synonyms or variations are present (monitoring, telemetry, metrics, logs, tracing, APM), matching the "some relevant keywords but missing common variations" anchor.	3 / 5
Distinctiveness Conflict Risk	Observability integration is a clear niche with a distinct trigger, but the generic opening "Analyze projects" leaves minor overlap risk with general project-analysis or devops skills, keeping it just below the minimal-conflict anchor.	4 / 5
	Total	14 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: fernandezbaptiste/Skrillz
Path: skills/project-observability-analyzer/SKILL.md
Commit: 93ed392

Reviewed: 1 day 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.