@tw93/waza 3.25.0

package/skills/read/scripts/fetch_local.py

@@ -0,0 +1,218 @@
+#!/usr/bin/env python3
+"""Local URL → Markdown extractor. Privacy-preserving tier 1 for fetch.sh.
+
+Two paths, picked at runtime:
+
+1. **Best path**: `readability-lxml` + `html2text` installed. Extract main
+   content via readability scoring, convert to clean Markdown. Quality close
+   to defuddle.md / r.jina.ai for static pages.
+
+2. **Fallback path**: stdlib only. Strip HTML tags, collapse whitespace, drop
+   <script>/<style>/<nav>/<footer>. Quality is poor for JS-heavy pages and
+   complex layouts, but works for simple article-style HTML without any
+   third-party dependency.
+
+JS-rendered pages (X/Twitter, paywalled news, SPA) are out of reach for both
+paths. Use `fetch.sh --use-proxy` for those.
+
+Exit codes:
+  0  success, markdown on stdout
+  1  fetch or extraction failed; reason on stderr
+  2  invocation error (missing URL)
+"""
+
+from __future__ import annotations
+
+import argparse
+import re
+import sys
+import urllib.error
+import urllib.request
+from html.parser import HTMLParser
+
+
+USER_AGENT = (
+    "Mozilla/5.0 (Macintosh; Intel Mac OS X 12_0) "
+    "AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120 Safari/537.36"
+)
+FETCH_TIMEOUT_SECS = 20
+
+
+def fetch_html(url: str) -> str:
+    req = urllib.request.Request(url, headers={"User-Agent": USER_AGENT})
+    with urllib.request.urlopen(req, timeout=FETCH_TIMEOUT_SECS) as resp:
+        raw = resp.read()
+    # Detect charset from Content-Type header; fall back to utf-8 with replace.
+    charset = "utf-8"
+    ctype = resp.headers.get("Content-Type", "")
+    m = re.search(r"charset=([\w\-]+)", ctype, re.IGNORECASE)
+    if m:
+        charset = m.group(1).lower()
+    try:
+        return raw.decode(charset, errors="replace")
+    except LookupError:
+        return raw.decode("utf-8", errors="replace")
+
+
+def extract_with_readability(html: str, url: str) -> str | None:
+    """Best path: readability-lxml + html2text. Returns Markdown or None if
+    deps missing. Raises only on genuine extraction failure."""
+    try:
+        from readability import Document  # type: ignore
+        import html2text  # type: ignore
+    except ImportError:
+        return None
+    doc = Document(html)
+    cleaned_html = doc.summary(html_partial=True)
+    title = (doc.short_title() or "").strip()
+    converter = html2text.HTML2Text()
+    converter.body_width = 0
+    converter.unicode_snob = True
+    converter.ignore_links = False
+    converter.ignore_images = False
+    body = converter.handle(cleaned_html).strip()
+    if not body:
+        return None
+    header = ""
+    if title:
+        header = f"# {title}\n\n"
+    return f"{header}> Source: {url}\n\n{body}\n"
+
+
+class _StdlibStripper(HTMLParser):
+    """Fallback HTML → text converter using only stdlib. Quality is poor but
+    deterministic; intended as a last resort when readability isn't installed.
+    Drops common non-content blocks (script/style/nav/footer/aside)."""
+
+    DROP_TAGS = {"script", "style", "nav", "footer", "aside", "noscript", "form"}
+    BLOCK_TAGS = {
+        "p", "div", "section", "article", "li", "ul", "ol",
+        "h1", "h2", "h3", "h4", "h5", "h6", "br", "tr",
+    }
+
+    def __init__(self) -> None:
+        super().__init__()
+        self._buf: list[str] = []
+        self._drop_depth = 0
+        self._title = ""
+        self._in_title = False
+
+    def handle_starttag(self, tag, attrs):
+        if tag in self.DROP_TAGS:
+            self._drop_depth += 1
+        elif tag == "title":
+            self._in_title = True
+        elif tag in self.BLOCK_TAGS:
+            self._buf.append("\n")
+
+    def handle_endtag(self, tag):
+        if tag in self.DROP_TAGS:
+            self._drop_depth = max(0, self._drop_depth - 1)
+        elif tag == "title":
+            self._in_title = False
+        elif tag in self.BLOCK_TAGS:
+            self._buf.append("\n")
+
+    def handle_data(self, data):
+        if self._drop_depth:
+            return
+        if self._in_title:
+            self._title += data
+            return
+        self._buf.append(data)
+
+    def text(self) -> str:
+        raw = "".join(self._buf)
+        lines = [line.strip() for line in raw.splitlines()]
+        # Drop empty lines but keep paragraph breaks.
+        out: list[str] = []
+        prev_blank = False
+        for line in lines:
+            if not line:
+                if not prev_blank:
+                    out.append("")
+                prev_blank = True
+            else:
+                out.append(line)
+                prev_blank = False
+        return "\n".join(out).strip()
+
+
+def extract_with_stdlib(html: str, url: str) -> str:
+    p = _StdlibStripper()
+    p.feed(html)
+    body = p.text()
+    if not body:
+        body = "(no text content extracted)"
+    header = ""
+    title = (p._title or "").strip()
+    if title:
+        header = f"# {title}\n\n"
+    return f"{header}> Source: {url}\n\n{body}\n"
+
+
+def main() -> int:
+    parser = argparse.ArgumentParser(description=__doc__)
+    parser.add_argument("url", help="URL to fetch")
+    parser.add_argument(
+        "--prefer",
+        choices=("auto", "readability", "stdlib"),
+        default="auto",
+        help="Force a specific extractor (default: auto = readability if installed, else stdlib)",
+    )
+    args = parser.parse_args()
+
+    try:
+        html = fetch_html(args.url)
+    except (urllib.error.URLError, urllib.error.HTTPError, TimeoutError, OSError) as exc:
+        print(
+            f"[fetch] tier=local status=fail reason=\"fetch failed: {exc}\"",
+            file=sys.stderr,
+        )
+        return 1
+
+    used = ""
+    body: str | None = None
+
+    if args.prefer in ("auto", "readability"):
+        body = extract_with_readability(html, args.url)
+        if body is not None:
+            used = "readability"
+        elif args.prefer == "readability":
+            print(
+                "[fetch] tier=local status=fail "
+                "reason=\"--prefer readability but readability-lxml or html2text not installed; "
+                "install with: pip install --user readability-lxml html2text\"",
+                file=sys.stderr,
+            )
+            return 1
+
+    if body is None:
+        body = extract_with_stdlib(html, args.url)
+        used = "stdlib"
+
+    # Sanity floor: if even the stdlib extractor returns essentially nothing,
+    # treat as failure so the proxy fallback (if --use-proxy) gets a chance.
+    body_lines = [l for l in body.splitlines() if l.strip()]
+    if len(body_lines) < 4:
+        print(
+            f"[fetch] tier=local status=fail reason=\"extractor={used} produced <4 non-empty lines\"",
+            file=sys.stderr,
+        )
+        return 1
+
+    if used == "stdlib":
+        print(
+            "[fetch] tier=local status=ok extractor=stdlib "
+            "hint=\"install readability-lxml + html2text for cleaner output\"",
+            file=sys.stderr,
+        )
+    else:
+        print(f"[fetch] tier=local status=ok extractor={used}", file=sys.stderr)
+
+    sys.stdout.write(body)
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())

package/skills/read/scripts/fetch_weixin.py

@@ -0,0 +1,107 @@
+#!/usr/bin/env python3
+"""Fetch WeChat public account article as Markdown using Playwright + BeautifulSoup.
+
+Special thanks to joeseesun for the excellent qiaomu-markdown-proxy project,
+which inspired the Playwright-based WeChat scraping approach in this script.
+https://github.com/joeseesun/qiaomu-markdown-proxy
+
+Requirements:
+    pip install playwright beautifulsoup4 lxml
+    playwright install chromium
+
+Usage:
+    python3 fetch_weixin.py <url>
+    python3 fetch_weixin.py <url> --json
+"""
+
+import sys
+import json
+import asyncio
+
+
+def yaml_string(value: str) -> str:
+    return json.dumps("" if value is None else str(value), ensure_ascii=False)
+
+
+async def fetch(url: str) -> dict:
+    try:
+        from playwright.async_api import async_playwright
+        from bs4 import BeautifulSoup
+    except ImportError as e:
+        return {"error": str(e) + "\nRun: pip install playwright beautifulsoup4 lxml && playwright install chromium"}
+
+    async with async_playwright() as p:
+        browser = await p.chromium.launch(headless=True)
+        page = await browser.new_page(
+            user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
+        )
+        try:
+            await page.goto(url, wait_until="domcontentloaded", timeout=30000)
+            await page.wait_for_selector("#js_content", timeout=15000)
+            html = await page.content()
+        except Exception as e:
+            await browser.close()
+            return {"error": f"Page load failed: {e}"}
+        await browser.close()
+
+    soup = BeautifulSoup(html, "lxml")
+
+    title = (soup.select_one("#activity-name") or soup.new_tag("x")).get_text(strip=True)
+    author = (soup.select_one("#js_author_name") or soup.new_tag("x")).get_text(strip=True)
+    date = (soup.select_one("#publish_time") or soup.new_tag("x")).get_text(strip=True)
+
+    content_el = soup.select_one("#js_content")
+    if not content_el:
+        return {"error": "Could not find #js_content"}
+
+    for tag in content_el.find_all(["script", "style"]):
+        tag.decompose()
+
+    for img in content_el.find_all("img"):
+        src = img.get("data-src") or img.get("src") or ""
+        img.replace_with(f"\n![image]({src})\n" if src else "")
+
+    lines = []
+    for el in content_el.find_all(["p", "h1", "h2", "h3", "h4", "section", "blockquote"]):
+        text = el.get_text(strip=True)
+        if not text:
+            continue
+        if el.name in ("h1", "h2", "h3", "h4"):
+            lines.append(f"{'#' * int(el.name[1])} {text}")
+        elif el.name == "blockquote":
+            lines.append(f"> {text}")
+        else:
+            lines.append(text)
+
+    content = "\n\n".join(lines) or content_el.get_text("\n", strip=True)
+    return {"title": title, "author": author, "date": date, "url": url, "content": content}
+
+
+def to_markdown(r: dict) -> str:
+    if "error" in r:
+        return f"Error: {r['error']}"
+    parts = [
+        "---",
+        f"title: {yaml_string(r.get('title', ''))}",
+        *([f"author: {yaml_string(r['author'])}"] if r.get("author") else []),
+        *([f"date: {yaml_string(r['date'])}"] if r.get("date") else []),
+        f"url: {yaml_string(r.get('url', ''))}",
+        "---",
+        "",
+        f"# {r['title']}" if r.get("title") else "",
+        "",
+        r.get("content", ""),
+    ]
+    return "\n".join(parts)
+
+
+if __name__ == "__main__":
+    if len(sys.argv) < 2:
+        print("Usage: fetch_weixin.py <url> [--json]", file=sys.stderr)
+        sys.exit(1)
+
+    result = asyncio.run(fetch(sys.argv[1]))
+    if "--json" in sys.argv:
+        print(json.dumps(result, ensure_ascii=False, indent=2))
+    else:
+        print(to_markdown(result))

package/skills/think/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: think
+description: "Turns rough ideas into approved, decision-complete plans with validated structure before coding. Use when users ask 出方案/给方案/深入分析/怎么设计/有没有必要/值不值得/plan this/how should I/should we keep this for features, architecture, or value judgments. Not for bug fixes or small edits."
+when_to_use: "出方案, 给方案, 深入分析, 怎么设计, 用什么方案, 判断一下, 有没有必要, 值不值得, what's the best approach, plan this, how should I, should we keep this"
+dispatch_intent: "New feature, architecture, how should I design this, value judgment, executable plan, handoff"
+---
+
+# Think: Design and Validate Before You Build
+
+Prefix your first line with 🥷 inline, not as its own paragraph.
+
+Turn a rough idea into an approved plan. No code, no scaffolding, no pseudo-code until the user approves.
+
+Give opinions directly. Take a position and state what evidence would change it. Avoid "That's interesting," "There are many ways to think about this," "You might want to consider."
+
+## 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."
+
+Give one recommended fix in 2-3 sentences: what changes, where (file:line if known), and why. Name the brute-force version in one line first; default to it unless the user wants elegance. List involved files, flag explicitly if more than 5. State one risk. Wait for approval before implementing.
+
+Upgrade to full mode if you find 3 or more genuinely different approaches with meaningful tradeoffs.
+
+## Evaluation Mode
+
+Activate when the user wants to judge whether something should exist, be kept, exposed, or removed. Typical triggers: "判断一下", "有没有必要", "值不值得", "should we keep this", "is this worth it", "我不想做", "商业前景", "有没有必要继续".
+
+State the evaluation target and what kind of judgment is needed (value, risk, or tradeoff). Take a current-state snapshot: what it does, who uses it, what depends on it; grep and read before opining.
+
+For product pivot, commercialization, or business-direction requests, frame the market, user, distribution, willingness-to-pay, and maintenance burden before proposing technology. Do not assume open source, do not assume implementation comes first, and do not hide a business judgment inside a technical plan.
+
+**Output format (Kill/Keep/Pivot):**
+
+Line 1: one of **Kill** / **Keep** / **Pivot** as the verdict. No preamble.
+
+Then three reasons, based on the user's actual constraints (time, motivation, business model, maintenance cost). Not generic tradeoffs.
+
+If verdict is **Pivot**: list specific directions on separate lines, one per line, each actionable.
+
+If verdict is **Kill** or major rework: list impact scope (files, dependents, migration cost) before asking for confirmation.
+
+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).
+
+## Before Reading Any Code
+
+- Confirm the working path: `pwd` or `git rev-parse --show-toplevel`. Never assume `~/project` and `~/www/project` are the same.
+- 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. `pake.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.
+
+## Propose Approaches
+
+Give one recommended approach with rationale. Include effort, risk, and what existing code it builds on. Mention one alternative only if the tradeoff is genuinely close (>40% chance the user would prefer it). Always include one minimal option.
+
+When the plan is about distilling lessons from one project into a reusable skill set or shared rules, split the plan into **promote** and **do not promote**. Promote only reusable workflow constraints. Explicitly reject project-specific commands, paths, release checklists, safety boundaries, and private local context unless the user asks to update that project itself.
+
+For the recommendation, identify the most fragile assumption (premise collapse) and state it explicitly: "This plan assumes X. If X does not hold, Y happens." If the assumption is load-bearing and fragile, deform the design to survive its failure.
+
+**Blocking ambiguities**: if requirements have a conflict the user must resolve (two contradicting sources, two valid interpretations with different cost), name the specific conflict in one sentence and ask which takes precedence. Do not silently pick.
+
+**Additional attack angles** (run only when the plan involves external dependencies, high concurrency, or data migration):
+
+| Attack angle | Question |
+|---|---|
+| Dependency failure | If an external API, service, or tool goes down, can the plan degrade gracefully? |
+| Scale explosion | At 10x data volume or user load, which step breaks first? |
+| Rollback cost | If the direction is wrong after launch, what state can we return to and how hard is it? |
+
+If an attack holds, deform the design to survive it. If it shatters the approach entirely, discard it and tell the user why. Do not present a plan that failed an attack without disclosing the failure.
+
+Get approval before proceeding. If the user rejects, ask specifically what did not work. Do not restart from scratch.
+
+## Validate Before Handing Off
+
+- More than 8 files or 1 new service? Acknowledge it explicitly.
+- More than 3 components exchanging data? Draw an ASCII diagram. Look for cycles.
+- Every meaningful test path listed: happy path, errors, edge cases.
+- Can this be rolled back without touching data?
+- Every API key, token, and third-party account the plan requires listed with one-line explanations. No credential requests mid-implementation.
+- Every MCP server, external API, and third-party CLI the plan depends on verified as reachable before approval.
+
+**No placeholders in approved plans.** Every step must be concrete before approval. Forbidden patterns: TBD, TODO, "implement later," "similar to step N," "details to be determined." A plan with placeholders is a promise to plan later.
+
+**Phase independence.** If the plan has multiple phases, each phase must be independently mergeable: after Phase N ships, the system is in a usable state, even if N+1 never lands. Plans that require all phases to complete before anything works are fragile (one stuck phase blocks the whole release) and waste review effort. If the work cannot be cut into mergeable phases, say so and ship it as one phase instead of pretending it is staged.
+
+**Plan red flags (self-check before handoff):**
+- A phase depends on the next phase to be useful (cannot ship alone).
+- A "Phase 0: investigate / spike" exists. Investigation belongs before the plan, not inside it.
+
+Either red flag means the plan is not ready. Resolve it before handing off.
+
+## Implementation Handoff
+
+A finished plan must be executable by another engineer or agent without re-deciding the direction. Include:
+
+- Scope and non-scope.
+- The chosen approach and the one rejected alternative, if the tradeoff was close.
+- Public API, schema, command, config, or file-interface changes, if any.
+- Verification commands and manual acceptance checks.
+- Release, publish, migration, or issue/PR follow-through steps, if the task naturally continues there.
+- Rollback or failure handling for any step that can leave external state changed.
+
+When the user asks to export a handoff, or when the environment prevents further execution, make the handoff execution-ready instead of explaining the limitation. Include file targets, key constants or selectors, exact commands, runtime or visual checklist, and risk boundaries. If the work depends on a screenshot or artifact, name the artifact and the pass/fail delta.
+
+When the user later says "Implement the plan", "可以干", "直接改", "整", or equivalent, treat that as approval of the written plan. Do not re-litigate the design. State which plan is being executed, check for obvious drift in the repo, and proceed. If the environment has changed enough that the plan is unsafe, name the specific drift and stop before editing.
+
+## Gotchas
+
+| What happened | Rule |
+|---------------|------|
+| Moved files to `~/project`, repo was at `~/www/project` | Run `pwd` before the first filesystem operation |
+| Asked for API key after 3 implementation steps | List every dependency before handing off |
+| User said "just do it" or equivalent approval | Treat as approval of the recommended option. State which option was selected, finish the plan. Do not implement inside `/think`. |
+| Planned MCP workflow without checking if MCP was loaded | Verify tool availability before handing off, not mid-implementation |
+| Rejected design restarted from scratch | Ask what specifically failed, re-enter with narrowed constraints |
+| User said "just fix X" and skipped /think | If the fix touches 3+ files or needs a method choice, pause and run Lightweight Mode |
+| User approved a concrete plan and the agent debated the plan again | Execute the approved plan. Only stop for repo drift, missing permissions, or unsafe external state |
+| Picked a regional or locale-specific API variant without checking | List all regional or locale differences before writing integration code |
+| Introduced a second language or runtime into a single-stack project | Never add a new language or runtime without explicit approval |
+| User said "判断一下这个报错" and got Evaluation Mode | "判断一下" + error/bug context = debugging, route to `/hunt`. Evaluation Mode is for value/existence judgments only |
+| User asked to "沉淀到 Waza" after a project review | First separate transferable Waza capability from project facts. Do not import that project's commands, paths, or release rules into Waza |
+
+## Output
+
+**Approved design summary:**
+- **Building**: what this is (1 paragraph)
+- **Not building**: explicit out-of-scope list
+- **Approach**: chosen option with rationale
+- **Key decisions**: 3-5 with reasoning
+- **Unknowns**: only items that are explicitly deferred with a stated reason and a clear owner. Not vague gaps. If an unknown blocks a decision, loop back before approval.
+
+After the user approves the design, stop. Implementation starts only when requested.
+
+## After Approval
+
+When the plan is approved, output this guidance:
+
+```
+Plan approved. To implement: say "implement this plan". After implementation, run `/check` to review before merging or release follow-through.
+```
+
+Keep it concise (2-3 sentences max). The user decides when to start implementation.

package/skills/write/SKILL.md

@@ -0,0 +1,129 @@
+---
+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"
+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.
+
+Strip AI patterns from prose and rewrite it to sound human. Do not improve vocabulary; remove the performance of improvement.
+
+## 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`
+   - 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.
+- **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, screenshots, product page, release page, changelog, issue/PR, or user-provided draft. Do not turn concrete product evidence into generic marketing language.
+- **Stop after output.** Deliver the rewritten text. Do not append a list of changes, a justification, or a closer.
+
+## 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.
+
+## 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. Run `gh release view --json body -R <owner>/<repo>` to read the most recent release as a style, length, and density reference.
+3. If the user mentions comparing with a sibling project's release style, ask for the `owner/repo` to fetch it: `gh release view --json body -R <owner>/<sibling>`.
+4. Match the reference release's item count, sentence length, and tone. Do not invent a new format.
+5. 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.
+
+## 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 | Read the current release page, changelog, issue/PR, 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.