devcxl/mattpocock-skills-zh: a Chinese mirror of Matt Pocock's agent skills

Two installers, one rule: pick exactly one

Two paths, and the Chinese README is emphatic that they are mutually exclusive. The Claude Code plugin route installs the whole set as a managed read-only bundle from the marketplace bundled in this repository. The skills.sh route copies editable Chinese files into your project. Installing both makes every skill appear twice, which is the stated reason to choose one.

claude plugin marketplace add devcxl/mattpocock-skills-zh
claude plugin install mattpocock-skills@mattpocock

Inside a Claude Code session the same two steps use slash form:

/plugin marketplace add devcxl/mattpocock-skills-zh
/plugin install mattpocock-skills@mattpocock

Both point at this repository's own marketplace rather than the English set in the official one. The editable path is the same single line installer, and it writes plain files you own:

npx skills@latest add devcxl/mattpocock-skills-zh

Nothing updates itself in the background after that. To pull later changes you run `npx skills update` yourself.

The same single-line installer is also the third option, aimed at anyone who wants to tinker, and it works on Claude Code as well as on Codex and other agents, because what it writes is an ordinary file in your repository. The stated design principles are small, customizable and composable skills that work with any model, and the stated audience is engineers doing real work rather than vibe coding. The contrast drawn here is with GSD, BMAD and Spec-Kit, approaches that help by taking over the process, at the cost of your control and of process bugs that become very hard to debug.

The manifest names the upstream English repository

The package manifest does not describe this repository. It is named mattpocock-skills, marked private, and its repository url is https://github.com/mattpocock/skills, the upstream English project rather than the Chinese fork you are reading. The version field reads 1.3.0, which lines up with the newest release tag v1.3.0 dated 2026-09-30, alongside v1.2.3 from 2026-08-08 and v1.1.0 from 2026-07-22. Only three npm scripts exist: changeset, version, and check-plugin-version. The version step chains changesets with a plugin version sync, and check-plugin-version runs that same sync script in check mode, which is the guard against the plugin bundle drifting from the package version. There are no runtime dependencies, no build step and no test command. The manifest pins [email protected] as its package manager and pulls only the changesets tooling as devDependencies. Nothing in this package executes when you install it, and any skew between the shipped plugin bundle and 1.3.0 has to be caught by that check mode rather than by npm. There is no homepage field either, and the prose carries the attribution instead: it says devcxl maintains this as an unofficial third-party Simplified Chinese localization of mattpocock/skills, that every Chinese install path points at this repository, and that the English original stays upstream.

A noon sync that nothing on record explains

The one-line summary claims the Chinese files are resynced from upstream every day at noon. Nothing here explains how that works. There is no workflow description, no sync command, and no note about which upstream commit the translation follows, or how a partially edited skill is handled when upstream moves under it. The root listing does carry scripts/, changelog.cjs and .changeset/, so release bookkeeping exists, but the only scripts with documented meaning are the three npm entries, and none of them is the noon sync. The repository was pushed to on 2026-10-01, one day before this writing, so the mirror is fresh in the way a mirror can be fresh: files landed recently, and no record says they landed at noon. That leaves the schedule resting on the summary line alone. The root also carries CLAUDE.md, AGENTS.md, a .claude-plugin/ directory and an .out-of-scope/ directory, none of which is explained here.

setup-matt-pocock-skills is the one selection that matters

The skills.sh installer asks which skills you want, and one selection is called out as mandatory: setup-matt-pocock-skills. Miss it and the engineering skills run without configuration. That setup runs once per repository and asks three questions: which issue tracker you use, GitHub, Linear or a local file; which labels to apply when classifying tickets, which the /triage skill consumes; and where you want created documents saved. The plugin route reaches the same wizard under a longer name, /mattpocock-skills:setup-matt-pocock-skills, while the skills.sh route uses the bare /setup-matt-pocock-skills. Two spellings for one step, and mixing them up is easy when both install methods end up on the same machine. Downstream skills read back what setup collected: /triage uses the chosen labels to move issues along a role state machine, and the document location decides where the rest of the set writes.

User-invoked skills cannot reach other user-invoked skills

The index splits the set by who can reach a given skill. User-invoked skills exist only when you type them, such as /grill-me, and their job is orchestration. Model-invoked skills can be picked up by an agent when a task fits. One structural rule holds the taxonomy together: a user-invoked skill may trigger a model-invoked skill, never another user-invoked skill. ask-matt sits above the user-invoked entries as a router that answers which skill or process fits your situation. to-spec then behaves differently from the grilling pair by not interviewing you at all; it synthesizes what the current conversation already settled and publishes it to your issue tracker. That split between interviewing and summarizing is the one worth tracking, since the upstream project names the grilling pair as its most popular skills and points people at them before every change.

The premise behind the whole set is that an agent arrives in a project without its vocabulary and has to learn the jargon on the fly, so it spends twenty words where you would use one. The grilling skills close that gap. The ambition behind the second one is a step further: agree the vocabulary once, and let the shorter phrasing carry across session after session.

grill-with-docs rewrites GLOSSARY.md in place

grill-with-docs runs the grilling and then keeps the vocabulary. It builds the domain model for your project, polishes the terms, and updates GLOSSARY.md and your ADRs on the spot. The worked example comes from a course video manager at a pinned commit, where the file was still called CONTEXT.md, before the GLOSSARY.md naming convention took hold. The before and after sentence is the whole argument: a lesson inside a section of a course being made real, given a spot in the file system, becomes a problem with the materialization cascade. Shorter, and it survives more sessions. The stated downstream effects are consistent naming of variables, functions and files, easier navigation for an agent, and fewer tokens spent thinking because the language is shorter. This repository root carries GLOSSARY.md and an .agents/adr/ directory, so the artifacts the skill writes have a home here. The reasoning comes from ubiquitous language in domain-driven design, where conversations among developers and the expressions in the code derive from one shared domain model. The glossary also absorbs decisions that are hard to explain, which is why the ADR records sit beside it.

improve-codebase-architecture scans, it does not rescue

improve-codebase-architecture scans a codebase for deepening opportunities, renders them as a visual HTML report, and then grills you about the one you select. The suggested cadence is every few days. Its own framing is that a scan is not a rescue: on a genuinely old codebase it will surface real candidates, but it will not untangle the mess for you. to-spec takes the complementary half, testing which modules you are about to touch before any spec exists. The underlying argument cites deep modules, ones that expose a lot of functionality through a simple interface, as the counterweight to the entropy that agents accelerate along with coding speed. The promise that this concern is built into every layer of the set is thinner than it sounds, since the section making that promise names only /to-spec in its list before moving on to the architecture skill. The framing for that section is about investing in the design of the system every day, paired with the observation that most applications built with agents end up complex and hard to modify, because an agent that speeds up coding speeds up software entropy too.

The skill index stops mid-link and Codex has no plugin

The published inventory is incomplete. The Engineering index breaks off in the middle of a link to to-tickets, so the visible list of engineering skills stops there and the remainder of the index cannot be read. Codex users also have no first-class path: a native Codex plugin is still in planning, with the decision recorded in .agents/adr/0002-ship-as-a-claude-code-plugin.md, so Codex and other agents depend entirely on the file-copy installer. One number belongs to someone else. The roughly 60,000 developer subscriber count for Matt Pocock's newsletter is attributed to the upstream README, not to anything this mirror counted. The last push landed on 2026-10-01 and the repository is not archived. Versions move on a comparable cadence, with v1.1.0 in July, v1.2.3 in August and v1.3.0 at the end of September 2026.

Editorial conclusion

Worth using if you want Matt Pocock's prompt set in Simplified Chinese and accept a translation layer you may want to edit by hand. Skip it if you need provenance you can audit from the manifest alone. Before installing, read package.json and confirm which repository the plugin marketplace actually resolves, then check whether the files on disk still match what the upstream set says.

Frequently asked questions

Official sources

1. devcxl/mattpocock-skills-zh on GitHub
2. Issues
3. License: MIT
4. README
5. Releases