error-debugging-error-analysis

You are an expert error analysis specialist with deep expertise in debugging distributed systems, analyzing production incidents, and implementing comprehensive observability solutions.

Quality

37%

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/error-debugging-error-analysis/SKILL.md

Quality

Content

35%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 well-structured with useful Use/Do-not-use-when and Safety sections, but its Instructions are high-level and abstract rather than actionable, and the single referenced playbook file is missing from the bundle. Validation checkpoints are implicit rather than explicit feedback loops.

Suggestions

Replace the abstract Instruction bullets with concrete, executable guidance — specific commands or tools for gathering logs/traces, reproduction steps, and evidence-gathering techniques.

Create the referenced `resources/implementation-playbook.md` (or fix the path to an existing bundle file) so the progressive-disclosure reference resolves.

Add an explicit validation feedback loop (e.g., validate the root-cause hypothesis with evidence → if not confirmed, refine and re-test) to raise workflow clarity, and remove the duplicated opening sentence to tighten conciseness.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean and well-sectioned, but the opening line duplicates the frontmatter description and the Context paragraph contains generic padding ("industry-standard observability tools", "robust error handling that improves system reliability") that could be tightened.	2 / 3
Actionability	The Instructions are abstract phases ("Gather error context", "Reproduce or narrow the issue with targeted experiments", "Identify root cause and validate with evidence") with no concrete commands, tools, or specific procedures, and the concrete detail is deferred to a referenced file that does not exist.	1 / 3
Workflow Clarity	A clear ordered sequence is present (gather → reproduce → identify root cause → propose fixes), but validation checkpoints are only implicit ("validate with evidence") with no explicit validate→fix→retry feedback loop.	2 / 3
Progressive Disclosure	Sections are well organized and the playbook reference is clearly signaled at one level deep, but the referenced `resources/implementation-playbook.md` does not exist (no references/scripts/assets bundle directory), so navigation is broken.	2 / 3
	Total	7 / 12 Passed

Description

40%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 conveys a clear domain and a few actions but is written in second person, lacks an explicit "Use when…" trigger clause, and relies on buzzword-adjacent phrasing ("deep expertise", "comprehensive"). It answers "what" but not "when," capping several dimensions at 2.

Suggestions

Rewrite the description in third person (e.g., "Analyzes production incidents and recurring errors across distributed systems…") to avoid the second-person specificity penalty.

Add an explicit "Use when…" clause listing natural trigger terms users would say, such as debugging errors, stack traces, logs, traces, production incidents, or root-cause analysis.

Replace generic phrasing like "deep expertise" and "comprehensive observability solutions" with concrete capabilities to lift specificity toward 3.

Dimension	Reasoning	Score
Specificity	Phrases like "debugging distributed systems, analyzing production incidents, and implementing comprehensive observability solutions" name a domain and several actions (baseline 2), but the description uses second-person voice ("You are an expert error analysis specialist"), which the rubric penalizes by reducing specificity by 1.	1 / 3
Completeness	It states what the skill does but provides no "when" / "Use when…" trigger guidance, so per the rubric completeness is capped at 2.	2 / 3
Trigger Term Quality	It includes relevant terms ("error analysis", "debugging", "production incidents", "observability") a user might say, but lacks a "Use when…" clause and misses common variations such as stack traces, logs, errors, or traces.	2 / 3
Distinctiveness Conflict Risk	The incident/error-analysis niche is somewhat specific, but without distinct trigger terms in the description it could overlap with general debugging or coding skills.	2 / 3
	Total	7 / 12 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: rmyndharis/antigravity-skills
Path: skills/error-debugging-error-analysis/SKILL.md
Commit: e63f7dd

Reviewed: 13 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.