Skills Are a Mess. Let's Fix That.

Skills Are a Mess. Let's Fix That. Here's the problem: you write a skill for zeroclaw. It works locally. You push it. Someone else tries to install it. Nothing works. The error says "missing dependency" but doesn't say which one. Or it installs but the audit fails silently. Or the test harness just... doesn't run. Sound familiar? I've been watching the zeroclaw skills ecosystem grow. More people are authoring skills. More people are hitting the same walls. The v0.7.6 release is about tearing those walls down. What Actually Breaks Let's get specific. Three failure modes I see every week: 1. Install hell zeroclaw skills install my-skill # → Error: Failed to resolve dependency graph # → (no other output) You're left guessing. Is it a peer dependency conflict? A missing Python version? A circular reference in the skill manifest? The loader gives you nothing. 2. Audit blindness zeroclaw skills audit ./my-skill # → Audit complete. 0 issues found. # → (skill crashes immediately on first use) The audit passed. But it didn't check for the actual runtime errors — missing environment variables, incompatible tool signatures, malformed output schemas. It checked the manifest format. That's it. 3. Test harness that doesn't test zeroclaw skills test ./my-skill # → Running 3 test cases... # → All passed. # → (skill still hallucinates in production) The test harness runs your skill against mock data. But the mock data doesn't match real tool outputs. Your skill passes locally, fails in the wild. Why This Happens The current architecture treats skills as static packages. You define metadata in a skill.json , point to some functions, and assume it works. But skills are dynamic. They call tools. They depend on runtime state. They interact with the sandbox. The loader doesn't validate the runtime contract. The audit doesn't simulate execution. The test harness doesn't fuzz inputs. So you get false positives everywhere. "Works on my machine" becomes "works in my specific environment with