create-dwy 0.13.2 → 0.13.3

package/CHANGELOG.md

@@ -0,0 +1,10 @@
+# create-dwy
+
+## 0.13.2
+
+### Patch Changes
+
+- 新增顶层命令 `dwy sync`，一次选择后同时同步 Claude Code 与 Codex 配置。
+- `dwy sync -i` 支持重新交互式选择；`dwy sync --dry-run` 支持预演；`dwy sync md` 同步 `CLAUDE.md` 到 `~/.claude/CLAUDE.md` 和 `~/.codex/AGENTS.md`。
+- 复用现有 `dwy claude sync` / `dwy codex sync` 的扫描、缓存选择、删除未选模板项和写入逻辑；`commands` 仅同步到 `.claude/commands`，`skills` / `rules` / `hooks` 同步到两端。
+- 新增 CLI 聚合同步回归测试，覆盖一次缓存选择同时写入 `.claude`、`.agents`、`.codex` 和 `AGENTS.md`。

package/package.json

@@ -1,12 +1,16 @@
 {
   "name": "create-dwy",
-  "version": "0.13.2",
+  "version": "0.13.3",
   "description": "项目脚手架与 Claude Code 配置同步工具",
   "type": "module",
   "bin": {
     "dwy": "./bin/index.js"
   },
+  "scripts": {
+    "test": "node --test tests/*.test.js"
+  },
   "files": [
+    "CHANGELOG.md",
     "bin",
     "src",
     "templates"
@@ -31,8 +35,5 @@
   "publishConfig": {
     "registry": "https://registry.npmjs.org/",
     "access": "public"
-  },
-  "scripts": {
-    "test": "node --test tests/*.test.js"
   }
-}
+}

package/templates/claude-global/hooks/Git/pre-git-commit-backtick-check.sh

@@ -0,0 +1,76 @@
+#!/bin/bash
+# Claude Code PreToolUse Hook
+# 拦截 git commit message 中会被 shell 命令替换的反引号 / $(...)
+#
+# 背景：AI 生成的 commit message 爱用 Markdown 风格反引号包代码标识符，
+#   git commit -m "fix: support `bun install` on windows"
+# 经 shell 执行时，双引号内的 `bun install` 会被当成命令替换 $(bun install) 实际执行，
+# 输出塞进 message，甚至误执行破坏性命令导致丢代码。
+# 单引号内 '...`...`...' 不展开，安全。
+# 安全写法：git commit -F <file> / --file=- / 单引号。
+
+# 从 stdin 读 JSON 取待执行命令（Claude Code 与 Codex 同样通过 stdin 传 .tool_input.command）
+CMD=$(python3 -c 'import sys,json; print(json.load(sys.stdin).get("tool_input",{}).get("command",""))')
+
+# 只在含 git commit 的命令上检查
+printf '%s' "$CMD" | grep -q 'git commit' || exit 0
+
+# 逐字符做轻量 shell 词法扫描：跟踪引号状态，
+# 只在「非单引号上下文」里出现裸反引号或 $( 时判危险（这些会被 shell 求值）。
+# 命令经环境变量传入（stdin 已被 heredoc 脚本占用，不能再走管道）。
+DANGER=$(CMD="$CMD" python3 <<'PY'
+import os
+
+s = os.environ.get("CMD", "")
+in_single = False   # 单引号内：所有字符字面，反引号安全
+in_double = False   # 双引号内：反引号 / $() 仍会命令替换
+i, n = 0, len(s)
+danger = False
+
+while i < n:
+    c = s[i]
+    if c == '\\' and not in_single:
+        # 反斜杠转义下一个字符（单引号内反斜杠不转义）
+        i += 2
+        continue
+    if c == "'" and not in_double:
+        in_single = not in_single
+        i += 1
+        continue
+    if c == '"' and not in_single:
+        in_double = not in_double
+        i += 1
+        continue
+    if not in_single:
+        # 非单引号上下文（裸或双引号内）：反引号 / $( 会被求值
+        if c == '`':
+            danger = True
+            break
+        if c == '$' and i + 1 < n and s[i + 1] == '(':
+            danger = True
+            break
+    i += 1
+
+print("DANGER" if danger else "OK")
+PY
+)
+
+[ "$DANGER" = "DANGER" ] || exit 0
+
+echo "========================================"
+echo "  WARNING: 危险的 commit message 写法"
+echo "========================================"
+echo ""
+echo "检测到 git commit message 中含会被 shell 命令替换的反引号 \` 或 \$(...)。"
+echo "双引号内的 \`...\` 会被当成命令替换实际执行，可能误执行命令甚至丢代码。"
+echo ""
+echo "改用以下任一安全写法："
+echo "  1. 文件提交（推荐多行 / 含特殊字符）："
+echo "       git commit -F <msg-file>"
+echo "       printf '%s\\n' \"\$MSG\" | git commit --file=-"
+echo "  2. 单引号包裹（单引号内反引号不展开）："
+echo "       git commit -m 'fix: support \`bun install\` on windows'"
+echo "  3. 转义反引号："
+echo "       git commit -m \"fix: support \\\`bun install\\\` on windows\""
+echo "========================================"
+exit 2  # 暂停等待人工审批

package/templates/claude-global/hooks/Git/pre-git-commit-sensitive-check.sh

@@ -2,40 +2,36 @@
 # Claude Code PreToolUse Hook
 # 在 git commit 前检查暂存文件中是否包含敏感数据
 
+# 从 stdin 读 JSON 并取出待执行命令（Claude Code 与 Codex 同样通过 stdin 传 .tool_input.command）
+CMD=$(python3 -c 'import sys,json; print(json.load(sys.stdin).get("tool_input",{}).get("command",""))')
+
 # 只拦截 git commit 命令
-echo "$TOOL_INPUT" | grep -q 'git commit' || exit 0
+printf '%s' "$CMD" | grep -q 'git commit' || exit 0
 
 # 获取暂存文件列表
 STAGED=$(git diff --cached --diff-filter=ACMR --name-only 2>/dev/null)
 [ -z "$STAGED" ] && exit 0
 
-# 敏感数据匹配模式
+# 敏感数据匹配模式（赋值/上下文形式，避免类名/变量名裸词误报）
 PATTERNS=(
-    # 密码/密钥
-    'password'
-    'passwd'
-    'secret'
-    'api[_-]?key'
-    'access[_-]?token'
-    'private[_-]?key'
-    'auth[_-]?token'
-    'client[_-]?secret'
-    'bearer'
-
-    # 数据库连接串
-    'jdbc:'
-    'mysql://'
-    'postgres://'
-    'mongodb://'
-    'redis://'
-
-    # 私钥文件
-    '-----BEGIN (RSA |EC |DSA |OPENSSH )?PRIVATE KEY'
-
-    # 平台 Token
-    'sk-[a-zA-Z0-9]{20,}'        # OpenAI
-    'ghp_[a-zA-Z0-9]{36}'        # GitHub
-    'AKIA[0-9A-Z]{16}'           # AWS
+    # 口令/密钥/令牌赋值（词 + :或= + 引号值；PairingSecret / clientSecret 等标识符不命中）
+    "(password|passwd)[[:space:]]*[:=][[:space:]]*[\"'][^\"']{4,}"
+    "secret[[:space:]]*[:=][[:space:]]*[\"'][^\"']{8,}"
+    "api[_-]?key[[:space:]]*[:=][[:space:]]*[\"'][^\"']{8,}"
+    "(access|auth)[_-]?token[[:space:]]*[:=][[:space:]]*[\"'][^\"']{8,}"
+    "client[_-]?secret[[:space:]]*[:=][[:space:]]*[\"'][^\"']{8,}"
+    "[Bb]earer[[:space:]]+[a-zA-Z0-9._-]{20,}"
+
+    # 含凭证的连接串（scheme://user:pass@host）
+    "://[a-zA-Z0-9_.-]+:[^@[:space:]/]{3,}@"
+
+    # 私钥文件块
+    "-----BEGIN (RSA |EC |DSA |OPENSSH )?PRIVATE KEY"
+
+    # 平台 Token（格式高特异，裸匹配）
+    "sk-[a-zA-Z0-9]{20,}"        # OpenAI
+    "ghp_[a-zA-Z0-9]{36}"        # GitHub
+    "AKIA[0-9A-Z]{16}"           # AWS
 )
 
 # 拼接为正则

package/templates/claude-global/rules//345/274/200/345/217/221/346/265/201/347/250/213/dwy-git-commit-safe.md

@@ -0,0 +1,66 @@
+---
+description: git commit message 安全写法(防反引号被 shell 命令替换误执行)
+---
+
+# git commit 安全写法
+
+## 核心风险
+
+AI 生成的 commit message 爱用 Markdown 风格反引号包代码标识符。经 shell 执行 `git commit -m "..."` 时，**双引号内**的反引号会被当成命令替换实际执行：
+
+```bash
+# 危险：`bun install` 被 shell 当成 $(bun install) 执行
+git commit -m "fix: support `bun install` on windows"
+```
+
+shell 实际跑了 `bun install`，把输出塞进 message，甚至误执行破坏性命令导致丢代码。`$(...)` 同理。
+
+## 强制规则
+
+commit message 含反引号 `` ` `` / `$(...)` / 多行 / emoji 等特殊字符时，**禁止** `git commit -m "..."`，必须走以下安全写法：
+
+### 1. 文件提交（首选，多行 / 特殊字符一律用它）
+
+```bash
+git commit -F <msg-file>
+
+# 或 stdin
+printf '%s\n' "$MSG" | git commit --file=-
+
+# 或 heredoc 写文件再提交
+cat > /tmp/commit-msg.txt <<'EOF'
+feat(agent): add `runConcurrent`
+
+- support drain-all-before-throw
+EOF
+git commit -F /tmp/commit-msg.txt
+```
+
+### 2. 单引号包裹（单行、无单引号时可用）
+
+```bash
+# 单引号内所有字符字面，反引号原样保留
+git commit -m 'fix: support `bun install` on windows'
+```
+
+### 3. 转义反引号（不推荐，易漏）
+
+```bash
+git commit -m "fix: support \`bun install\` on windows"
+```
+
+## 安全速查
+
+| 方式 | 反引号风险 |
+|---|---|
+| `git commit -m "...`...`..."` | 危险（双引号内被求值） |
+| `git commit -m '...`...`...'` | 安全（单引号不展开） |
+| `git commit -F <file>` | 安全（Git 直读文件，不过 shell） |
+| `git commit --file=-` | 安全 |
+
+## 禁止
+
+- **禁止**把含反引号 / `$(...)` 的 message 拼进 `git commit -m "..."` 双引号
+- **禁止**为图省事忽略此约束 —— 误执行后果是丢代码，不可逆
+
+> PreToolUse hook `pre-git-commit-backtick-check.sh` 会在双引号 message 含未转义反引号 / `$(...)` 时硬拦截（exit 2），但 hook 是兜底，写法本身就该走安全方式。

package/templates/claude-global/settings.json

@@ -7,6 +7,10 @@
           {
             "type": "command",
             "command": "bash $CLAUDE_PROJECT_DIR/.claude/hooks/pre-git-commit-sensitive-check.sh"
+          },
+          {
+            "type": "command",
+            "command": "bash $CLAUDE_PROJECT_DIR/.claude/hooks/pre-git-commit-backtick-check.sh"
           }
         ]
       }

package/templates/claude-global/skills//345/206/205/345/256/271/345/210/233/344/275/234/dwy-article/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dwy-article
-description: 用「我」的口吻把素材写成微信公众号图文文章，输出 Markdown（可直接喂 markdown-nice / 秀米 转排版）。涉及以下任何场景**必须**使用此 skill（即使用户没点名 'dwy-article'）：用户说『写一篇公众号』『帮我写篇推文/分享』『把这个 markdown / 草稿整理成公众号』『润色成公众号』『写篇技术分享 / 个人感悟』，或给一个中心思想 + 约束让我扩写成文，或丢一篇技术笔记 / 草稿让我去掉 AI 味、改成像他本人写的。覆盖多种文章类型，骨架模板放在本 skill 的 templates/ 目录、可随时扩展：技术教程、个人感悟、项目复盘、踩坑排错实录、工具资源安利、行业观察评论等。核心目标——简洁清晰、像一个 IT 全栈开发者本人随手写的，绝不能有 AI 范儿（套话结构词、空洞金句、说教礼貌腔、emoji 标题党）。
+description: 用「我」的口吻把素材写成微信公众号图文文章，输出 Markdown（可直接喂 markdown-nice / 秀米 转排版）。涉及以下任何场景**必须**使用此 skill（即使用户没点名 'dwy-article'）：用户说『写一篇公众号』『帮我写篇推文/分享』『把这个 markdown / 草稿整理成公众号』『润色成公众号』『写篇技术分享 / 个人感悟』，或给一个中心思想 + 约束让我扩写成文，或丢一篇技术笔记 / 草稿让我去掉 AI 味、改成像他本人写的。覆盖多种文章类型，骨架模板放在本 skill 的 templates/ 目录、可随时扩展：技术教程、个人感悟、项目复盘、踩坑排错实录、工具资源安利、行业观察评论、方案选型对比、概念科普等。核心目标——简洁清晰、像一个 IT 全栈开发者本人随手写的，绝不能有 AI 范儿（套话结构词、空洞金句、说教礼貌腔、emoji 标题党）。
 ---
 
 # dwy-article
@@ -94,6 +94,8 @@ AI 怕得罪人，什么都「因人而异」「视情况而定」。真人有
 
 为什么：读者关注一个人，是想听他**真实的判断**，不是听一段免责声明。早点亮明态度，敢说「我不推荐 X」「这个坑我卡了俩小时」。
 
+反过来，别用对冲词把话说软：「现阶段 / 理论上 / 某种程度上 / 往往 / 基本上 / 总体而言」。单看都没错，但 AI 句句挂一个，活像怕被人抓把柄。判断就判断，留余地的活交给读者自己加。
+
 ### 4. 上具体的，别泛泛而谈
 
 去 AI 味最有效的一招：**用真实的细节**——真实命令、真实报错、真实数字、真实踩坑经过。AI 爱说正确的废话，真人说具体的事。
@@ -107,6 +109,8 @@ AI 一上来就把什么都拆成 1. 2. 3.，每条一句话。真人会把有
 
 为什么：列表适合**真正并列的步骤或清单**（命令清单、配置项）。但论证、观点、过程，用段落更像人说话，有起承转合。拿不准就用段落。
 
+还有种更隐蔽的列表，要专门防：把 1. 2. 3. 换成「先说 X。再说 Y。最关键的 Z。」——看着是段落，骨子里还是三点工整平行，照样不像人话。换个口语连接词不等于去了列表味。真要并列，就让几点长短不一、详略不均，甚至把其中一点顺手揉进上一段说掉。
+
 ### 6. 句子有长短、有口语、有呼吸
 
 长短句交错，多用短句和断句。允许碎片句、口语词（其实、说白了、反正、我一开始也以为、踩过坑）。偶尔用破折号或括号补一句吐槽——就像真人聊天那样插一嘴。一个意思一句话能说完，就不要写三句。
@@ -117,6 +121,56 @@ AI 一上来就把什么都拆成 1. 2. 3.，每条一句话。真人会把有
 
 为什么：标题党和 emoji 堆砌是公众号最廉价的 AI / 营销号味，跟「一个工程师认真分享」的气质冲突。
 
+### 8. 警惕「工整」：排比、对仗、三连、套路句式
+
+前面七条都躲过了、却仍一身 AI 味，元凶常在这。AI 的句子太均匀、太对称、太有设计感，读着像反复打磨的文案，不像人随口说出来的话。
+
+成串出现就要警觉：
+
+- **三连 / 排比**：「更稳、更聪明、更少返工」「又小又强、又便宜又好用」。
+- **「不是 X，是 Y」**：单用有力，一篇里冒五六次就是模板。
+- **自问自答**：「它长什么样？你给它一个目标……」——设问引导是 AI 最爱的节奏。
+- **段段点金句**：每段都先抑后扬、停顿一下再点睛，段段如此，本身就是范文腔。
+
+为什么：真人写东西节奏是颠簸、不对称的——有的点一句带过，有的啰嗦一大段，有的干脆忘了点题。对仗排比偶尔来一下是亮点，连着用就是病。改法：把工整的三连拆成长短不一的大白话，成对的「不是……是……」改一两处为平铺直叙，允许有的段落平淡收尾、不点题。
+
+### 9. 要有「我」的体温，要更口语
+
+最深的一层 AI 味：通篇「你」「它」「普通人」「大家」，就是没有一个**真人活过的痕迹**。内容全对、结构齐整，照样一眼假。
+
+- **上「我」亲历的具体事**：别光讲道理，讲「我上周拿它干了啥、花了多少、踩了什么坑、当时啥反应」。评论 / 感悟 / 安利类尤其——没一件「我」真做过的事垫底，判断就没分量。代笔时若不知道作者的真实经历，别编：用第一人称把他已表露的立场说出来，再提醒他补一两个真实细节。
+- **更口语**：加口水词——「说白了」「你想啊」「我跟你讲」「反正」「就那么回事」；容忍没说完的半句、临时插一嘴、偶尔的啰嗦。每句都干净利落、信息密度一样高，就是 AI。出声念，不像跟朋友唠嗑就没到位。
+
+为什么：读者追一个号，追的是这个**具体的人**——他的经历、口头禅、说话的随意劲儿。这些「正确」替代不了，也正是 AI 最难仿的。
+
+### 10. 砍冗余：能一句说完，别铺成三段
+
+最容易被忽略的一层 AI 味是「篇幅」本身。AI 求全、求稳、求完整——一个动作恨不得配上引导句、分步骤、三个例子、末了再总结一遍；真人写随笔是想到哪说到哪，说完就走，留一堆没说尽的地方。读着「顺、全、稳」，可抽掉之后没剩几句有用信息，就是它。
+
+几种典型的「撑长」：
+
+- **报幕句 / 过渡句**：段首预告自己接下来要干啥——「我把这套说清楚」「装完才是开始」「接下来才是重点」「先说结论」。真人直接说事，不报幕。
+- **凑例子、凑角度**：为显得全面，给每个角度都配一个例子（「最常用的是… / 再就是… / 还有…」）。一个点举一个例子就够，别凑齐三个。
+- **首尾复述**：开头铺垫一句、结尾再把全文拎成一句对称金句（「X 不挑机器，挑的是…」「顺序别整反」）。这跟第 2、第 8 条是连着的病。
+
+为什么：真人话糙但密，AI 话顺但稀；同一个意思，AI 铺一段，你一句话带过。**写完务必做减法**——每句问一遍「删了读者会漏信息吗」，不会就删，报幕、过渡、结尾复述金句优先砍。还要按文章类型摆对详略：观察评论的落点是一句带态度的方向，不是一份分步教程；该一笔带过的别写成操作手册。宁可短、宁可跳，别匀速铺满。
+
+### 11. 技术教程别写「正确的废话」
+
+技术教程最容易假：明明是给小白解决一个卡点，却写成百科式说明、安装路径说明、概念解释、重复验证。正确，但读者用不上。
+
+这次 `Node / Python / opencode` 教程的有效改法：
+
+- **开篇从读者看到的真实东西切入**：比如 `npm install xxx`、`npx xxx`、`pip install xxx`。别只说「很多工具依赖某环境」，那是概念；读者卡住的是命令。
+- **先检查，再安装**：小白教程不要默认让人重装。先给 `node -v`、`npm -v`、`python --version` 这类检查，符合就跳过，缺哪个装哪个。
+- **按读者路径组织，不按知识点组织**：Windows 的检查和安装放一起，macOS 的检查和安装放一起。别拆成「准备 / 安装 / 验证」后让读者来回翻。
+- **图形安装别啰嗦**：有安装包就给完整下载 URL 和关键勾选项。不要写下载到哪里、双击哪个本地路径、安装向导每一页叫什么——这些是正确废话。
+- **版本判断要让小白能做决定**：写「Node 是 `v2` 开头」「Python 是 `Python 3` 开头」，比纠结小版本更有用。只有真的影响兼容时再写精确版本。
+- **保留能改变结果的细节**：国内 npm 慢要写镜像源；Python 安装要写 `Add python.exe to PATH`；macOS 芯片影响下载链接就分开写，不影响就明说通用。
+- **用一个小验证收尾**：装完跑一个真实工具，如 `npm install -g opencode-ai`、`opencode --help`、`opencode`。别只说「环境已配置完成」。
+
+判断一句话是不是废话：删掉后，读者会不会少做一个必要动作、少避一个真实坑、少知道一个判断标准？不会，就删。
+
 ## 选模板（固定骨架放在 templates/）
 
 每篇都套一个**固定骨架**：锚点的顺序和命名都固定——这是我的栏目感和辨识度，读者一看就知道是我写的。骨架不写死在这份 SKILL 里，全部放在本 skill 的 `templates/` 目录，方便随时加新类型。
@@ -132,6 +186,7 @@ AI 一上来就把什么都拆成 1. 2. 3.，每条一句话。真人会把有
 
 - **固定的是结构，不是语气**：锚点按模板来，但每一块里面的话仍要保持人味（短句、口语、敢下判断、上真实细节），别因为有了模板就写得四平八稳。
 - **含步骤 / 命令的模板（如教程、排错），步骤区要齐到能复现**：命令完整、占位符标清、给预期结果、零跳步。这种工整**不算** AI 味——反 AI 味管的是语气和废话，不管操作的严谨。
+- **技术教程只写会影响读者动作的内容**：检查条件、下载入口、关键选项、命令、预期结果、真实坑要保留；安装路径、向导页常识、抽象背景、重复总结能删就删。
 
 > 加新类型只需往 `templates/` 丢一个新 `.md`（格式见 `templates/README.md`），不用改这份 SKILL。
 
@@ -139,7 +194,7 @@ AI 一上来就把什么都拆成 1. 2. 3.，每条一句话。真人会把有
 
 1. **判断输入形态，并想好属于哪类文章**（教程 / 感悟 / 复盘 / 排错 / 安利 / 观察…）。模糊就先问一句，别脑补。
 2. **定中心思想**：用户给了观点就以它为准；给了草稿就守住他的观点和事实。
-3. **从 `templates/` 选对应模板，读进来照骨架写**：锚点齐全、按顺序，全程对照「别露 AI 马脚」七条。含步骤的类型额外保证零跳步、命令完整、能照着复现。
+3. **从 `templates/` 选对应模板，读进来照骨架写**：锚点齐全、按顺序，全程对照「别露 AI 马脚」十条。含步骤的类型额外保证零跳步、命令完整、能照着复现。
 4. **脱敏**：把正文里所有真实敏感值（IP / token / 域名 / 真名路径等）按「脱敏」一节的规则换成假值，同一真值保持一致。
 5. **交稿前过一遍自检清单**（下方），自己改掉问题再交。
 6. **落盘**（强制）：`date +%Y%m%d%H%M` 取当前时刻，用 Write 把脱敏后的正文存成 `<年月日时分>-<标题slug>.md` 到当前工作目录；然后在对话里给出**完整绝对路径** + 「真值 → 假值」对照表。**别忘了这步——只在对话里贴正文不算交付。**
@@ -154,8 +209,14 @@ AI 一上来就把什么都拆成 1. 2. 3.，每条一句话。真人会把有
 - [ ] 有没有「首先 / 其次 / 综上 / 值得注意的是」这类结构词？删掉重写
 - [ ] 最后一段是不是在复述全文 + 升华？改成具体落点
 - [ ] 通篇有没有真实细节（命令 / 数字 / 报错 / 经历），还是全在说正确的废话？
+- [ ] （技术教程）是不是先让读者检查当前状态，再按缺失项安装？有没有把「检查 / 安装 / 验证」拆得太散，让读者来回翻？
+- [ ] （技术教程）有没有下载目录、安装向导常识、抽象背景这种正确废话？删掉后不影响操作的句子删了吗？
 - [ ] 观点是不是在和稀泥、面面俱到？敢不敢下一个判断？
-- [ ] 列表是不是太多？能改成段落的改掉
+- [ ] 列表是不是太多？能改成段落的改掉；有没有「先说X再说Y」式的伪段落列表？
+- [ ] **工整病**：排比 / 对仗 / 三连 / 「不是X是Y」/ 自问自答，是不是成串冒出来？是不是每段都在点金句？打散、改平
+- [ ] **是不是写太满**：报幕 / 过渡句、凑数的例子、首尾复述金句——能一句说完的别铺成三段？做减法砍到只剩骨头，详略对上文章类型（评论别写成分步教程）
+- [ ] **有没有「我」的体温**：通篇是不是只有「你 / 它 / 大家」，没一件「我」亲历的具体事？口语够不够，出声念像不像跟朋友唠嗑？
+- [ ] 判断有没有被「现阶段 / 理论上 / 往往 / 基本上」这类对冲词稀释软
 - [ ] 标题是不是标题党 / 震惊体？emoji 是不是冒出来了？
 - [ ] 标点是不是混入了英文逗号 / 英文括号？正文一律用中文标点（代码块内除外）
 - [ ] 出声读一遍：像不像我这个人在跟朋友说话？

package/templates/claude-global/skills//345/206/205/345/256/271/345/210/233/344/275/234/dwy-article/templates/README.md

@@ -49,5 +49,7 @@
 | 项目复盘.md | 做完一个项目 / 功能的经验总结 |
 | 踩坑排错实录.md | 一次具体 bug / 故障的排查全过程 |
 | 行业观察评论.md | 对某个 IT 新闻 / 趋势 / 热点的看法 |
+| 方案选型对比.md | 几个方案里选一个，给对比和「我选谁、为什么」 |
+| 概念科普.md | 一文搞懂某个概念 / 术语，讲清不教操作 |
 
 > 这张表是给人看的索引，不影响选模板逻辑——加新模板可以顺手补一行，忘了也不影响功能。

package/templates/claude-global/skills//345/206/205/345/256/271/345/210/233/344/275/234/dwy-article/templates//346/212/200/346/234/257/346/225/231/347/250/213.md

@@ -4,35 +4,43 @@
 
 # 技术教程模板
 
-定位：**照着零跳步就能复现**。步骤必须齐、命令必须完整。但省掉原理和术语科普——不解释「为什么」，只给「怎么做」，保持精简。
+定位：**照着零跳步就能复现**。重操作、轻原理——读者要的是「跟着做能跑通」，不是听一堂原理课。原理点到为止就行。
 
-固定锚点，按顺序：
+技术教程不要写「正确的废话」。能影响读者动作的才写：检查命令、下载入口、关键选项、必要路径、预期输出、真实坑。下载目录、安装向导常识、抽象背景、重复验证、泛泛提醒，删掉。
+
+四个固定章节（`##`），按顺序；实操下的子项（`###`）按需取舍——「真没有」才省，不是图省事，操作步骤不能省、验证别轻易省。
 
 ```
 # 标题：直接说清做什么（如「用 frps 把群晖 NAS 暴露到公网」）
 
-[开篇] 1-2 句：要解决什么问题 / 什么场景用得上。不铺垫、不讲原理。
+## 场景
+要解决什么问题 / 什么场景用得上 / 我自己为什么要搞这个。把读者代入「对，我也卡在这」。最好从读者实际看到的命令、报错、页面、现象切入，比如 `npm install xxx`、`npx xxx`、`pip install xxx`，不要只从概念切入。
+
+## 技术简介（可选，没有可不写）
+1-2 段说清这次用的主角是什么、解决什么——让读者动手前知道自己在装 / 用什么。点到为止，别展开讲原理。是开源库 / 工具就附一句仓库或官网链接，方便读者深挖。不需要背景就整节删掉。
 
-## 开始前准备
-把前置条件一次性列全，读者照着先备齐：系统 / 软件版本 / 下载链接 / 需要的账号 / 要放行的端口 / 依赖。漏一项，读者就会卡在中途。
+## 实操
+### 开始前准备（可选）
+把前置条件一次性列全，读者照着先备齐：系统 / 软件版本 / 下载链接 / 需要的账号 / 要放行的端口 / 依赖。漏一项，读者就会卡在中途。没有前置就省掉。
 
-## 步骤 1 · 这步在干嘛
-先一句说这步做什么，再给**完整、可直接复制**的命令或操作：
+### 操作步骤
+教程的核心，不能省。每步先一句说这步在干嘛，再给**完整、可直接复制**的命令或操作：
 - 命令不截断、不省略，含真实路径和文件名
-- 凡是要读者替换的，用占位符写清并标注「改成你自己的 X」（如 `serverAddr = "你的公网IP"`）
+- 凡要读者替换的，用占位符写清并标注「改成你自己的 X」（如 `serverAddr = "你的公网IP"`）
 - 给出预期结果：看到什么输出 / 什么现象，才算这步成了
-## 步骤 2 · 下一步在干嘛
-同上。**零跳步**——不能出现「配置一下 xxx」这种含糊带过，每一步都要能照着做出来。
-
-（步骤按实际数量往下排）
+- 零跳步——不许出现「配置一下 xxx」这种含糊带过，每步都要能照着做出来
+- 先检查当前状态，再安装缺失项；已有就跳过，别默认让读者重装
+- 按读者路径组织步骤：Windows 的检查和安装放一起，macOS 的检查和安装放一起；不要为了结构工整把相关动作拆散
+- 图形安装只写下载 URL 和关键选项；「打开安装包、一路同意、默认路径」这种常识一句带过
 
-## 踩坑提醒
-把坑单独成一节，每个坑写清三件事：现象（报什么错 / 什么表现）→ 原因 → 怎么解。让读者对照自己卡在哪。
+### 踩坑提醒（可选）
+有坑才写。每个坑写清三件事：现象（报什么错 / 什么表现）→ 原因 → 怎么解，让读者对照自己卡在哪。坑多、过程曲折，单独开一篇『踩坑排错实录』更合适。
 
-## 验证
-怎么确认整套通了——一条命令或一个现象。
+### 验证（可选）
+怎么确认整套通了——一条命令或一个现象。除非这事真没法验证，否则别省：读者最想知道的就是「我做对了没」。
 
-[收尾] 一句：到这就能用了。可选加一句取舍或延伸（什么场景用别的方案更省事 / 还能怎么扩展）。不升华。
+## 收尾总结
+一句：到这就能用了。可选加一句取舍或延伸（什么场景用别的方案更省事 / 还能怎么扩展）。不复述全文、不升华。
 ```
 
 省的是原理，不是步骤。一个没碰过的人照着这篇，要能真跑通。

package/templates/claude-global/skills//345/206/205/345/256/271/345/210/233/344/275/234/dwy-article/templates//346/226/271/346/241/210/351/200/211/345/236/213/345/257/271/346/257/224.md

@@ -0,0 +1,28 @@
+---
+适用场景: 在几个技术方案 / 框架 / 库之间做选择，给对比维度和「我选了哪个、为什么」的结论——决策导向，区别于单个工具安利
+---
+
+# 方案选型对比模板
+
+定位：帮读者（和未来的自己）做一个技术决策。核心是**对比维度 + 一个明确结论**，敢说「我选 X，不选 Y」。不是把几个方案各夸一遍然后「看需求」。
+
+固定锚点，按顺序：
+
+```
+# 标题：点出在选什么、结论（如「Tauri 还是 Electron，我最后选了 Tauri」）
+
+[开篇] 1-2 句：什么场景下要做这个选择 / 我当时纠结什么。
+
+## 候选方案
+在比哪几个，各一两句：它是什么、主打什么、为什么进入候选。别长篇介绍，读者只要知道选手是谁。
+
+## 怎么比的
+按**真正影响决策**的维度逐条比——包体积、上手成本、生态、性能、踩坑、维护活跃度等，挑这次最关键的几个。每个维度给具体事实 / 数字 / 亲历，别用「优秀 / 良好」这种空泛打分。
+
+## 我的选择
+明确结论：选哪个、为什么。再说清什么情况下我会选另一个——让结论可迁移，不绝对化，但也别和稀泥回到「看需求」。
+
+[收尾] 一句：落到「你是 X 场景，直接选 Y」这种能用的建议。
+```
+
+选型文章的价值全在那个敢下的结论。把维度摆清楚、把结论说死，读者才省心。

package/templates/claude-global/skills//345/206/205/345/256/271/345/210/233/344/275/234/dwy-article/templates//346/246/202/345/277/265/347/247/221/346/231/256.md

@@ -0,0 +1,28 @@
+---
+适用场景: 给同行 / 入门读者讲清一个概念或术语是什么、解决什么问题——「一文搞懂 X」，重解释、不深挖源码、不教操作
+---
+
+# 概念科普模板
+
+定位：把一个听起来唬人的概念，讲到读者「哦，原来就这」。重点是打比方、去术语。比原理深挖浅，比教程少操作——不贴源码、不给搭建步骤。
+
+固定锚点，按顺序：
+
+```
+# 标题：「一文搞懂 X」/「X 到底是个啥」
+
+[开篇] 1-2 句：这个词到处在说，但很多人其实没搞懂 / 我自己当初也绕晕过。
+
+## 它解决什么问题
+先讲没有它之前的痛点——概念都是为了解决某个问题才出现的。从痛点切入，读者才有代入感。
+
+## 它到底是什么
+用一个生活化的类比 + 一个最小例子讲清核心。别堆定义、别甩公式。读者脑子里能浮现一个画面，就成了。
+
+## 容易搞混的点
+把最常被问到 / 最容易搞混的两三个点单独澄清（比如「它和 Y 有啥区别」）。这是科普文区别于词典的地方。
+
+[收尾] 一句：用人话把它重新概括一遍 / 点出什么时候你会用到它。不上价值。
+```
+
+讲明白的标准：一个没接触过的人读完，能用自己的话跟别人解释清楚。

package/templates/claude-global/skills//345/256/211/345/205/250/dwy-sdk-spec/SKILL.md

@@ -1,18 +1,20 @@
 ---
 name: dwy-sdk-spec
-description: "SDK 接口规范与发布安全检查。检查 SDK 接口注释是否泄露后端实现（内网域名、数据库表名、Redis key、内部服务名、员工邮箱、JIRA 链接、SQL 语句），检查商业版 Python SDK 是否用 Cython 编译成 .so 隐藏源码，检查商业版 JS SDK 是否用 tsup/rollup minify + files 白名单，检查 PyPI/npm 发布产物是否含 .py 源文件 / .map source map / .env / .npmrc / tsbuildinfo / __pycache__ 等隐藏泄露文件。跨项目复用：首次进入新项目用 AskUserQuestion 问商业版还是开源版，缓存到 ~/.config/dwy-sdk-spec/projects.json，下次自动按规则检查。涉及以下任何场景必须使用此 skill：用户说「检查 SDK」「SDK 发版前检查」「SDK 注释脱敏」「SDK 接口规范」「准备发 PyPI」「准备发 npm」「商业版 SDK 打包」「Cython 编译 .so」「打包前体检」「.gitignore 漏了什么」「npm pack 看看包里有什么」「发布前安全检查」「SDK 源码泄露检查」「重设 SDK 版本类型」。"
+description: "通用 SDK 发布前安全检查——任何 SDK 对外发布（PyPI / npm / 私有源 / 直接交付，渠道不限）前都应先过这一关。查三类风险：①接口注释是否泄露后端实现（内网域名、数据库表名、Redis key、内部服务名、员工邮箱、JIRA 链接、SQL 语句）；②商业版 SDK 源码是否被保护（Python 用 Cython 编译 .so、JS 用 tsup/rollup minify + files 白名单）；③发布产物是否夹带隐藏敏感文件（.py 源码 / .map source map / .env / .npmrc / tsbuildinfo / __pycache__ 等）。跨项目复用：首次进入新项目用 AskUserQuestion 问商业版还是开源版，缓存到 ~/.config/dwy-sdk-spec/projects.json，下次自动按规则检查。涉及以下任何场景必须使用此 skill：用户说「检查 SDK」「SDK 发版前检查」「SDK 注释脱敏」「SDK 接口规范」「发布前安全检查」「SDK 源码泄露检查」「商业版 SDK 打包」「Cython 编译 .so」「打包前体检」「.gitignore 漏了什么」「npm pack 看看包里有什么」「重设 SDK 版本类型」，或准备把 SDK 发到 PyPI / npm / 任意渠道时。"
 ---
 
 # dwy-sdk-spec — SDK 接口规范与发布安全检查
 
 防三类风险：接口注释泄露后端实现 / 商业版 SDK 源码被还原 / 发布产物夹带隐藏敏感文件。
 
+**适用范围**：任何 SDK 对外发布前的通用安全闸门，与发布渠道无关——PyPI / npm / 私有源 / 直接打包交付都先过这一关。发 PyPI 只是其中一种渠道，不是触发前提。检查通过后，通用发版流程（测试 / bump / changelog / tag / publish）走 `dwy-publish`；含 C 扩展需跨平台 wheel 的走 `dwy-cibuildwheel`。
+
 ## 何时触发
 
 下列任何场景**必须**用此 skill，不要直接 `npm publish` / `python -m build` / `twine upload`：
 
 - 用户说「检查 SDK」「SDK 发版前检查」「SDK 接口规范」
-- 用户说「准备发 PyPI / npm」「发布前体检」「打包前检查」
+- 用户说「准备发布 SDK」（PyPI / npm / 私有源等任意渠道）「发布前体检」「打包前检查」
 - 用户说「SDK 注释脱敏」「SDK 源码泄露检查」「.gitignore 漏了什么」
 - 用户说「商业版 SDK 打包」「Cython 编译 .so」「npm 包混淆」
 - 用户说「npm pack 看看包里有什么」「dist 目录看一下」