SkillAnything: A Meta-Skill That Generates Agent Skills From a Target Name

The Gap SkillAnything Targets: Skill Authoring Is Manual and Platform-Specific

Writing a skill for an agent platform is a small amount of prose wrapped around a large amount of guessing. You decide what the tool can do, you guess which phrasings will trigger the skill, you write it once for Claude Code and then rewrite it for whatever else your team runs. SkillAnything exists to remove that repetition. The README describes it as a Skill that generates Skills, and the input is deliberately loose: a CLI tool name, a REST API with an OpenAPI or Swagger spec, a library package name from pip or npm, a step-by-step workflow description, or a service URL with public docs. The output is a directory tree with a SKILL.md, supporting scripts and references, plus a dist/ folder containing per-platform builds. The audience is anyone who maintains agent skills as an artifact rather than as a one-off prompt, which in practice means platform teams and developer-tooling groups. A solo user with a single Claude Code setup gains less, because the multi-platform packaging is the part that pays for the extra machinery.

Seven Phases, and Why the Eval Phases Are the Real Product

The pipeline runs Analyze, Design, Implement, Test Plan, Evaluate, Optimize, Package. Phase 1 detects the target type and writes analysis.json. Phase 2 maps capabilities onto skill architecture and writes architecture.json. Phase 3 scaffolds the directory. Phase 4 generates eval cases and trigger queries into evals.json. Phase 5 is the one that matters: it benchmarks the skill with and without the skill present and grades the results into benchmark.json. Phase 6 runs a train/test loop against trigger-evals.json to improve the skill description. Phase 7 fans the result out to dist/claude-code/, dist/openclaw/, dist/codex/ and dist/generic/. The README credits CLI-Anything's methodology as the inspiration for this structure, which is a useful signal about where the design came from. Most skill generators stop at Phase 3 and hand you text. SkillAnything's claim to being different rests on Phases 5 and 6, where the generated artifact is measured against a no-skill baseline and then rewritten based on that measurement. If you strip those two phases out, what remains is a scaffolder with a nice directory layout.

Target Auto-Detection and Its Failure Modes

Detection is rule-based, and the README is explicit about the rules. A CLI tool is found with which <name> followed by --help parsing. A REST API is identified by a URL that serves an OpenAPI or Swagger spec. A library is identified by a package name resolvable through pip or npm. A workflow is taken from a step-by-step description. A service is a URL with web documentation. Each of these has an obvious failure mode. A CLI tool that is not on PATH at analysis time will not be detected, so the pipeline cannot describe a tool it cannot invoke. A library whose package name differs from its import name, or which lives on a private index, falls outside the pip/npm lookup. A service with documentation spread across many pages gives the analyzer no single spec to parse. The workflow case is the weakest, because a prose description has no machine-checkable structure, so the quality of analysis.json depends entirely on how completely you wrote the description. None of this is disqualifying, but it means the first phase is a gate: if analysis.json looks thin, every later phase inherits that thinness.

Running It: Install Paths and the Phase Commands

Installation is a clone into the skills directory of whichever platform you use. For Claude Code the README gives git clone https://github.com/AgentSkillOS/SkillAnything.git ~/.claude/skills/skill-anything, with equivalent paths for ~/.openclaw/skills/skill-anything and ~/.codex/skills/skill-anything. After that you can drive it conversationally, for example by asking Claude Code to create a skill for the httpie CLI tool, or you can run phases individually. The individual commands are the more useful interface for CI. Phase 1 is python -m scripts.analyze_target --target "jq" --output analysis.json. Phase 2 is python -m scripts.design_skill --analysis analysis.json --output architecture.json. Phase 3 is python -m scripts.init_skill my-skill --template cli --output ./out. Phase 4 is python -m scripts.generate_tests --analysis analysis.json --skill-path ./out/my-skill. Phase 5 is python -m scripts.run_eval --eval-set evals.json --skill-path ./out/my-skill. Phase 6 is python -m scripts.run_loop --eval-set trigger-evals.json --skill-path ./out/my-skill --model claude-sonnet-4-20250514. Phase 7 is python -m scripts.package_multiplatform ./out/my-skill --platforms claude-code,openclaw,codex. Note the --model flag in Phase 6: the optimization loop calls a model, so that phase has an API cost and a credential requirement that the other phases do not.

What the Repository Layout Says About Maintenance

The tree separates instructions from execution. SKILL.md is the entry point and the README states it is kept under 500 lines, with METHODOLOGY.md holding the full seven-phase specification. The agents/ directory contains markdown instructions for each role: analyzer, designer, implementer, grader, comparator, optimizer, packager. The scripts/ directory contains the Python that does the work, and the README marks analyze_target.py, design_skill.py, init_skill.py, generate_tests.py and package_multiplatform.py as new. There is a config.yaml for pipeline configuration. Two consequences follow. First, the pipeline is a hybrid: the reasoning steps are prompt-driven through the agent markdown files, while the file manipulation is Python. That means upgrading the model you point Phase 6 at can change behaviour without any code change, which is convenient and also means your results are not reproducible across model versions unless you pin --model. Second, the README's own listing omits scripts/run_eval.py and scripts/run_loop.py from the tree even though the quick start invokes them, and the tree in the supplied material is truncated. Verify those two files are present in your clone before you plan around Phases 5 and 6.

The Limitation That Matters: Measurement Depends on the Evals You Generated

Phase 5 benchmarks with and without the skill, and Phase 6 optimizes the description against trigger evals. Both consume evals.json and trigger-evals.json, which Phase 4 generated automatically from analysis.json. That is a closed loop. If Phase 1 misread the target, the evals will test the wrong capabilities, and the optimization in Phase 6 will tune the description toward those wrong evals. A skill can pass its own benchmark and still fail on the queries your users actually type. The comparator agent exists for blind A/B comparison, which is a reasonable mitigation, but it is still comparing against the same eval set. The practical implication is that auto-generated evals are a starting point, not a substitute for a handful of real queries pulled from your own usage. The README does not describe a mechanism for importing externally authored evals, so in the supplied material it is unclear whether you can seed the loop with your own cases. Treat that as an open question to check in the code.

Where It Fits Against Writing Skills by Hand

The alternative is authoring SKILL.md directly, the way most Claude Code users do today: write the frontmatter, describe the tool, test it by asking the agent a few questions, edit, repeat. That approach has one advantage SkillAnything cannot match, which is that a human who knows the tool writes down the parts that matter and omits the rest. It has two disadvantages. The first is that the manual loop is unmeasured: you find out a skill triggers poorly when a colleague complains, not from a benchmark.json. The second is duplication across platforms. SkillAnything's packaging step is what makes the multi-platform case concrete, and the README notes the platform differences are not cosmetic: Claude Code takes hooks in frontmatter, OpenClaw uses an external settings.json, and Codex gets an openai.yaml companion. Hand-maintaining three variants of the same skill is the problem Phase 7 solves. If you only ever target one platform and you already know the tool well, hand-writing is faster and gives you tighter prose. If you target two or more, or you want a trigger-quality number before shipping, the pipeline earns its complexity.

Licence, Versioning and What to Check Before Adopting

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence, but it covers SkillAnything's own code and templates, not the skills it generates from third-party targets. A skill generated from the Stripe API or from a proprietary internal CLI carries whatever constraints apply to that target, and nothing in the MIT grant changes that. This is not legal advice; if you are packaging generated skills for distribution, check the target's terms separately. On versioning, the repository shows v1.0.0 released 2026-04-06 and a last push on the same day, so the project is at its first tagged release with no upgrade history to reason about. There is no published changelog or migration guide in the supplied material, so the cost of moving from v1.0.0 to a later version is unknown. Python 3.9 or newer is required per the README badge. The concrete checks before you commit: confirm scripts/run_eval.py and scripts/run_loop.py are present, confirm the --model identifier you pass to run_loop.py is one your account can call, and run Phase 7 for your actual platform and load the output from the skills directory you really use, because a packaged skill that does not load is indistinguishable from no skill at all.

Editorial conclusion

Adopt SkillAnything if you maintain more than one agent platform and want a single source skill that fans out into per-platform packages, or if you have a CLI or API you want an agent to drive reliably. Do not adopt it if you cannot run the eval phases, because the generation half without the measurement half leaves you with an unverified SKILL.md. Before committing, verify that scripts/run_eval.py and scripts/run_loop.py exist in your clone, that the model identifier you pass to --model is one your account can call, and that the packaged output for your target platform loads from the skills directory you actually use.

Official sources

1. AgentSkillOS/SkillAnything on GitHub
2. Issues
3. License: MIT
4. README
5. Releases