translate-skill

Translation skill

Use this skill to translate the content of the upstream mattpocock/skills into Simplified Chinese for use in vinvcn/mattpocock-skills-zh-CN。

This skill is used forcontent localization, not Git synchronization.

Operating principles

Translate user-visible English explanatory text into natural Simplified Chinese, while preserving all behavior-critical content as-is.

The target repository is an independent Simplified Chinese localized version. It should receive translated content, not the upstream repository metadata.

What to translate

Translate natural language text, including:

README 说明
skill instructions
skill descriptions
用户可见的 frontmatter prompts
面向 agent 的指引
面向维护者的指引
docs 说明性文字
以说明性文字写成的示例
Markdown 标题（headings）

Translation rules for Markdown headings

Headings are explanatory text; translate them into Simplified Chinese; keep the heading hierarchy and Markdown structure unchanged. Inline code and identifiers embedded in headings are preserved as-is.

The fixed schema headings of docs pages (What it does、When to reach for it、Common questions、It's working if、Where it fits、Prerequisites) and the structural headings of skill files (Steps、Reference , etc.) must use the TRANSLATION-GLOSSARY.md unified translations registered in, to ensure consistency across all pages.
Other headings are translated freely according to the page context and do not need to be registered one by one.
Exceptions (kept in English as terms, not translated): bucket names (Engineering、Productivity、Misc , etc., consistent with directory names); invocation terms (User-invoked、Model-invoked）。
When modifying headings, also update the anchor links in the same file that point to that heading (GitHub generates slugs based on heading text; Chinese headings generate Chinese anchors).

What to preserve as-is

Do not translate or rewrite:

目录名
skill 名称
slash commands
CLI 命令
代码块
inline code
文件路径
package 名
tool identifiers
API identifiers
环境变量名
frontmatter keys
JSON/YAML/TOML keys
Markdown 链接 URL
行为关键 labels

Keep the Markdown structure, heading hierarchy, list nesting, tables, link targets, relative paths, and code fences unchanged.

Repository path localization

When translating user-visible installation examples, replace the upstream repository path:

mattpocock/skills

with the localized repository path:

vinvcn/mattpocock-skills-zh-CN

Only make this replacement when the command or explanatory text is telling users how to install or use the localized repository.

Do not remove attribution to the upstream project.

Frontmatter rules

Preserve frontmatter keys as-is.

Classify each frontmatter value by meaning, not just by field name:

Keep the name value unchanged.
Translate user-visible or agent-facing natural language text into Simplified Chinese, including the values of description and argument-hint .
Keep identifiers, commands, paths, package names, URLs, tool names, booleans, numbers, and other typed configuration values unchanged.
Within translatable values, preserve embedded slash commands, inline code, placeholders, paths, URLs, package names, tool names, and other behavior-critical fragments as-is.
Flag ambiguous values for review; do not guess.

Examples:

---
name: teach
description: 在这个工作区中教用户一个新技能或概念。
disable-model-invocation: true
argument-hint: "你想学习什么？"
---

Translation style

Use Simplified Chinese that meets the following requirements:

自然
对开发者友好
简洁
准确
与本仓库现有语气一致

If a common engineering term is standard usage among developers, or translating it would reduce clarity, keep it in English.

Terminology reference

Consult the repository root's TRANSLATION-GLOSSARY.md。

For terms that have been decided, strictly use the recorded translation.

Term decision and implementation workflow

For the term request and claiming workflow, see CONTRIBUTING.mdthe translation is governed solely by TRANSLATION-GLOSSARY.md as the sole authority. A complete implementation workflow:

Approval: the maintainer enters the term into the "Decided translations" section of the glossary and fills in "Decided on"; the request line remains in the requests section.
Implementation: create a branch, replace literal occurrences in the repository according to the decided translation (case-insensitive matching), and only change occurrences related to that term;dsh-plugin/skills/ is a build artifact (gitignored, generated by dsh-plugin/scripts/copy-skills.mjs from skills/ ), do not edit it by hand; after fixing the source, it will be automatically synchronized with the plugin build.
Update the glossary: change the status of the request line to applied(this status takes effect after the application PR is merged), and keep the source references and history lines.
Submit the PR: follow the PR checklist in CONTRIBUTING.md (first git add then run the script); the PR description should link to the glossary entry and the related issue; unless you explicitly want to close the issue, do not use keywords that will automatically close it.

Single-file workflow

When translating a single file:

Confirm the file path and file type.
Classify the file as translatable natural language text, mixed content, config/metadata, or untranslatable.
Before translating, protect behavior-critical fragments first.
Translate only natural language text.
Restore the protected fragments exactly as they were.
Check that commands, code blocks, paths, URLs, identifiers, and frontmatter keys remain unchanged.
Check that the localized installation command uses vinvcn/mattpocock-skills-zh-CN。
Return the translated file content or patch, along with all review markers.

Repository refresh workflow

When refreshing from upstream:

Treat upstream as a content source, not as Git history.
Identify newly added, changed, and removed content files.
Translate newly added and changed files that contain explanatory text.
Copy or retain untranslatable support files only when they are within the refresh scope.
Keep the localized repository's README positioning and installation path unchanged.
Follow the "Verification steps" to complete the post-sync checks of structure, integrity, index, and behavior-critical content.
Append a brief entry to the README sync record.
Record this verification result, the translator, and a summary of the translation strategy in the README.
Flag ambiguous files, removed files, or risky conversions for review and hand them to the maintainer.
Summarize translated files, copied or retained files, removed files, skipped files, verification results, and review markers.

Verification steps

After each upstream content refresh, the following checks must be completed and recorded:

Run node scripts/check-translation.mjs, and confirm that the Markdown structure, frontmatter, README install path, and license invariant have not been broken.
Check public skill index consistency:engineering/、productivity/、misc/ the skills under README.md must appear in both the top-level .claude-plugin/plugin.json；personal/、in-progress/、deprecated/ should not appear in the plugin or top-level public index.
Compare upstream/main 's in-scope file list to confirm that no upstream files are missing and that no stale files that have already been removed from upstream and are not part of local policy are retained.
Check behavior-critical content in shared Markdown files: frontmatter keys and name values unchanged, fenced code blocks balanced, paths, commands, URLs, and identifiers not mistakenly changed.
Run git diff --check and git diff --cached --check, confirming there are no whitespace or patch hygiene issues.
Check that the README sync record points to the latest upstream short SHA and includes the local sync commit; do not leave a "pending" placeholder.
Scan for stale install paths and old paths, such as install commands still pointing to the upstream repo, old short Chinese repo paths, removed triage skill names, removed relative domain-model paths, etc.
Run node scripts/audit-english.mjs as a manual review queue. This script will contain many legitimate English terms, commands, examples, and identifiers in this repo, so it only serves as a review flag, not as a hard failure threshold.

Verification results should be written to the top-level README.mdin sync, using a short checklist; do not paste full command output into it.

SYNC.md sync record

Every upstream refresh should add a short entry to the sync record in the top-level SYNC.md .

The entry should include:

Refresh date, using the YYYY-MM-DD format
Upstream source revision, usually mattpocock/skills@<short-sha>
Local sync commit (if it already exists); otherwise write a short pending note first, and replace it after committing
A one-sentence description of the visible content changes in this refresh

Keep the record short.

Example:

- 2026-05-09：已同步上游 `mattpocock/skills@733d312`，本地 commit `c9fe120`。为 `prototype` 和 `in-progress` 内容新增了中文翻译，并刷新公开 skill 索引。

Review output format

When reviewing a translation refresh, provide:

改动文件：
- ...

已翻译文件：
- ...

复制或保留文件：
- ...

移除或过时文件：
- ...

复核标记：
- ...

SYNC.md 同步记录：
- ...

验证结果:
- ...

不变量检查：
- 安装命令指向 vinvcn/mattpocock-skills-zh-CN
- 代码块保持原样
- frontmatter keys 保持原样
- 路径和 identifiers 保持原样
- Markdown 结构保持原样

Fail-closed rule

When unsure whether a piece of text is behavior-critical, preserve it as-is first and mark it for review.

Do not silently rewrite any content that could affect installation, skill discovery, command execution, file references, API calls, tool usage, or agent behavior.