CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

debug

Structured platform troubleshooting — classifies the problem layer, collects evidence, forms a root-cause hypothesis, and proposes a fix with validation and rollback steps.

Quality

76%

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/debug/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

82%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 lean, well-structured troubleshooting skill: the timeline mode provides executable copy-paste commands, the main flow sequences evidence-before-fix with explicit validation and rollback steps, and nothing wastes tokens explaining what Claude already knows. The main improvements are clarifying how the timeline mode is selected from arguments and adding a few concrete per-layer evidence commands to the primary path.

DimensionReasoningScore

Conciseness

The body assumes Claude's competence throughout — no concept explanations, one-line section directives ("Commands to confirm the fix worked."), tersely labeled commands, and one-liner mistake entries. Every token earns its place, matching the lean anchor rather than the 'minor over-explanation' level below.

5 / 5

Actionability

The timeline mode is fully copy-paste ready ("kubectl get events -A --sort-by='.lastTimestamp' | tail -50", the custom-columns restart count sort, "flux get all -A | grep -v True") and the main structure gives specific directives ("include namespace flags, resource names from the description, and output filters"; "Show before and after"). Not 5 because the primary debug path supplies instructional scaffolding only — no example evidence commands per layer.

4 / 5

Workflow Clarity

The main flow is a clear six-step sequence (classify → evidence → hypothesis → fix → validation → rollback) with explicit validation and a rollback error-recovery path, and the timeline mode is numbered step-by-step. Not 5 because mode dispatch is implicit — the argument-hint promises "[timeline <minutes>|symptom]" but the body never explains how to select the timeline mode from $ARGUMENTS — and there is no re-validation loop after rollback.

4 / 5

Progressive Disclosure

Well-organized with clear section headers and no nested or buried references (the skill ships no bundle files). Not 5 because the ~60-line timeline mode is inlined content that could live in a separate reference file for a 130-line skill, and the closing "Next" pointer references "/platform-skills:debug" (a self-reference) and "/platform-skills:product postmortem" (external to this bundle) without explanation.

4 / 5

Total

17

/

20

Passed

Description

60%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 excels at concrete, third-person capability statements but fails on trigger guidance: it has no 'Use when' clause and lacks the natural keywords (debug, error, incident, platform names) that would let a user — or the model — select it over a generic debugging skill. Adding explicit trigger phrases and naming the covered platforms would lift three dimensions at once.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user reports an error, crash, failed deployment, or asks to debug/troubleshoot platform infrastructure (Kubernetes, OpenShift, Terraform, Flux, Argo CD, Linkerd, GitHub Actions, AWS/Azure)."

Include the natural words users actually say — "debug", "error message", "incident", "why is X failing" — not just the formal term "troubleshooting".

DimensionReasoningScore

Specificity

"classifies the problem layer", "collects evidence", "forms a root-cause hypothesis", and "proposes a fix with validation and rollback steps" list multiple concrete, distinct actions in third person that comprehensively cover the troubleshooting workflow, matching the top anchor rather than the 'minor gaps' level below.

5 / 5

Completeness

The 'what' is clear and multi-part, but there is no 'Use when...' clause or equivalent explicit trigger guidance (only weakly implied by "troubleshooting"), which per the judging guidelines caps completeness at 3. Not 4 because the 'when' is not merely underspecified — it is absent.

3 / 5

Trigger Term Quality

"troubleshooting", "root-cause", and "fix" are natural terms, but the description omits the phrases users would actually say — "debug", "error message", "broken", "incident" — and none of the platform names (Kubernetes, Terraform, Flux, AWS) the skill covers, matching the 'some relevant keywords but missing common variations' anchor.

3 / 5

Distinctiveness Conflict Risk

"Structured platform troubleshooting" narrows the domain somewhat, but no platforms or tooling are named, so it would collide with any generic debugging or troubleshooting skill rather than only closely related ones.

3 / 5

Total

14

/

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

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

nitinjain999/platform-skills

Path

skills/debug/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.