Note: This Skill focuses on streamlining sentence structure and polishing rhythm. If you need to handle AI-generated traces, translationese, and mainland Chinese terms, use it together with humanizer-tw. Recommended order: first humanizer-tw (remove the machine feel) → then good-writing-zh (polish the rhythm).
Rhythm Rules
Breath
Between two punctuation marks (，。；：！？), the number of consecutive characters must not exceed 15–20 characters. If exceeded, the sentence should be broken up or a comma added.
Variation
The length difference between adjacent sentences should be > 5 characters. Avoid 3 or more consecutive sentences of similar length (±3 characters).
Sentence Ending
- Ending with a noun → steady
- Ending with a verb → forceful
- Ending with a particle (的、了、呢) → soft
Avoid consecutive sentence endings all falling into the same type.
Rewriting Techniques
1. Delete redundant characters (consecutive 「的」)
Three consecutive 「的」 → the ideas are not well organized; delete at least one.
原句：這是公司的新的產品的宣傳方案。
改寫：這是公司新產品的宣傳方案。
（理由：三連「的」刪為一個，語意不變）
原句：他提出的關於市場的未來的發展報告。
改寫：他提出的市場未來發展報告。
（理由：「關於」多餘，「的」可精簡為一個）
2. Delete redundant characters (進行/實施/加以)
「進行」「實施」「加以」 can usually be deleted directly.
原句：我們對此問題進行了深入的討論。
改寫：我們深入討論了這個問題。
（理由：刪「進行」，動詞前移）
原句：相關部門已對該方案加以審核。
改寫：相關部門已審核該方案。
（理由：刪「加以」，直接用動詞）
3. Split long sentences
In principle, do not exceed 30 characters. Exceptions: tightly linked conditional clauses, parallel structures, and strings of technical terms may be relaxed, but punctuation must be used to ensure internal pauses.
原句：由於天氣不好加上交通阻塞的關係，所以他沒有辦法準時抵達會場參加會議。
改寫：天氣差，路又塞。他遲到了。
（理由：一句塞了兩個因果，拆開各自獨立）
原句：為了能夠更好地滿足客戶在不同場景下對於產品功能的多樣化需求，我們決定重新設計整個系統架構。
改寫：客戶需求多樣，現有架構撐不住。我們決定重新設計。
（理由：40+ 字壓縮為兩句，因果更清晰）
4. Cut the opening
Directly delete filler openings and start from the key point.
原句：關於這個問題，我認為我們應該重新思考策略。
改寫：我們應該重新思考策略。
（理由：「關於這個問題」是廢話）
原句：基本上來說，這個方案的可行性是比較高的。
改寫：這個方案可行性高。
（理由：砍開頭 + 刪「是...的」句式）
5. Restore strong verbs
「weak verb + abstract noun」 → restore to a single strong verb. Passive voice → active voice.
Common patterns:
- "進行 X" → "X"
- "Make X" → "X" (make a decision → decision)
- "Give X" → "X" (give assistance → assistance)
- "Carry out X" → "X" (carry out improvement → improvement)
- "Achieve the purpose of X" → "for X"
- 「被...所...」→ active voice
原句：我們需要對現有流程做出改善。
改寫：我們需要改善現有流程。
（理由：「做出改善」→ 直接用「改善」）
原句：這個問題被許多研究者所關注。
改寫：許多研究者關注這個問題。
（理由：「被...所...」→ 主動句，更有力）
原句：本計畫旨在達到提升效率的目的。
改寫：本計畫旨在提升效率。
（理由：「達到...的目的」是多餘包裝）
Checklist
After rewriting is complete, check item by item:
- In principle, there are no sentences exceeding 30 characters (except tightly linked conditional clauses, parallel structures, and strings of technical terms, but they must have punctuation pauses)
- There are no three consecutive 「的」
- Adjacent sentence length difference > 5 characters, with no 3 or more sentences of equal length (±3 characters)
- The opening has no filler nonsense
- Sentence endings do not have consecutive same types (consecutive 「的」「了」「呢」)
- All deletable instances of 「進行」「實施」「加以」 have been deleted
- 「weak verb + abstract noun」 has been restored to a strong verb, and passive voice has been converted to active
Workflow
Mode 1: Rewrite an existing article
Output three sections in order:
<diagnosis> — Scan the original text sentence by sentence and list all violations:
- Which sentences exceed 30 characters
- Where there are consecutive 「的」
- Which openings are nonsense
- Which 「weak verb + noun」 can be restored
- Whether the rhythm is monotonous (consecutive equal-length sentences)
<planning> — Devise a revision strategy for each violation:
- Where to break the sentence, which redundant word to delete, how to restore the verb
- Ensure the logic remains coherent after splitting sentences (add transitional words if necessary)
<rewrite> — Output the rewritten version, marking the main changes in bold.
<diagnosis>and<planning>are the necessary outputs of the rewriting process, ensuring the revisions are comprehensive and consistent.
Mode 2: Automatically apply when writing
When writing Chinese content, automatically follow the above rhythm rules, rewriting techniques, and checklist, without needing extra prompts.
Mode 3: Technical documentation conservative mode (conservative)
Trigger conditions: When handling technical READMEs, API documentation, CLI descriptions, error messages, technical blogs, or when the user explicitly requests "only change punctuation/breathing, do not touch the structure."
This mode exists because technical documentation contains a large amount of content that should not be "polished": code examples, command-line snippets, error message strings, API names, parameter lists. If the full mode's "variation" and "break formulism" rules were forcibly applied, structured enumerations (such as table descriptions and command explanations) would be altered beyond recognition, actually harming information delivery.
Only perform (four categories):
- Delete consecutive three "的" — when the meaning is not lost
- Delete "進行／加以／實施" — when the verb can be used directly
- Split single sentences longer than 30 characters — but see the terminology concatenation exception below
- Fix breathing — insert commas to break continuous 15–20 character runs between punctuation
Suspend:
- "Variation" rule (adjacent sentence length difference > 5 characters) — identical structure in technical enumerations is intentional
- "Break formulistic paragraphs" — first/second/finally are actually clear in operational steps
- Reorganize paragraph order, rewrite semantics
- Use "sentence-ending type rotation"
Absolutely do not touch:
- Code blocks (
…、inline） - CLI commands, file paths, URLs, Markdown link syntax
- Table structure and fields
- English technical terms (keep as-is, even when embedded in Chinese sentences)
- YAML front matter, language menus, version annotations
- Blocks the user explicitly marks as "do not change"
Terminology concatenation exception(even if longer than 30 characters, do not force-split):
Long fragments in the following situations are considered to already have "internal pauses" and do not need commas added:
- Enumeration with enumeration commas: "
.py .ts .js .go .rs .java .c .cpp .rb .cs .kt .scala .php" — each file extension is a pause point - Dash introduction: "Fully multimodal — graphify will use Claude vision to extract concepts from this content" — the dash already segments it
- Parenthetical supplement: "Perform structural analysis on code files (classes, functions, imports, call graphs, docstrings)" — the parentheses themselves are a pause
- Hyphen concatenation: "Edges between code-paper will have higher weight than code-code edges" —
-provides a visual pause
Judgment principle: if a fragment,after removing Chinese/English characters/numbers/punctuation, has fewer than 15 Chinese characters left, even if the character count is long, it still does not count as a violation.
For the theoretical background, see references/guide.md. Integrated from Paul Graham's "Good Writing," Yu Guangzhong, and Wang Dingjun.