CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

observability-pattern-detector

Automated pattern recognition in Claude Code telemetry. Use when detecting failures, slowness, anomalies, trends, inefficiencies, conversation patterns, or tool sequences.

Quality

72%

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 ./.claude/skills/observability-pattern-detector/SKILL.md

The canonical home for this skill is observability-pattern-detector in fernandezbaptiste/Skrillz

SKILL.md
Quality
Evals
Security

Quality

Content

57%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.

A well-organized operations reference with concrete, executable LogQL queries for each detection type and clear output descriptions. Its weaknesses are a duplicated 'Pattern Detection Queries' section that repeats the Operations content, missing orchestration/usage guidance for the scripts it advertises, and a bundle mismatch: only 1 of 5 referenced scripts exists, and the one bundled script queries {job="claude_code"} rather than the {job="claude_code_enhanced"} source the body documents.

Suggestions

Remove or merge the 'Pattern Detection Queries' section (lines 167–203) into the Operations sections, since it duplicates failure, tool-sequence, session-anomaly, and context queries that already appear above — this would tighten conciseness to anchor 4/5.

Fix the bundle mismatch in the Scripts section: either add the four missing scripts (detect-anomalies.sh, detect-trends.sh, detect-sequences.sh, generate-pattern-report.sh) or trim the list to scripts/detect-failures.sh, and align its {job="claude_code"} query with the documented {job="claude_code_enhanced"} data source and consistent field names (tool_name, previous_tool).

Add a short workflow section explaining when to prefer each operation and how to invoke the scripts (e.g., ./scripts/detect-failures.sh 7d 5 with LOKI_URL) so the per-operation recipes chain into the advertised 'full pattern report'.

DimensionReasoningScore

Conciseness

Per-operation sections are lean (query + one-line algorithm + output), but the 'Pattern Detection Queries' section (lines 167–203) substantially duplicates material already covered in Operations — failure queries, tool sequences, session anomalies, and context patterns each appear twice with near-identical LogQL. That ~35 lines of repetition is unnecessary content that could be tightened, matching anchor 3 ('mostly efficient but includes some unnecessary explanation or could be tightened') rather than anchor 2, since there is no concept over-explanation or padded prose.

3 / 5

Actionability

Each of the 11 operations ships a concrete, copy-paste-ready LogQL query plus expected output shape — mostly executable guidance per anchor 4. Minor gaps keep it below anchor 5: the Scripts section lists five scripts but only scripts/detect-failures.sh exists; scripts/ usage (arguments like SINCE/THRESHOLD) is never shown; and field naming is inconsistent across queries ('tool_name' after |json in some, label 'tool="Task"' and '.previous_tool' in others), some of which will not run as written against the documented source.

4 / 5

Workflow Clarity

Each operation has an implicit mini-sequence (run query → group → rank/output) stated via one-line 'Algorithm' notes, but there is no orchestration guidance: when to prefer which operation, how operations chain into the referenced 'generate-pattern-report.sh' full report, or how scripts are invoked. This matches anchor 3 ('steps listed but validation gaps; sequence present but checkpoints missing or implicit'). Not lower: the operations are read-only queries, so the destructive/batch validation cap does not apply, and the per-op sequence itself is unambiguous.

3 / 5

Progressive Disclosure

The body is well-sectioned into one-level operations with inline queries that do not require external files, and script references are clearly signaled — but scored against the actual bundle, 4 of the 5 referenced script paths (detect-anomalies.sh, detect-trends.sh, detect-sequences.sh, generate-pattern-report.sh) do not exist, making those navigation pointers dead. This sits between anchors 2 and 3: structure is good and references are clearly signaled (not buried), but the dangling script references break the bundle navigation, so anchor 3 fits best.

3 / 5

Total

13

/

20

Passed

Description

75%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.

A well-formed description with an explicit 'Use when...' trigger clause, good natural keyword coverage, and a clearly bounded Claude Code telemetry niche. Its main limitation is that the 'what' statement ('Automated pattern recognition') is more abstract than the concrete action list in the anchor-5 examples, and a few obvious synonyms (errors, slow, waste) are absent. No third/second person violations were found.

DimensionReasoningScore

Specificity

The description names the domain ('Automated pattern recognition in Claude Code telemetry') and lists several specific capability areas ('detecting failures, slowness, anomalies, trends, inefficiencies, conversation patterns, or tool sequences'), but the core action is a single abstract verb ('pattern recognition') and it never states what is done with results, so it falls between anchors 4 and 5, matching 'several specific actions; minor gaps in coverage' more than the fully concrete anchor-5 example.

4 / 5

Completeness

Both parts are explicitly present: 'what' ('Automated pattern recognition in Claude Code telemetry') and a clear 'when' ('Use when detecting failures, slowness, anomalies, trends, inefficiencies, conversation patterns, or tool sequences'). The when-clause is fully explicit with concrete triggers, but the what-statement is more abstract than the anchor-5 example ('Extract text and tables from PDF files, fill forms...'), so it sits between anchors 4 and 5.

4 / 5

Trigger Term Quality

Natural trigger keywords are well covered — 'failures', 'slowness', 'anomalies', 'trends', 'inefficiencies', 'conversation patterns', 'tool sequences' are phrases a user would plausibly say. Common synonyms like 'errors', 'slow responses', or 'waste' are missing, so it matches anchor 4 ('good keyword coverage; a few natural terms missing') rather than anchor 5's synonym-and-extension completeness.

4 / 5

Distinctiveness Conflict Risk

'Claude Code telemetry' carves out a distinct niche unlikely to collide with unrelated skills, and the enumerated detection types (conversation patterns, tool sequences, context issues) are domain-specific. Generic observability terms like 'failures' and 'trends' retain some overlap risk with general log-analysis skills, matching anchor 4 ('mostly distinct; minor overlap risk with closely related skills').

4 / 5

Total

16

/

20

Passed

Validation

93%

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

CriteriaDescriptionResult

referenced_paths_exist

Referenced path issues: 4 missing

Warning

Total

15

/

16

Passed

Repository

fernandezbaptiste/Skrillz

Path

.claude/skills/observability-pattern-detector/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.