huashu-skills: a 53-entry index for Agent Skills, with a machine-readable manifest
花叔全部开源 Agent Skills 总目录:16 旗舰 + 14 人物视角 + 22 内置共 52 个 skill,分层分类 + AI Agent 安装协议 + 机器可读 skills.json + 更新检查机制
At a glance
- What is it?
- huashu-skills is a catalogue repository rather than a tool: it lists 18 flagship skills, 14 persona skills and 22 built-in skills, ships a skills.json manifest for agents to read, and documents an install protocol. The judgement is that its value is the index and the manifest, not the skills themselves, and the licence is unstated.
- Who is it for?
- Adopt huashu-skills if you already run Claude Code or another agent that reads SKILL.md and you want a curated starting set rather than a search engine; skip it if you need per-skill licence clarity, since the repository states no licence and each skill lives in its own repo under its own terms.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is discovery, not capability
Agent Skills are just directories containing a SKILL.md file, and that format has spread faster than any index of what exists. The README states the catalogue covers 53 skills in three tiers, all in standard Agent Skills format, and that Claude Code, Codex and Kimi Code can all consume them because the format is shared. The audience is therefore narrow and specific: someone who already has an agent that loads skills from a directory and now needs to know which ones to load. The repository does not teach the format, does not provide a runtime, and does not wrap any of the skills in a CLI. It answers one question, which skill do I want, and it answers it with a need-based routing table rather than a description list. That table is the most useful artefact here: rows like wanting a high-fidelity prototype, or wanting to de-AI a piece of writing, or wanting to turn a person's thinking style into a skill, each map to a named repository. Anyone evaluating this project should treat it as a directory, because that is what it is.
Three tiers, and why the split matters for installation
The catalogue divides into flagship skills (18 independent repositories, each described as a complete system for one domain), persona skills (14 independent repositories, described as person-based thinking operating systems distilled by the nuwa skill), and built-in skills (22, lightweight content-creation utilities plus an update checker, living inside this repository). The tiering is not cosmetic. It determines how you install. Flagship and persona skills are cloned from their own repositories, so they carry their own README, their own dependencies and their own licence. Built-in skills are copied out of subdirectories of this repository, so they inherit whatever terms this repository has, which the supplied material does not state. The README's own summary table gives exactly this mapping: git clone for the first two tiers, copy the subdirectory for the third. One entry breaks the pattern and the README flags it. dukou is a flagship skill, but its skill lives at skill/dukou/ inside its repository, so the README instructs you to install it by copying the subdirectory rather than cloning the top level. Treat that as the general rule: read the per-skill note before running a command.
How an agent is meant to read this repository
The README contains a section titled for AI agents and a stated protocol: the shortest path is to hand the agent the repository URL and ask it to read the README and skills.json and install a named skill or recommend one. The manifest is the mechanism. The README says the machine-readable catalogue lives in skills.json and that agents should prefer it over the prose. That is the design decision worth noticing: the human-facing README carries the routing table and the install commands, while the agent-facing file carries the structured list. It means the project can be consumed in two ways without either audience parsing the other's format. What the supplied material does not show is the schema of skills.json, so the field names, whether entries carry install paths or runtime constraints, and how the file is versioned cannot be confirmed from what is here. If you plan to build tooling on top of the manifest, read the file itself before designing around it.
Installing a skill, and the one command you actually need
For the independent-repository skills the README gives a single command shape, using huashu-design as the worked example: git clone https://github.com/alchaincyf/huashu-design.git ~/.claude/skills/huashu-design. The target path is the agent's skill directory, and the README states that after installing you restart the agent session for the skill to take effect. Built-in skills are not cloned; you copy the subdirectory into the same skills location. The README also lists the update path: a built-in skill called huashu-skill-updater, described as the tool for checking whether installed skills have newer versions. That is the closest thing to a package manager here, and it is worth being precise about what it is not. There is no registry, no version pinning, no lockfile and no dependency resolution across skills. Updating means re-cloning or re-copying. For a catalogue of this size that is workable, but it puts the burden of knowing what changed on you, and the README's own framing of the updater as a check rather than an install mechanism is consistent with that.
Runtime constraints are real and are stated per skill
Several entries are tied to a specific agent environment, and the README says so in the table rather than burying it. huashu-icon-set is marked as Doubao-environment only and is described as depending on a built-in image_gen capability. huashu-slide-doubao is likewise Doubao-specific and is described as using the built-in image_gen so that it incurs zero API cost. huashu-slide-codex is the Codex equivalent, again routed through the agent's built-in image generation. The distinction matters because the cost model changes with the runtime: on an environment with built-in image generation the skill does not call an external API, and on an environment without it the same skill has nothing to call. huashu-mac-use is the other constrained entry, described as letting an agent drive native Mac apps that expose no API, probing across CDP, accessibility, coordinate and pixel layers, with a Swift core and CDP tooling. That is macOS-specific by construction. This is the clearest limitation in the catalogue: a skill that looks portable because it is a Markdown file may still assume a runtime feature that your agent does not have.
Where the catalogue stops being the right tool
A directory is only as good as the judgement behind its entries, and this one is curated by a single author around a single workflow. The README's own framing supports that reading: it describes the author as an independent developer and lists flagship skills across design, document pipelines, video, writing distribution, reading and skill engineering. If your work sits outside those areas, the routing table will not have a row for you, and the 53 entries will not help. The second failure mode is provenance. Because the skills live in separate repositories, this catalogue cannot vouch for their contents, their dependencies or their maintenance. The README's flagship table carries star badges, which the supplied material shows as the only signal attached to individual entries; that is a popularity indicator, not a statement about code quality or whether a skill still works with the current version of your agent. The third issue is the licence. The repository metadata in the supplied material gives no licence, and the README does not discuss one. For a catalogue whose whole purpose is to send you to other repositories, that gap is the thing to resolve before you build anything on top of it.
The alternative is a general skill registry, and the difference is curation
The obvious comparison is a general-purpose skill registry or marketplace, where skills are published by many authors and found by search. The difference in approach is not features, it is the selection mechanism. A registry optimises for coverage and lets ranking or search do the filtering; huashu-skills optimises for a small, hand-picked set organised by task, with the routing table written so that a need maps to one named repository. That has a concrete consequence: a registry will surface a skill for a task the curator here never considered, and this catalogue will surface a skill whose author has actually used it in the described workflow. Neither is strictly better. If you know exactly what you want and it is unusual, a registry wins. If you want a starting set and you trust the curator's taste, this wins. The manifest is what makes the two comparable at all, since skills.json gives an agent something structured to read in the same way it would read a registry index. Note also that the catalogue is self-referential in a useful way: nuwa-skill distils a person's thinking into a skill, darwin-skill is described as evaluating and improving an existing skill, and skills-guide teaches how to write one. If you intend to author rather than consume, those three entries are the part of the catalogue aimed at you.
Maintenance cost and what to verify before adopting
The maintenance model is manual by design. Independent skills are updated by re-cloning their repositories; built-in skills are updated by re-copying subdirectories; huashu-skill-updater exists to tell you that a newer version is available, not to apply it. There is no version constraint tying a skill to a particular agent release, and the supplied material does not describe a compatibility matrix. The repository's last push is recorded as 2026-09-06 and no releases were retrieved, so the release cadence cannot be judged from what is here. The licence position is the sharpest open question: the metadata gives no licence for this repository, and each linked skill is a separate repository whose terms are not described in the README. That is not a legal problem to be solved by reading this article; it is a fact to check in each repository you intend to depend on. Concretely, before adopting, open skills.json to see whether the manifest carries install paths and runtime notes, confirm the target skill's repository is still being pushed to, and check the licence file in that repository rather than assuming this catalogue's terms cover it.
Editorial conclusion
Adopt huashu-skills if you already run Claude Code or another agent that reads SKILL.md and you want a curated starting set rather than a search engine; skip it if you need per-skill licence clarity, since the repository states no licence and each skill lives in its own repo under its own terms. Before installing anything, open skills.json and the individual target repository, confirm the skill matches your agent runtime (huashu-icon-set and huashu-slide-doubao are marked as Doubao-environment only, huashu-slide-codex as Codex-only), and check whether the skill is a standalone repo or a subdirectory of this one, because dukou is installed by copying skill/dukou/ rather than by cloning the top level.
Community notes