devcxl/mattpocock-skills-zh: a Chinese translation of Matt Pocock's agent skills, synced daily
Matt Pocock 技能集的中文翻译版 — 地道中文，原汁原味的技术术语。基于 mattpocock/skills 复刻。每日中午12点钟同步
At a glance
- What is it?
- This repository republishes Matt Pocock's engineering-oriented agent skills with Chinese prose and English technical terms. It is a translation layer, not a fork with its own behaviour, so adoption depends on how much you trust a daily sync.
- Who is it for?
- Adopt devcxl/mattpocock-skills-zh if your team reads Chinese more comfortably than English and you want the same skill set, but verify the translation commit against the upstream mattpocock/skills before relying on it in a repository you care about, since the README documents a daily sync rather than a pinned upstream commit.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What devcxl/mattpocock-skills-zh actually is
This is a Chinese-language republication of mattpocock/skills. The upstream project is a set of agent skills for Claude Code, Codex and other coding agents, written by Matt Pocock and described in its README as skills for doing real engineering rather than what the README calls vibe coding. The translation repository keeps the skill files in the same shape and translates the surrounding prose into Chinese while leaving technical terms in their original form. That last decision matters more than it sounds. A skill file is mostly instructions to a model, and model instructions that mix translated narrative with untranslated identifiers tend to survive translation better than fully localized ones, because the identifiers are the parts the model has to match against real files, commands and APIs.
The repository is Shell-first, MIT licensed, and its default branch is main. Its topics list ai-agent, chinese, prompt-engineering, skills and translation, which is an accurate summary of the scope: this is a localization project, not a reimplementation. The README states that it is based on mattpocock/skills and syncs every day at noon. The last push was on 2026-09-16, and the most recent release is v1.2.3 from 2026-08-08, so the project is being pushed to regularly.
Who is it for? Teams whose working language is Chinese but whose code, issue trackers and identifiers are in English. If you have tried to run an English skill set past engineers who read English slowly, you already know the failure mode: the skill gets skipped, and the team falls back to ad hoc prompting.
How the translation is structured and what it inherits from upstream
The top-level layout mirrors the upstream repository: .agents/, .changeset/, .claude-plugin/, .github/, docs/, scripts/ and skills/. The package.json names the package mattpocock-skills at version 1.2.3, marked private, with the repository URL pointing at mattpocock/skills and an MIT licence field. Its scripts are changeset, version and check-plugin-version, and the dev dependencies are @changesets/changelog-github and @changesets/cli. In other words, the release machinery is inherited from upstream rather than invented here, and the translation rides along with it.
The skills themselves are organized by who can trigger them. The upstream README splits them into user-invoked skills, reachable only when you type them, and model-invoked skills, which the agent can pick up on its own when a task fits. A user-invoked skill can trigger a model-invoked one, but never another user-invoked skill. That constraint is the architectural spine of the whole set, and a translation has to preserve it exactly, because it is expressed in the skill metadata, not in the prose. If a translated skill file changes which category a skill belongs to, the orchestration breaks in a way that is hard to debug.
The engineering skills listed upstream include ask-matt, grill-with-docs, triage, improve-codebase-architecture, setup-matt-pocock-skills, to-spec, to-tickets, implement and wayfinder, with tdd and diagnosing-bugs appearing in the README's discussion of feedback loops. Each of those is a separate SKILL.md under skills/engineering/ or skills/productivity/. Anything the upstream README says about what a skill does applies to the translated copy only insofar as the translation is faithful, and the repository does not, from what the README shows, publish a per-file fidelity report.
Installing the Chinese skills and running setup once per repository
The upstream README gives two installation philosophies and warns that installing both causes every skill to appear twice. The Claude Code plugin installs the whole set as a managed read-only bundle that updates when new versions ship, which the README frames as subscribing rather than forking. The skills.sh path, driven by the npx installer, copies editable skill files into your repository so you can modify them. The translation repository does not document a separate installer of its own, so the realistic approach is to use the same installer against this repository, or to vendor the translated skill files directly.
The Claude Code plugin route, as documented upstream, looks like this:
claude plugins install mattpocock-skillsAfter running it you should see the skill set registered as a plugin, and the README notes it lives in the official Claude Code marketplace, so no extra marketplace entry is needed and updates arrive automatically. Be aware that this installs the upstream English bundle, not the Chinese translation, because the plugin name and marketplace entry belong to mattpocock/skills.
For Codex and other agents, the upstream installer is:
npx skills@latest add mattpocock/skillsThe installer asks which skills you want and which coding agents to install them onto. The README is explicit that you must select setup-matt-pocock-skills during this step. The same command is also the route for people who want the skills as plain editable files in their own repository; in that case nothing updates in the background and you run npx skills update when you want the latest changes.
Once the skills are in place, run the setup skill in your agent, once per repository:
/setup-matt-pocock-skillsAccording to the README it asks three things: which issue tracker you use (GitHub, Linear or local files), which labels you apply when triaging tickets, and where you want created documents stored. A first real use after that is a grilling session, which the README describes as the fix for the most common failure mode, misalignment between you and the agent before work starts. The productivity skill is /grill-me and the engineering variant is /grill-with-docs, which additionally builds a shared domain language and records hard-to-explain decisions as ADRs.
The translation lag is the real constraint
The README states that this repository syncs at noon every day. That is a claim about a schedule, not a guarantee about content. A daily sync means there is a window, up to roughly a day, in which upstream has changed and the translated copy has not. For a skill that mostly encodes process, a day of lag rarely matters. For a skill that references a specific file path, a flag or a config key, a day of lag is exactly when you get an instruction that no longer matches the code it points at.
There is a second, quieter problem. The repository does not document a pinned upstream commit, a diff review process, or a way to see which upstream revision a given translated file corresponds to. The CHANGELOG.md and .changeset/ directory exist, and releases are tagged (v1.0.1, v1.1.0, v1.2.3), so there is a version trail. But version numbers here track the packaging, and the README does not state that a release corresponds to a specific upstream revision. If you need to know precisely which upstream state you are running, the README does not tell you how to find out.
Translation fidelity is the third limitation, and it is the one nobody can check for you. Technical terms are deliberately kept in English, which reduces the blast radius, but the surrounding instructions are still prose that a model reads and acts on. A translated skill that softens a constraint, or that renders a conditional as a suggestion, behaves differently from the original. The README gives no translation guidelines, no glossary and no review policy, so fidelity rests on the translator's judgement alone. That is a reasonable bet for a personal workflow and a much weaker one for a regulated or shared codebase.
When you should use upstream mattpocock/skills instead
The honest alternative is the source: mattpocock/skills. The difference is not features, since the skill set is the same, but the update path. Upstream's Claude Code plugin is described as a managed read-only bundle that updates automatically when new versions are published, and the README positions it as the option where you subscribe instead of forking. This translation repository has no equivalent managed channel documented; you are consuming a copy that someone else refreshes on a schedule.
If your team reads English comfortably, upstream removes an entire class of risk: no translation lag, no fidelity question, no ambiguity about which revision you are on. If your team reads Chinese more comfortably, the calculus flips. A skill that engineers actually invoke beats a more faithful skill that nobody opens, and the whole point of the upstream set is that the skills get used every time you make a change, not admired once.
A middle path is worth naming. Because the npx installer writes skills as plain files into your repository, you can install upstream and translate only the skills your team actually uses, keeping your own copy under version control. That trades the daily sync for maintenance work you control. The upstream README warns against installing both the plugin and the file-based copy, since every skill then appears twice, so pick one channel per repository and stay on it.
Licence, upgrade cost and what to check before you commit
The licence is MIT, stated in both the repository metadata and the package.json licence field. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are preserved. This article is not legal advice, and there is a practical detail worth flagging rather than resolving: the translated repository carries its own MIT licence, while the underlying skill content originates in mattpocock/skills, which is also MIT. Keeping the upstream notice intact in redistributed copies is the conservative reading, and the repository layout includes a LICENSE file at the top level.
Upgrade cost is low if you use the file-based installer and low if you consume the repository as-is, because the sync is automated on the maintainer's side. The cost rises the moment you edit translated skills locally, because your edits and the daily sync will diverge, and the repository does not document a merge or rebase workflow for that case. The scripts in package.json (changeset, version, check-plugin-version) are release tooling inherited from upstream and are not something an adopter needs to run.
Before adopting, check three concrete things. First, open skills/ and confirm the specific skills you want are present and translated, since the README's index describes the upstream set and the repository does not enumerate its own coverage. Second, read the translated SKILL.md for your most-used skill side by side with the upstream file and confirm the trigger conditions survived. Third, read CHANGELOG.md to see how releases have tracked upstream changes, which is the only evidence in the repository about how the sync has behaved over time.
Editorial conclusion
Adopt devcxl/mattpocock-skills-zh if your team reads Chinese more comfortably than English and you want the same skill set, but verify the translation commit against the upstream mattpocock/skills before relying on it in a repository you care about, since the README documents a daily sync rather than a pinned upstream commit. Do not adopt it if you need the Claude Code plugin's managed, auto-updating bundle, because the upstream README describes that path as the one where you subscribe rather than fork. Check the CHANGELOG and the skills directory layout first to confirm the skills you want are actually translated.
Frequently asked questions
What are Matt Pocock's Claude Code skills?
They are a set of agent skills for real engineering work, organized by whether the user or the model can trigger them, and covering things like grilling sessions, spec writing, ticket breakdown, TDD and codebase architecture review. devcxl/mattpocock-skills-zh republishes that set with Chinese prose and English technical terms.
How do I install Matt Pocock Skills?
The upstream README gives two routes: the Claude Code plugin via claude plugins install mattpocock-skills, or the file-based installer via npx skills@latest add mattpocock/skills, which also works for Codex and other agents. The README warns that installing both makes every skill appear twice.
What is Matt Pocock's "Grill Me" skill?
It is a grilling session in which the agent asks you detailed questions about what you intend to build, so you and the agent align before any code is written. The README describes it as the fix for the most common failure mode, misalignment, and recommends using it every time you want to make a change.
How to use Mattpocock skills?
After installing, run /setup-matt-pocock-skills once per repository; it asks which issue tracker you use, which labels you triage with, and where documents should be saved. Then invoke user-invoked skills by typing them, such as /grill-me or /grill-with-docs.
Community notes