Chinese documentation gets a defined editing routine
zh-tech-writing asks a coding assistant to replace vague praise with facts a reader can use: commands, file names, or the exact error. The project is written in Chinese, and the repository has no English documentation. Its intended output is Chinese technical writing, including READMEs and API explanations. If your team's documents already go through an assistant, this gives that assistant a specific editorial routine instead of another request to make the text clearer.
The main skill contains a 14-item checklist for common machine-written habits. It flags ceremonial openings, sales adjectives, and rigid rhetorical patterns, then tells the assistant to revise every occurrence. That specificity is the attraction. You can inspect the rules before using them and decide whether they match your house style.
What happened when we ran it
Our lab did not run commit ffda935 on October 13, 2026: the harness found no supported ecosystem, GitHub's language field was null, and the repository had no Dockerfile. There are no install, build, test, or audit results to report. The run record therefore cannot support a claim about execution success, writing quality, or how reliably a model follows these instructions.
The files explain that outcome. This repository supplies SKILL.md and reference documents, while an external assistant performs the writing. A useful evaluation would compare actual document edits, check that commands and conditions survived, and record which instructions the assistant ignored. We haven't measured that behavior here. Reading the rules can establish what the project asks for, but cannot establish how consistently any chosen model delivers it.
The skill sets sentence limits and preserves reader intent
The sentence guidance aims for clauses under 20 Chinese characters, asks writers to split clauses beyond 30, and sets a 100-character ceiling for a whole sentence. It also prefers active verbs and explicit referents. Those are usable editing instructions for a README whose nouns and prerequisites have become buried in long sentences. A reviewer can check each recommendation against the original meaning rather than accepting every shorter sentence automatically.
Before drafting, the assistant must identify the reader and the action the document should enable. If it can't state that clearly, the skill tells it to ask. This is more useful than editing only punctuation: an API guide for a caller needs different explanations from a design document for a maintainer. The instructions also tell the assistant to read an existing document fully before changing it, which discourages isolated sentence repairs that miss surrounding conditions.
Installation adds instructions to an existing assistant
The README provides npx skills add leter/zh-tech-writing -g and a manual route that copies skills/zh-tech-writing into ~/.claude/skills/. You still need Claude Code or another tool that supports Agent Skills. The repository supplies no model service and requires no separate project API credential. Access, model choice, and any billing remain properties of the assistant you use to read and apply the skill.
Its writing workflow has 5 steps, ending with automatic typography correction and a manual punctuation check. AutoCorrect is recommended rather than bundled. The README gives platform-specific ways to obtain it and says the assistant should skip the executable step if the command is unavailable. That fallback is convenient, though teams who require identical formatting on every machine should make the formatter an explicit prerequisite of their own workflow.
Review-only mode requires an explicit request
By default, the skill tells the assistant to modify an existing document directly. To receive suggestions without file changes, you must ask for that mode. The requested response then pairs the original sentence with an edit and a reason. This matters in a repository where documentation changes need owner review: installing the skill does not itself make every invocation a read-only editorial pass.
The 14-item checklist is also an instruction for a model to judge its own output. It does not supply an independent checker for weak explanations, deleted caveats, or invented facts. The README says facts must come from your project and that missing evidence should lead to removing empty claims or asking you. Keep the original nearby and verify names, commands, and limitations after an edit. Better prose can still contain a technical mistake.
Typography rules are specific enough to clash with house style
typography.md distinguishes number ranges, units, and percentage changes, including the difference between changing by an amount and changing to a result. The main skill requires spaces between Chinese text and English or numbers. These choices help settle recurring editorial disagreements, but they're choices. A team with established typography should compare its conventions with this file before making the skill part of routine documentation work.
Paragraph guidance prefers no more than 4 lines and allows at most 7. That is harder to apply consistently because line counts depend on wrapping and display width. The manual-structure reference supplies a proposed hierarchy for product documentation and rules for file names. I would use it when planning a new manual, while keeping an existing documentation site's navigation decisions unless changing them solves a reader's actual problem.
September activity supports a trial, without evidence of adoption quality
The last push was September 24, 2026. GitHub reported 368 stars and 0 open issues and PRs, and the latest-release endpoint returned no release. The issue list was empty. These facts show a recently touched repository with little public feedback to assess. They don't demonstrate that users have validated the rules across projects, and the absence of a release tag alone doesn't establish abandonment.
Ruan Yifeng's document-style-guide is the direct alternative when a human editor wants the underlying Chinese style reference. AutoCorrect is preferable when the requirement is repeatable spacing and punctuation checks, including CI linting. Choose zh-tech-writing when you want the assistant to apply editorial judgment as well. Start with a document you know closely, request suggestions only, and reject any change that makes an instruction easier to read by making it less accurate.