production-debugging

I've been looking at how you structured the debugging workflow here—the way you've organized the diagnostic steps feels practical, though I'm curious whether the current approach handles cascading failures where one diagnostic masks another.

Links:

• GitHub
• Your agentic skill in the SkillzWave marketplace

The TL;DR

You're at 88/100, solid B grade territory. This is based on Anthropic's skill best practices rubric. Your strongest area is Utility (19/20)—the debugging methodology and bug patterns table are genuinely useful. The weakest is Spec Compliance (11/15), mainly because you're missing trigger phrases in the description that help users discover this skill when they actually need it.

What's Working Well

• Excellent practical utility: Your "Common Bug Patterns" table with specific AttributeError, 500 error, and service integration scenarios gives users a real roadmap. That's the kind of thing people bookmark.
• Smart run→check→fix loops: The Debugging Checklist and "Verify Deployment" sections have clear feedback patterns. Users know exactly what success looks like.
• Self-documenting commands: Your kubectl templates and grep-friendly patterns mean people can copy-paste and actually understand what they're running—not just blindly executing commands.
• Metadata is tight: Your description triggers ("500 errors", "silent failures", "service integration") will activate appropriately when developers are in the thick of it.

The Big One

Missing trigger phrases in your frontmatter description. Right now it reads like documentation; it needs to read like "when should I use this?" Your description is cut off at "Debug production issues in Kubernetes clusters. Use this skill when investigating 500 err...