CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

debug-buttercup

All pods run in namespace crs. Use when pods in the crs namespace are in CrashLoopBackOff, OOMKilled, or restarting, multiple services restart simultaneously (cascade failure), or redis is unresponsive or showing AOF warnings.

Quality

76%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./plugins/AI-Agents-Safe-Coding-Skills/skills/debug-buttercup/SKILL.md

The canonical home for this skill is debug-buttercup in administrakt0r/AI-Agents-Safe-Coding-Skills

SKILL.md
Quality
Evals
Security

Quality

Content

78%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 strong diagnostic skill body: copy-paste-ready commands, a well-sequenced triage workflow with smart interpretation guidance, and dense environment-specific facts with no padding. Its main defects are dangling bundle references (failure-patterns.md and diagnose.sh do not exist in the bundle) and small duplications that could be trimmed.

Suggestions

Ship the referenced bundle files — references/failure-patterns.md and scripts/diagnose.sh — or remove/inline those pointers; currently both references dangle and the progressive-disclosure chain breaks.

Deduplicate the resources jsonpath command (appears in Triage and again in Deployment Config Verification) and drop the When to Use list's overlap with the frontmatter description to tighten token usage.

Move the misplaced '# What is /data mounted on?' comment from the end of the redis-cli code block into the bash block it actually describes.

DimensionReasoningScore

Conciseness

The body is lean: tables for services and queue names, terse copy-paste commands with one-line comments, and it explains only Buttercup-specific facts Claude cannot know (health_check_alive, CORPUS_TMPFS_PATH, consumer group names) without lecturing on Kubernetes or Redis basics. Minor trimming opportunities keep it below score 5: the When to Use section duplicates the frontmatter description, the resources jsonpath command appears in both Triage and Deployment Config Verification, and a stray "# What is /data mounted on?" comment sits at the end of the wrong code block.

4 / 5

Actionability

Fully executable throughout: exact kubectl/redis-cli commands with only pod-name placeholders ("kubectl logs -n crs <pod-name> --previous --tail=200", "redis-cli XPENDING fuzzer_build_queue build_bot_consumers - + 10"), concrete stream keys, consumer-group names, and specific log signatures to grep for ("redis.exceptions.ConnectionError", "WAIT_PATCH_PASS"). Commands cover the common cases (OOM, cascade, AOF, disk pressure) and are copy-paste ready.

5 / 5

Workflow Clarity

A clear sequenced triage flow — "Always start with triage. Run these three commands first", then "Then narrow down" with per-symptom follow-ups, plus interpretation checkpoints like checking --since=300s to distinguish historical from ongoing restarts and the cascade rule ("if they all say redis.exceptions.ConnectionError, debug Redis, not the individual services"). It is a read-only diagnostic skill so the destructive/batch validation cap does not apply, but the flow relies on section ordering and prose cues rather than explicit validation steps and error-recovery loops, which keeps it below the score-5 anchor.

4 / 5

Progressive Disclosure

Section structure is good, but the disclosure chain is broken: the body points to "references/failure-patterns.md" and "{baseDir}/scripts/diagnose.sh", yet the bundle contains no references/, scripts/, or assets/ directories at all — both pointers dangle, so an agent following them fails. This is worse than the score-4 anchor (references mostly clear and usable) and lands at "references present but the organization/chain has real gaps"; it stays above score 2 because the main body is well-sectioned and the inlined quick-reference is appropriately brief.

3 / 5

Total

16

/

20

Passed

Description

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

An excellent pure trigger description — concrete failure signatures that would reliably fire for the right problems — but it never states what the skill actually does. Adding one leading capability clause (e.g., "Diagnose and triage Buttercup service failures...") would make it a complete description.

Suggestions

Open with a 'what' clause stating the skill's actions, e.g., "Diagnoses and triages failures across Buttercup's services (pods, Redis, queues, nodes) in the crs Kubernetes namespace. Use when..." — this would lift both specificity and completeness.

Fold a few of the body's When-to-Use triggers into the description (node DiskPressure/MemoryPressure, growing queue backlog, DinD/docker-daemon failures, stuck scheduler) so it triggers on the same breadth of symptoms the skill covers.

Keep the description's trigger list in sync with the body's When to Use section — currently the body lists nine conditions while the description covers three.

DimensionReasoningScore

Specificity

Phrases like "pods in the crs namespace are in CrashLoopBackOff, OOMKilled, or restarting" and "redis is unresponsive or showing AOF warnings" are concrete and domain-specific, but the description states no actions the skill performs — the only non-trigger statement, "All pods run in namespace crs", is environmental context. This matches the anchor of naming a domain with concrete detail but no comprehensive capability list; it is above score 2 ("actions are minimal or generic") because the trigger conditions are highly specific, and below score 4 because zero debugging/triage actions are stated.

3 / 5

Completeness

The "when" half is explicit and concrete ("Use when pods... are in CrashLoopBackOff..."), but the "what" is never stated — nothing says the skill diagnoses, triages, or fixes these failures; that intent is only implied by the symptom list. It sits between the "clear what, weak when" (3) and "both present, when could be more explicit" (4) anchors: the when is excellent but the what is absent rather than merely vague.

3 / 5

Trigger Term Quality

Strong natural vocabulary an operator would actually say: "CrashLoopBackOff", "OOMKilled", "restarting", "cascade failure", "unresponsive", "AOF warnings". It misses several equally natural triggers that the body itself lists (DiskPressure/MemoryPressure, queue backlog, DinD failures, scheduler stuck, failing health probes, Helm values mismatch), which keeps it at "good keyword coverage; a few natural terms missing" rather than comprehensive.

4 / 5

Distinctiveness Conflict Risk

Triggers are pinned to the "crs" namespace and distinctive failure signatures (OOMKilled, redis AOF warnings, simultaneous mass restarts), creating a clear niche with minimal overlap risk against generic Kubernetes or Redis skills. Re-reading the score-4 anchor ("minor overlap risk"), nothing here would plausibly fire the wrong skill, so the best-fit anchor is 5.

5 / 5

Total

15

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

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

Warning

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

14

/

16

Passed

Repository

administrakt0r/AI-Agents-Safe-Coding-Skills

Path

plugins/AI-Agents-Safe-Coding-Skills/skills/debug-buttercup/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.