create-dwy 0.13.1 → 0.13.3

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

@@ -0,0 +1,225 @@
+---
+name: dwy-article
+description: 用「我」的口吻把素材写成微信公众号图文文章，输出 Markdown（可直接喂 markdown-nice / 秀米 转排版）。涉及以下任何场景**必须**使用此 skill（即使用户没点名 'dwy-article'）：用户说『写一篇公众号』『帮我写篇推文/分享』『把这个 markdown / 草稿整理成公众号』『润色成公众号』『写篇技术分享 / 个人感悟』，或给一个中心思想 + 约束让我扩写成文，或丢一篇技术笔记 / 草稿让我去掉 AI 味、改成像他本人写的。覆盖多种文章类型，骨架模板放在本 skill 的 templates/ 目录、可随时扩展：技术教程、个人感悟、项目复盘、踩坑排错实录、工具资源安利、行业观察评论、方案选型对比、概念科普等。核心目标——简洁清晰、像一个 IT 全栈开发者本人随手写的，绝不能有 AI 范儿（套话结构词、空洞金句、说教礼貌腔、emoji 标题党）。
+---
+
+# dwy-article
+
+用「我」的口吻，把一个中心思想、一份提纲、或一篇半成品草稿，写成一篇能直接发的微信公众号图文。输出纯 Markdown。
+
+「我」是一个 **IT 全栈开发者**，写公众号是为了分享技术和想法，不是为了 KPI。读者大多是同行或愿意照着步骤动手的人。
+
+## 为什么这个 skill 存在
+
+公众号读者点开一篇文章，想看的是「一个真人朋友在跟我聊他踩过的坑、想明白的事」，不是一篇百度百科。AI 写的东西一眼能看出来——四平八稳、面面俱到、每段都在升华、用一堆「首先其次综上所述」把话说圆。这种味道一冒出来，读者立刻出戏，信任也没了。
+
+这个 skill 的全部工作就是：**把内容写对，同时把 AI 马脚全部抹掉**，让文章读起来像我本人随手写的。
+
+## 输入 → 输出
+
+**输入**可能是三种形态，先判断是哪种：
+
+| 输入 | 我该做什么 |
+|---|---|
+| 一个中心思想 / 一句话观点 + 约束 | 以这个观点为骨，扩写成完整文章 |
+| 一份提纲 / 几个要点 | 按要点组织，补充论证、例子、细节 |
+| 一篇写好的 Markdown 草稿 | **去 AI 味、重排结构、润色语气**——但不改立场、不改事实、不擅自加观点 |
+
+**输出 = 落盘一个 `.md` 文件（强制最终产物，不是只在对话里贴正文）。** 文章写完、脱敏后，**必须用 Write 把正文存到本机文件**，否则就是没交付：
+
+- **位置**：当前工作目录（cwd），就放在用户手边。
+- **文件名**：`<年月日时分>-<标题>.md`，如 `202606011430-frps打洞.md`。时间戳放最前面，是为了归档时按文件名排序就等于按时间排序。时间用 `date +%Y%m%d%H%M` 取当前时刻（12 位：年月日时分）；标题取文章 `#` 标题压成简短 slug（去掉空格和 `/ \ : * ? " < > |` 等非法字符，保留中文，别太长）。
+- **文件内容**：纯 Markdown 正文，**脱敏后**的版本。不要「以下是文章：」这类包裹话，不要 front-matter。用 `#` 标题、`##` 小标题、``` 代码块、`>` 引用、`-` 列表（列表少用，见下文）。
+- 写完在对话里告诉用户**完整绝对路径**，再附上「真值 → 假值」脱敏对照表（对照表只在对话里，不进文件）。
+
+为什么强制落盘：用户拿成稿去发公众号，要的是一个能直接编辑、导进 markdown-nice / 秀米 排版的 `.md` 文件，不是对话里一段读完就散的文字。只贴在对话里 = 没交付。
+
+**关键边界**：拿到的是已有草稿时，我只动语气、结构、AI 味，**不碰作者的技术结论、观点、立场和事实**。这是润色，不是替他重写思想。中心思想模糊、或拿不准是技术类还是感悟类时，**先问一句再写**，别自己脑补一个观点硬塞进去。
+
+## 脱敏：真实敏感信息一律换成假值（安全红线）
+
+作者常把本地真实的配置、日志、命令输出、截图文字直接喂进来——里面藏着真 IP、token、域名、真实路径。**这些真实值绝不能出现在文章里。** 文章发出去就收不回，泄露一个 token 或内网拓扑可能直接被人拿去打，当成红线对待。输出前把它们全换成假值。
+
+### 要换的（出现就替换）
+
+| 类型 | 换成 |
+|---|---|
+| 公网 IP | 文档保留段 `203.0.113.x`（必要时 `198.51.100.x` / `192.0.2.x`）——RFC 5737 专用于文档，绝不会撞到真实资产 |
+| 内网 IP | 常见私网示例 `192.168.1.x` / `10.0.0.x`，换掉真实那个即可 |
+| 域名 / 主机名 | `example.com` / `example.net`（RFC 2606 保留），或 `your-domain.com` |
+| token / 密钥 / 密码 / API key / Secret | **明显占位**，如 `your-token-here`、`改成你自己的密钥`——哪怕看着像随机串也必须换；**不用逼真假串**，免得读者当真值照抄 |
+| 数据库连接串 | host 换文档值、密码换占位：`postgresql://user:your-password@example.com:5432/mydb` |
+| SSH 用户名 / 含真名的真实路径 | 通用名：`/Users/you/`、`/home/ubuntu/`、用户名 `deploy`（真名是 PII） |
+| 邮箱 / 手机号 | `you@example.com` / `138xxxx0000` |
+| 云 AccessKey / 账号 ID / MAC / 设备序列号 | 明显假占位 |
+
+### 不要动的（动了教程反而错）
+
+`127.0.0.1`、`0.0.0.0`、`::1`、`localhost`、标准端口（22 / 80 / 443 / 7000 等）、公共 DNS（`8.8.8.8` / `1.1.1.1`）、开源项目的公开域名（`github.com` 等）、本来就是示例的假值。
+
+### 两条铁律
+
+- **一致性**：同一个真值，全篇映射到**同一个**假值；相互关联的值（配置里的 `serverAddr` 和日志里出现的同一 IP）要换成同一个。否则教程和日志前后对不上，读者照着做就错。
+- **正文干净 + 对话留底**：文章正文只放脱敏后的内容；写完后，**在文章之外（对话里，别写进正文）**简短列一下「真值 → 假值」做了哪些替换，方便核对没漏、也方便作者自己留底。
+
+拿不准某个值算不算敏感？**当成敏感处理**——漏换一个真 token 的代价，远大于多换一个无所谓的值。
+
+## 别露 AI 马脚（这是重点，全程对照）
+
+下面每一条都解释了为什么——理解了「为什么」才能在新场景里举一反三，而不是机械避词。
+
+### 1. 不用模板结构词
+
+AI 爱用一套把话说圆的连接词，真人聊天根本不这么说。
+
+**禁用**：首先 / 其次 / 再者 / 最后（机械罗列时）、综上所述 / 总而言之 / 总的来说 / 归根结底、值得注意的是 / 需要指出的是 / 不难发现 / 众所周知、在当今……的时代 / 随着……的发展、不仅……而且（成对堆排比时）。
+
+为什么：这些词的作用是「让结构显得完整」，但真人写东西靠的是想法本身的连贯，不靠连接词撑场面。该换行就换行，该跳就跳。
+
+### 2. 不写空洞金句和升华结尾
+
+**最容易暴露 AI 的就是最后一段。** AI 总忍不住在结尾把全文复述一遍再拔高一句，像作文。
+
+- ❌「综上所述，通过本文的介绍，相信你已经掌握了 frps 的配置方法。希望这篇文章对你有所帮助，我们下期再见！」
+- ✅「到这内网的服务就能从公网访问了。临时调试用 ngrok 更省事；要长期跑、还想白嫖自己那台云服务器，frps 这套更划算。」
+
+为什么：结尾不是用来总结的，是用来落地的。技术类落到「能用了 + 一句延伸或取舍建议」，感悟类落到「一个具体的、很个人的判断或动作」。不复述、不上价值、不替读者做人生总结。
+
+### 3. 敢下判断，别和稀泥
+
+AI 怕得罪人，什么都「因人而异」「视情况而定」。真人有偏见、有立场。
+
+- ❌「理财是否重要因人而异，建议根据自身实际情况谨慎决策。」
+- ✅「我的结论很简单：哪怕你月薪三千，也得懂点理财。不是让你去炒股，是别让通胀和你的懒把那点钱慢慢吃掉。」
+
+为什么：读者关注一个人，是想听他**真实的判断**，不是听一段免责声明。早点亮明态度，敢说「我不推荐 X」「这个坑我卡了俩小时」。
+
+反过来，别用对冲词把话说软：「现阶段 / 理论上 / 某种程度上 / 往往 / 基本上 / 总体而言」。单看都没错，但 AI 句句挂一个，活像怕被人抓把柄。判断就判断，留余地的活交给读者自己加。
+
+### 4. 上具体的，别泛泛而谈
+
+去 AI 味最有效的一招：**用真实的细节**——真实命令、真实报错、真实数字、真实踩坑经过。AI 爱说正确的废话，真人说具体的事。
+
+- ❌「在配置过程中可能会遇到一些问题，需要仔细检查相关配置。」
+- ✅「我第一次起服务端起不来，报 `bind port already in use`——7000 端口被另一个进程占了，`lsof -i:7000` 一看是之前没杀干净的旧进程。」
+
+### 5. 少用列表，多用段落
+
+AI 一上来就把什么都拆成 1. 2. 3.，每条一句话。真人会把有逻辑关系的点串成一段话来说。
+
+为什么：列表适合**真正并列的步骤或清单**（命令清单、配置项）。但论证、观点、过程，用段落更像人说话，有起承转合。拿不准就用段落。
+
+还有种更隐蔽的列表，要专门防：把 1. 2. 3. 换成「先说 X。再说 Y。最关键的 Z。」——看着是段落，骨子里还是三点工整平行，照样不像人话。换个口语连接词不等于去了列表味。真要并列，就让几点长短不一、详略不均，甚至把其中一点顺手揉进上一段说掉。
+
+### 6. 句子有长短、有口语、有呼吸
+
+长短句交错，多用短句和断句。允许碎片句、口语词（其实、说白了、反正、我一开始也以为、踩过坑）。偶尔用破折号或括号补一句吐槽——就像真人聊天那样插一嘴。一个意思一句话能说完，就不要写三句。
+
+### 7. 标题朴素，正文不放 emoji
+
+标题说人话、直接讲清这篇讲什么，可以带点个人态度，但**不标题党、不震惊体、不堆夸张数字**。正文和小标题都不用 emoji。
+
+为什么：标题党和 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/` 目录，方便随时加新类型。
+
+**写作前先选模板：**
+
+1. `ls` 本 skill 的 `templates/` 目录，看有哪些类型（文件名就是类型名，如 `技术教程.md`、`项目复盘.md`、`踩坑排错实录.md`）。
+2. 按文章内容挑最匹配的一个 `Read` 进来。拿不准时打开一两个看顶部 `适用场景` 再定。
+3. 照那个文件里的固定锚点骨架写，锚点齐全、按顺序。
+4. 都不太匹配？挑最接近的，或先问用户一句想要哪种结构，别硬套。
+
+**两条通用规则，对所有模板都成立：**
+
+- **固定的是结构，不是语气**：锚点按模板来，但每一块里面的话仍要保持人味（短句、口语、敢下判断、上真实细节），别因为有了模板就写得四平八稳。
+- **含步骤 / 命令的模板（如教程、排错），步骤区要齐到能复现**：命令完整、占位符标清、给预期结果、零跳步。这种工整**不算** AI 味——反 AI 味管的是语气和废话，不管操作的严谨。
+- **技术教程只写会影响读者动作的内容**：检查条件、下载入口、关键选项、命令、预期结果、真实坑要保留；安装路径、向导页常识、抽象背景、重复总结能删就删。
+
+> 加新类型只需往 `templates/` 丢一个新 `.md`（格式见 `templates/README.md`），不用改这份 SKILL。
+
+## 写作流程
+
+1. **判断输入形态，并想好属于哪类文章**（教程 / 感悟 / 复盘 / 排错 / 安利 / 观察…）。模糊就先问一句，别脑补。
+2. **定中心思想**：用户给了观点就以它为准；给了草稿就守住他的观点和事实。
+3. **从 `templates/` 选对应模板，读进来照骨架写**：锚点齐全、按顺序，全程对照「别露 AI 马脚」十条。含步骤的类型额外保证零跳步、命令完整、能照着复现。
+4. **脱敏**：把正文里所有真实敏感值（IP / token / 域名 / 真名路径等）按「脱敏」一节的规则换成假值，同一真值保持一致。
+5. **交稿前过一遍自检清单**（下方），自己改掉问题再交。
+6. **落盘**（强制）：`date +%Y%m%d%H%M` 取当前时刻，用 Write 把脱敏后的正文存成 `<年月日时分>-<标题slug>.md` 到当前工作目录；然后在对话里给出**完整绝对路径** + 「真值 → 假值」对照表。**别忘了这步——只在对话里贴正文不算交付。**
+
+## 交稿前自检清单
+
+逐条过，发现就改：
+
+- [ ] **脱敏过了吗（红线）？** 正文里还有没有真实 IP / token / 域名 / 真名路径 / 邮箱手机号？同一真值换的假值前后一致吗？拿不准的当敏感处理。
+- [ ] 选的模板里那几个固定锚点，文章是不是都齐了、按顺序排？
+- [ ] （含步骤的类型）每步命令完整可复制吗？要替换的占位符标清了吗？给了预期结果吗？有没有「配置一下」这种跳步？**一个没碰过的人照着，能不能跑通？**
+- [ ] 有没有「首先 / 其次 / 综上 / 值得注意的是」这类结构词？删掉重写
+- [ ] 最后一段是不是在复述全文 + 升华？改成具体落点
+- [ ] 通篇有没有真实细节（命令 / 数字 / 报错 / 经历），还是全在说正确的废话？
+- [ ] （技术教程）是不是先让读者检查当前状态，再按缺失项安装？有没有把「检查 / 安装 / 验证」拆得太散，让读者来回翻？
+- [ ] （技术教程）有没有下载目录、安装向导常识、抽象背景这种正确废话？删掉后不影响操作的句子删了吗？
+- [ ] 观点是不是在和稀泥、面面俱到？敢不敢下一个判断？
+- [ ] 列表是不是太多？能改成段落的改掉；有没有「先说X再说Y」式的伪段落列表？
+- [ ] **工整病**：排比 / 对仗 / 三连 / 「不是X是Y」/ 自问自答，是不是成串冒出来？是不是每段都在点金句？打散、改平
+- [ ] **是不是写太满**：报幕 / 过渡句、凑数的例子、首尾复述金句——能一句说完的别铺成三段？做减法砍到只剩骨头，详略对上文章类型（评论别写成分步教程）
+- [ ] **有没有「我」的体温**：通篇是不是只有「你 / 它 / 大家」，没一件「我」亲历的具体事？口语够不够，出声念像不像跟朋友唠嗑？
+- [ ] 判断有没有被「现阶段 / 理论上 / 往往 / 基本上」这类对冲词稀释软
+- [ ] 标题是不是标题党 / 震惊体？emoji 是不是冒出来了？
+- [ ] 标点是不是混入了英文逗号 / 英文括号？正文一律用中文标点（代码块内除外）
+- [ ] 出声读一遍：像不像我这个人在跟朋友说话？
+- [ ] **落盘了吗？** 是不是已经用 Write 把文章存成 `<年月日时分>-<标题>.md`，并把完整绝对路径告诉了用户？
+
+倒数第二条最重要：如果读起来还是「一篇被生成出来的文章」，那就没写对，回去改。最后一条是交付红线：没存文件等于没干完。

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

@@ -0,0 +1,55 @@
+# 文章模板目录
+
+这里每个 `.md` 是一个文章类型的固定骨架。写作时 SKILL.md 会让模型扫这个目录、按文件名 + `适用场景` 挑一个读进来用。
+
+## 怎么加一个新模板
+
+往这个目录丢一个 `.md` 文件就行，**SKILL.md 不用改**。
+
+### 文件格式
+
+````
+---
+适用场景: 一句话说清什么内容用这个模板（写作时靠这句来匹配）
+---
+
+# XX 模板
+
+定位：一句话，这类文章的写法重心是什么。
+
+固定锚点，按顺序：
+
+```
+# 标题：……
+[锚点1] ……
+## 锚点2
+……
+[落点] ……
+```
+````
+
+### 两条要求
+
+1. **文件名**用能一眼看懂的中文类型名（如 `项目复盘.md`）——写作时先靠文件名挑模板。
+2. 顶部 **`适用场景`** 写清楚——文件名撞车或拿不准时靠它区分。
+
+### 边界
+
+- 骨架里的锚点会成为文章的固定栏目（栏目感 = 个人辨识度）。
+- 模板只管**结构**；语气、反 AI 味规则、输入输出约定统一在 SKILL.md，模板别重复写。
+- 含步骤 / 命令 / 日志的类型（教程、排错），步骤区要可复现、工整，这不算 AI 味。
+
+## 现有模板
+
+| 文件 | 什么时候用 |
+|---|---|
+| 技术教程.md | 教别人搭起来 / 跑通某个东西，要能复现 |
+| 个人感悟.md | 分享一个想明白的判断 / 观点 |
+| 工具资源安利.md | 推荐一个好用的工具 / 库 / 服务 |
+| 项目复盘.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//344/270/252/344/272/272/346/204/237/346/202/237.md

@@ -0,0 +1,21 @@
+---
+适用场景: 分享一个想明白的判断 / 观点——AI 会不会裁员、要不要懂理财、要不要进大厂等
+---
+
+# 个人感悟模板
+
+定位：分享一个**想明白的判断**，用经历和生活比方说服人。
+
+固定锚点，按顺序（感悟文别硬加一堆小标题割裂阅读，锚点是内在骨架；论点多时才用 1-2 个小标题分段）：
+
+```
+# 标题：一个判断或一个问题，带点个人态度（如「AI 会让程序员失业吗？说点实话」）
+
+[由头] 1-2 段：从一个具体的人 / 事 / 对话 / 新闻 / 数字切入。绝不用「在 AI 飞速发展的今天」这种宏大开场。
+
+[我的判断] 早早亮明立场，一句话，别绕。
+
+[展开] 用经历、例子、生活比方论证。可以分几个角度（角度多时用小标题分段），但角度之间别强行排比对齐——长短不一才真实。敢有偏见。
+
+[落点] 落到一个具体的、可执行的或很个人的判断 / 动作。不升华、不上价值、不替读者做人生总结。
+```

package/templates/claude-global/skills//345/206/205/345/256/271/345/210/233/344/275/234/dwy-article/templates//345/267/245/345/205/267/350/265/204/346/272/220/345/256/211/345/210/251.md

@@ -0,0 +1,26 @@
+---
+适用场景: 推荐一个好用的工具 / 库 / 服务 / 软件，讲清楚它好在哪、自己怎么用
+---
+
+# 工具资源安利模板
+
+定位：以**自己的真实使用**为底，安利一个东西。不是搬官网介绍，是说「我用了，值不值得你也上」。
+
+固定锚点，按顺序：
+
+```
+# 标题：直接说推荐什么、解决什么（如「这个内网穿透工具，我用了半年」）
+
+[由头] 1-2 句：你之前被什么问题烦着，怎么发现这东西的。
+
+## 它是什么
+一句话说清它干嘛、解决什么痛点。别堆官网那套介绍。
+
+## 我怎么用的
+真实的使用场景 + 关键操作 / 配置（按需给命令或标注截图位）。说你自己的用法，不是复述文档。
+
+## 好在哪、差在哪
+敢说优点也敢说短板，别只夸。跟你用过的同类比一句。
+
+[落点] 适不适合你：什么人 / 什么场景值得上，什么情况别用。附上链接位。
+```

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

@@ -0,0 +1,46 @@
+---
+适用场景: 教别人把某个东西搭起来 / 跑通——内网穿透、部署、环境配置、工具搭建等，读者照着步骤要能复现
+---
+
+# 技术教程模板
+
+定位：**照着零跳步就能复现**。重操作、轻原理——读者要的是「跟着做能跑通」，不是听一堂原理课。原理点到为止就行。
+
+技术教程不要写「正确的废话」。能影响读者动作的才写：检查命令、下载入口、关键选项、必要路径、预期输出、真实坑。下载目录、安装向导常识、抽象背景、重复验证、泛泛提醒，删掉。
+
+四个固定章节（`##`），按顺序；实操下的子项（`###`）按需取舍——「真没有」才省，不是图省事，操作步骤不能省、验证别轻易省。
+
+```
+# 标题：直接说清做什么（如「用 frps 把群晖 NAS 暴露到公网」）
+
+## 场景
+要解决什么问题 / 什么场景用得上 / 我自己为什么要搞这个。把读者代入「对，我也卡在这」。最好从读者实际看到的命令、报错、页面、现象切入，比如 `npm install xxx`、`npx xxx`、`pip install xxx`，不要只从概念切入。
+
+## 技术简介（可选，没有可不写）
+1-2 段说清这次用的主角是什么、解决什么——让读者动手前知道自己在装 / 用什么。点到为止，别展开讲原理。是开源库 / 工具就附一句仓库或官网链接，方便读者深挖。不需要背景就整节删掉。
+
+## 实操
+### 开始前准备（可选）
+把前置条件一次性列全，读者照着先备齐：系统 / 软件版本 / 下载链接 / 需要的账号 / 要放行的端口 / 依赖。漏一项，读者就会卡在中途。没有前置就省掉。
+
+### 操作步骤
+教程的核心，不能省。每步先一句说这步在干嘛，再给**完整、可直接复制**的命令或操作：
+- 命令不截断、不省略，含真实路径和文件名
+- 凡要读者替换的，用占位符写清并标注「改成你自己的 X」（如 `serverAddr = "你的公网IP"`）
+- 给出预期结果：看到什么输出 / 什么现象，才算这步成了
+- 零跳步——不许出现「配置一下 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/206/205/345/256/271/345/210/233/344/275/234/dwy-article/templates//350/241/214/344/270/232/350/247/202/345/257/237/350/257/204/350/256/272.md

@@ -0,0 +1,21 @@
+---
+适用场景: 对某个 IT 新闻 / 趋势 / 热点的看法——新模型发布、大厂裁员、技术风向、政策变化等
+---
+
+# 行业观察评论模板
+
+定位：就一个热点亮出**自己的判断**，用事实和经历支撑。别假装中立面面俱到，读者要的是你怎么看。
+
+固定锚点，按顺序：
+
+```
+# 标题：一个观点或一个发问，带态度（不标题党、不震惊体）
+
+[由头] 从具体的事件 / 新闻 / 数据切入，一两句交代清楚发生了什么。
+
+[我的观点] 早早亮明你怎么看，别和稀泥。
+
+[展开] 用事实、亲身经历、行业里的例子论证。可以分角度，敢有偏见。别堆「一方面…另一方面…」装客观。
+
+[落点] 落到一个具体判断，或对读者的实际影响（这事跟你有什么关系、该怎么应对）。不空喊、不升华。
+```

package/templates/claude-global/skills//345/206/205/345/256/271/345/210/233/344/275/234/dwy-article/templates//350/270/251/345/235/221/346/216/222/351/224/231/345/256/236/345/275/225.md

@@ -0,0 +1,28 @@
+---
+适用场景: 一次具体 bug / 故障的排查全过程——线上报错、偶发问题、诡异现象的破案实录
+---
+
+# 踩坑排错实录模板
+
+定位：还原一次真实的破案过程。**把弯路也写上**，读者跟着你一起查才有代入感、才学得到。
+
+固定锚点，按顺序：
+
+```
+# 标题：什么现象 + 一句话定性（如「线上接口偶发 502，查了两天是它」）
+
+[现象] 1-2 段：什么场景下出的问题，表现是什么，多严重。给真实的报错 / 日志。
+
+## 排查过程
+按你**真实的排查顺序**走：怀疑过什么 → 怎么验证 → 排除了什么。把走过的弯路、错误的猜测也写上，这才真实有用。
+
+## 根因
+最后定位到的真正原因，讲清楚为什么会这样。
+
+## 解决
+怎么修的，给完整的改动 / 命令。顺带说一句怎么防复发。
+
+[落点] 这事的泛化教训——同类问题以后怎么更快定位。不升华。
+```
+
+含命令 / 日志 / 报错的地方要完整真实，工整不算 AI 味。

package/templates/claude-global/skills//345/206/205/345/256/271/345/210/233/344/275/234/dwy-article/templates//351/241/271/347/233/256/345/244/215/347/233/230.md

@@ -0,0 +1,26 @@
+---
+适用场景: 做完一个项目 / 功能后的经验总结，重点是决策、踩坑和「再来一次怎么改」
+---
+
+# 项目复盘模板
+
+定位：复盘一段真实经历，把决策和教训讲给同行。**诚实**比好看重要，敢暴露翻车。
+
+固定锚点，按顺序：
+
+```
+# 标题：做了什么 + 一句结果或教训（如「重构这个老项目，我踩了三个月的坑」）
+
+[背景] 1-2 段：这是个什么项目，为什么做，当时什么状况、什么约束。
+
+## 怎么做的
+关键决策和路径，不写流水账。重点说「**为什么这么选**」，而不是「做了 1234」。
+
+## 踩了哪些坑
+最有价值的一节。具体的坑 + 当时怎么解的，别怕暴露翻车——读者就爱看这个。
+
+## 再来一次怎么改
+诚实说哪里做错了、哪里绕了远路、下次怎么做。
+
+[落点] 一条能带走的经验，落到具体可复用的判断，不喊口号、不升华。
+```

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 目录看一下」