@tw93/waza 3.27.0 → 3.28.1

package/skills/read/scripts/fetch_feishu.py

@@ -31,6 +31,7 @@ except ImportError:
     sys.exit(1)
 
 API = "https://open.feishu.cn/open-apis"
+TIMEOUT = 20
 
 
 def yaml_string(value):
@@ -43,7 +44,8 @@ def get_token():
     if not app_id or not app_secret:
         return None, "FEISHU_APP_ID or FEISHU_APP_SECRET not set"
     resp = requests.post(f"{API}/auth/v3/tenant_access_token/internal",
-                         json={"app_id": app_id, "app_secret": app_secret})
+                         json={"app_id": app_id, "app_secret": app_secret},
+                         timeout=TIMEOUT)
     d = resp.json()
     if d.get("code") != 0:
         return None, f"Auth failed: {d.get('msg', resp.text)}"
@@ -69,7 +71,8 @@ def parse_url(url):
 def resolve_wiki(token, wiki_token):
     resp = requests.get(f"{API}/wiki/v2/spaces/get_node",
                         headers={"Authorization": f"Bearer {token}"},
-                        params={"token": wiki_token})
+                        params={"token": wiki_token},
+                        timeout=TIMEOUT)
     d = resp.json()
     if d.get("code") == 0:
         node = d["data"]["node"]
@@ -85,7 +88,8 @@ def get_blocks(token, doc_id):
             params["page_token"] = page_token
         resp = requests.get(f"{API}/docx/v1/documents/{doc_id}/blocks",
                             headers={"Authorization": f"Bearer {token}"},
-                            params=params)
+                            params=params,
+                            timeout=TIMEOUT)
         d = resp.json()
         if d.get("code") != 0:
             return None, f"Blocks fetch failed: {d.get('msg', resp.text)}"
@@ -141,7 +145,7 @@ def blocks_to_md(blocks):
             key = f"heading{level}"
             data = block.get(key) or block.get("heading", {})
             text = extract_text(data.get("elements", []))
-            lines.append(f"{'#' * level} {text}")
+            lines.append(f"{'#' * min(level, 6)} {text}")
         elif bt == 10:
             text = extract_text(block.get("bullet", {}).get("elements", []))
             lines.append(f"- {text}")
@@ -203,8 +207,9 @@ def fetch_feishu(url):
         doc_id, doc_type = real_id, real_type or "docx"
 
     info_resp = requests.get(f"{API}/docx/v1/documents/{doc_id}",
-                             headers={"Authorization": f"Bearer {token}"})
-    doc_info = info_resp.json().get("data", {}).get("document", {})
+                             headers={"Authorization": f"Bearer {token}"},
+                             timeout=TIMEOUT)
+    doc_info = (info_resp.json().get("data") or {}).get("document") or {}
     title = doc_info.get("title", "")
 
     blocks, err = get_blocks(token, doc_id)

package/skills/think/SKILL.md

@@ -20,6 +20,14 @@ Give opinions directly. Take a position and state what evidence would change it.
 - Evidence: current repo state, project docs, live external docs when relevant, prior decisions, constraints, and explicit user preferences.
 - Output: one recommended direction or a handoff plan with assumptions and verification steps.
 
+## Durable Context Preflight
+
+See [rules/durable-context.md](../../rules/durable-context.md) for when to read durable context, the read-order budget, and the memory-type mapping (planning constraints, reusable patterns, facts that need re-verification against current state).
+
+For `/think`, planning constraints are `decision`, `preference`, and `principle` entries; current repo state, live docs, logs, tests, and remote state override memory. Lock durable decisions and preferences before asking questions. Do not ask the user to restate an intent that the durable context already establishes unless it is risky, stale, or contradicted by current state.
+
+Before outputting any plan, scan the project's `AGENTS.md`, `CLAUDE.md`, `.claude/rules/*.md`, and any local agent-memory summary if the user pointed at one. If the proposed plan contradicts a "hard rule", "never X", "must Y", or "prefer Z" stated in those files, surface the contradiction in the plan output (one sentence: which rule, which step contradicts it, recommended resolution). Do not silently override the rule. If the rule blocks the plan, stop and ask before continuing.
+
 ## Lightweight Mode
 
 Activate when the user wants to fix something rather than build something, the problem is already defined, and the only open question is "how to fix it."
@@ -50,6 +58,22 @@ Do not use a build-plan template here. Do not list options. Give one verdict.
 
 Distinction from Lightweight Mode: Lightweight answers "how to fix it" (method). Evaluation answers "should it exist" (value judgment).
 
+## Triage Mode
+
+Activate when the user forwards a bundle of asks: an issue with multiple requests, a batch of screenshots, a user saying "看看这几个需求", or any input containing 3+ distinct items that could each be accepted or rejected independently.
+
+Do not treat the bundle as a to-do list. Classify each item first:
+
+| Bucket | Meaning | Action |
+|--------|---------|--------|
+| **Bug** | Broken behavior with evidence | Fix |
+| **Already works** | The feature exists but the reporter missed it | Point to the existing affordance |
+| **Accepted improvement** | Genuine gap, low-risk, aligns with product direction | Implement |
+| **Cosmetic / preference** | Subjective, no functional impact | Note it, do not implement unless the maintainer agrees |
+| **Out of scope** | Conflicts with product boundary or adds unjustified complexity | Decline with one sentence |
+
+Output the classification table first. Wait for the user to confirm the accepted subset before implementing anything. "Already works" misidentified as missing is the most common waste; grep for the existing affordance before classifying an item as a gap.
+
 **Negative-user feedback is not automatic scope.** When a user evaluation is triggered by a refund customer, a churn report, or a "competitor X is more intuitive" comparison, do not convert the complaint into a rework plan by default. First check whether the current behavior is intentional product differentiation, not an oversight: read the project's own AGENTS.md / CLAUDE.md / product notes for phrases like "review-first", "verifiability over speed", "evidence-driven", "explicit confirmation". If the behavior the user criticized is named there as a deliberate choice, the verdict is **Keep**, with one sentence on why the differentiation matters, and a note that the maintainer can override. Do not write a "fix the friction" plan that quietly removes the differentiator. The signal-to-respect ratio for refund / competitor-comparison feedback on a deliberately-designed surface is low.
 
 ## Before Reading Any Code
@@ -58,14 +82,6 @@ Distinction from Lightweight Mode: Lightweight answers "how to fix it" (method).
 - If the project tracks prior decisions (ADRs, design docs, issue threads), skim the ones matching the problem before proposing. Skip if none exist.
 - If the plan involves a default value, env var, or config field, open the project's actual config file (e.g. `app.config.json`, `tauri.conf.json`, `package.json`, `.env`) and lift the live value. Never quote a default from memory or docs.
 
-## Durable Context Preflight
-
-See [rules/durable-context.md](../../rules/durable-context.md) for when to read durable context, the read-order budget, and the memory-type mapping (planning constraints, reusable patterns, facts that need re-verification against current state).
-
-For `/think`, planning constraints are `decision`, `preference`, and `principle` entries; current repo state, live docs, logs, tests, and remote state override memory. Lock durable decisions and preferences before asking questions. Do not ask the user to restate an intent that the durable context already establishes unless it is risky, stale, or contradicted by current state.
-
-Before outputting any plan, scan the project's `AGENTS.md`, `CLAUDE.md`, `.claude/rules/*.md`, and any local agent-memory summary if the user pointed at one. If the proposed plan contradicts a "hard rule", "never X", "must Y", or "prefer Z" stated in those files, surface the contradiction in the plan output (one sentence: which rule, which step contradicts it, recommended resolution). Do not silently override the rule. If the rule blocks the plan, stop and ask before continuing.
-
 ## Check for Official Solutions First
 
 Before proposing custom implementations, search for framework built-ins, official patterns, and ecosystem standards. Use Context7 MCP tools to query latest docs when available. If an official solution exists, it is the default recommendation unless you can articulate why it is insufficient for this specific case.

package/skills/write/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: write
-description: "Rewrites and polishes prose in Chinese or English, removing AI-like wording while preserving intent for drafts, docs, release notes, launch copy, and social posts. Use when users ask 帮我写/改稿/润色/去AI味/写一段/审稿/tweet/rewrite/proofread. Not for code comments, commit messages, or inline docs."
-when_to_use: "帮我写, 改稿, 润色, 去AI味, 写一段, 审稿, 文档review, check this document, 推特, twitter, X推文, tweet, social post, 连贯性, 段落连贯, draft, edit text, proofread, sound natural, polish, rewrite"
+description: "Rewrites and polishes prose in Chinese or English, removes AI-like wording, and reviews product localization copy while preserving intent for drafts, docs, release notes, launch copy, and social posts. Use when users ask 帮我写/改稿/润色/去AI味/写一段/审稿/本地化文案/tweet/rewrite/proofread. Not for code comments, commit messages, or inline docs."
+when_to_use: "帮我写, 改稿, 润色, 去AI味, 写一段, 审稿, 文档review, 本地化文案, 多语言文案, i18n copy, localization copy, check this document, 推特, twitter, X推文, tweet, social post, 连贯性, 段落连贯, draft, edit text, proofread, sound natural, polish, rewrite"
 dispatch_intent: "Writing, editing prose, polish, release notes, launch/social copy, remove AI tone"
 ---
 
@@ -18,6 +18,17 @@ Strip AI patterns from prose and rewrite it to sound human. Do not improve vocab
 - Evidence: supplied text, target audience, project style references, release or product state, and requested language.
 - Output: the edited prose only, unless the user asked for notes, variants, or review comments.
 
+## Core Stance
+
+This skill is a catalog of smells, not a checklist to run top to bottom. Use it to recognize AI taste, then make judgment calls. The reference files (especially `write-zh.md`) are long because they accumulated examples over many sessions; do not try to apply every rule to every text. Applying more rules is not doing a better job.
+
+- **Over-editing is failure, equal to under-editing.** If a sentence is already natural, clear, and stable, leave it. Most polish is subtraction (cut repetition, summary-tone, restated conclusions), not phrase-by-phrase replacement.
+- **The author's voice wins.** Keep the author's existing colloquial words, cadence, and stance. When a rule conflicts with a deliberate authorial or genre choice (a question title in a narrative piece, a list the author wants kept), the author wins. Rules are defaults, not laws.
+- **Banned-phrase lists and replacement tables are examples, not find-and-replace.** A flagged word that reads naturally in context stays. Match the smell, not the string.
+- **Prefer fewer, stronger edits.** Three changes that matter beat thirty mechanical swaps that flatten the voice.
+
+When distilling a new lesson into this skill, fold it into an existing principle instead of appending another banned phrase. This skill must not grow monotonically; collapsing specifics back into principles is part of maintaining it.
+
 ## Pre-flight
 
 1. **Text present?** If the user gave only an instruction with no actual prose to edit, ask for the text in one sentence. Do not proceed.
@@ -25,6 +36,7 @@ Strip AI patterns from prose and rewrite it to sound human. Do not improve vocab
 3. **Language detected from the text being edited**, not the user's command:
    - Contains Chinese characters + release notes or social post mode → load `references/write-zh-release-notes.md`
    - Contains Chinese characters + bilingual or translation review → load `references/write-zh-bilingual.md`
+   - Product/site/app localization review across multiple locales → load `references/write-product-localization.md`; also load `references/write-zh-bilingual.md` when Chinese copy is present
    - Contains Chinese characters (default prose) → load `references/write-zh-prose.md` (quick rules); load `references/write-zh.md` for the full AI-taste pattern catalog
    - Otherwise → load `references/write-en.md`
 
@@ -39,10 +51,25 @@ For `/write`, voice and format constraints are `decision`, `preference`, and `pr
 ## Hard Rules
 
 - **Meaning first, style second.** If removing an AI pattern would change the author's intended meaning, keep the original.
-- **No silent restructuring.** Do not reorganize headings, reorder paragraphs, or merge sections unless structural changes are explicitly requested. Edit in place.
+- **No silent restructuring.** Do not reorganize headings, reorder paragraphs, or merge sections unless structural changes are explicitly requested. Edit in place. (Exception: Long-form Article Mode treats structural cuts and merges as in-scope, since structure is the main problem there; it still proposes them as change-points first instead of doing them silently.)
 - **Artifact-grounded claims.** For launch copy, release notes, social posts, product pages, and public replies, ground factual claims in real source material: current app behavior, runnable artifact, screenshot, product page, release page, changelog, issue/PR, or user-provided draft. Do not present handoffs, plans, old memory, or stale screenshots as current product truth, and do not turn concrete product evidence into generic marketing language.
 - **No em-dash.** Never produce em-dash (U+2014 `—`) or en-dash (U+2013 `–`) in Chinese or English output. Em-dash is the strongest AI-tone fingerprint in this style of writing. Use commas, periods, colons, semicolons, or parentheses to break clauses. Hyphen-minus (`-`) inside compound words is allowed; replace it with a space or a period when possible. When editing a draft that contains em-dashes, replace every one before returning the text.
-- **Stop after output.** Deliver the rewritten text. Do not append a list of changes, a justification, or a closer.
+- **Stop after output.** Deliver the rewritten text. Do not append a list of changes, a justification, or a closer. (Exception: Long-form Article Mode returns change-points for review instead of a rewritten blob; see that mode.)
+
+## Long-form Article Mode
+
+Activate when: editing a Markdown article or file over ~300 lines, or one with multiple `##` sections plus tables and images (technical long-reads, blog posts, deep dives).
+
+In long-form, the dominant problem is usually structural: the same checklist repeated across sections, prose that re-reads a table sitting right above it, list bloat, whole redundant sections. Sentence-level AI taste is the smaller half. A single in-place polish pass cannot see or fix the structural half, which is why a plain `/write` on a long article feels like it changed wording but left the bloat. This mode therefore overrides two Hard Rules: structural cuts and merges are in-scope, and the output is change-points for review, not a rewritten blob.
+
+Workflow:
+
+1. **Map first, read-only.** Before editing anything, read the whole article and list every `##` section, table, list, and image. Flag three structural problems: cross-section repetition (same checklist / judgment list / core claim in 2+ sections), table re-reading (a section whose prose walks the rows of the table above it), and whole redundant sections or paragraphs.
+2. **Propose cuts as change-points.** Show before to after for each structural cut or merge and let the user pick the subset. Never delete a whole section or paragraph silently; confirm first, since it may hold a fact found nowhere else (see `references/write-zh.md` 删段之前先确认信息量).
+3. **Then line-level de-AI**, section by section, per `references/write-zh.md`.
+4. **Output is change-points, not a blob.** Show what changed so the user can review and keep their own hand-edits. Only return fully rewritten text when the user says 直接改 / just rewrite.
+
+Do not single-pass rewrite a 40k-character article: it silently overwrites the author's hand-tuned phrasing and cannot be reviewed as a diff. See `references/write-zh.md` 结构级重复与表格复读（长文专项）for the matching content rules.
 
 ## Bilingual Review Mode
 
@@ -57,6 +84,20 @@ Activate when: mixed Chinese/English, "Chinese copywriting", "bilingual consiste
 
 **Bilingual pairs**: Confirm EN and CN versions convey the same meaning; mark translation loss.
 
+## Product Localization Review Mode
+
+Activate when: "本地化文案", "多语言文案", "localization copy", "i18n copy", product/site/app strings, release feed copy, runtime catalog, or a user asks whether localized copy feels native.
+
+Load `references/write-product-localization.md`. If Chinese is one of the locales, also load `references/write-zh-bilingual.md`.
+
+Default workflow:
+
+1. Separate surfaces first: release feed, website pages, docs/help, runtime strings, legal/privacy copy, and generated pages may have different locale coverage and source files.
+2. Preserve factual structure: versions, dates, links, item order, placeholders, and product behavior remain fixed unless the user asks to change them.
+3. Review by locale artifacts, not by English meaning alone. Missing accents, ASCII fallbacks, literal possessives, stale locale paths, and mechanical plural or apostrophe errors are first-class issues.
+4. After broad cleanup, run a second pass for replacement damage. Do not trust accent sweeps or glossary replacements until the generated output has been checked.
+5. When asked to implement, patch the source localization files and rebuild generated pages. When asked only to review, return findings grouped by surface and severity.
+
 ## Release Note Template Mode
 
 Activate when: "release", "changelog", "version", "release notes"
@@ -74,7 +115,7 @@ Format: target-project style by default. If no project style is available, use n
 Before drafting, gather style references:
 
 1. Read the target project's `CLAUDE.md` for its Release Convention / Release Flow section.
-2. Read the target project's existing release source as a style, length, and density reference: changelog, release notes, registry page, appcast, or platform release page.
+2. Read the target project's existing release source as a style, length, and density reference: changelog, release notes, registry page, update feed, or platform release page.
 3. For GitHub projects, `gh release view --json body -R <owner>/<repo>` is the preferred way to read the most recent release when `gh` is available. If the project is not on GitHub, use the release source named by the project docs or user request.
 4. If the user mentions comparing with a sibling project's release style, ask for the target identifier or release URL before fetching it.
 5. Match the reference release's item count, sentence length, and tone. Do not invent a new format.
@@ -85,7 +126,7 @@ Before drafting, gather style references:
 - **Group by user-perceivable feature**, not by internal taxonomy. "Polish", "细节打磨", "Misc improvements", "Chores" are not categories users can act on. Group by product surface (Clean / Uninstall / Status / Settings) or by user-visible verb (Faster startup / New keyboard shortcut / Fixed crash on M3).
 - **Extract from `git log <last-tag>..HEAD`** rather than from memory. Read every `feat:` and `fix:` commit; do not omit small items just because they look minor in commit form (iOS wrapper support, Dock cleanup, AV-vendor protection boundary are not "minor" from a user point of view).
 - **One sentence per item, naming the user-visible change**, not the implementation. "Use `CKDownloadQueue` observer for App Store updates" is not a release note; "App Store updates now run inside the app instead of opening App Store" is.
-- **Bilingual structure**: when the project ships bilingual release notes, put the English block and the Chinese block as two parallel sections inside the same release item; do not interleave per bullet. For Sparkle appcast CDATA, separate with `<h4>Changelog</h4>` and `<h4>更新日志</h4>` so the rendered update window shows both.
+- **Bilingual structure**: when the project ships bilingual release notes, put the English block and the Chinese block as two parallel sections inside the same release item; do not interleave per bullet. For HTML-capable update-feed CDATA, separate language blocks with headings so the rendered update window does not collapse them together.
 - **No em-dash** in release prose (covered by the Hard Rule). Use Chinese full-width punctuation in Chinese blocks, ASCII in English blocks.
 
 ## Public Reply Mode (GitHub issue / PR)

package/skills/write/references/write-en.md

@@ -1,10 +1,12 @@
+> **How to use this file**: it is a catalog of smells, not a checklist to run top to bottom. The principles in `SKILL.md` Core Stance apply here too: over-editing is failure, the author's voice and genre win, and these lists are examples, not find-and-replace. A sentence that already reads natural stays. Match the smell, not the word.
+
 ## English Scenario
 
 Eliminate predictable AI writing patterns. Write like a human: varied, imperfect, specific.
 
 ### Core Rules
 
-1. **Cut filler phrases.** Remove throat-clearing openers, emphasis crutches, and all adverbs.
+1. **Cut filler phrases.** Remove throat-clearing openers, emphasis crutches, and adverbs that only signal emphasis. Keep adverbs that carry real meaning.
 2. **Break formulaic structures.** Avoid binary contrasts, negative listings, dramatic fragmentation, rhetorical setups, false agency.
 3. **Use active voice.** Every sentence needs a human subject doing something. No inanimate objects performing human actions ("the complaint becomes a fix").
 4. **Be specific.** No vague declaratives ("The reasons are structural"). Name the specific thing. No lazy extremes ("every," "always," "never") doing vague work.
@@ -19,7 +21,7 @@ Eliminate predictable AI writing patterns. Write like a human: varied, imperfect
 
 Examples, not exhaustive -- any word used to signal importance rather than to say something is suspect.
 
-**Overused adverbs: kill them all:**
+**Overused emphasis adverbs (cut these when they only signal importance, not every adverb):**
 "quietly", "deeply", "fundamentally", "remarkably", "arguably", "certainly", "really", "just", "literally", "genuinely", "honestly", "simply", "actually"
 
 > NO: "quietly orchestrating workflows" / "fundamentally reshape how we think"
@@ -162,9 +164,23 @@ Examples, not exhaustive -- any construction that performs insight rather than d
 > NO: "It's worth noting that this approach has limitations." / "Notably," / "Importantly,"
 > OK: Say the thing directly. Skip the announcement.
 
+**Meta figure and diagram explanations:**
+> NO: "This diagram lists the sensor stack of a humanoid robot. With it in view, the previous problems become easier to place."
+> NO: "I made this diagram with ChatGPT Image2. Seeing the representations side by side makes the differences easier to grasp."
+> NO: "This timeline shows the evolution... That is one of the reasons I find this field more interesting..."
+> OK: The image or timeline itself. Let the surrounding judgment or personal project anchor carry the weight. Keep creation-process details only if they are themselves part of the story.
+
+**List or classification intros:**
+> NO: "Community data is an interesting piece. Diversity has to cover..."
+> NO: "One detail is easy to miss. 'Output action' can mean..."
+> OK: Go straight to the content: "Community data has a practical requirement: diversity has to cover..." or "Output action can mean different things..."
+
+**Re-anchoring after cutting recaps (long-form articles):**
+After removing table re-reads and structural repetition, scan the remaining prose for places where a general explanation can be tied back to the author's concrete project or experience already mentioned in the piece. This is one of the strongest ways to restore human voice in technical long-form writing.
+
 ### Quick Checks Before Delivering Prose
 
-- Any adverbs? Kill them.
+- Any adverb only adding emphasis? Cut it. (Meaning-bearing adverbs stay.)
 - Any passive voice? Find the actor, make them the subject.
 - Inanimate thing doing a human verb? Name the person.
 - Sentence starts with "Here's"? Cut to the point.
@@ -178,20 +194,6 @@ Examples, not exhaustive -- any construction that performs insight rather than d
 - Any "In conclusion" or "To sum up"? Cut it.
 - Any emoji? Remove it.
 
-### Scoring
-
-Rate 1-10 on each dimension:
-
-| Dimension | Question |
-|-----------|----------|
-| Directness | Statements or announcements? |
-| Rhythm | Varied or metronomic? |
-| Trust | Respects reader intelligence? |
-| Authenticity | Sounds human? |
-| Density | Anything cuttable? |
-
-Below 35/50: revise.
-
 ---
 
 **Bottom line: varied, imperfect, specific. Any single trope used once may be fine. The problem is when multiple appear together or one repeats.**

package/skills/write/references/write-product-localization.md

@@ -0,0 +1,43 @@
+# Product Localization Copy Review
+
+Use this when reviewing product pages, release notes, app strings, runtime notifications, appcast or update feeds, docs/help pages, legal/privacy copy, and other localized product surfaces.
+
+## Core Principles
+
+1. **Split surfaces before editing.** A release feed, website page, runtime catalog, help article, and legal page may intentionally support different locale sets. Do not force every surface to mirror the broadest one.
+2. **Keep product facts fixed.** Preserve versions, dates, item order, links, placeholders, keyboard shortcuts, product names, bundle IDs, and behavior claims unless the user asked to change them.
+3. **Use source files, not generated output, as the edit target.** Patch generated pages only when the project explicitly treats them as source. Otherwise find the template, locale JSON, string catalog, or content partial and rebuild.
+4. **Review the final rendered or generated surface.** A translation can look fine in a source file but break in a button, menu, release feed, notification, or generated HTML page.
+5. **Do not polish into generic marketing.** Native localization means the sentence sounds like a local product, not like a fluent sales page.
+
+## High-Signal Failure Patterns
+
+- **Chinese**: Literal possessives such as "你的 Mac" or "你的设备" when plain "Mac" or "本机" is enough; machine-output verbs such as "检测到" when a result sentence would read better; mixed punctuation; English words with stable Chinese equivalents.
+- **Traditional Chinese**: Mainland phrasing copied into Traditional copy; stale locale URLs; words that feel mainland-specific or overly colloquial for the target audience.
+- **Japanese**: English noun compounds translated too tightly; missing spaces around product terms when the project style uses them; UI strings that sound like a manual instead of a Mac app.
+- **Korean**: Inconsistent platform terms, especially menu bar / menu item wording; overly literal second-person sentences.
+- **German**: ASCII fallbacks such as `fuer`, `Pruef`, `Eintraege`, `Menue`, `Luefter`; English developer nouns like "binary" in user-facing copy.
+- **Spanish**: Missing accents such as `gestion`, `analisis`, `menus`, `suscripcion`; mechanical replacements that create invalid forms like `actualizaciónes`.
+- **French**: Missing apostrophes or accents such as `L app`, `memoire`, `desinstallation`, `defaut`; spaces before punctuation should follow French conventions when the surrounding text already does.
+- **Italian**: Missing accents and articles such as `piu`, `non e`, `un app`; mechanical replacements that create invalid forms like `puòi`.
+
+## Review Procedure
+
+1. Identify all source and generated surfaces in scope. For websites, include templates, locale JSON, content partials, generated pages, language switchers, canonical links, and route rewrites. For apps, include runtime catalogs, permission strings, update feeds, and notification copy.
+2. Pick the factual source of truth. Release notes usually follow the English release page or changelog; runtime copy follows the current app behavior and placeholders.
+3. Run a first pass for local voice: remove translationese, restore local punctuation, and keep product names stable.
+4. Run a second pass for mechanical artifacts: missing accents, stale paths, invalid plural forms, malformed placeholders, and accidental path translations.
+5. Rebuild generated files and rerun the relevant project checks. If the user only asked for review, list the required checks instead of claiming they ran.
+
+## Rewrite Rules
+
+- Keep placeholders exactly, including order and type: `%@`, `%d`, `%1$@`, `{name}`, and similar tokens.
+- Do not glue translated fragments with punctuation in code or copy. A full sentence or format string per locale is safer.
+- Avoid broad find-and-replace unless it is followed by residual scans. Broad accent fixes can produce broken words.
+- Leave product names and established UI names in English when the product itself uses them that way.
+- Legal and privacy copy should be plain and accurate. Do not make it friendlier by weakening obligations, data collection boundaries, refund terms, or third-party roles.
+- Release feed localization can be narrower than website localization. Respect the surface-specific product decision.
+
+## Output Guidance
+
+For rewrite requests, return the edited localized copy. For review requests, group findings by surface first, then locale. Call out blockers where copy misstates product behavior, privacy, legal terms, version history, or update availability.

package/skills/write/references/write-zh-bilingual.md

@@ -17,8 +17,6 @@
 - 后续出现：只用中文，不要英中混用
 - 例外：SFT、RL、MoE 这类已成行业通用缩写，全程保留缩写形式
 
-**常见可替换词**：context→上下文、state→状态、cache→缓存、claim→断言、runtime→运行时、contract→契约
-
 ## 有稳定中文对译的英文词
 
 中文技术圈已有通用译法的，换中文：
@@ -30,6 +28,7 @@
 | cache | 缓存 |
 | claim | 断言 |
 | runtime | 运行时 |
+| contract | 契约 |
 
 术语在中文圈还未收敛的（prompt、embedding、tokenizer），保留英文合理。
 
@@ -41,7 +40,7 @@
 
 **抽象名词做主语**："工程上的现实比这些数字难看"这种骨架，凡碰到"X 的 Y 比 Z 更 W"，重写让人/动作做主语。
 
-**有稳定对译词直接混入**："context 不崩、state 可恢复"—— 换成中文。
+**有稳定对译词直接混入**："context 不崩、state 可恢复"，换成中文。
 
 ## 双语并列的排版
 

package/skills/write/references/write-zh-prose.md

@@ -46,3 +46,5 @@
 | 值得注意的是 | 直接说结论 |
 
 完整规则、AI 味检测所有模式、标题设计、引号/括号/分号规则见 `write-zh.md`。
+
+长文（多 `##` 节、带表格和图）先做结构再抠句子：跨章节同义清单只留最全一份、表格旁正文别复读、判断/取舍类列表默认转 prose，详见 `write-zh.md` 的「结构级重复与表格复读（长文专项）」，整体流程见 `SKILL.md` 的 Long-form Article Mode。

package/skills/write/references/write-zh-release-notes.md

@@ -20,6 +20,8 @@
 
 **长度参考**：和上一个版本 release 的条目数、句子长度、密度匹配。不要自创新格式。
 
+**边界**：GitHub Release 正文和社交公告是两份 artifact。Release notes 解释用户会感受到什么，默认不写 CI、tap、registry、API 名称、fallback 路径等机制细节；公告另按社交发文规则挑 2 到 4 个亮点。
+
 ## 对外发文专项检查
 
 公开发文交出去之前，扫三件事：

package/skills/write/references/write-zh.md

@@ -1,3 +1,5 @@
+> **怎么用这份文件**：它是「认 AI 味」的例子库，不是从头套到尾的检查清单。先用它识味，再凭判断改。自然的句子就别动，**过度改和改不到位一样糟**。作者已有的声音、口语词和体裁选择，优先于任何单条规则。下面所有禁用词、替换表、形式规则（标题、列表、标点），都是「倾向和例子」，不是查找替换。沉淀新教训时并进已有原则，别再加一条禁用词，这份文件不许只增不减。
+
 ## 中文场景
 
 像资深工程师写技术长文，给同行讲清楚一条链路。自然、准确、不刻意。
@@ -123,6 +125,18 @@ OK: **alias**，我在 .zshrc 里加了一行...
 
 序号 1/2/3 留给真正有顺序的：优先级、时间、流程步骤、reference 排序。
 
+默认倾向：判断 / 取舍 / 总结型清单（每条一句、是观点不是步骤）默认转成 prose 段落；速查表 / syllabus（术语密集、读者要逐项对照）和带链接的参考文献保留 list。拿不准时，先转 prose 看读不读得顺。
+
+### 结构级重复与表格复读（长文专项）
+
+后面 AI 味检测第 3 条「重复核心观点」是段落级。长文还有三类只有把整篇摊开横向比对才看得到的结构水分，单段 in-place 润色检测不到：
+
+- **跨章节同义清单**：同一张评估 / 判断 / 取舍清单在 2+ 个 `##` 节里各写一遍（比如「评估机器人看动作频率、数据来源、失败处理」在入门、对比、总结三处都出现）。留信息最全的一份，其余删，或后文一句话带过。
+- **表格旁正文复读**：一节里有对比表，正文却一行行复述表里的列。正文只补表给不了的，里程碑、具体例子、判断、为什么，表能讲清的交给表。
+- **图 / 表旁文字复述**：紧邻一张图或表的正文，把图 / 表已经列出的项再用文字列一遍，或用「这张图更直观」这类预判句替图说话。删掉复述和预判，留判断和上下文；画图过程只在它本身是叙事时才保留。例外：图的 alt 读者看不到，「图后必要说明段」不算复读，不要删（见图片节奏）。
+
+判断信号：删掉这段 / 这句，读者会不会丢失一个别处没有的事实，不会就是复读，删；会就保留。
+
 ### 标题设计
 
 标题格式三种，看结构选，不是统一用一种。
@@ -155,6 +169,8 @@ NO: 「多 Agent 协作」（只说了主题）
 OK: 「多 Agent 协作让幻觉互相放大」（有判断）
 OK: 「评测先于 Agent，不然你不知道在修什么」（有立场）
 
+以上是倾向，不是硬规则。判断式标题适合分析 / 论证型文章；叙事、经历、探索型长文里，疑问句和好奇式短语往往更抓人（「机器人怎么知道自己在哪」「一根没有销钉的手指」），同一篇里两种可以混用。作者已经定的标题形式优先，别为了「凑判断」改掉一个好的好奇式标题。
+
 ### 引号（""）
 
 引号不是强调键。不要因为某个词"感觉重要"就套上引号。
@@ -199,9 +215,9 @@ OK: File System State 开销只有 5~15%，几乎总是值得的。Verifier Agen
 > NO: `...也决定后训练有没有可以利用的空间；但它没有决定这个模型会不会听指令`
 > OK: `...也决定后训练有没有可以利用的空间。但它不决定模型会不会听指令`
 
-### AI 味检测：这几个模式要主动排查
+### AI 味检测：这几个模式帮你认味
 
-以下是高频出现的具体模式（举例，不完全）。读起来有同样 AI 味的句式一律适用。
+以下是高频出现的具体模式（举例，不完全），用来识别 AI 味，不是必须逐条执行的清单。句子本来自然、清楚就别套规则，命中了味再改。
 
 **1. 升华句**: 把具体工程观察上升到普适人生道理
 > NO: "很多东西都是这样，当初成立的假设，过一段时间回头看可能已经不成立了。"
@@ -372,7 +388,7 @@ context、state、cache、claim 这类词有现成中文对译：上下文、状
 > NO: “Kimi K2.5 的 PARL 是这里最值得拆开的工程案例。它只训练 orchestrator...”（直接进细节）
 > OK: “Kimi K2.5 的 PARL 代表了一条新路线：只训 orchestrator、把 credit assignment 收到编排层。奖励信号分三类...”（先说代表什么）
 
-### 今日沉淀：工程技术文实战规则
+### 工程技术文实战规则
 
 下面这组来自真实改稿回合，优先级高于”风格偏好”：
 
@@ -385,7 +401,7 @@ context、state、cache、claim 这类词有现成中文对译：上下文、状
 - 结论不重复宣告。第 0 节说过的核心判断，后文不要再换措辞重复一遍
 - 保留作者的内在矛盾。如果原文在不同段落持有看似矛盾的立场（比如既推崇自由又强调纪律），不要替作者消解。时间性矛盾（早期 vs 近期观点）标注演化即可；领域性矛盾（工作 vs 生活的不同规则）保留两面；本质性张力（价值观的内在冲突）原样呈现，这通常是文章最有深度的部分
 
-### Summary 写法（新增）
+### Summary 写法
 
 `summary` 先判断目标，不同目标写法不同：
 
@@ -399,23 +415,32 @@ context、state、cache、claim 这类词有现成中文对译：上下文、状
 - 不要混写，避免一段里既像导读又像结论宣判
 - 默认 2 到 3 句，信息完整但不铺满正文细节
 
-### 报告腔专项（新增）
-
-下面是最近高频替换，按“左边少用，右边推荐”执行：
-
-- `主要叙事` -> `大家通常用...来解释...`
-- `系统梳理` -> `从...一路讲到...`
-- `核心结论是` -> `最后会看到`
-- `逻辑分工 / 流程节点` -> `为了看分工 / 更细的版本`
-- `公开口径里` -> `按公开数据`
-- `共同模式已经很稳定` -> `能看到几个共同点`
-- `可以从三个角度看` -> `可以先看三件事`
-- `不需要读成 X` -> `不只是 X`
+### 高频替换：报告腔和不喜欢的表达
 
-补充：
+按「左边少用，右边推荐」执行，读起来有同样报告腔或不自然的一律适用。
 
-- 比较表达优先自然中文：`最清晰` 通常比 `最清楚` 更稳
-- 避免“句子评价句”，例如“这句话解释不了”，直接写对象本身“X 解释不了 Y”
+| NO | OK |
+|----|----|
+| 主要叙事 | 大家通常用...来解释... |
+| 系统梳理 | 从...一路讲到... |
+| 核心结论是 | 最后会看到 |
+| 逻辑分工 / 流程节点 | 为了看分工 / 更细的版本 |
+| 公开口径里 | 按公开数据 |
+| 共同模式已经很稳定 | 能看到几个共同点 |
+| 可以从三个角度看 | 可以先看三件事 |
+| 不需要读成 X | 不只是 X |
+| 别掉链子 / 露过头（过重口语）| 直接说事实 |
+| 团队 / 实验室 / 行业（抽象主语）| 能写动作就别先摆抽象主体 |
+| 真拆开看 / 这背后是同一个变化 / 真正的问题变成了 / 真正关键的问题是 / 都在说明同一件事（讲解腔起手）| 直接说 |
+| 先问问是不是 / 你要先明白 / 先搞清楚再说（训人感起手）| 可以先看 / 先确认 |
+| 硬约束（工程黑话）| 约束 |
+| 摆出来（半口语半讲稿）| 直接陈述 |
+| 当然 / 这话不算错，但 / 这么理解不能说错，但（让步腔）| 直接说结论，不先让步再转折 |
+| 塑形 / 塑造（行为、方向、结果）| 调整 / 决定 / 影响 / 优化 |
+| 相邻（空间词描述逻辑关系）| 关系紧密 / 有交集 |
+| 聚焦（空泛目标词）| 重点写什么 / 主要看什么 |
+
+补充：比较表达优先自然中文，`最清晰` 通常比 `最清楚` 更稳；避免「句子评价句」，「这句话解释不了」直接写成「X 解释不了 Y」。
 
 ### 参考资料排列
 
@@ -424,19 +449,6 @@ context、state、cache、claim 这类词有现成中文对译：上下文、状
 - 论文和官方技术报告优先，仓库与博客只保留高承重项
 - 数量以可读为先，通常 10 到 14 条比较稳
 
-### 最近确认的不喜欢的表达（新增）
-
-- 少用过重口语：`别掉链子`、`露过头`
-- 少用抽象主语：`团队`、`实验室`、`行业`；如果能直接写动作，就别先摆一个抽象主体
-- 少用讲解腔起手：`真拆开看`、`这背后是同一个变化`、`真正的问题变成了`、`真正关键的问题是`、`都在说明同一件事`
-- 少用训人感起手：`先问问是不是`、`你要先明白`、`先搞清楚再说`
-- 少用工程黑话式表达：`硬约束`
-- 少用半口语半讲稿的词：`摆出来`
-- 少用让步腔：`当然`（"预训练当然还是底座" → "预训练是底座"）、`这话不算错，但`、`这么理解不能说错，但`: 直接说结论，不要先让步再转折
-- 少用学术塑造感词：`塑形`、`塑造`（行为/方向/结果） → 用`调整`、`决定`、`影响`、`优化`
-- 少用空间位置词描述逻辑关系：`相邻` → 用`关系紧密`、`有交集`等说清楚实际关系
-- 少用空泛目标词：`聚焦`，直接写“重点写什么”“主要看什么”
-
 ### 文章自说明句（默认少写）
 
 文章不该反复谈自己在做什么。默认直接进内容，必要时只保留 1 句路线提示。
@@ -557,9 +569,9 @@ OK: 如果确实需要路线提示，只写一遍，避免在开头和结尾重
 
 判断标准：1-3 类是字符级、5 分钟扫完；4-6 类要带上下文判断、需要全文回读。10 轮后 prose 大改不动了，时间就花在这 6 类残留上。
 
-### 工程师谦虚口吻深扫（新增）
+### 专家腔
 
-下面这组来自一次 7 章具身智能长技术博客（约 615 行 / 40k 字）的多轮 polish。前面 24 类 AI 味之外，这些是"已经像人话但还不够像作者本人"层的 gap。
+润色容易把作者改得比原文更像专家、更会教人。下面这几处是同一个倾向的常见表现。
 
 **0. 实作经历不能为了工程感补细节**
 > NO: 作者只说"串口通信难"，润色时补成"ACK 丢了、超时重传、翻串口日志定位"这类原文没有的排障故事
@@ -577,8 +589,8 @@ OK: 如果确实需要路线提示，只写一遍，避免在开头和结尾重
 > OK: 去"你"做主语，事实陈述：「翻论文时会先看 X」「同时会多出 X」「自然会想问 X」
 
 **3. 段首 announce-a-feature 引子**（rule 12 章节引介过渡句的段内变体）
-> NO: 「X 也是容易被低估的部分：」「X 也是 Y 的延伸：」「还有一项 Y 经常被低估：」
-> OK: 直接进 X：「X 也容易被低估：[直接讲]」「再往后一层是 X：[直接讲]」
+> NO: 「X 也是容易被低估的部分：」「X 也是 Y 的延伸：」「还有一项 Y 经常被低估：」「我了解到 X 常见的 Y 有这几类，工程代价也各不一样：」
+> OK: 直接进 X：「X 也容易被低估：[直接讲]」「再往后一层是 X：[直接讲]」，分类引子直接进列表或表格
 
 **4. 章节编号一/二/三 prefix**
 > NO: `## 一、X` `## 二、Y` 中文数字编号像教材目录
@@ -615,6 +627,16 @@ OK: 如果确实需要路线提示，只写一遍，避免在开头和结尾重
 > OK: 「动作空间、控制频率和真机测试比参数量更早决定可比性」「公司层面的差异，最后会变成几个问题」
 > 判断：第一人称是经历证据，不是审稿姿态。中后段如果像作者站出来教读者怎么看，优先删主语或改成可观察事实。
 
+**11. 学习路径不要改成入门教程**
+> NO: 「入门不用一上来」「先把 X 跑通」「再往前一步」「几个常见坑」「这一圈下来，我先把收获留成检查项」
+> OK: 「按我现在的理解，资料大概能这样串起来」「跑过一遍后，哪些词会落到具体字段上」「还有几个问题我现在没答案」
+> 判断：原文如果是工程师边做边学、把材料慢慢串起来的过程，不要改成老师给读者安排课程。学习路径可以写，但语气要像作者自己的探索路线。除非用户明确要教程，少用命令、清单、检查项、常见坑、入门教程这类框架词。
+
+**12. 不要把轻一点的作者口气修成老派说教**
+> NO: 「盯」「检查项」「安全动作放前面」「失败样本要不要留」「更有抓手」「后续继续跟踪」「需要重点关注」
+> OK: 「看」「几个判断更具体」「限角度、限速度、急停这些东西要留在本地」「失败数据怎么处理」「会落到更具体的问题上」「我现在还没有答案」
+> 判断：这些词本身未必错，但在博客里容易变成老派专家指导读者。作者原本如果是「我跑过 / 我看到 / 我还没答案」的探索口气，不要润成「我来告诉你该怎么做」。
+
 #### 工程文用词替换补充
 
 | NO | OK |
@@ -632,59 +654,36 @@ OK: 如果确实需要路线提示，只写一遍，避免在开头和结尾重
 | 更稳的写法是 | 更准确的说法是 |
 | 学习曲线决定 X | 具体后果（「下一次就不容易再栽」）|
 | 阶段性突破点（独立 closer）| 合上一句做因果 |
+| 入门不用一上来 / 先把 / 再往前一步 | 按我现在的理解 / 跑过一遍后 / 接着看 |
+| 检查项 / 常见坑 / 重点关注 | 判断 / 容易漏掉的细节 / 还没有答案的问题 |
+| 盯 / 跟踪 / 持续关注 | 看 / 继续看 / 回到具体问题 |
+| 更有抓手 | 会落到更具体的问题上 |
 
 ### 默认禁用（举例，不完全，读起来有同样报告腔的一律适用）
 
+报告腔替换词见上文「高频替换」「用词去正式化」两张表。下面这些已在上文各 pattern / 段落展开，命中即按对应处改，不在这里重列：破折号（见「句式」）、随着…的发展（见「开头直接」）、对比框架与「X 本身没价值 / X 不是瓶颈 Y 才是」（pattern 2）、瓶颈转移句（pattern 6）、两 / 三层缺一不可（pattern 5）、引号强调（见「引号」）、瑞士奶酪 / Poka-yoke（见「不要用外来术语做比喻」）、孤立单句段落（见「句式」）、文章自说明句（先给最短结论 / 这篇真正想钉住的 / 脑子里还是那老三样 / 拿一组数字更直观 / 如果说…那…，见「文章自说明句」）、升华开头（pattern 1）、抽象集体主语（pattern 18）。
+
+下面只补上文没单列的高频禁用词：
+
 NO: 本文旨在
-NO: 主要叙事
-NO: 系统梳理（可改成“从 A 讲到 B”）
-NO: 核心结论是（可改成“最后会看到”）
-NO: 逻辑分工 / 流程节点（优先换成自然描述）
-NO: 公开口径里（可改成“按公开数据”）
-NO: 共同模式已经很稳定（可改成“能看到几个共同点”）
-NO: 可以从三个角度看（可改成“可以先看三件事”）
-NO: 值得注意的是
-NO: 综上所述
-NO: 随着...的发展
-NO: 非常 / 极其
-NO: 破折号（用逗号/分号替代）
 NO: emoji（任何场合，包括列表、标题、状态标记）
 NO: 这篇是整理出来的结果（冗余，删掉）
 NO: 有一个大背景值得先说（直接说）
 NO: 读下来有几个地方和直觉不一样，提前说一下（直接列）
 NO: 精准命中了 N 个条件
-NO: 瓶颈从 X 转移到了 Y
 NO: 是最常见的失败模式之一
-NO: X 本身没有价值，真正有用的是 Y
-NO: X 已经不是瓶颈，Y 才是
-NO: 两层/三层缺一不可
-NO: 用引号强调概念（"翻译""提升""完成了"）
-NO: 瑞士奶酪模型 / Poka-yoke（直接说道理，去掉模型名）
-NO: 孤立的单句段落（并进上下文）
-NO: 当然（让步腔，直接陈述）
-NO: 这话不算错，但 / 这么理解不能说错，但
-NO: 先给最短结论，就 N 句 / 这篇真正想钉住的 / 如果先只记一张表（文章自说明句）
-NO: 脑子里还是那老三样 / 最常见的解释就是三件事（代替读者归纳）
-NO: 拿一组具体数字看会更直观（宣告数据）
-NO: 如果说...那...（条件句段落引入）
-NO: 塑形 / 塑造行为（学术腔，用调整/影响/优化）
-NO: 下图（图片引导语，用「这张图」或「下面这张图」）
-NO: 聚焦（多为抽象目标词，改成”重点写什么”）
 NO: 拿来即用 / 装好就能用（拿来即用是营销词，自己介绍工具直接说”装好就能用”）
 NO: 翻倍 / 翻番（带数字渲染感）
 NO: 事半功倍 / 少走弯路（成语腔，前者更重）
 NO: 先立住（劝告腔，可改”注意一下”或直接陈述）
-NO: 归根到底就一件事（升华开头，pattern 1 升华句的典型）
-NO: 业务判断和用户感知是我们要守住的（抽象+集体语气，pattern 18 抽象主语）
 NO: 完全没关系（去掉”完全”两字更口语，”没事”更稳）
 NO: 把模糊性降到最低（学术抽象，改成”让它要猜的部分变少”这种动词具体）
-NO: 最好的 / 最适合 / 直接搞定 / 一句话就出（介绍自己工具的营销词，改成"我自己这么用 / 装好就能用 / 我攒了一套"）
-NO: 颗粒度（技术黑话，改成"粒度"或直接说"拆得更细"）
-NO: 家规（类比腔，直接说"规则"或"约束"）
-NO: 黑乎乎（口语过重，改成"偏暗"或"深色"）
+NO: 最好的 / 最适合 / 直接搞定 / 一句话就出（介绍自己工具的营销词，改成”我自己这么用 / 装好就能用 / 我攒了一套”）
+NO: 颗粒度（技术黑话，改成”粒度”或直接说”拆得更细”）
+NO: 家规（类比腔，直接说”规则”或”约束”）
+NO: 黑乎乎（口语过重，改成”偏暗”或”深色”）
 NO: 不可或缺（空泛形容，直接说依赖关系或删掉）
 NO: 奇妙之处（升华腔，直接说具体现象）
-NO: 我会先看 / 我更在意 / 我盯 / 我不会把（审稿式个人判断，技术分析段优先让事实做主语）
 
 ---