Zhijian Skills: nineteen skills, one generated marketplace

One repository is the source and the publishing pipeline

The stated premise is that this is the only publishing repository: new skills, releases, issues and contributions all belong here. That is a governance choice rather than a technical one, and it shapes everything else in the tree.

Installation goes through the `skills` command. Listing what is available is one call:

npx skills add zjp1997720/zhijian-skills --list

Installing one skill by name is the same command with a selector, and the fuller form targets a specific agent and scope:

npx skills add zjp1997720/zhijian-skills \
  --skill codex-model-routing-team --agent codex --global --copy --yes

So a user has three decisions to make before a skill lands: which one, which harness, and whether it is global for that harness or local to a project. The `--copy` flag is worth noticing next to `--global`, because it implies the files are materialized rather than linked at install time.

The repository itself carries the plumbing for that. Alongside the skills there is a registry directory, a plugins directory, scripts, templates, tests, assets, an `AGENTS.md`, a contributing guide and a Chinese README, plus a `.codebuddy-plugin/` directory that names the target host explicitly.

Nineteen skills, grouped by what they operate on

The catalog covers seven areas, and the grouping says more than the skill names do.

Model infrastructure has two entries, `codex-cli-model-bridge` and `workbuddy-cli-model-bridge`, both about connecting verified CLI subscription models through a loopback proxy rather than an API key. Codex control is the largest group: `codex-doctor` diagnoses context, configuration and workspace drift without changing files, `codex-handoff` moves an oversized or slow task into a fresh task with compact context, `codex-skill-admin` audits and toggles local skills, and `codex-model-routing-team` compiles parallel work into TeamPlans.

The rest are content and publishing tools. `codex-external-handoff` supervises persistent Codex App Server threads from another host, `codex-image-gen` reuses the logged-in Codex CLI OAuth state to generate images without an API key, `codex-theme-studio` builds reversible macOS themes, and `gpt56-sol-pro-consult` asks for a file-grounded second opinion.

The publishing side is where the volume is. `html-express` turns dense material into a self-contained HTML report, `leadbook` produces evidence-backed Chinese business books, `wechat-article-search` discovers public-account articles as structured JSON, `wechat-styler` converts Markdown into inline HTML for WeChat, `web-clipper` saves article URLs as structured Markdown, and `wxmp-article-harvester` exports a whole account into Markdown with a completion report. `enterprise-clone-builder` builds a digital-twin repository from evidence, `light-plan-and-work` plans briefly and escalates only on heavy conditions, and `skill-open-sourcer` is the skill for auditing and publishing skills.

Adding the WorkBuddy marketplace installs nothing

The second distribution route is a marketplace inside WorkBuddy. The path in the product is Experts, then Skills, then Connectors, then Skills, then Bundles, then Add marketplace, where you enter the repository name or the full git URL. The instructions are explicit that you should use the repository URL rather than a web page pointing at a directory such as `/tree/main/skills`, or a raw JSON URL.

The reason given is payload completeness. Git distribution preserves each skill's whole payload, including its scripts, references and assets, which is exactly what a web page or a raw file fetch flattens away. That distinction matters for the heavier skills in this catalog, several of which wrap CLI tools rather than just prose.

The line that catches most people is this: adding the marketplace does not install every skill. You select `zhijian-skills` after adding it and then install the individual bundles you want. So the marketplace is an index, and installation is still a per-skill decision, the same decision you make with the command line.

The verification note is narrower still. Installation has been verified with macOS WorkBuddy, and Windows has not been tested at all.

Catalog presence is not the same as runtime compatibility

The documentation draws a distinction that many skill collections blur, and it is worth quoting in spirit. Being listed in the catalog does not imply that the WorkBuddy runtime can run it. Some entries are marked with a label meaning they require Codex host capabilities, and the catalog carries that marker rather than hiding those entries.

Beyond that, other entries may still need local CLIs, authentication, or dependencies, and the documentation points you at each skill's own page for those requirements. The adapter layer does not change them, which is the sentence that matters: installing through the marketplace does not give you a Python toolchain, a logged-in OAuth state or a browser session that you do not already have.

That makes the skills less portable than the marketplace suggests, and it is an honest framing. Several entries in this catalog are wrappers around other tools, including an OAuth reuse path for image generation and a loopback proxy for subscription models, so the real dependency list for any given skill is longer than its name implies.

The same caution applies on the Codex side, where the `--agent codex` flag decides where the files land but nothing about what they need at run time.

The catalog is generated from a JSON registry, and CI fails on drift

The catalog is not hand-maintained prose. It is generated from `registry/skills.json` plus the existing Chinese documentation, which means the JSON file is the real index and the tables you read are a build artifact.

Maintainers run a script after any catalog or version change:

python3 scripts/build_workbuddy_marketplace.py

And continuous integration checks for drift, which is the part that makes the approach workable. A generated file nobody verifies is just a file that goes stale, so the drift check turns the generator into a contract: if someone edits the marketplace manifests by hand, or changes a version without regenerating, CI fails.

The same generate-then-verify pattern shows up in the plugin layer. Manifests and repository-local symlinks under `plugins/` are generated, while the editable skill source stays under `skills/`. Installation materializes those links into complete files, which is what turns a generated link into something a host can actually read.

The cost of that design is a dependency on symlink support in the git checkout. The documentation states the requirement plainly: git checkouts must support symlinks. On a platform or filesystem where they are not available, the editable source and the installed payload come apart.

A Python verifier checks cold-start discovery and payload hashes

There is a script whose job is to prove an install actually works, not merely that files were copied:

python3 scripts/verify_workbuddy_install.py --cli <WorkBuddy-bundled-codebuddy>

It checks three things: that the installation is present, that the host discovers the skills at cold start, and that the payload hashes match. The work happens in a temporary config, so the check does not disturb your real configuration. Adding `--source zjp1997720/zhijian-skills` extends the check to the public source rather than a local checkout.

The payload hash check is the meaningful one. Because installation materializes generated links into complete files, a skill can be present and still be wrong, if the files that landed are not the files the registry describes. Hashing them is the only way to catch that class of problem, and it is the sort of verification most skill marketplaces skip.

Cold-start discovery is the other half, because a host that needs a restart before it sees a new bundle fails in a way that looks like a missing file. Testing discovery on a fresh start catches it before you go looking in the wrong place.

An npm manifest runs Python tests and pins the skills CLI exactly

The `package.json` is small and slightly surprising. The package is named `zhijian-skills`, marked private at version 1.0.0, and its single dev dependency is `skills` pinned to exactly 1.5.18 with no range. Pinning the CLI exactly is the sensible choice for a repository whose release process depends on that tool's behavior.

The two scripts are the other surprise. One lists the local catalog, running `skills add . --list` against the repository itself. The other runs the test suite with `python3 -m unittest discover -s tests -v`, which is Python's standard library test runner rather than anything from the npm ecosystem. So a Node manifest is the entry point for a Python test suite, and the `tests/` directory is exercised through unittest.

Releases are tagged per skill rather than for the repository. The recent tags are `wechat-styler/v1.0.0`, `wechat-styler/v1.0.1` and `wechat-styler/v1.0.2`, all three published on 2026-07-17 within about an hour and a half of each other. That is a fast cadence for one skill and says nothing about the others, so per-skill tags are the thing to check when you want to know whether a specific capability is current.

The project is MIT licensed with 778 stars, 102 forks and 4 open issues, and the last push was 2026-09-30.

Editorial conclusion

Zhijian Skills fits somebody who wants one auditable place to install agent skills from, and its own tooling, a registry generator plus a verifier, is more disciplined than most skill collections. Skip it if you cannot use git checkouts with symlinks, since the payload delivery depends on them, or if you are on Windows, which is untested. Before installing, read the runtime requirements on the entry you want, since appearing in the catalog does not mean the host can run it, and regenerate the marketplace whenever you change the catalog.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zjp1997720/zhijian-skills on GitHub