@1aboveio/skills 0.0.0-stage → 1.0.0

package/skills/content/mermaid/release-check.mjs

@@ -0,0 +1,93 @@
+#!/usr/bin/env node
+import { spawnSync } from 'node:child_process';
+import { mkdirSync, readFileSync, writeFileSync } from 'node:fs';
+import { homedir } from 'node:os';
+import { dirname, join } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const DAY_MS = 24 * 60 * 60 * 1000;
+const WEEK_MS = 7 * DAY_MS;
+const here = dirname(fileURLToPath(import.meta.url));
+
+function readJson(path, fallback = {}) {
+  try { return JSON.parse(readFileSync(path, 'utf8')); } catch { return fallback; }
+}
+
+function frontmatterValue(text, key) {
+  const frontmatter = /^---\n([\s\S]*?)\n---/.exec(text)?.[1] ?? '';
+  const match = new RegExp('^' + key + ':\\s*([^\\n]+)$', 'm').exec(frontmatter);
+  return match?.[1].trim().replace(/^['"]|['"]$/g, '') ?? null;
+}
+
+function repositoryOf(source) {
+  const value = String(source ?? '').trim();
+  const match = /^(?:git@github\.com:|https:\/\/github\.com\/)?([A-Za-z0-9_.-]+\/[A-Za-z0-9_.-]+?)(?:\.git)?$/.exec(value);
+  return match?.[1] ?? null;
+}
+
+function stableVersion(value) {
+  const match = /^v?(\d+)\.(\d+)\.(\d+)$/.exec(String(value ?? '').trim());
+  return match ? match.slice(1).map(Number) : null;
+}
+
+function newer(left, right) {
+  for (let index = 0; index < 3; index += 1) {
+    if (left[index] !== right[index]) return left[index] > right[index];
+  }
+  return false;
+}
+
+function writeCache(path, value) {
+  try {
+    mkdirSync(dirname(path), { recursive: true });
+    writeFileSync(path, JSON.stringify(value));
+  } catch { /* A read-only cache must not block skill use. */ }
+}
+
+function main(now = Date.now()) {
+  if (process.env.ONEABOVEIO_NO_UPDATE_CHECK) return;
+  const skill = readFileSync(join(here, 'SKILL.md'), 'utf8');
+  const name = frontmatterValue(skill, 'name');
+  const localVersion = stableVersion(frontmatterValue(skill, 'release-version'));
+  if (!name || !localVersion) return;
+
+  const lock = readJson(join(process.env.HOME || homedir(), '.agents', '.skill-lock.json'));
+  const entry = lock.skills?.[name];
+  const repository = repositoryOf(entry?.sourceUrl || entry?.source);
+  if (!repository) return;
+
+  const cacheRoot = process.env.XDG_CACHE_HOME || join(process.env.HOME || homedir(), '.cache');
+  const cachePath = join(cacheRoot, '1aboveio-skills', 'release-check.json');
+  const all = readJson(cachePath);
+  const cache = all[repository] && typeof all[repository] === 'object' ? all[repository] : {};
+
+  if (!cache.lastCheck || now - cache.lastCheck >= DAY_MS) {
+    const result = spawnSync('gh', ['api', 'repos/' + repository + '/releases/latest', '--jq', '.tag_name'], {
+      encoding: 'utf8',
+      stdio: ['ignore', 'pipe', 'ignore'],
+      timeout: 1500,
+    });
+    cache.lastCheck = now;
+    if (result.status === 0 && stableVersion(result.stdout)) cache.latestTag = result.stdout.trim();
+    else delete cache.latestTag;
+    all[repository] = cache;
+    writeCache(cachePath, all);
+  }
+
+  const latestVersion = stableVersion(cache.latestTag);
+  if (!latestVersion || !newer(latestVersion, localVersion)) return;
+  if (cache.notifiedTag === cache.latestTag && cache.notifiedAt && now - cache.notifiedAt < WEEK_MS) return;
+
+  cache.notifiedTag = cache.latestTag;
+  cache.notifiedAt = now;
+  all[repository] = cache;
+  writeCache(cachePath, all);
+  const command = `npx skills@1.5.23 add '${repository}#${cache.latestTag}' --global --agent universal claude-code --skill ${name} --yes`;
+  process.stdout.write(
+    `UPDATE_AVAILABLE: A newer 1AboveIO skills release (${cache.latestTag}) is available; this skill is `
+      + `v${localVersion.join('.')}. Ask once whether to refresh ${name}. On approval run \`${command}\`. `
+      + 'The refreshed instructions apply next session. Either way, continue the current task and do not ask again this session.\n',
+  );
+}
+
+try { main(); } catch { /* Update checks are advisory and always fail silent. */ }

package/skills/content/wechat-article-writer/LICENSE

@@ -0,0 +1,3 @@
+MIT License
+
+Copyright (c) 2026 1AboveIO

package/skills/content/wechat-article-writer/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: wechat-article-writer
+description: "Write WeChat 公众号 articles in Chinese content styles — 踩坑型 (pitfall-story), 实操型 (how-to), 对比型 (comparison), 观察型 (industry insight) — in the account's house style from the nearest WRITING.md. Use for drafting from scratch, rewriting a draft, adapting source material into a publishable article, or picking the right style. NOT for business or technical documents (write-doc)."
+release-version: 0.36.0
+---
+**Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
+# WeChat Article Writer (公众号写作)
+
+Write a WeChat public account article in one of four styles, in the account's own voice.
+
+| Need | Read |
+| --- | --- |
+| Which style fits the topic | [style-selector](references/style-selector.md) |
+| Title formulas, language, 金句, checklist | [writing-rules](references/writing-rules.md) — always, before drafting |
+| The four styles | [templates/](templates/) |
+
+## Principles
+
+**Cases and numbers come only from the author's material.** Example: the author gives no case
+count → write「我们复盘了这类问题」, not「我们拆了 50 个案例」. A missing fact the article needs is
+marked `【待确认：…】`; tell the author in the delivery note.
+
+**Template examples show form, never facts.** Example titles, figures and brand names in a
+template or in `writing-rules.md` are not about this article.
+
+**Leave the house style alone.** Never edit WRITING.md or a project template unless the author
+asks in this request.
+
+## Step 0: Find the house style
+
+1. Look for `WRITING.md` in the article's folder, then each parent folder up to the repository root
+   (the nearest folder with `.git`; no repository: keep going up). Never use one in the home
+   directory or above it. The first one
+   found applies.
+2. Apply all of it, including the brand name and CTA, except rules that describe other kinds of
+   documents (reports, specs, policies).
+3. Precedence: the author's request → the project style template → WRITING.md →
+   [writing-rules](references/writing-rules.md) → the bundled style template.
+4. No WRITING.md: use [writing-rules](references/writing-rules.md) and a neutral CTA (invite comments
+   or a follow). Say so in the delivery note.
+
+The full lookup and precedence rules are the `house-style` skill's
+`references/rules.md`, when that skill is installed.
+
+## Step 1: Choose a style
+
+Recommend a style from the topic, or use the one the author names. Unsure → read
+[style-selector](references/style-selector.md).
+
+| Style | 适用场景 | Template |
+|-------|---------|---------|
+| **踩坑型** | 经验教训、避坑指南、工具使用 | `wechat-pitfall.md` |
+| **实操型** | 操作教程、配置指南、步骤分解 | `wechat-howto.md` |
+| **对比型** | 概念澄清、产品对比、方案选型 | `wechat-comparison.md` |
+| **观察型** | 行业动态、趋势分析、深度观点 | `wechat-insight.md` |
+
+Read the template from the project's `writing/templates/` beside the WRITING.md that applies; if it
+has none of that name, read the bundled one in [templates/](templates/). A project file replaces
+the bundled one; never merge the two.
+
+## Step 2: Gather inputs
+
+Read the author's material before asking. Ask once, in one message, only for what the template
+marks `Material: ask once` and the material does not give, each question with your recommended
+answer:
+
+1. **Topic**, and the one thing the reader should take away.
+2. **Source material**: the author's experience, cases, data, links.
+3. **Length**: WRITING.md's, else default 800–1200 字 (观察型 up to 1500).
+
+## Step 3: Draft
+
+Follow the template's Reasoning and Sections. Apply these defaults in every style, unless WRITING.md
+or the project template says otherwise (the account's own length, 金句 rhythm or title style wins):
+
+- **Title**: a formula from [writing-rules](references/writing-rules.md) with a number from the
+  material or an emotional hook.
+- **Opening (前 200 字)**: first-person narrative or a client case; the reader must feel "this is
+  about me" before the body. Never open with a definition or background.
+- **金句 every 300–500 字**: at least one standalone quotable sentence per section, at paragraph
+  start or end; the last paragraph ends with one.
+- **Something to act on**: a checklist, numbered steps or a decision framework before the end.
+- **CTA**: from WRITING.md; otherwise neutral.
+- **Typography**: when `house-style` is installed, apply the 标点与留白 section of its
+  `references/style-zh.md`. Its restrained technical voice does not apply to articles.
+
+## Step 4: Check and deliver
+
+Run the template's `Done when` and the 发布前自查清单 in
+[writing-rules](references/writing-rules.md). Deliver the article with a note: the WRITING.md and
+template used (or "none: defaults"), each `【待确认】` item, and any number or case you need the
+author to confirm.

package/skills/content/wechat-article-writer/references/style-selector.md

@@ -0,0 +1,133 @@
+# 风格选择指南
+
+## 为什么风格选择很重要
+
+不同风格适配不同的内容目标和传播场景。选错风格会导致：
+- 内容失去传播动力（该踩坑的却写成了行业观察）
+- 读者流失（该给步骤的却只讲道理）
+- 品牌调性不一致（该严肃权威的却过于口语化）
+
+---
+
+## 四种风格的适用背景
+
+### 踩坑型（「真人踩坑 + 工具化输出」）
+
+**核心机制：** 我的痛苦 → 你的解决方案
+
+**最适合的场景：**
+- 你或你的团队/客户**真实踩过这个坑**，有一手经验
+- 目标读者在**同一个痛点上普遍焦虑**（封号、踩坑、选错方案）
+- 问题有**可操作的解决路径**（不是无解的行业困境）
+- 你想**快速建立权威感**（「踩了3次才搞懂」比「专家告诉你」更有说服力）
+
+**不适合的场景：**
+- 没有真实案例支撑，纯观点输出
+- 问题太宏观，无法给出具体步骤
+- 读者已经很了解这个坑，不需要被教育
+
+**在 B2B 场景的变体：**
+- 「我/我们」可以替换为「客户案例」：「某跨境商家踩了这个坑，我们帮他排查了48小时」
+- 情绪可以比 C 端克制：「非常头疼」代替「心态崩了」
+- 工具化输出必须更精确：步骤/CheckList/决策树，不能只是建议
+
+**典型标题信号词：** 踩坑、教训、终于搞懂了、血泪总结、才发现
+
+---
+
+### 实操型（「步骤教程 + 保姆级指南」）
+
+**核心机制：** 照着做就行
+
+**最适合的场景：**
+- 读者有**明确的执行意图**（想做某件事，但不知道怎么做）
+- 操作过程有**标准流程可遵循**（不是因情况而异的判断题）
+- 受众是**执行层**（需要操作手册，不需要战略判断）
+- 内容更新频率低，**不容易过时**（避免下个月就失效的教程）
+
+**不适合的场景：**
+- 问题没有统一答案，高度依赖具体情况
+- 读者是决策层，他们不需要自己操作
+- 内容更新太快，步骤容易过时
+
+**在 B2B 场景的变体：**
+- 读者可能是技术人员（接入文档）或业务人员（配置后台）
+- 技术读者：代码/命令行步骤要精确
+- 业务读者：截图 + 标注 + 常见问题 FAQ
+
+**典型标题信号词：** 手把手、保姆级、完整指南、从0到1、附教程
+
+---
+
+### 对比型（「概念澄清 + 选型决策」）
+
+**核心机制：** 帮读者做决定，省去自己研究的时间
+
+**最适合的场景：**
+- 读者对**两个容易混淆的概念/方案**感到困惑
+- 行业内**存在普遍的认知误区**需要纠正
+- 读者正处于**选型决策阶段**，需要判断框架
+- 你有**比较维度的第一手数据**（不是泛泛而谈的优缺点）
+
+**不适合的场景：**
+- 只有一个合理选择，没有真正的对比价值
+- 比较维度太多，读者看完更迷糊
+- 属于个人偏好，无法给出客观判断
+
+**在 B2B 场景的变体：**
+- 对比要有明确的「适用条件」：什么规模/场景/预算下选 A，什么条件下选 B
+- 可以做成「决策矩阵」或「判断树」，比简单对比更有价值
+- 引用真实数据支撑（成本差异、性能数据、故障率等）
+
+**典型标题信号词：** vs、区别、哪个好、分不清、对比、选型
+
+---
+
+### 观察型（「行业洞察 + 深度观点」）
+
+**核心机制：** 我看到了一个别人没注意到的趋势/问题
+
+**最适合的场景：**
+- 行业**正在发生结构性变化**，读者需要提前感知
+- 你有**独特的数据来源或视角**（非公开的行业洞察）
+- 目标是**建立行业权威感**，培养高质量长期读者
+- 内容**有长尾价值**，不是蹭热点
+
+**不适合的场景：**
+- 只是整合公开信息，没有新的判断
+- 没有明确立场，全篇「可能」「也许」
+- 读者需要即时操作指导，观察型无法满足
+
+**在 B2B 场景的变体：**
+- 可以稍长（1200-1500字），B2B 读者接受深度内容
+- 必须有明确观点，不能只做信息汇总
+- 适合搭配数据图表，增强说服力
+
+**典型标题信号词：** 趋势、观察、为什么、背后、意味着什么、正在发生
+
+---
+
+## 快速选型决策树
+
+```
+有真实案例/一手踩坑经验？
+├── 是 → 有可操作的解决步骤？
+│         ├── 是 → 踩坑型 ✅
+│         └── 否 → 观察型（案例作为佐证）
+└── 否 → 读者有执行意图（想做某件事）？
+          ├── 是 → 实操型 ✅
+          └── 否 → 两个概念/方案需要厘清？
+                    ├── 是 → 对比型 ✅
+                    └── 否 → 观察型 ✅
+```
+
+---
+
+## 混搭原则
+
+单篇文章可以以一种风格为主，融合另一种风格的元素：
+- **踩坑型 + 实操** — 最常见组合：踩坑开场 → 步骤化解决方案
+- **对比型 + 观察** — 概念澄清之后，加一节「行业趋势判断」
+- **观察型 + 实操** — 趋势分析之后，给读者「现在可以做的3件事」
+
+避免：踩坑型 + 观察型混搭（叙事钩子和宏观视角会互相稀释）

package/skills/content/wechat-article-writer/references/writing-rules.md

@@ -0,0 +1,152 @@
+# 公众号写作通用规则
+
+## 目录
+- [目标读者定位](#目标读者定位)
+- [标题公式](#标题公式)
+- [语言规范](#语言规范)
+- [金句设计](#金句设计)
+- [视觉设计适配](#视觉设计适配)
+- [C 端 → B2B 改写参考](#改写参考)
+- [结构共性](#结构共性)
+- [发布前自查清单](#发布前自查清单)
+
+---
+
+## 目标读者定位
+
+项目的 WRITING.md（Readers and documents、Voice）优先于本节。没有 WRITING.md 时，根据品牌受众调整。以 **B2B 专业服务行业（如金融科技、支付、SaaS）** 为例：
+- 有业务背景，但不一定是技术开发者
+- 关心「怎么选」「会不会踩坑」「行业在发生什么」
+- 阅读场景：碎片时间刷手机、午休；核心诉求：**省时间、少踩坑、用得上**
+- B2B 读者更在意**权威性和数据背书**，比 C 端用户情绪更克制
+
+如果是 C 端品牌（消费、生活方式、教育），情绪表达可以更活泼，CTA 可以是「立即体验」「关注账号」。
+
+---
+
+## 标题公式
+
+示例里的数字（50 个案例、90%）只示范形式。写作时，标题和正文里的每个数字都必须来自作者素材；没有就用不带数字的公式。
+
+### 公式 A：踩坑-数字-顿悟
+```
+[情绪事件] + [数字] + [顿悟感]
+```
+示例：「被封了3次之后，我终于搞懂了 Claude 的封号逻辑」
+B2B 改写版：「踩了50个支付坑后，我们终于搞懂了网关选型的逻辑」
+
+### 公式 B：问题-解决方案
+```
+[问题定位] + [权威背书] + [用户画像]
+```
+示例：「Claude 封号避坑指南：十几个真实案例总结的国内用户生存法则」
+B2B 改写版：「支付网关怎么选？我们拆了50个真实案例，给出一套可落地的标准」
+
+### 公式 C：数字-痛点
+```
+[数字冲击] + [痛点/悬念]
+```
+示例：「99%的电商都在这三个地方翻车」
+B2B 改写版：「90%的企业在配置风控规则时犯的同一个错误」
+
+### 公式 D：概念对比
+```
+[概念A] vs [概念B]：[X%] 的人分不清
+```
+示例：「支付失败 vs 交易拒付：90%的人都分不清这两个概念」
+
+---
+
+## 语言规范
+
+### 人称使用
+- 叙事/经历 → 「我」：「我们遇到过这样一个案例」
+- 指导/建议 → 「你」：「你应该先检查这一项」
+- 客观分析 → 「我们」：「我们发现，这类问题有三个共性」
+- 不要全篇只用一种人称，保持「我们讲 → 你学」的节奏
+
+### 句子节奏
+- 平均句子长度：12–20字（手机阅读友好）
+- 每段 2–4 句，不超过4句
+- 每 300–500 字安排一个金句
+
+### 禁止表达
+- ❌ 首先、其次、最后（太正式）
+- ❌ 由此可见、综上所述（太书面）
+- ❌ 必须、绝对、一定（语气过硬）
+- ❌ 纯技术术语堆砌不解释
+- ❌ AI 腔：「当然」「值得注意的是」「不难看出」
+
+---
+
+## 金句设计
+
+好金句的三个条件：
+1. 不需要上下文就能理解（截图传播）
+2. 有情绪或观点，不是陈述事实
+3. 50字以内，3秒读完
+
+### 四种金句类型
+**类比型**：「这相当于你一边戴着假发，一边却把身份证递给官方看」
+**反常识型**：「你以为最安全的做法，恰恰是最容易被风控识别的」
+**数字冲击型**：「我们审查过的50个失败案例，有37个栽在同一个地方」
+**自嘲/幽默型**（慎用于 B2B 场景）：「申诉基本无用，但我还是让 AI 写了封言辞恳切的英文信」
+
+### 金句位置
+- 放在段首或段尾，不要埋在段落中间
+- 文章结尾必须以金句收尾
+- 副标题本身也可以是金句
+
+---
+
+## 视觉设计适配
+
+### 文字层面
+- **小标题 ≤10 字** — 一眼扫过能理解
+- **加粗关键词** — 每段 1–2 个，不要整段加粗
+- **数字突出** — 「3次」「7个问题」「90%」这类数字本身是视觉锚点
+
+### 金句卡片（朋友圈截图友好）
+- 金句单独成卡，背景色与正文区隔
+- 留白充足（不是越满越好）
+- 品牌名要够大（缩略图里要看得见）
+
+---
+
+## 改写参考
+
+**原版（C 端风格）：**
+> 「选错支付网关？99%的人都踩过这3个坑，心态崩了！」
+
+**B2B 改写版：**
+> 「选错支付网关？90%的企业都在这三个地方翻车。我们拆了50个真实案例，找到了根本原因。」
+
+改写要点：
+- 去掉情绪夸张（「心态崩了」→ 去掉）
+- 加数据背书（只用素材中真实的数据，例如作者提供的案例数）
+- 语气平实、有说服力
+
+**如果是 C 端品牌，反向操作：** 加情绪词、减数据堆砌、CTA 更直接。
+
+---
+
+## 结构共性
+
+所有风格文章共同要求：
+1. **开头 200 字**：建立情感连接或紧迫感，不要直接进正文
+2. **每节有「怎么做」**：不只讲「是什么」，给读者行动路径
+3. **CheckList 或步骤**：至少一个可收藏的结构化内容
+4. **结尾 CTA**：根据品牌类型选择合适的行动召唤
+
+---
+
+## 发布前自查清单
+
+- [ ] 标题有数字或情绪钩子吗？
+- [ ] 开头 200 字有代入感吗？
+- [ ] 每节有「怎么做」而不是只有「是什么」吗？
+- [ ] 有金句吗？放在显眼位置了吗？
+- [ ] 文章结尾有明确行动召唤吗？
+- [ ] 有没有超过 4 句没分段的长段落？
+- [ ] 有没有生硬的技术术语没解释？
+- [ ] 截图发朋友圈，3 秒内能看懂核心观点吗？

package/skills/content/wechat-article-writer/release-check.mjs

@@ -0,0 +1,93 @@
+#!/usr/bin/env node
+import { spawnSync } from 'node:child_process';
+import { mkdirSync, readFileSync, writeFileSync } from 'node:fs';
+import { homedir } from 'node:os';
+import { dirname, join } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const DAY_MS = 24 * 60 * 60 * 1000;
+const WEEK_MS = 7 * DAY_MS;
+const here = dirname(fileURLToPath(import.meta.url));
+
+function readJson(path, fallback = {}) {
+  try { return JSON.parse(readFileSync(path, 'utf8')); } catch { return fallback; }
+}
+
+function frontmatterValue(text, key) {
+  const frontmatter = /^---\n([\s\S]*?)\n---/.exec(text)?.[1] ?? '';
+  const match = new RegExp('^' + key + ':\\s*([^\\n]+)$', 'm').exec(frontmatter);
+  return match?.[1].trim().replace(/^['"]|['"]$/g, '') ?? null;
+}
+
+function repositoryOf(source) {
+  const value = String(source ?? '').trim();
+  const match = /^(?:git@github\.com:|https:\/\/github\.com\/)?([A-Za-z0-9_.-]+\/[A-Za-z0-9_.-]+?)(?:\.git)?$/.exec(value);
+  return match?.[1] ?? null;
+}
+
+function stableVersion(value) {
+  const match = /^v?(\d+)\.(\d+)\.(\d+)$/.exec(String(value ?? '').trim());
+  return match ? match.slice(1).map(Number) : null;
+}
+
+function newer(left, right) {
+  for (let index = 0; index < 3; index += 1) {
+    if (left[index] !== right[index]) return left[index] > right[index];
+  }
+  return false;
+}
+
+function writeCache(path, value) {
+  try {
+    mkdirSync(dirname(path), { recursive: true });
+    writeFileSync(path, JSON.stringify(value));
+  } catch { /* A read-only cache must not block skill use. */ }
+}
+
+function main(now = Date.now()) {
+  if (process.env.ONEABOVEIO_NO_UPDATE_CHECK) return;
+  const skill = readFileSync(join(here, 'SKILL.md'), 'utf8');
+  const name = frontmatterValue(skill, 'name');
+  const localVersion = stableVersion(frontmatterValue(skill, 'release-version'));
+  if (!name || !localVersion) return;
+
+  const lock = readJson(join(process.env.HOME || homedir(), '.agents', '.skill-lock.json'));
+  const entry = lock.skills?.[name];
+  const repository = repositoryOf(entry?.sourceUrl || entry?.source);
+  if (!repository) return;
+
+  const cacheRoot = process.env.XDG_CACHE_HOME || join(process.env.HOME || homedir(), '.cache');
+  const cachePath = join(cacheRoot, '1aboveio-skills', 'release-check.json');
+  const all = readJson(cachePath);
+  const cache = all[repository] && typeof all[repository] === 'object' ? all[repository] : {};
+
+  if (!cache.lastCheck || now - cache.lastCheck >= DAY_MS) {
+    const result = spawnSync('gh', ['api', 'repos/' + repository + '/releases/latest', '--jq', '.tag_name'], {
+      encoding: 'utf8',
+      stdio: ['ignore', 'pipe', 'ignore'],
+      timeout: 1500,
+    });
+    cache.lastCheck = now;
+    if (result.status === 0 && stableVersion(result.stdout)) cache.latestTag = result.stdout.trim();
+    else delete cache.latestTag;
+    all[repository] = cache;
+    writeCache(cachePath, all);
+  }
+
+  const latestVersion = stableVersion(cache.latestTag);
+  if (!latestVersion || !newer(latestVersion, localVersion)) return;
+  if (cache.notifiedTag === cache.latestTag && cache.notifiedAt && now - cache.notifiedAt < WEEK_MS) return;
+
+  cache.notifiedTag = cache.latestTag;
+  cache.notifiedAt = now;
+  all[repository] = cache;
+  writeCache(cachePath, all);
+  const command = `npx skills@1.5.23 add '${repository}#${cache.latestTag}' --global --agent universal claude-code --skill ${name} --yes`;
+  process.stdout.write(
+    `UPDATE_AVAILABLE: A newer 1AboveIO skills release (${cache.latestTag}) is available; this skill is `
+      + `v${localVersion.join('.')}. Ask once whether to refresh ${name}. On approval run \`${command}\`. `
+      + 'The refreshed instructions apply next session. Either way, continue the current task and do not ask again this session.\n',
+  );
+}
+
+try { main(); } catch { /* Update checks are advisory and always fail silent. */ }

package/skills/content/wechat-article-writer/templates/wechat-comparison.md

@@ -0,0 +1,52 @@
+# WeChat article: 对比型（概念澄清 + 选型决策）
+
+## Use when
+
+读者常把两个概念搞混，或要在几个方案之间做选择。读者读完能分清，并知道自己该选哪个。
+
+- 读者需要的是操作步骤 → **wechat-howto**。
+- 话题是行业趋势而不是两个选项 → **wechat-insight**。
+
+## Tone
+
+开头可以直接点出「很多人搞错了」；分析部分客观，少用「最好」「一定」；结论清晰，不模棱两可。
+
+## Inputs
+
+- 被比较的对象及其准确定义。Material: ask once。
+- 各维度的事实（费率、流程、适用条件）。只用来源中的；缺失的维度写 `【待确认：…】` 或删掉。
+- 搞混后的实际损失或场景。只用作者提供的案例。
+- 品牌和 CTA：来自 WRITING.md。
+
+## Reasoning
+
+「帮读者做决定，省去自己研究的时间」：
+
+1. 抛出混淆现象，并说明搞混的代价。
+2. 先各用一句话定义两个概念。
+3. 从 3–5 个维度对比，或用一个场景对比两种处理方式。每个维度：A 的情况 → B 的情况 → 实际影响。
+4. 给一个判断方法（判断树或口诀），让读者遇到时能自己分辨。
+5. 用 3–5 条要点或一张表收尾，方便截图收藏。
+
+## Sections
+
+Omit Optional sections that add nothing. Do not pad with empty headings.
+
+1. **标题** (Required): `[A] vs [B]：…`；百分比只在来源有时使用。示例：「支付失败 vs 交易拒付：很多商家都搞混了」。
+2. **开头（约 150 字）** (Required): 混淆现象和它造成的损失。
+3. **概念澄清** (Required): 两个一句话定义。
+4. **对比分析** (Required): 维度对比或场景对比；表格不超过 5 列。
+5. **决策框架** (Required): 判断树、口诀或「遇到 X → 是 A 还是 B」的方法。
+6. **总结要点或表格** (Optional): 3–5 条，方便截图。
+7. **结尾 CTA** (Required): 按 WRITING.md。
+
+## Done when
+
+- 两个定义各一句，且互不重叠？
+- 每个维度都写到对实际的影响？
+- 读者读完能用决策框架自己判断？
+- 每个数字和对比事实都有来源？
+
+## Sources
+
+Rewritten from this skill's former `references/style-comparison.md` into the template contract; improve per account with `distill-writing`.

package/skills/content/wechat-article-writer/templates/wechat-howto.md

@@ -0,0 +1,51 @@
+# WeChat article: 实操型（步骤教程 + 保姆级指南）
+
+## Use when
+
+读者想完成一个具体操作：工具上手、配置、接入、排查。读者不需要理解原理，只要照着做就能得到结果。
+
+- 重点是踩坑经历和教训 → **wechat-pitfall**。
+- 重点是帮读者在两个选项之间做决定 → **wechat-comparison**。
+
+## Tone
+
+平实，不需要情绪。每步动词开头；FAQ 可以轻松一点。
+
+## Inputs
+
+- 操作步骤、界面名称、参数、命令。Material: ask once。不凭记忆重建产品界面或参数。
+- 前提条件（权限、文件、耗时）。来源没有的耗时不写。
+- 常见卡点。只写作者提供或步骤中真实存在的。
+- 品牌、产品名和 CTA：来自 WRITING.md；没有则用 `[产品]` 和中性 CTA。
+
+## Reasoning
+
+「照着做就行」：
+
+1. 一句话说清读完能做到什么。
+2. 列出开始前要准备的东西，避免读者做到一半卡住。
+3. 每步一个动作，按实际顺序；易错处用 ⚠️ 标在该步之前或之中。
+4. 用 FAQ 接住「做到这里卡住了怎么办」，用清单确认完成。
+
+## Sections
+
+Omit Optional sections that add nothing. Do not pad with empty headings.
+
+1. **标题** (Required): 动作 + 保姆级 / 完整 / 手把手。示例：「手把手配置 [产品] 风控规则（附完整参数说明）」。
+2. **开头（约 150 字）** (Required): 「如果你在 XXX，读完这篇，你能做到 YYY」；可以加一句很多人卡在哪一步。
+3. **前提条件** (Optional): 权限、文件或信息、预计耗时。
+4. **步骤** (Required): 3–5 步以上，每步 `## 第 N 步：动词 + 做什么`，简短说明为什么，具体操作，⚠️ 注意事项。
+5. **常见问题 FAQ** (Optional): 3–5 个卡点及解决办法。
+6. **CheckList** (Required): 完成后的自查清单。
+7. **结尾** (Required): 完成后应看到的结果；CTA 按 WRITING.md。
+
+## Done when
+
+- 每一步只有一个动作，并以动词开头？
+- 新手只靠这篇文章能从头做到尾？
+- 每个界面名、参数和命令都来自来源？
+- 易错点标在对应步骤，而不是放在文末？
+
+## Sources
+
+Rewritten from this skill's former `references/style-howto.md` into the template contract; improve per account with `distill-writing`.