Agent skill

Debug Buttercup

by sickn33 in sickn33/agentic-awesome-skills

All pods run in namespace crs. An agent skill from sickn33/agentic-awesome-skills.

MITAuto-check passedDatabases

Install Debug Buttercup

skills CLI
$ npx skills add sickn33/agentic-awesome-skills --skill debug-buttercup -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install sickn33/agentic-awesome-skills debug-buttercup --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/sickn33/agentic-awesome-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/debug-buttercup .claude/skills/debug-buttercup && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
debug-buttercup
GitHub stars
47k
Used in
2 other repos
Token cost
~2.5k tokens
SKILL.md length
642 words
Files
1
Skills in repo
1,354
Repo updated
First seen
Licence
MIT

At a glance

All pods run in namespace crs. An agent skill from sickn33/agentic-awesome-skills.

  • Pods in the crs namespace are in CrashLoopBackOff
  • SKILL.md covers When to Use, When NOT to Use, Namespace and Services and Triage Workflow, plus 9 more sections
  • Calls kubectl and bash
  • Multiple services restart simultaneously (cascade failure)

What it does

Debug Buttercup is an agent skill from sickn33/agentic-awesome-skills. 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.

Its SKILL.md is about 2.5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Databases. It works with Redis. The repository describes itself as: AAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,400+ agentic skills. Includes… The licence is MIT.

When your agent uses it

  • Pods in the crs namespace are in CrashLoopBackOff
  • Multiple services restart simultaneously (cascade failure)
  • Redis is unresponsive
  • Showing AOF warnings

Example prompts

  • “/debug-buttercup”

Requirements

  • Docker

What it can do on your machine

Read from SKILL.md and the folder at commit ec02547. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • kubectl
    • bash

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use kubectl, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Debug Buttercup loads about 2.5k tokens when it runs. Until then it costs about 61 tokens; SKILL.md has 642 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~61
When it runs · the whole SKILL.md, loaded when a task matches
~2.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from sickn33/agentic-awesome-skills at commit ec02547, republished under its MIT licence (© sickn33). 642 words, ~2,479 tokens.

Download SKILL.mdSave it as .claude/skills/debug-buttercup/SKILL.md (or your agent's skills folder).
name
debug-buttercup
description
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.
risk
critical
source
community
date_added
2026-09-04

Debug Buttercup

When to Use

  • Pods in the crs namespace are in CrashLoopBackOff, OOMKilled, or restarting
  • Multiple services restart simultaneously (cascade failure)
  • Redis is unresponsive or showing AOF warnings
  • Queues are growing but tasks are not progressing
  • Nodes show DiskPressure, MemoryPressure, or PID pressure
  • Build-bot cannot reach the Docker daemon (DinD failures)
  • Scheduler is stuck and not advancing task state
  • Health check probes are failing unexpectedly
  • Deployed Helm values don't match actual pod configuration

When NOT to Use

  • Deploying or upgrading Buttercup (use Helm and deployment guides)
  • Debugging issues outside the crs Kubernetes namespace
  • Performance tuning that doesn't involve a failure symptom

Namespace and Services

All pods run in namespace crs. Key services:

LayerServices
Infraredis, dind, litellm, registry-cache
Orchestrationscheduler, task-server, task-downloader, scratch-cleaner
Fuzzingbuild-bot, fuzzer-bot, coverage-bot, tracer-bot, merger-bot
Analysispatcher, seed-gen, program-model, pov-reproducer
Interfacecompetition-api, ui

Triage Workflow

Always start with triage. Run these three commands first:

bash
# 1. Pod status - look for restarts, CrashLoopBackOff, OOMKilled
kubectl get pods -n crs -o wide

# 2. Events - the timeline of what went wrong
kubectl get events -n crs --sort-by='.lastTimestamp'

# 3. Warnings only - filter the noise
kubectl get events -n crs --field-selector type=Warning --sort-by='.lastTimestamp'

Then narrow down:

bash
# Why did a specific pod restart? Check Last State Reason (OOMKilled, Error, Completed)
kubectl describe pod -n crs <pod-name> | grep -A8 'Last State:'

# Check actual resource limits vs intended
kubectl get pod -n crs <pod-name> -o jsonpath='{.spec.containers[0].resources}'

# Crashed container's logs (--previous = the container that died)
kubectl logs -n crs <pod-name> --previous --tail=200

# Current logs
kubectl logs -n crs <pod-name> --tail=200
Historical vs Ongoing Issues

High restart counts don't necessarily mean an issue is ongoing -- restarts accumulate over a pod's lifetime. Always distinguish:

  • --tail shows the end of the log buffer, which may contain old messages. Use --since=300s to confirm issues are actively happening now.
  • --timestamps on log output helps correlate events across services.
  • Check Last State timestamps in describe pod to see when the most recent crash actually occurred.
Cascade Detection

When many pods restart around the same time, check for a shared-dependency failure before investigating individual pods. The most common cascade: Redis goes down -> every service gets ConnectionError/ConnectionRefusedError -> mass restarts. Look for the same error across multiple --previous logs -- if they all say redis.exceptions.ConnectionError, debug Redis, not the individual services.

Log Analysis

bash
# All replicas of a service at once
kubectl logs -n crs -l app=fuzzer-bot --tail=100 --prefix

# Stream live
kubectl logs -n crs -l app.kubernetes.io/name=redis -f

# Collect all logs to disk (existing script)
bash deployment/collect-logs.sh

Resource Pressure

bash
# Per-pod CPU/memory
kubectl top pods -n crs

# Node-level
kubectl top nodes

# Node conditions (disk pressure, memory pressure, PID pressure)
kubectl describe node <node> | grep -A5 Conditions

# Disk usage inside a pod
kubectl exec -n crs <pod> -- df -h

# What's eating disk
kubectl exec -n crs <pod> -- sh -c 'du -sh /corpus/* 2>/dev/null'
kubectl exec -n crs <pod> -- sh -c 'du -sh /scratch/* 2>/dev/null'

Redis Debugging

Redis is the backbone. When it goes down, everything cascades.

bash
# Redis pod status
kubectl get pods -n crs -l app.kubernetes.io/name=redis

# Redis logs (AOF warnings, OOM, connection issues)
kubectl logs -n crs -l app.kubernetes.io/name=redis --tail=200

# Connect to Redis CLI
kubectl exec -n crs <redis-pod> -- redis-cli

# Inside redis-cli: key diagnostics
INFO memory          # used_memory_human, maxmemory
INFO persistence     # aof_enabled, aof_last_bgrewrite_status, aof_delayed_fsync
INFO clients         # connected_clients, blocked_clients
INFO stats           # total_connections_received, rejected_connections
CLIENT LIST          # see who's connected
DBSIZE               # total keys

# AOF configuration
CONFIG GET appendonly     # is AOF enabled?
CONFIG GET appendfsync   # fsync policy: everysec, always, or no

# What is /data mounted on? (disk vs tmpfs matters for AOF performance)
bash
kubectl exec -n crs <redis-pod> -- mount | grep /data
kubectl exec -n crs <redis-pod> -- du -sh /data/
Queue Inspection

Buttercup uses Redis streams with consumer groups. Queue names:

QueueStream Key
Buildfuzzer_build_queue
Build Outputfuzzer_build_output_queue
Crashfuzzer_crash_queue
Confirmed Vulnsconfirmed_vulnerabilities_queue
Download Tasksorchestrator_download_tasks_queue
Ready Taskstasks_ready_queue
Patchespatches_queue
Indexindex_queue
Index Outputindex_output_queue
Traced Vulnstraced_vulnerabilities_queue
POV Requestspov_reproducer_requests_queue
POV Responsespov_reproducer_responses_queue
Delete Taskorchestrator_delete_task_queue
bash
# Check stream length (pending messages)
kubectl exec -n crs <redis-pod> -- redis-cli XLEN fuzzer_build_queue

# Check consumer group lag
kubectl exec -n crs <redis-pod> -- redis-cli XINFO GROUPS fuzzer_build_queue

# Check pending messages per consumer
kubectl exec -n crs <redis-pod> -- redis-cli XPENDING fuzzer_build_queue build_bot_consumers - + 10

# Task registry size
kubectl exec -n crs <redis-pod> -- redis-cli HLEN tasks_registry

# Task state counts
kubectl exec -n crs <redis-pod> -- redis-cli SCARD cancelled_tasks
kubectl exec -n crs <redis-pod> -- redis-cli SCARD succeeded_tasks
kubectl exec -n crs <redis-pod> -- redis-cli SCARD errored_tasks

Consumer groups: build_bot_consumers, orchestrator_group, patcher_group, index_group, tracer_bot_group.

Health Checks

Pods write timestamps to /tmp/health_check_alive. The liveness probe checks file freshness.

bash
# Check health file freshness
kubectl exec -n crs <pod> -- stat /tmp/health_check_alive
kubectl exec -n crs <pod> -- cat /tmp/health_check_alive

If a pod is restart-looping, the health check file is likely going stale because the main process is blocked (e.g. waiting on Redis, stuck on I/O).

Show full SKILL.md (257 more words)Show less

Telemetry (OpenTelemetry / Signoz)

All services export traces and metrics via OpenTelemetry. If Signoz is deployed (global.signoz.deployed: true), use its UI for distributed tracing across services.

bash
# Check if OTEL is configured
kubectl exec -n crs <pod> -- env | grep OTEL

# Verify Signoz pods are running (if deployed)
kubectl get pods -n platform -l app.kubernetes.io/name=signoz

Traces are especially useful for diagnosing slow task processing, identifying which service in a pipeline is the bottleneck, and correlating events across the scheduler -> build-bot -> fuzzer-bot chain.

Volume and Storage

bash
# PVC status
kubectl get pvc -n crs

# Check if corpus tmpfs is mounted, its size, and backing type
kubectl exec -n crs <pod> -- mount | grep corpus_tmpfs
kubectl exec -n crs <pod> -- df -h /corpus_tmpfs 2>/dev/null

# Check if CORPUS_TMPFS_PATH is set
kubectl exec -n crs <pod> -- env | grep CORPUS

# Full disk layout - what's on real disk vs tmpfs
kubectl exec -n crs <pod> -- df -h

CORPUS_TMPFS_PATH is set when global.volumes.corpusTmpfs.enabled: true. This affects fuzzer-bot, coverage-bot, seed-gen, and merger-bot.

Deployment Config Verification

When behavior doesn't match expectations, verify Helm values actually took effect:

bash
# Check a pod's actual resource limits
kubectl get pod -n crs <pod-name> -o jsonpath='{.spec.containers[0].resources}'

# Check a pod's actual volume definitions
kubectl get pod -n crs <pod-name> -o jsonpath='{.spec.volumes}'

Helm values template typos (e.g. wrong key names) silently fall back to chart defaults. If deployed resources don't match the values template, check for key name mismatches.

Service-Specific Debugging

For detailed per-service symptoms, root causes, and fixes, see references/failure-patterns.md.

Quick reference:

  • DinD: kubectl logs -n crs -l app=dind --tail=100 -- look for docker daemon crashes, storage driver errors
  • Build-bot: check build queue depth, DinD connectivity, OOM during compilation
  • Fuzzer-bot: corpus disk usage, CPU throttling, crash queue backlog
  • Patcher: LiteLLM connectivity, LLM timeout, patch queue depth
  • Scheduler: the central brain -- kubectl logs -n crs -l app=scheduler --tail=-1 --prefix | grep "WAIT_PATCH_PASS\|ERROR\|SUBMIT"

Diagnostic Script

Run the automated triage snapshot:

bash
bash {baseDir}/scripts/diagnose.sh

Pass --full to also dump recent logs from all pods:

bash
bash {baseDir}/scripts/diagnose.sh --full

This collects pod status, events, resource usage, Redis health, and queue depths in one pass.

Limitations

  • Use this skill only when the task clearly matches the scope described above.
  • Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

© sickn33, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/debug-buttercup of sickn33/agentic-awesome-skills.

Open the folder on GitHubat commit ec02547

Used in 2 other repositories

We found 11 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 2 other GitHub owners. This page covers the copy in sickn33/agentic-awesome-skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Debug Buttercup next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Debug Buttercup compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Debug Buttercup this skillsickn33/agentic-awesome-skills47k2 repos~2.5kAutomated safety check: PassMIT
Bump Test Imageredis/node-redis18k—~1.4kAutomated safety check: PassMIT
Mail Timeveliovgroup/mail-time143—~1kAutomated safety check: PassBSD-3-Clause
Tgf Server Devthkhxm/tgf128—~1.3kAutomated safety check: NotesMIT
AspireifyCommunityToolkit/Aspire629—~5.3kAutomated safety check: NotesMIT
Commandkit Cacheneplexlabs/commandkit165—~506Automated safety check: PassMIT

Similar skills

  • Bump Test Image

    redis/node-redis

    Official

    Bump the default Redis docker test image (redislabs/client-libs-test) in the shared DEFAULTDOCKERCONFIG and the CI matrix, then force-push the bump-test-image branch and open a PR against upstream.

    18k GitHub stars~1.4k tokensUpdated yesterday
    DatabasesAuto-check passed
  • Mail Time

    veliovgroup/mail-time

    A skill your agent uses when building, wiring, reviewing, or debugging MailTime and ostrio:mailer email queues for horizontally scaled Node.js, Bun, or Meteor apps.

    143 GitHub stars~1k tokensUpdated today
    DatabasesAuto-check passed
  • Tgf Server Dev

    thkhxm/tgf

    基于 tgf v2(github.com/thkhxm/tgf/v2)用确定性的 tgfctl 工作流创建、验证和维护 Go 游戏服务器项目。

    128 GitHub stars~1.3k tokensUpdated 2 mo ago
    DatabasesAuto-check: notes
  • Aspireify

    CommunityToolkit/Aspire

    WORKFLOW SKILL - Wire Aspire AppHosts or repair TypeScript AppHost toolchains.

    629 GitHub stars~5.3k tokensUpdated yesterday
    DatabasesAuto-check: notes
  • Commandkit Cache

    neplexlabs/commandkit

    Implement deterministic caching with @commandkit/cache. An agent skill from neplexlabs/commandkit.

    165 GitHub stars~506 tokensUpdated 12 days ago
    DatabasesAuto-check passed
  • Cloudrun Development

    TencentCloudBase/CloudBase-AI-Toolkit

    CloudBase Run backend development rules (Function mode/Container mode).

    1.1k GitHub starsUsed in 1 repo~7.2k tokens
    DatabasesAuto-check passed

More from sickn33/agentic-awesome-skills

All 1,354 skills in this repo
  • Liuguang Banlan UI

    sickn33/agentic-awesome-skills

    Implements an interface in one of two named color modes, iridescent white or colorful black, from a parameterized starter that reports measured color intensity.

    47k GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed
  • User Thoughts Memory

    sickn33/agentic-awesome-skills

    Saves a user's project decisions, rules and preferences into a project-local mdbase so later sessions and other agents can recover the intent.

    47k GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed
  • Using LWC Memory and Graphs

    sickn33/agentic-awesome-skills

    Keeps project decisions, research and verified results available across coding-agent sessions through LWC memory, a document Wiki graph and a CodeGraph code index.

    47k GitHub starsUsed in 1 repo~2k tokens
    Auto-check passed
  • Find Complementary Founders

    sickn33/agentic-awesome-skills

    Guides an agent through assessing its own owner for cofounder fit, publishing an approved profile, and ranking complementary profiles other agents published for their owners.

    47k GitHub starsUsed in 1 repo~4.8k tokens
    Auto-check passed
  • Cline Pilot

    sickn33/agentic-awesome-skills

    Acts as a proxy for the Cline CLI, dispatching coding tasks one at a time, monitoring runs by hard evidence, relaying decisions to you and learning per-project preferences.

    47k GitHub starsUsed in 1 repo~4.6k tokens
    Auto-check passed
  • Content Creator

    sickn33/agentic-awesome-skills

    Drafts and reviews audience-specific content from supplied brand examples, with local scripts for brand voice and SEO diagnostics, channel templates and a content calendar.

    47k GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed

Works with

Questions about Debug Buttercup

What does Debug Buttercup do?

All pods run in namespace crs. An agent skill from sickn33/agentic-awesome-skills. Debug Buttercup is an agent skill from sickn33/agentic-awesome-skills. All pods run in namespace crs.

When should I use Debug Buttercup?

Debug Buttercup fits situations like: pods in the crs namespace are in CrashLoopBackOff; multiple services restart simultaneously (cascade failure); redis is unresponsive; showing AOF warnings.

How do I install Debug Buttercup in Claude Code?

Run `npx skills add sickn33/agentic-awesome-skills --skill debug-buttercup -a claude-code`. Or copy the skill folder (skills/debug-buttercup in sickn33/agentic-awesome-skills) into .claude/skills/debug-buttercup in your project. Claude Code loads it when a task matches its description.

How do I install Debug Buttercup in Codex?

Run `npx skills add sickn33/agentic-awesome-skills --skill debug-buttercup -a codex`. Or copy the skill folder (skills/debug-buttercup in sickn33/agentic-awesome-skills) into .agents/skills/debug-buttercup in your project. Codex loads it when a task matches its description.

Can I use Debug Buttercup in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add sickn33/agentic-awesome-skills --skill debug-buttercup -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/debug-buttercup, .gemini/skills/debug-buttercup, .github/skills/debug-buttercup and .opencode/skills/debug-buttercup in your project.

What does Debug Buttercup need to run?

Going by SKILL.md and its folder, Debug Buttercup needs the command-line tools its instructions call (kubectl and bash). Our summary lists: Docker.

Does Debug Buttercup access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Debug Buttercup safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Debug Buttercup use?

Debug Buttercup is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Debug Buttercup use?

About 2.5k tokens (SKILL.md is roughly 9.9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Debug Buttercup?

Skills that share tags, products or a category with Debug Buttercup: Bump Test Image (redis/node-redis, 18k stars), Mail Time (veliovgroup/mail-time, 143 stars), Tgf Server Dev (thkhxm/tgf, 128 stars) and Aspireify (CommunityToolkit/Aspire, 629 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Debug Buttercup?

sickn33 (a GitHub user) maintains it in sickn33/agentic-awesome-skills, which has 47,343 GitHub stars. The repository holds 1,354 skills in this directory. The repository was last updated on October 7, 2026.

Source: sickn33/agentic-awesome-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.