CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

project-observability-analyzer

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

Quality

69%

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

Quality

Content

61%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 an efficient, well-sequenced outline that stays lean, but it reads like a skeleton: every step describes what to do at a high level without a single executable command, code snippet, or template, and the Framework Templates section is an unbacked promise. Adding concrete detection commands and one real integration template would lift actionability and workflow clarity substantially.

Suggestions

Add concrete detection mechanics to the workflow — e.g., 'Check package.json dependencies for express/next; requirements.txt/pyproject.toml for fastapi; build.gradle/pom.xml for spring-boot' — so the Scan/Detect steps are executable rather than named.

Back the 'Framework Templates' section with real content: either inline one minimal Express OTEL/logging config snippet or create reference files (e.g., references/express.md) and link them; remove the section if neither is warranted.

Add a validation checkpoint after file generation — e.g., 'Run docker compose config to validate the generated compose file' or 'Start the stack and confirm the app appears in Grafana/tempo traces' — and an error-recovery note (fix instrumentation, re-verify).

DimensionReasoningScore

Conciseness

The body is lean with zero padding and no explanations of concepts Claude already knows — close to 'Lean and efficient; every token earns its place'. It falls short of 5 because the 'Framework Templates' section is four content-free bullets ('Express.js integration', etc.) that convey no information and earn no tokens.

4 / 5

Actionability

Some concrete guidance exists — named libraries (express-prom-bundle, Winston, Loki, Alloy, LGTM stack, OTEL), named output files (docker-compose-with-app.yml, otel-instrumentation.js), and an example report — but there is no executable code, no commands for scanning/detecting frameworks, and no actual template content, matching 'Some concrete guidance but incomplete; pseudocode instead of executable code'. Not 2, because the workflow steps and example output go beyond high-level hints.

3 / 5

Workflow Clarity

The 7-step sequence is present and sensibly ordered (detect before recommend, recommend before generate), but there are no validation checkpoints anywhere — no step verifies the detected framework is correct or that the generated compose/instrumentation files actually work — matching 'Steps listed but validation gaps; sequence present but checkpoints missing or implicit'. Not 4, which requires most checkpoints to be present.

3 / 5

Progressive Disclosure

A sub-60-line body with clear sections (Workflow, Example Output, Framework Templates) that needs no external references — good structure overall. It falls short of 5 because the 'Framework Templates' section promises four framework integrations that exist neither inline nor in any bundle file, leaving a dangling section that navigates nowhere — a minor organization gap matching 'Good structure; most content is appropriately placed; minor organization gaps'.

4 / 5

Total

14

/

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 is well-formed with both a what and a Use-when clause in third person, but it is thin: it relies on the single keyword "observability" for both capability and triggering, and the "what" is one generic action short of concrete. Adding synonyms (monitoring, metrics, logging, tracing) would materially improve both specificity and trigger coverage.

Suggestions

Expand the what-clause with concrete capabilities: e.g., 'Detect frameworks, logging libraries, and existing instrumentation (OTEL, Prometheus, APM agents), then generate integration files' instead of the generic 'Analyze projects'.

Add natural trigger synonyms users would actually say — 'monitoring', 'metrics', 'logging', 'tracing', 'APM', 'Prometheus', 'Grafana' — to the Use-when clause, e.g., 'Use when the user mentions observability, monitoring, metrics, or tracing for a project'.

Make the when-clause more concrete by naming the signals that should fire it (e.g., 'when the user asks to add monitoring/observability to an app, set up Prometheus or OTEL, or configure log aggregation').

DimensionReasoningScore

Specificity

"Analyze projects and recommend observability integration" names the domain and two actions, but "Analyze projects" is generic and the analysis scope (metrics, logging, tracing, dashboards) is never specified — matching the anchor 'Names domain and 1-2 concrete actions, but not comprehensive', not 4 which requires several specific actions.

3 / 5

Completeness

Both parts are present: what ("Analyze projects and recommend observability integration") and when ("Use when adding observability to projects Claude Code works on"). The when-clause is explicit but somewhat vague and lacks concrete trigger phrases, so it fits 'Has both what and when; when could be more explicit or specific' rather than the fully concrete anchor at 5.

4 / 5

Trigger Term Quality

The only trigger terms are "observability" (twice) and "projects"; common natural variations users would say — monitoring, metrics, logging, tracing, APM, Prometheus, Grafana — are all missing, matching 'Some relevant keywords but missing common variations or synonyms' rather than the good-coverage anchor at 4.

3 / 5

Distinctiveness Conflict Risk

"Observability integration" carves a clear niche with minimal conflict risk, but the broad opener "Analyze projects" gives minor overlap risk with general project-analysis skills, matching 'Mostly distinct; minor overlap risk with closely related skills' rather than the clean-niche anchor at 5.

4 / 5

Total

14

/

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.

Repository

fernandezbaptiste/Skrillz

Path

skills/project-observability-analyzer/SKILL.md

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.