I asked: can the first skill-creator be created automatically? The answer was already in my own published framework
A week ago I learned about the SKILL concept — I happened to see someone's SKILL.md. After noticing how detailed it was, I immediately thought: "If this is written by hand, how do we ensure the AI understands it exactly the way we intended when we wrote it?"
A lot of people would think AI is designed to understand humans, right? So writing a skill file for AI to read should be straightforward. But there's evidence the simple assumption fails in many cases. Some of my own observations are what pushed me to develop simple prompting techniques into what I named S-Prompting — a technique for tuning AI's abstraction level via POLA situations (situations that hint at violating the Principle of Least Astonishment, a well-known software design principle). I also publish about an architecture called HDVO, whose iteration layer is prompt-orchestrated and integrates naturally with S-Prompting.
When the underlying architecture might be counter-intuitive, pure S-Prompting is usually less effective than HDVO. HDVO would have been the route I went to — but before that, I did the obvious thing first: searched. "How to create a skill effectively for OpenClaw", "skill creation process for OpenClaw", looking for some automation. After enough searching, the core question — how do I create a SKILL the AI will actually understand and execute correctly? — was still unresolved. I didn't have enough confidence to just sit down and write one.
Then I stumbled on Codex's $skill-creator. Not through reading docs — I'd typed $ looking at available skills per a guide I was following, and the auto-completion surfaced it. A few minutes later I had the critical question: "Can it update an existing skill?"
That question carried a hypothesis: if $skill-creator can update skills, then $skill-creator itself has probably been updated many times — and the process for doing so is integrated into the tool. I tested this by building my own handoff skill with $skill-creator walking me through it. It worked.
This is where it gets interesting. The natural next question is:
- Is $skill-creator the final version?
- Is using $skill-creator to update itself even a valid process?
I … did not ask those questions. 😅 What I asked instead was: "Can the first $skill-creator be created automatically?"
That's when I realized the answer had been in my own work all along. I'd been describing it for months in another context:
>Treat the AI as a bright apprentice. You're collaborating to build a logical entity. The final outputs you ask it to return — code, markdown, a general_skill.md — are byproducts, not the goal.
And the matching philosophy from a different project of mine:
>Notebook design where maintenance and expansion are optimized by leveraging the language model's reasoning abilities.
I took these seriously and ran one HDVO iteration. The ideal optimization target was an independent sub-agent's judgment of how well a skill's output matches the expectations implied by the skill-creation prompt.
The result showed structural features — anti-trigger explicitness, risk profile taxonomy, archetype routing, cross-link validation — that the three established skill-creators I compared against (Codex, Antigravity, Claude Code) either don't have or only address implicitly.
Full case study with scorecard and methodology: What HDVO Forces You to Notice — full Medium post
Caveats are noted in the post: sub-agent runs were simulated, not executed; some competitor tool descriptions couldn't be independently verified against first-party docs and are marked accordingly.
If anyone wants to poke at this hands-on, I've used general_skill.md to author a kubernetes-diagnostic skill (A4 + R2 in the framework's taxonomy). The repo has a 4-scenario testbed of intentionally broken pods you can run locally: https://github.com/thienannguyen-cv/Kubernetes-Skill-Test