superpowers-zh: a Chinese fork that turns 20 skills into installs for 26 AI coding tools
🦸 AI 编程超能力 · 中文增强版 — superpowers（250k+ ⭐）完整汉化 + 4 个中国原创 skills，让 Claude Code / Copilot CLI / Hermes Agent / Cursor / Windsurf / Kiro / Gemini CLI / Qoder 等 26 款 AI 编程工具真正会干活
At a glance
- What is it?
- The project translates the upstream superpowers skill set into Chinese and adds four China-specific skills, then wraps the whole thing in one npx command that detects which AI coding tool a project uses. The judgement: the installer and the China-specific skills are the real product, and the translated prose is the part most likely to drift out of sync with upstream.
- Who is it for?
- Adopt superpowers-zh if your team writes Chinese-language specs, commit messages and review comments, and you want the upstream skill methodology available without maintaining per-tool plugin commands. Do not adopt it if you are pinned to an upstream superpowers version and cannot tolerate translation lag between the two repositories, or if your tooling is not on the supported list.
- 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 received new commits within the last day.
- What is it written in?
- Mainly JavaScript, 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 not translation, it is per-tool installation
Upstream superpowers ships its skills as a plugin marketplace entry per tool. The README of this fork states the English project supports 6 tools and requires a different install command for each. That is fine for one developer on one editor. It stops being fine when a team has Cursor on some machines, Claude Code on others, and Qoder or CodeBuddy on the rest, because the setup instructions multiply and nobody remembers which variant they ran. The fork's answer is a single npm package: npx superpowers-zh. According to the README, that command inspects the project, works out which AI coding tool is present, and installs the matching skill set. If detection fails, --tool <name> lets you name the target explicitly. The audience is Chinese-speaking developers who want the superpowers methodology without reading English prompt files, and who move between more than one AI coding tool.
What is actually in the twenty skills
The README's comparison table breaks the 20 skills into 14 translations, 4 China-original skills, and 2 kept from upstream history. The four original ones are the ones worth reading first, because they are the only files this repository owns outright. They cover Git platform support beyond GitHub (Gitee, Coding, 极狐 GitLab, and CNB, Tencent's cloud-native build service), CI/CD examples including Gitee Go, Coding CI, 极狐 CI and a .cnb.yml file, a code review style adapted to domestic team communication norms, and Chinese conventions for Conventional Commits plus Chinese typography and mixed Chinese-English typesetting rules. Two further additions are independent rather than translated: an mcp-builder skill and a workflow-runner skill described as multi-role YAML orchestration. If you already run upstream superpowers and only want the Chinese review and commit conventions, those four skills are the delta you are actually installing.
The translation boundary is enforced, not promised
Forks that translate upstream documentation usually rot quietly: someone edits a translated paragraph, upstream changes the same paragraph, and the two versions diverge with no record of where. This project takes an unusual position on that. The README states that translated skills contain exactly two incremental passages, both explicitly marked in the body with the label 「本节是 superpowers-zh 的增量内容」: one in executing-plans covering common exception handling, and one in using-superpowers covering China-specific skill routing. Everything else is described as section-by-section translation with no modification to upstream sections, and the README says an audit step fails the build if an unmarked increment appears. That is a verifiable design claim rather than a stylistic one, and it is the strongest argument for trusting the translated files. It also tells you what to check when you upgrade: whether the audit still passes after a new upstream release.
Release cadence follows upstream, with a lag you have to plan for
The recent release list shows the pattern clearly. v1.6.0 is labelled as aligning with upstream v6.0.0 and adding Kimi and Pi harness support. v1.7.0 adds global installation plus CodeBuddy and CodeArts support and a Traditional Chinese site. v1.7.1 is described as rewriting subagent-driven-development to align with upstream v6. The gap between v1.6.0 in June and v1.7.1 in July is short, which suggests active tracking, but the version numbering makes the cost visible: this repository's own version and the upstream version it targets are separate numbers, and the release notes are where they are reconciled. If your workflow depends on a specific upstream skill behaviour, you cannot assume the fork has it on the day upstream ships it. The README's own comparison row states the model plainly: 同步上游 + 国产增量叠加, sync upstream plus stack domestic additions. Budget for reading release notes before upgrading, not for blind upgrades.
Tool coverage is wide, and that width is the risk
The supported list runs to 26 entries: Claude Code, Copilot CLI, Hermes Agent, Cursor, Windsurf, Kiro, Gemini CLI, Codex, Aider, Trae, VS Code (Copilot), DeerFlow, OpenCode, OpenClaw, Qwen Code, Antigravity, Claw Code, Qoder, CodeBuddy, CodeArts, Cline, Kilo Code, Crush, and others named in the comparison table including ZCode, DeepSeek Harness and Reasonix. Each of those tools reads skills from a different location and expects a different file layout. A single installer that handles all of them is doing a lot of guessing about paths it does not control. The README acknowledges the failure mode by offering --tool <name> as an escape hatch, which is the honest design: automatic detection is a convenience, and the explicit flag is the contract. If your tool is on the list but the installer picks the wrong target, the flag is the fix, and it is worth knowing that before you file anything.
Where it is the wrong tool
The audit rule cuts both ways. Because translated sections are meant to stay byte-faithful to upstream, this fork is not the place to send improvements to the English skill text. If you find a weakness in how, say, the TDD skill is worded, the README's own framing points you at obra/superpowers, and the comparison table notes that upstream 一般不接受 new skill contributions. That combination means the four China-original skills have no upstream home and the translated ones have no editing latitude here. Second, the project is JavaScript and distributed through npm, so an environment without Node or npm access cannot install it via the documented path. Third, the README carries a substantial sponsor section with referral links and discount codes. That does not make the technical claims wrong, but it does mean the README is part marketing surface, and the skill files themselves are the thing to evaluate. The comparison table also leans on upstream star count as a maturity signal, which is not evidence of anything about this fork's code.
Licence and what an upgrade actually costs you
The repository is MIT licensed, which permits reuse and modification with attribution and without warranty. The upstream project's licence is not stated in the supplied material, so if you plan to redistribute the translated skill files commercially, confirm the upstream terms separately rather than assuming the MIT badge on this fork covers the translated content. Practically, the upgrade cost is the audit. Every upstream release that touches a translated section forces a re-translation and a re-run of the audit that rejects unmarked increments. The release notes show this happening on a roughly monthly rhythm across v1.6.0, v1.7.0 and v1.7.1. For a team that pins a version and reads release notes before moving, that is manageable. For a team that expects the fork to absorb upstream changes silently, the audit rule is the thing that will surprise them.
Editorial conclusion
Adopt superpowers-zh if your team writes Chinese-language specs, commit messages and review comments, and you want the upstream skill methodology available without maintaining per-tool plugin commands. Do not adopt it if you are pinned to an upstream superpowers version and cannot tolerate translation lag between the two repositories, or if your tooling is not on the supported list. Before installing, check two things: run npx superpowers-zh --help to confirm the detection path and the --tool flag behave as documented for your editor, and read the four China-specific skills to see whether their review and commit conventions match your team's, because those are the files the upstream project does not maintain.
Community notes