self-evolve-framework 1.0.7 → 1.1.0

package/template/skills/write/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: write
+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"
+---
+
+# Write: Cut the AI Taste
+
+Prefix your first line with 🥷 inline, not as its own paragraph.
+
+**Update check (non-blocking).** Before starting, run `bash ../../scripts/check-update.sh` once; if it prints a line, relay it to the user, then continue. It runs at most once a day, only reads a public version file, sends no data, and fails silently.
+
+Strip AI patterns from prose and rewrite it to sound human. Do not improve vocabulary; remove the performance of improvement.
+
+## Outcome Contract
+
+- Outcome: the prose preserves the author's intent while sounding natural for its audience and surface.
+- Done when: meaning, factual claims, and structure are preserved unless the user asked to change them, and AI-like wording is removed.
+- 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.
+2. **Audience locked?** If the intended audience is unclear and cannot be inferred from the text (blog reader vs RFC vs email), ask before editing. Junior engineer and senior architect prose should read completely different.
+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`
+
+Read the loaded reference file. Then edit. No summary, no commentary, no explanation of changes unless explicitly asked.
+
+## 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.
+
+For `/write`, voice and format constraints are `decision`, `preference`, and `principle` entries; editing checks are `pattern` and `learning`. The supplied text, audience, project docs, current release state, and source material override memory. Durable preferences can set brevity, tone, and social-post shape. They do not override the hard rule to edit in place, keep meaning intact, and avoid change lists unless the user explicitly asks.
+
+## 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. (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. (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
+
+Activate when: mixed Chinese/English, "Chinese copywriting", "bilingual consistency", "release notes"
+
+**Chinese rules** (from https://github.com/mzlogin/chinese-copywriting-guidelines):
+- Space between Chinese and English characters (CN文字EN → CN 文字 EN)
+- No mixing of punctuation (Chinese uses 、。？！；：, not commas/periods)
+- Consistent terminology across all instances
+
+**English in Chinese documents**: Flag unexplained English, suggest translation or add context.
+
+**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"
+
+Generate from commit messages:
+- **Breaking Changes**
+- **New Features**
+- **Fixes & Improvements**
+- **Deprecations**
+
+Format: target-project style by default. If no project style is available, use numbered items with bold labels, one sentence on user effect, and bilingual output only when the project already uses bilingual release notes.
+
+### Release Notes Pre-flight
+
+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, 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.
+6. Keep each release-note item to one sentence unless the reference project clearly does otherwise. Do not add emoji to release prose unless the target surface is explicitly a reaction or celebratory social surface.
+
+### Release Notes Content Rules
+
+- **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 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)
+
+Activate when: "回复 issue", "reply to PR", "comment on #N", "回 issue", or the user asks for the text of a GitHub issue / PR comment.
+
+Five hard rules for the reply body:
+
+1. **Open with `@<reporter>` + one thanks line.** Match the reporter's language (Chinese → "感谢反馈" / English → "thanks for the detailed report"). No exclamation mark. No emoji. No "🙏".
+2. **Then state the cause in one sentence, the impact in one sentence.** No multi-paragraph background, no internal symbol names, no walk-through of the fix.
+3. **Then state the ship state**, exactly one of: already shipped in v<X.Y.Z>, fixed on `main` and going out in the next release, planned for v<X.Y.Z>, not planned (with one-line reason and an alternative path). Do not write "already shipped" without release evidence in the current turn.
+4. **Two paragraphs maximum**, separated by one blank line. No bullet lists, no section headers, no code blocks except a one-line command when actually needed.
+5. **No em-dash.** Use commas, periods, colons. (Covered by the Hard Rule, surfaced again because issue replies attract this pattern.)
+
+The reply is the final user-facing text, not an agent log. Do not write "刚才我判断错了", "前面回复有误", "I re-read it and changed the comment", or any meta narration about your own process. If editing an existing maintainer comment, replace it with the clean final wording as if it were the only comment the user will read.
+
+Before posting, re-read the live issue / PR with `gh issue view <num>` or `gh pr view <num>`. Do not reply from memory; titles, states, and author languages change between sessions.
+
+For paid / subscribed users, acknowledge the purchase relationship and the inconvenience in one phrase, then state the boundary. Do not over-explain. When the current product cannot support their setup, suggest the safest practical path (upgrade macOS, wait for the next release, provide logs, refund route) without arguing.
+
+Closing rule: when closing as `completed`, the comment must independently explain what was fixed and the expected release. When closing as `not planned`, the comment must independently explain the current boundary and an alternative path. Do not rely on prior thread context as the explanation.
+
+## Document Review Mode
+
+Activate when: PDF, document, white paper, "review this document", "check this document", "审稿"
+
+Review checklist:
+- **Privacy scan**: Detect PII (names, companies, employment dates, salary hints, location details). Hard stop if any text implies job seeking, competitor info, or personal data leakage.
+- **Tone consistency**: Flag voice shifts, register mismatches, formulaic phrasing. Check for AI patterns using the loaded `write-zh.md` or `write-en.md` rules.
+- **Bilingual validation**: For CN/EN pairs, confirm translation accuracy and terminology consistency. Apply Bilingual Review Mode rules.
+- **Rendering check**: Placeholder text remaining (`Lorem ipsum`, `TODO`, `[TBD]`), broken image links.
+- **Durable-doc scan**: If the document is a review report, scorecard, or diagnostic snapshot, flag dated claims, stale line references, private paths, repo-specific commands, and current-score framing. Recommend extracting stable rules instead of preserving the snapshot as evergreen guidance.
+
+Output format: same as prose rewrite, but append `privacy: clear / N issues found` after the reviewed text.
+
+## Paragraph Coherence Mode
+
+Activate when: "连贯性", "段落连贯", "可读性", "coherence", "flow check", "段落顺不顺"
+
+Do not rewrite. Instead, work through each paragraph in sequence:
+1. Flag transitions that abruptly shift topic without a signal.
+2. Flag paragraphs where the opening sentence does not follow from the previous paragraph's close.
+3. Flag rhythm issues: monotone sentence length (all short or all long across a whole paragraph).
+4. Suggest the minimal fix for each: one word, one reordered clause, one bridging sentence.
+
+Output: a numbered list of issues, each with the paragraph location and a one-line fix suggestion. Then ask if the user wants any applied.
+
+## Tweet / Social Post Mode
+
+Activate when: "推特", "twitter", "X推文", "tweet", "social post", "折叠长度", "长文推特", "发文"
+
+Apply the five announcement rules for product-engineer projects when the project context or prior artifact shows this style:
+1. **Lead with community**: open with the social anchor (star count, user thanks, whose feedback drove the fix). Changes follow, not lead.
+2. **Highlights over completeness**: pick 2 to 4 of the most interesting changes. Dropping whole items is fine.
+3. **UX framing**: phrase each point as "你用它的时候..." or "有一种...的感觉", not "这个工具做了...".
+4. **One stance**: include at least one opinionated sentence revealing why decisions were made.
+5. **Native Chinese rhythm**: use idiomatic phrasing. Avoid translation-sounding terms.
+
+Close casually with an invitation, not a CTA. End with one short sentence inviting readers to try, not "立即升级".
+
+For other engineering projects or English posts, apply the same structure (community lead, highlights, UX framing, one stance, casual close) adapted to the project's voice.
+
+## Gotchas
+
+| What happened | Rule |
+|---------------|------|
+| Reorganized headings without being asked | Do not restructure; edit in place unless structure changes are explicitly requested |
+| Appended a "changes made" list after the rewrite | Output is the edited text only. No changelog, no commentary. |
+| Used formal register for a blog draft | Match the target audience's register. Blog is conversational, not academic. |
+| Applied Chinese/English spacing rules to a pure-English text | Bilingual spacing rules (半角/全角) only apply when the text mixes Chinese and English |
+| Polished the user's voice into generic launch copy | Preserve the author's cadence and stance. Use real product artifacts to sharpen facts, not to replace the voice. |
+| Drafted release or social copy from memory or a handoff | Read the current release page, changelog, issue/PR, runnable artifact, product page, screenshot, or supplied source before making factual claims. |
+| Wrote launch copy in one pass without checking the live screenshots | Iterate: draft, compare against the real product screenshot or page, tighten wording to match what ships, repeat until copy and artifact agree |
+| Polished a review report until it sounded timeless | Keep snapshots labeled as snapshots, or distill them into stable rules. Do not make dated claims sound evergreen |
+
+## Output
+
+Return only the edited prose. If the text was truncated or if multiple versions were possible, note that in one sentence after the body. Otherwise, no wrapper, no preamble, no postscript.

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

@@ -0,0 +1,199 @@
+> **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 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.
+5. **Put the reader in the room.** No narrator-from-a-distance voice. "You" beats "People." Specifics beat abstractions.
+6. **Vary rhythm.** Mix sentence lengths. Two items beat three. End paragraphs differently. No em dashes.
+7. **Trust readers.** State facts directly. Skip softening, justification, hand-holding.
+8. **Cut quotables.** If it sounds like a pull-quote, rewrite it.
+9. **Do not replace one formula with another.** “Human” does not mean slangy, quirky, or performatively casual.
+10. **No emoji.** Remove any emoji from the text being edited.
+
+### Word Choice
+
+Examples, not exhaustive -- any word used to signal importance rather than to say something is suspect.
+
+**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"
+> OK: Say what it does. Drop the adverb.
+
+**AI vocabulary: replace with plain language:**
+
+| Avoid | Use instead |
+|-------|-------------|
+| delve (into) | examine, look at, explore |
+| leverage (as verb) | use |
+| utilize | use |
+| robust | strong, reliable, solid |
+| streamline | simplify, cut |
+| harness | use, apply |
+| navigate (challenges) | handle, address |
+| unpack | explain, examine |
+| paradigm | system, approach, model |
+| synergy | combination, cooperation |
+| ecosystem | community, network, field |
+| tapestry | mix, combination |
+| landscape | situation, field, area |
+| game-changer | significant, important |
+| deep dive | analysis, examination |
+| moving forward | next, from now |
+
+**Pompous copulas: use "is" instead:**
+> NO: "serves as", "stands as", "marks", "represents"
+> OK: "is"
+
+### Sentence Structures to Avoid
+
+Examples, not exhaustive -- any construction that performs insight rather than delivers it belongs here.
+
+**Negative parallelism**: the single most common AI tell:
+> NO: "It's not bold. It's backwards." / "Not because X, but because Y." / "The question isn't X. The question is Y."
+> OK: State Y directly. Drop the negation entirely.
+
+**Negative countdown:**
+> NO: "Not a bug. Not a feature. A fundamental design flaw."
+> OK: "It's a fundamental design flaw."
+
+**Rhetorical self-questions:**
+> NO: "The result? Devastating." / "The worst part? Nobody saw it coming."
+> OK: State it: "The result was devastating."
+
+**Anaphora abuse**: repeating the same sentence opener:
+> NO: "They assume that... They assume that... They assume that..."
+> OK: Combine or restructure. One statement, clear subject.
+
+**Tricolon abuse**: rule of three, used three times back to back:
+> NO: "Products impress people; platforms empower them. Products solve problems; platforms create worlds."
+> OK: Make the point once, cleanly.
+
+**False ranges:**
+> NO: "From innovation to cultural transformation" (what's in between?)
+> OK: List the two things directly, or pick one.
+
+**Dramatic fragmentation**: manufactured emphasis via fragments:
+> NO: "He published this. Openly. In a book. As a priest."
+> OK: Complete sentences. Trust content over presentation.
+
+**False agency**: inanimate objects performing human verbs:
+> NO: "the complaint becomes a fix" / "the decision emerges" / "the data tells us"
+> OK: Name the human. "Someone fixed it." "The team decided."
+
+### Tone Patterns to Avoid
+
+**False suspense transitions:**
+> NO: "Here's the kicker." / "Here's the thing." / "Here's where it gets interesting."
+> OK: Make the point. No buildup.
+
+**Patronizing analogies:**
+> NO: "Think of it like a highway system for data." / "Think of it as a Swiss Army knife."
+> OK: Explain the concept directly. If an analogy helps, test it against three criteria before keeping it: (1) remove it and the paragraph collapses: it is load-bearing, not decorative; (2) push it one layer deeper and it still holds; (3) the reader gets it without further explanation. If it fails any of these, drop the analogy and state the idea directly.
+
+**Futurist invitation:**
+> NO: "Imagine a world where every tool you use has a quiet intelligence behind it..."
+> OK: Describe what actually exists or what you're actually proposing.
+
+**False vulnerability**: performative self-awareness:
+> NO: "And yes, I'm openly in love with the platform model"
+> OK: Real vulnerability is specific and uncomfortable. Skip the polish.
+
+**Asserting simplicity instead of proving it:**
+> NO: "The reality is simpler and less flattering" / "History is clear"
+> OK: Show the evidence. Don't announce the conclusion before it.
+
+**Grandiose stakes inflation:**
+> NO: "This will fundamentally reshape how we think about everything." / "will define the next era of computing"
+> OK: Say what it actually does.
+
+**Pedagogical hand-holding:**
+> NO: "Let's break this down step by step." / "Let's unpack what this really means."
+> OK: Start with the content, not an announcement of the content.
+
+**Vague attributions:**
+> NO: "Experts argue..." / "Industry reports suggest..." / "Observers have cited..."
+> OK: Name the expert, link the report, quote the person. If you can't, you don't have a source.
+
+**Invented concept labels**: compound labels that sound analytical but aren't grounded:
+> NO: "the supervision paradox" / "the acceleration trap" / "workload creep"
+> OK: Describe the thing directly. Don't name it as if it's an established term.
+
+### Paragraph & Composition Patterns to Avoid
+
+**Short punchy fragments as paragraphs:**
+> NO: "These weren't just products. And the software side matched. Then it professionalised."
+> OK: Complete sentences. No staccato drama.
+
+**Bold-first bullets**: every bullet starts with a bolded phrase:
+> NO: "**Security**: Environment-based configuration..." / "**Performance**: Lazy loading..."
+> OK: Write bullets as sentences, or drop the bold. Not every list needs labels.
+
+**Fractal summaries**: "what I'm going to tell you; what I'm telling you; what I just told you":
+> NO: "In this section, we'll explore... [3000 words later] ...as we've seen in this section."
+> OK: Skip the preview and the recap. Write the content.
+> Exception: a single closing sentence in a TL;DR that orients non-specialist readers to the structure ahead ("The rest of this piece follows X in order...") is intentional navigation, not a fractal summary. Keep it; flag it at most, but do not delete without author approval.
+
+**Signposted conclusions:**
+> NO: "In conclusion..." / "To sum up..." / "In summary..."
+> OK: End. Don't announce that you're ending.
+
+**The dead metaphor**: one metaphor used 10 times across a piece:
+> NO: "The ecosystem needs ecosystems to build ecosystem value."
+> OK: Use a metaphor once, then move on.
+
+**Historical analogy stacking:**
+> NO: "Apple didn't build Uber. Facebook didn't build Spotify. Stripe didn't build Shopify."
+> OK: Make the point. One example is enough.
+
+**One-point dilution**: same argument restated 10 ways across 4000 words:
+> OK: Say it once. Add evidence or move on.
+
+**"Despite its challenges..." formula:**
+> NO: "Despite these challenges, the initiative continues to thrive."
+> OK: Either address the challenges or don't raise them.
+
+**It's worth noting / It bears mentioning:**
+> 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 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.
+- Any "not X, it's Y" contrasts? State Y directly.
+- Three consecutive sentences match length? Break one.
+- Paragraph ends with punchy one-liner? Vary it.
+- Em-dash anywhere? Remove it.
+- Vague declarative ("The implications are significant")? Name the specific implication.
+- Meta-joiners ("The rest of this essay...")? Delete. Exception: a single TL;DR closing sentence that orients readers to the structure ahead is navigation, not filler. Keep it.
+- Any bullet starting with bold label? Reconsider the format.
+- Any "In conclusion" or "To sum up"? Cut it.
+- Any emoji? Remove it.
+
+---
+
+**Bottom line: varied, imperfect, specific. Any single trope used once may be fine. The problem is when multiple appear together or one repeats.**

package/template/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/template/skills/write/references/write-zh-bilingual.md

@@ -0,0 +1,59 @@
+# 中英双语规则
+
+## 双语一致性检查
+
+**中英混排格式**（来自 mzlogin/chinese-copywriting-guidelines）：
+- 中文和英文字符之间加空格：`CN文字EN` → `CN 文字 EN`
+- 不混用标点：中文用 `、。？！；：`，不用英文逗号/句号
+- 术语跨全文一致
+
+**中文里的英文**：标记出现的未翻译英文，建议翻译或加说明。
+
+**双语对**：确认 EN 和 CN 版本传达的意思相同；标记翻译损失。
+
+## 英文术语首次出现规则
+
+- 首次出现：保留英文 + 中文注解，或中文前置 + 英文括注（`指令微调（Instruction tuning）`）
+- 后续出现：只用中文，不要英中混用
+- 例外：SFT、RL、MoE 这类已成行业通用缩写，全程保留缩写形式
+
+## 有稳定中文对译的英文词
+
+中文技术圈已有通用译法的，换中文：
+
+| 英文 | 推荐中文 |
+|------|----------|
+| context | 上下文 |
+| state | 状态 |
+| cache | 缓存 |
+| claim | 断言 |
+| runtime | 运行时 |
+| contract | 契约 |
+
+术语在中文圈还未收敛的（prompt、embedding、tokenizer），保留英文合理。
+
+## 翻译腔套路（主动排查）
+
+**物理动作动词**：接住、击穿、锋利、不崩、不爆、打穿、扛住，这类词把抽象认知过程想象成了物理动作（骨架是英文 catch/pierce/sharp）。换成日常中文：你这几条我都收到了 / 这个假设不成立。
+
+**形容词预判+冒号**："更干净："、"逻辑很清晰："引出内容。删掉形容词，只留后面事实。
+
+**抽象名词做主语**："工程上的现实比这些数字难看"这种骨架，凡碰到"X 的 Y 比 Z 更 W"，重写让人/动作做主语。
+
+**有稳定对译词直接混入**："context 不崩、state 可恢复"，换成中文。
+
+## 双语并列的排版
+
+中英双语 release notes 的排版：
+
+- 英文版在前，中文版在后（或分两个段落）
+- 条目编号一一对应
+- 专有名词（产品名、功能名）在两种语言里保持一致
+- 不要在同一条内中英混写
+
+## 标点规则
+
+- 中文标点：`，。；：！？、""『』【】`
+- 英文在中文句子中出现时用中文标点断句
+- 禁止用破折号（—），用逗号或分号替代
+- `bold 小标题 + 句号` 改为 `bold 小标题 + 逗号`（内联而非独立标题）

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

@@ -0,0 +1,50 @@
+# 中文散文核心规则
+
+技术长文的去 AI 味和自然化。完整规则见 `write-zh.md`，本文摘录最高频的 10 类改写模式。
+
+## 最高优先级：保语义 > 去 AI 味
+
+先确认事实、逻辑、因果不变，再做以下改写。如果为"更口语"改坏原意，属于失败改写。
+
+## 高频 AI 痕迹（首先检查）
+
+**1. 段末收尾总结句**：一段刚解释完某机制，结尾再重述一遍。识别信号："到这里"、"这说明"、"这本身就是"、"可以看出"开头，或者段落最后一句比其他句短且抽象。直接删掉。
+
+**2. 升华句**：把具体工程观察上升到普适人生道理。直接给出具体建议，不升华。
+
+**3. 对比句式**："不是…而是…"、"X 本身没有价值，真正有用的是 Y"、"X 已经不是瓶颈，Y 才是"。直接说结论，不用对比框架铺垫。
+
+**4. bold 小标题模式**：`**xxx**。content` 改为 `**xxx**，content`，让 bold 变成承重词，不是独立小标题。例外：bold 部分本身是完整句子时保留句号。
+
+**5. 章节引介过渡句**：章节开头或结尾写"上面这些模式解决的是…，下面再看…"。直接删掉，章节标题本身已经承接。
+
+**6. 空泛形容词预判**："更干净："、"逻辑很清晰："，形容词抢先下判断。删掉形容词，只留后面的事实。
+
+**7. 工整并列 bold 标题**：四个 bold 标题全是同一格式。每个点语气不同，或改成散文叙述。
+
+**8. 段内重复**：同一段把同一意思用不同措辞说两遍。说一遍，够了。
+
+**9. 讲解腔起手**："真拆开看"、"这背后是同一个变化"、"真正关键的问题是"。删掉，直接说。
+
+**10. 训人感起手**："先问问是不是"、"你要先明白"。改成"可以先看"、"先确认"。
+
+## 句式规则
+
+- 禁止用破折号（—），用逗号或分号代替
+- 四五个句号连发、每句很短 = 打电报，合成长句或用逗号连
+- 单独成段的一两句话，多半是上一段的收尾，直接并进去
+- 不用"首先…其次…最后"，用"一方面…另一方面…"
+
+## 用词去正式化
+
+| 不用 | 用 |
+|------|-----|
+| 非常/极其 | 很 |
+| 综上所述 | 直接收尾 |
+| 例如 | 比如 |
+| 购买/使用 | 买/用 |
+| 值得注意的是 | 直接说结论 |
+
+完整规则、AI 味检测所有模式、标题设计、引号/括号/分号规则见 `write-zh.md`。
+
+长文（多 `##` 节、带表格和图）先做结构再抠句子：跨章节同义清单只留最全一份、表格旁正文别复读、判断/取舍类列表默认转 prose，详见 `write-zh.md` 的「结构级重复与表格复读（长文专项）」，整体流程见 `SKILL.md` 的 Long-form Article Mode。

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

@@ -0,0 +1,40 @@
+# 对外发文专项：release notes 和推文
+
+## 推文 / 社交发文五规则
+
+适用于已有社区语气和轻量发布节奏的产品工程师项目对外发文：
+
+1. **社区先行**：开头用社会锚点（star 数、感谢用户、谁的反馈推动了这次修复）。改动清单跟在后面，不放在最前。
+2. **亮点不全量**：挑 2 到 4 个最有意思的改动。跳过整个模块也没问题。读者要的是故事，不是 changelog。
+3. **用户感受帧**：每条写法用"你用它的时候…"或"有一种…的感觉"，不是"这个工具做了…"。
+4. **一条立场**：至少一句表明决策原因的意见句（例："我更相信模型本身的能力，而非各种规则限制他的天花板"）。
+5. **中文节奏**：用地道表达（给留了一手、玩玩、大伙、大概就是这些）。避免翻译腔和正式词（具体判据、主轴、本意）。
+
+结尾用邀请，不用 CTA：「假如没有用过的小伙伴，欢迎去试试看，玩玩。」而不是「立即升级」。
+
+## Release Notes 格式
+
+**结构**：Breaking Changes → New Features → Fixes & Improvements → Deprecations
+
+**格式**：优先匹配目标项目最近一次 release。没有可用参考时，使用编号列表、bold 标签、一句话说用户效果；只有目标项目已经使用中英双语时才输出双语。
+
+**长度参考**：和上一个版本 release 的条目数、句子长度、密度匹配。不要自创新格式。
+
+**边界**：GitHub Release 正文和社交公告是两份 artifact。Release notes 解释用户会感受到什么，默认不写 CI、tap、registry、API 名称、fallback 路径等机制细节；公告另按社交发文规则挑 2 到 4 个亮点。
+
+## 对外发文专项检查
+
+公开发文交出去之前，扫三件事：
+
+**1. 身份和敏感信号脱敏**：不出现可反推作者身份的细节（雇主、地点、简历式表述）。技术决策可以具体，身份信息默认删。
+
+**2. 不踩竞品**：介绍自己产品时不主动贬低同类产品。直接说自己做了什么、为什么。
+
+**3. 用户感受先于功能清单**：先给一句场景或感受，再进改动细节。不要开场就列功能。
+
+## 发版前检查
+
+- 不出现"不再更新"、"final release"、"停止维护"等终止信号（除非是真实情况）
+- release title 简洁：版本号 + 最核心的改动或主题，不超过 10 个词
+- 中英版本条目数一一对应
+- 建议 5 到 8 条，每条一句话