c456-cli 0.5.0 → 0.7.0

package/skills/c456-llm-wiki/SKILL.md

@@ -0,0 +1,262 @@
+---
+name: c456-llm-wiki
+description: >-
+  将 Karpathy LLM Wiki 三层架构与 C456.com 双向同步结合的知识库管理规范。
+  支持 raw/wiki/c456-sync 四层架构、多对多映射、双向同步、自动 Ingest。
+  撰写 c456-sync 与上行正文时须符合仓库 AGENTS.md §1.2–1.3；处理远端已删本地仍存须符合 §6.5（orphan_local：清单 + 用户确认）。
+  Use when the user mentions LLM Wiki, C456 sync, knowledge base, c456-sync,
+  bidirectional sync, orphan_local, remote-deleted local sync, or ingesting
+  content to wiki and c456.com.
+---
+
+# LLM Wiki + C456 双向同步
+
+## 核心思想
+
+在 Karpathy LLM Wiki 三层架构（raw/wiki/schema）基础上增加 C456 双向同步层，实现本地知识库与 c456.com 之间的内容发布与拉取。
+
+## 必读：仓库根 `AGENTS.md`
+
+- **§1.2**：c456-wiki **定位、目的、受众**（收集整理 → 对外分享 → 帮互联网读者选择高价值工具与方案）。
+- **§1.3**：`c456-sync/` 与 C456 **上行正文**的六条原则——**准确性、可读性、整洁性、逻辑性、推荐性、推广性**（含与 `wiki/` 分工：镜像层单篇自洽、面向陌生读者）。
+- **§6.5**：远端记录已删、本地 `c456-sync` / `meta` / `wiki` 仍在时（**orphan_local**）——**先列清单、用户确认后再删或归档**，禁止自动删除；详见下文「orphan_local」与 `AGENTS.md` 全文。
+
+**冷启动 / 初始化目录时**：先打开仓库根 `AGENTS.md`，确认已包含 **§1.2–1.3** 与 **§6.5**（若缺失则补全后再建 `c456-sync/` 或首次 Ingest）；旧模板仅有 §1.2–1.3 时至少补 **§6.5**。可在首条 `wiki/log.md` 注明「已对齐 §1.2–1.3 / §6.5」。
+
+任何写入 **`c456-sync/`**、或组装将提交给 **`c456 intake` / `c456 playbook` 的正文** 之前，重读 **§1.3** 自检一遍。
+
+## 四层架构
+
+```
+raw/（原始素材层）  ← 你存放，AI 只读
+    ↑↓
+c456-sync/（镜像层）← C456 线上内容的本地镜像
+    ↑↓
+wiki/（知识库层）   ← AI 生成的结构化 Markdown，互相链接
+    ↑↓
+AGENTS.md（Schema） ← 定义 AI 如何组织 Wiki
+```
+
+## 目录结构
+
+```
+.
+├── raw/
+│   ├── articles/  books/  papers/  courses/
+│   ├── resources/  quotes/  tools/  work/
+├── c456-sync/
+│   ├── signal/  tool/  channel/  playbook/  walkthrough/
+├── wiki/
+│   ├── index.md  log.md  c456-meta.yml
+│   ├── entities/  concepts/  threads/  sources/  agents/
+├── output/
+└── AGENTS.md
+```
+
+### 四层关系
+
+
+| 层级           | 谁维护   | 用途      | 与 C456 关系 |
+| ------------ | ----- | ------- | --------- |
+| `raw/`       | 用户放入  | 原始素材    | 上行时作为内容来源 |
+| `c456-sync/` | AI 同步 | C456 镜像 | 与线上一一对应   |
+| `wiki/`      | AI 生成 | 提炼后的知识库 | 多对多映射     |
+| `output/`    | 用户创作  | 主动产出    | 可发布到 C456 |
+
+
+**关键原则**：`c456-sync/` 与 `wiki/` 之间不用 symlink。关联通过 Frontmatter 引用 + `wiki/c456-meta.yml` 实现。
+
+### c456-sync 与上行正文（执行摘要）
+
+`c456-sync/` 虽是镜像层，正文须视同 **对外读者可读版本**：事实可核对、结构清晰、有推荐结论与诚实边界、CTA 明确；细节与表格见 **`AGENTS.md` §1.3**。
+
+---
+
+## 页面类型
+
+### 实体页 `wiki/entities/`
+
+- 命名：小写 kebab-case，如 `andrej-karpathy.md`
+- Frontmatter：`type: entity` + `c456-id` + `c456-kind` + `c456-sync-path` + `tags: [...]`
+
+### 概念页 `wiki/concepts/`
+
+- 命名：小写 kebab-case，如 `rag.md`
+
+### 线索页 `wiki/threads/`
+
+- 命名：小写 kebab-case，如 `ai-engineering-trilogy.md`
+
+### 来源摘要页 `wiki/sources/`
+
+- 命名：与 raw 文件名呼应
+- Frontmatter：`type: source` + `c456-kind` + **`c456-title`** + **`c456-summary`**（上行必备）+ `c456-id` + `c456-status` + `date: YYYY-MM-DD` + `raw: raw/.../xxx.md`
+
+---
+
+## 链接规范
+
+- 使用 Obsidian Wikilink：`[[page-name]]`
+- 链接目标文件名不带 `.md` 后缀
+- 页面标题使用一级标题 `# Title`
+
+---
+
+## 三种核心操作
+
+### Ingest（摄入）
+
+1. 读取素材
+2. 判定 C456 类型（signal/tool/channel/playbook/walkthrough）
+3. 创建/更新来源摘要页（Frontmatter 含 `c456-title` + `c456-summary`，供后续上行）
+4. 提取实体（无则新建，有则追加）
+5. 提取概念（无则新建，有则整合）
+6. 更新线索页
+7. 更新 `wiki/index.md`
+8. 追加 `wiki/log.md`
+
+**C456 类型判定**：介绍工具用法 → `tool`；介绍作者/频道 → `channel`；step-by-step → `walkthrough`；策略/框架 → `playbook`；其余 → `signal`。
+
+### Query（查询）
+
+1. 先读 `wiki/index.md`
+2. 定位相关页
+3. 读取并综合
+4. 引用来源
+5. 回写好答案：若用户认可，提议保存为 wiki 新页面
+
+### Lint（检查）
+
+1. 扫描矛盾
+2. 发现孤立页
+3. 检查缺失页
+4. 评估数据缺口
+5. 输出 Markdown 报告
+
+---
+
+## C456 集成规范
+
+### 内容类型映射
+
+
+| C456 类型         | 含义     | 对应 raw/                        | 对应 wiki/                      | 对应 output/ |
+| --------------- | ------ | ------------------------------ | ----------------------------- | ---------- |
+| **signal**      | 信息片段   | articles/, quotes/, resources/ | wiki/sources/                 | 短评         |
+| **tool**        | 工具/软件  | tools/                         | wiki/entities/                | 工具评测       |
+| **channel**     | 频道/账号  | resources/                     | wiki/entities/                | 频道推荐       |
+| **playbook**    | 方法论/框架 | work/, books/                  | wiki/concepts/, wiki/threads/ | 方法论文章      |
+| **walkthrough** | 教程     | courses/, articles/            | wiki/threads/                 | 教程         |
+
+
+### Frontmatter 扩展
+
+收录五种 C456 类型并准备**上行**时，须在 Frontmatter 中写明 **`c456-title`** 与 **`c456-summary`**，作为同步到 C456 的展示标题信息（与页面正文的一级标题 `# Title` 区分，避免与通用 `title` 字段混淆）。
+
+- **`c456-title`**：主标题（单行，对应 CLI/API 的标题字段）。
+- **`c456-summary`**：紧跟标题语义的一句简短说明，用于列表/卡片上的补充展示；上行时与 `c456-title` 一并交给 Agent 或写入请求（具体拼接格式以当次 CLI/API 为准）。
+
+**这句简短描述叫什么**：若强调「从属于主标题的补充短语」，中文常用 **副标题**，英文 **subtitle**；若强调「一句话概括、列表摘要」，产品与 API 语境常用 **摘要**，英文 **summary**（C456 Intake 卡片上与标题配对展示的也是 summary）。营销语境也可称 **标语 / tagline**。本规范 Frontmatter 使用字段名 **`c456-summary`**，语义与上述「摘要」对齐。
+
+```yaml
+---
+type: source
+c456-kind: signal      # signal | tool | channel | playbook | walkthrough
+c456-title: "主标题"
+c456-summary: "一句简短描述，用作上行列表/卡片摘要（副标题语义）"
+c456-id: 42            # 发布后回填
+c456-status: draft     # draft | published | outdated | conflict
+date: 2026-05-08
+---
+```
+
+### 发布工作流（上行）
+
+1. 扫描带 `c456-kind` 但缺 `c456-id` 或 `status: draft` 的页面
+2. 转换 Markdown 为 C456 富文本格式（移除 Wikilink、Frontmatter）
+3. 选择命令：signal/tool/channel → `c456 intake new -k <kind>`；playbook/walkthrough → `c456 playbook new`
+4. 正文写入 `.tmp/`，通过 `--body-file` 传入 CLI
+5. 回填 ID 到 Frontmatter `c456-id`，改 `c456-status: published`
+6. 记录日志到 `wiki/log.md`
+
+更新已有内容：用 `c456 intake update <id>` 或 `c456 playbook update <id>`，不重复新建。
+
+### 双向同步
+
+**c456-sync/ 目录**：作为 C456 镜像层，按五类型分目录存储。撰写、从线上拉回后的润色、以及准备 `--body-file` 的正文，须满足 **`AGENTS.md` §1.3**。
+
+**关联方式**：`c456-sync/` 文件 Frontmatter 标注 `local-wiki-source`、`local-wiki-entities` 等字段；`wiki/` 页面 Frontmatter 标注 `c456-id`、`c456-sync-path`；`wiki/c456-meta.yml` 记录总索引。
+
+**双向索引**：`wiki/index.md` 中已发布条目可标注 `[c456:#id]`。C456 正文可保留回链到本地 Wiki 的链接。
+
+### 远程已删、本地仍存（orphan_local）
+
+见仓库根 **`AGENTS.md` §6.5**：须先向用户输出 **待删除/待处理清单** 并取得 **明确确认** 后，方可删除 `c456-sync/` 或调整 `wiki/` 与 `c456-meta.yml`；可选路径含删镜像、wiki 归档、`meta` 去幽灵 id、或 `intake new` 重发。
+
+### 状态流转
+
+```
+draft → publishing → published → outdated → published
+                                    ↘ conflict
+```
+
+---
+
+## 特殊文件规范
+
+### `wiki/index.md`
+
+内容导向的目录，每页一行摘要 + 链接。按分类组织。每次 Ingest 后更新。
+
+### `wiki/log.md`
+
+时间导向的追加日志。条目格式：`## [YYYY-MM-DD] 操作类型 | 标题/简述`
+操作类型：`ingest`、`query`、`lint`、`update`、`create`、`c456-publish`、`c456-down-ingest`、`c456-conflict`
+保持 append-only。
+
+### `wiki/c456-meta.yml`
+
+C456 ↔ 本地映射总索引。记录每个 C456 ID 的 `sync_path`、`wiki_pages[]`、状态、时间戳、checksum。AI 在同步操作中自动维护。
+
+---
+
+## 产品录入调研与数据自动补充（Enrichment）
+
+录入产品（tool 类型）时，若提供的信息不完整（如仅给 GitHub 仓库 URL），AI 应主动上网调研并自动补充多种数据类型。
+
+### 调研来源
+
+| 信息类型 | 调研方法 | 示例 |
+|---|---|---|
+| **官网** | 从 GitHub README 或组织页提取 | `github.com/rails/rails` → `rubyonrails.org` |
+| **包管理器** | 搜索 npm / RubyGems / PyPI / Crates.io / Homebrew | `github.com/rails/rails` → `gem rails` |
+| **GitHub 元数据** | 读取仓库页（stars、license、语言、最新发布） | 自动记录 stars 数、许可证、主要语言 |
+| **产品描述** | 从官网首页或 README 提炼一句话简介 | 用于 `c456-summary` |
+| **核心功能** | 从官网 Features 页或 README 提取 | 用于正文 |
+| **安装方式** | 从 README 或官网提取 | apt / brew / npm / Docker 等 |
+
+### 调研流程
+
+1. **输入**：用户提供任意信息（官网 URL、GitHub URL、产品名等）
+2. **调研**：AI 使用 WebFetch 工具获取官网、GitHub、包管理器页面
+3. **交叉验证**：确认官网与 GitHub 的对应关系
+4. **补充**：将调研结果填入 raw 素材、c456-sync 镜像、wiki 页面
+5. **发布**：按标准 Ingest 流程创建/更新所有页面
+
+### 数据填充规则
+
+- **c456-title**：`品牌名 | 定位 · 特色后缀`
+- **c456-summary**：一句话概括核心价值
+- **正文**：包含核心功能模块表、安装方式、适用场景；并自检 **`AGENTS.md` §1.3**（对外可读、可推荐、不夸大）。
+- **实体页**：包含关键属性表（官网、GitHub、stars、许可证、语言）、核心功能、差异化亮点、竞品对比
+- **来源摘要**：包含核心信息、关键功能、开源信息
+
+### 示例：GitHub URL → 多类型数据
+
+给定 `github.com/rails/rails`，AI 应自动：
+1. 读取 GitHub README → 提取官网 `rubyonrails.org`
+2. 搜索 RubyGems → 找到 `gem rails`
+3. 记录 GitHub stars、许可证（MIT）、主要语言（Ruby）
+4. 访问官网 → 提取产品描述、核心功能
+5. 创建完整 raw / c456-sync / wiki 页面
+6. 发布到 C456

package/skills/c456-product-channel-article/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: c456-product-channel-article
+description: >-
+  按「五段式产品叙事漏斗」撰写工具/渠道介绍长文或图文脚本：概述钩子、产品基因、
+  核心功能、差异化亮点（含对比与局限）、总结与 CTA；强调价值先于功能、可信证据与诚实边界。
+  在用户要写产品介绍、公众号/渠道稿、C456 tool 或 channel 配套文案、或提到「按技能写渠道文」时使用。
+---
+
+# 工具/渠道产品介绍写作
+
+从「Ghost 类」五页幻灯结构抽象出的可复用叙事；适用于 SaaS/开源工具/自托管产品、以及 C456 的 `tool` / `channel` 配套长文。
+
+## 写作前先收集（可缺省但尽量补齐）
+
+- **一句话定位**（动笔前自用清单）：品类 + 给谁 + 解决什么主痛点——**成稿时不要**用 `## 一句话定位` 之类当对外标题；定位融在 **概述节正文** 里。
+- **正反定义**：不是什么 + 是什么（消除误解）。
+- **证据**：官网/GitHub、版本或数据、奖项/榜单/社媒、第三方评测（注明来源与日期）。
+- **竞品或旧范式**：传统主机商、纯脚本、闭源 SaaS 等——只写真实可核对的对比轴。
+- **约束与局限**：服务商绑定、地域延迟、支持边界、仍需的技术门槛——写清楚反而增信。
+- **行动入口**：试用链接、仓库、文档、定价页。
+
+## 五段式叙事漏斗（建议章节顺序）
+
+全文或长图用顶栏/目录标出当前段：**概述 → 基因 → 功能 → 亮点 → 总结**，降低跳出与迷失。
+
+### 1. 概述（钩子 + 价值前置）
+
+- **类比钩子**：用读者熟悉的行为比喻复杂能力（如「像刷短视频一样完成某事」）；一句即可，避免堆砌。
+- **3 条高层收益**：部署/成本/掌控、或时间/钱/数据，每条短句直达结果。
+- **可选：价值公式**：用极简式子概括产品逻辑，例如「私服体验 = 云底层算力 + 极简可视化面板」。
+- **配图**：首屏或落地页截图，建立「真实产品」感。
+
+### 2. 产品基因（Why：信任与立场）
+
+- 写 **价值观/设计立场**：开源透明、自托管与数据主权、自动化降门槛、成本结构（直连云价 vs 中间商加价）等；选 3～4 个支柱即可。
+- **与旧范式对比一句**：商业托管逐利 vs 本品的白盒/可控（不人身攻击，只对比机制）。
+- **业务逻辑三层**（若适用）：用户自有账号 → 工具编排 → 云资源/游戏进程；用短流程图或三 bullet 说明钱与数据归谁。
+
+### 3. 核心功能（What：具体能力）
+
+- 列表项用 **「动作 + 结果」**：例如「一键部署 → 数分钟内可玩」，避免只堆名词。
+- 覆盖：部署路径、模板/多游戏或多场景、管理面板、备份与恢复、监控告警、更新与运维自动化等——只写产品真实具备的。
+- **配图**：产品内页截图（列表/地图/仪表盘），作为「可交付证明」。
+
+### 4. 核心亮点（So what：差异化）
+
+- 每条亮点先 **用户收益** 再 **机制支撑**：成本（付云原价）、性能（自选规格/地域）、安全与存档归属、速度（如就绪时间，需可验证再写）。
+- **对比表**（推荐）：左「传统方案」、右「本产品 + 用户云」；列：成本、性能自由度、数据归属、门槛——措辞可犀利，事实须可辩护。
+- **社会证明**：Product Hunt、GitHub Star、知名客户或 Maker——数字与名次写准确，避免夸大。
+- **局限与产品思考**（强烈建议单独小节或列表）：绑定某云、非完全零门槛、社区支持有限等；与目标场景（如重度联机、长档游戏）一起写，显得懂行。
+
+### 5. 总结（战略收束 + CTA）
+
+- **收束三句内**：权力转移（从买服务到控资产）、运维产品化、长期数字资产等择一二展开，忌空喊。
+- **金句对照**：如「商业托管卖便利，本品卖信任与可控」——根据产品改写，避免套话雷同。
+- **CTA**：主按钮式文案 + 链接/二维码说明；若同步 C456，正文可保留回链到本地 Wiki。
+
+## 文风与版式
+
+- **标题**：段内小标题用「收益型」短语，少用纯技术枚举。
+- **节奏**：先价值与基因，再功能清单；技术细节服从叙事，不抢戏。
+- **术语**：渠道向读者适度解释「自托管」「白盒」等；英文品牌名保留原文。
+- **禁止**：无法核实的数据、虚构奖项、攻击性拉踩；不确定则写「以官方说明为准」或删掉。
+- **少用模版小节标题**：如 `## 一句话结论`、`## TL;DR`；金句可用段落内加粗，不要为「只有一句」的判断单开 `##`。
+
+## 产出前自检清单
+
+- [ ] 读者 30 秒内能回答：这是什么、为谁、为什么现在用。
+- [ ] 每段有 **一张图或一张表**（概述/功能/亮点至少各一处实据）。
+- [ ] 功能项均能从 **受益** 读回去。
+- [ ] 写过至少 **一条真实局限**。
+- [ ] CTA 与链接可点击、路径清晰。
+
+## Markdown 骨架模板（按需删节）
+
+```markdown
+# [产品名]｜[品类] · [一句差异化]
+
+> [类比钩子一句]
+
+**本篇结构**：概述｜产品基因｜核心功能｜核心亮点｜总结
+
+## 概述
+
+- **不是什么**：[例如：不是零散脚本合集 / 不是高价托管代运营]
+- **是什么**：[开源/自托管/编排工具等，一句]
+- **你将获得**：
+  1. …
+  2. …
+  3. …
+
+![落地页或首屏](...)
+
+## 产品基因
+
+（开源 / 自托管 / 自动化 / 成本结构 / 玩家或团队主权 —— 择要展开）
+
+**业务逻辑**：用户 → 工具 → 云/运行时 → [游戏/业务]
+
+## 核心功能
+
+- **[动作]** → [用户可感知的结果]
+- …
+
+![控制台或关键流程](...)
+
+## 核心亮点
+
+| 维度 | 传统方案 | 本产品 |
+|------|----------|--------|
+| 成本 | … | … |
+| 性能/规格 | … | … |
+| 数据归属 | … | … |
+
+**社会证明**：[来源 + 数字 + 时间]
+
+**局限与适用**：…
+
+## 总结
+
+[战略收束 2～4 句]
+
+**一句话**：[对照金句]
+
+**下一步**：[链接与说明]
+```
+
+## 与仓库 Wiki/C456 的衔接（可选）
+
+- 深度参数与竞品表可进 `wiki/entities/`；素材出处进 `wiki/sources/`；渠道短文保留叙事与引用。
+- Frontmatter 若走 C456：按 `AGENTS.md` 使用 `c456-kind: tool | channel` 等，避免把长文误标为 `signal`。

package/skills/c456-signal-product-vs/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: c456-signal-product-vs
+description: >-
+  撰写「产品 vs 产品」类 C456 signal（深度对比）：信息源分层（P0/P1）、篇幅区间、章节骨架（首节正文承载核心判断，禁止「## 一句话结论」式标题）、调研笔记落盘；并约束对外稿语气（具体场景、诚实边界、少套话）以减少模版感。
+  与 c456-sync 对外规则（无正文一级标题、无仓库工序）一致。在扩写 Auth/IdP、SaaS 对等对比、或任意 tool vs tool 信号前使用。
+---
+
+# 产品 vs 类 Signal（深度对比）
+
+`c456-kind: signal` 若要做成 **能照着选型的对比**，除了 AGENTS.md 里的对外正文原则（准确性、诚实边界、推荐性），还要同时满足：
+
+- **对外 Markdown**：`c456-sync/` 正文从 `##` 起，不写 `#`；不放截图工序、仓库路径、`c456 screenshot` 等——细则见 [.cursor/skills/c456-sync-public-markdown/SKILL.md](../c456-sync-public-markdown/SKILL.md)。
+
+先保证 **事实与来源** 站得住，再谈文采；但成稿时应读起来像 **熟手写给同行的笔记**，而不是说明书翻译腔。
+
+## 1. 信息源分层（可信度）
+
+| 层级 | 渠道 | 用途 |
+| --- | --- | --- |
+| **P0 必查** | 双方官方文档（Auth、RLS/授权、SSO、组织/多租户、M2M、Webhooks、Limits） | 能力边界、已知限制 |
+| **P0 必查** | 定价 / 用量 / 配额页；Status 或 Changelog；公开路线图（若有） | 计费口径、变更节奏 |
+| **P0 必查** | GitHub 主仓 README、Releases、高票 issue/discussion | 真实痛点、版本节奏 |
+| **P1 建议** | 官方博客 / 工程师文章 | 理解设计取舍 |
+| **P1 线索** | 第三方对比文 | 只借维度，**结论回 P0 核对** |
+| **P2 可选** | Stack Overflow、HN、Reddit 高票帖 | 标明「社区经验」，个案不当全称判断 |
+| **合规线索** | 隐私政策、DPA、数据区域说明（托管产品） | **不拟法律意见**，写「由团队自行评估」 |
+
+交稿前问一句：**P0 是否都能打勾**？双方是否各至少有 **两段** 能指到官网或带日期的依据？
+
+## 2. 篇幅（代理指标）
+
+- **深度 vs 信号**：正文（不含 Frontmatter、不含纯链接堆砌）中文 **约 2,000～3,500 字** 通常是「真的调研过」的体量；若大量用表 + 决策分支，可略短，但 P0 覆盖不能省。
+- **上限**：尽量一次读完，一般不超过 **6,000 字**；更长就拆成系列 signal，或把考证过程丢进 `output/` 长笔记。
+
+字数只是 proxy；硬标准是 **来源是否盖住关键争议**、**事实是否够密**。
+
+## 3. 建议章节结构（`c456-sync` 用 `##`）
+
+`wiki/sources/` 里可以保留 `#`、Wikilink 和本地路径；对外稿按下面骨架，小标题可按题材改名，但 **信息类型** 建议别缺。
+
+**开头要让读者 30 秒内知道「要不要往下读」：**
+
+1. **首个 `##` + 开篇正文（合并「场景 + 判断」）**：小标题用 **具体内容**，例如「谁在选型、卡在什么矛盾」或「两条路径差在哪里」，**不要**用「概述」「背景」式空壳。在该节 **第一段至第二段正文里** 直接写出 **可执行的选型判断**（若双方各有受众，各用一句落地，忌「各有千秋」）——这就是过去的「一句话结论」，但 **必须写在段落里**，**禁止**再单开 `## 一句话结论`、`## TL;DR`、`## 核心结论` 这类标签式标题（典型 AI 腔）。
+2. **双方定位**：各 80～120 字 + 官网；像产品页导语，不要复制粘贴官方口号堆砌形容词。
+
+**中间按技术选型真实会踩的点展开：**
+
+3. **架构与数据模型**：目录、token、与业务库或服务的分界；_doc 锚点跟上_。
+4. **认证与授权**：OAuth/OIDC、MFA、会话、多租户、SSO、M2M、审计等，用 **有 / 无 / 部分 / 以文档为准**，忌「全面支持」这种空词。
+5. **开发者体验**：SDK、框架示例、本地跑通路径、和 Serverless/Edge 等结合方式——写「你实际会碰到的摩擦」。
+6. **运维与部署**：托管 vs 自托管、升级、备份、SLA；核不到就写「以合同/官网状态页为准」。
+7. **成本与计费**：免费档、计量维度、规模上去之后 bill 会怎样飘；**定价页 URL + 核对日期**。
+8. **安全与合规**：公开材料能支撑什么就写什么；不编造认证、不替厂商承诺。
+
+**收尾要敢写边界，否则对比没有信用：**
+
+9. **局限与诚实边界**：每方至少 **三条**「不适合谁」或已知短板（注明来自文档还是社区）。
+10. **迁移与双栈**：3～5 条步骤级风险（目录映射、回调、RLS/策略、割接窗口等）。
+11. **选型决策**：表或分支；**表前用一句正文**引导读表顺序，**表后用一句正文**提示「若仍犹豫，优先验证哪条假设」（除非说明本身长到值得独立成节，否则不要为这两句再叠「小结」类 `##` 标题）。
+12. **下一步**：双方文档入口 + 试用/沙箱；链接只留公网或本站 intake。
+
+## 4. 正文语气：对比稿怎样写才像人写的
+
+这些规则针对 **C456 对外正文**（`c456-sync`），写的时候自检一遍。
+
+**叙事**
+
+- 用 **具体触发句** 开头：「如果你已经上了 Supabase 只想补一套 IdP」比「在当今身份管理领域」有用得多。
+- **一句一意**：少写对称排比（「不仅…而且…」「一方面…另一方面…」信息量为零就删）。
+- **长短句混用**：关键判断用短句砸下去，紧接着一两句解释依据或例外。
+
+**对比**
+
+- 少写「A 优于 B」的抽象裁判；多写 **在同一约束下**（团队规模、是否已有 Postgres、是否要自托管）谁更省事。
+- 表格里每个单元格尽量 **可核查**：数字、档位名、文档小节名；避免「更强」「更灵活」这种无法证伪的词单独占一栏。
+
+**诚实**
+
+- 不确定写 **「以官网为准」** 或 **「我们核对到某页如此（日期）」**，比假装全知可信。
+- 「局限」小节不是走流程：每条短板最好能让读者想到 **自己是否中招**。
+
+**少用**
+
+- 开篇帽子：数字化、赋能、新常态、深度赋能、综上所述、值得注意的是、让我们一探究竟。
+- **标签式小结标题**：`## 一句话结论`、`## TL;DR`、`## 核心观点`（仅作标题而无实质章节）——核心判断放进 **第一节正文段落**，`##` 只留给真实主题。
+- 内部批注腔：「观察：」「可以看到：」——若保留观察，改成「实践里常见的是…」并加来源或场景。
+- 无信息 Emoji、过量「！！」；除非品牌本身极度活泼，否则对外对比文默认 **克制标点**。
+
+**可多用的转折**（天然带着限定，像人在说话）
+
+- 「前提是你们已经……否则……」
+- 「这块文档写得很清楚，但默认假设是……」
+- 「若你唯一硬性条件是……那优先看……」
+
+## 5. 调研笔记 vs 对外稿
+
+- **链接清单、长摘录、打勾草稿**：`wiki/` 或 `output/`（如 `output/research-notes-<topic>.md`）。
+- **`c456-sync/`**：只放 **蒸馏后的成稿**；`c456 signal update <id> --body-file` 用 **无 Frontmatter** 正文，并过一遍 `c456-sync-public-markdown`。
+
+## 6. 与 `c456-sync-public-markdown` 速记
+
+- 正文从 **`##`、导语或图** 起，不重复标题。
+- 图：斜体一行外链作图说即可，不解说拍摄过程。
+- 竞品索引只留 **https** 或 `https://c456.com/intakes/<id>`。
+
+## 7. 参考示例
+
+- 成稿链路：`c456-sync/signal/logto-vs-supabase-auth.md`（C456 #160）；考证过程：`output/research-notes-logto-vs-supabase.md`。

package/skills/c456-signal-researcher/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: c456-signal-researcher
+description: >-
+  Drafts C456 signals in a news-researcher voice: verified facts, independent value judgment, links to existing intakes, end-of-article source block; routes to product-vs or channel article skills when the piece is a deep compare or long intro.
+  Use when writing signals, news intakes, or industry updates in this wiki repo (c456-sync / C456).
+disable-model-invocation: true
+---
+
+# C456 信号研究员（Signal Researcher）
+
+## 定位
+
+目标不是「记一条笔记」，而是 **让读者在短时间内做决定**：这条消息值不值跟进、对谁有意义、和站上已有内容怎么拼在一起。
+
+动笔前心里过三个问题即可：
+
+1. **发生了什么**——能核对吗？日期、主体、数字是否齐？
+2. **为什么值得看**——对谁、在什么约束下有用？不是替厂商喊口号。
+3. **和咱们已有内容什么关系**——接续、打脸、还是补一句背景？没有就说没有。
+
+对外正文版式须同时遵守 [.cursor/skills/c456-sync-public-markdown/SKILL.md](../c456-sync-public-markdown/SKILL.md)。
+
+## 信号结构
+
+### 1. 导语（1～3 句）
+
+先用 **人话** 交代事件 + 对你这类读者意味着什么。十秒钟内要能判断：还要不要往下读。  
+避免「在数字化浪潮下」「值得注意的是」这种零信息开篇。
+
+`c456-sync` 对外稿若用 `##` 分节：**核心判断写在第一节下的正文段落里**（可与导语同段或紧接一段），**不要**单开 `## 一句话结论`、`## TL;DR` —— 标签标题一眼像生成文。
+
+### 2. 事实描述（2～5 段）
+
+- 谁、做什么、什么时间、对哪条产品线/用户群生效。
+- 版本号、价格、配额、发布日期等 **硬事实** 跟紧；吃不准就写 **「以官方最新说明为准」** 并指 URL。
+- 官网通稿可以读，成稿时 **改写** 成读者要用的信息密度；不要整段复制营销句式。
+
+段落之间用一句短承接（「这次更新真正会影响到的是……」）比纯列表更像活人写的。
+
+### 3. 价值分析（核心）
+
+信号和「转载摘要」的差就在这里：**你有没有自己的判断**。
+
+| 分析维度 | 自问 |
+|----------|------|
+| **行业** | 这条是噪声还是范式变化？有没有更可验证的旁证？ |
+| **读者** | 谁该盯？ small team / 企业 / 开源用户——别假装「所有人都该关心」。 |
+| **时机** | 现在就该动手试，还是先放进观察清单？ |
+| **边界** | 哪些是厂商叙事、哪些是我们从材料里推出来的？哪里留白？ |
+
+少写对称废话（「不仅……而且……」信息量为零就删）。一句短结论 + 一两句依据，通常就够。
+
+### 4. 关联研究
+
+**必做**：搜一圈已有内容，回答「这条和站上已经有的东西怎么接」。
+
+- 已有 **signal**：继承、反驳、还是补充同一条线？
+- **tool**：会不会改写某个工具的采用/定价/风险画像？
+- **channel**：是不是某个创作者或团队的可核验动态？
+- **playbook**：有没有让某套打法过时或变难？
+
+翻完 **没有发现硬关联**，就老老实实写一句：暂未发现与现有收录的直接关联，后续可再跟。别硬拗联系。
+
+### 5. 读者行动（1～2 句）
+
+给一个 **单一清楚的下一步**：读哪篇 doc、开哪个试用、关注哪个 changelog——别列一串 equally important 的链接糊弄过去。
+
+### 6. 来源（正文最末，固定块）
+
+主体正文与来源块之间 **空一行** 即可。**不要** 在 `**来源**` 前单独写一行 `---`：在 Markdown 里那是水平线，不是 Frontmatter；也容易让版面像「没粘干净的元数据」。
+
+```markdown
+**来源**：[标题](URL) · 作者/团队 · YYYY-MM-DD
+
+**延伸阅读**：
+- [标题](URL) · 简述
+- [标题](URL) · 简述
+
+**相关收录**：
+- C456 #id 信号/工具/渠道：[标题](https://c456.com/intakes/id)
+```
+
+## 调研流程
+
+### 第一步：事实核查
+
+| 优先级 | 渠道 | 干什么用 |
+|--------|------|----------|
+| **P0** | 官方公告、官博 | 定调、日期、产品名 |
+| **P1** | 文档、Changelog、GitHub Releases | 技术细节、行为变化 |
+| **P1** | 严肃科技媒体 | 外部视角，仍须回 P0 对关键事实 |
+| **P2** | HN、Reddit、X 等 | 摩擦点、舆情，标成社区视角 |
+| **P3** | 第三方解读 | 借问题意识，**结论自己用 P0 重核** |
+
+### 第二步：关联扫描
+
+翻 `c456-sync/`（以及本仓库 `wiki/`）：
+
+1. 工具名 / 人名 / 技术栈关键词
+2. 同主题过往 signal
+3. 可能被牵连的 tool、channel 条目
+
+### 第三步：要不要叫别的技能
+
+| 信号类型 | 技能 | 何时用 |
+|----------|------|--------|
+| 两家产品 **深度对比** | [c456-signal-product-vs](../c456-signal-product-vs/SKILL.md) | 主干就是选型对照，篇幅与 P0 覆盖按该技能来 |
+| 单工具/单渠道 **长叙事介绍** | [c456-product-channel-article](../c456-product-channel-article/SKILL.md) | 主干是「讲清楚一个产品或一个人」 |
+| 事实缺口大 | WebFetch 等独立调研 | 官稿太薄，补背景但仍回落到可核对来源 |
+| 普通动态 | 本技能独立完成 | 事实链清楚、影响一句话能说圆 |
+
+默认 **别过度叠技能**。只有真要做深度对比或长介绍时，再挂别的 SKILL。
+
+写 **产品 vs** 对比稿时，`c456-signal-product-vs` 里对 **对外语气** 有单独一节，与本技能一并满足。
+
+## 配图规则
+
+若材料里有 **肉眼可懂的界面、对比表、架构示意**，可以主动截图进正文；纯文字公告不必硬截。（CLI：`c456 screenshot`、`c456 asset upload`，详见全局 c456-cli 技能。）
+
+### 什么时候值得截
+
+| 值得 | 不太值得 |
+|------|----------|
+| 官网友好首屏、关键功能界面 | 全文纯文字声明 |
+| 对比表、架构图、定价档位 | 只有一个孤立数字 |
+| 可复述的性能对比页 | 论坛吵架帖 |
+
+### 怎么截、怎么传
+
+1. **截图**：`c456 screenshot <url> -o .tmp/xxx.png`  
+   - 首页/落地页：**视窗**即可，默认不加 `--full-page`。  
+   - 定价、长文再考虑 `--full-page`。
+2. **上传**：`c456 asset upload -f .tmp/xxx.png`
+3. **塞进正文**：紧跟相关段，媒体级图说；正文里 **不讲** 截图命令、视口、素材 ID 叙事（平台用 `title` 里的 `c456:asset` 即可）。
+
+### 插入格式示例
+
+```markdown
+*[Pinecone Nexus 架构](https://www.pinecone.io/blog/introducing-nexus-knowledge-engine/) — 知识引擎架构图。*
+
+![Nexus 架构](https://c456.com/our-assets/.../xxx.png "c456:asset/YY")
+```
+
+- 图说：**斜体 + 外链**，陌生读者也懂指什么。
+- 不要单开「配图」小节堆工序说明。
+
+## 文风：像研究员投稿，不像模板生成
+
+- **第一句就要落地**：谁、改了什么、对谁刺痛，比「背景介绍」优先。
+- **长短句混用**：判断用短句，限定条件用从句；别全文同一句式长度。
+- **分得清事实和观点**：事实带来源；观点说清 **凭什么**（行业常识、历史类似案例、文档里的前提）。
+- **慎用空洞强调**：「重大」「颠覆性」要有可核对背书，否则改成具体变化。
+- **克制内部腔**：少写「观察：」「可以看到：」；改成「实践里常见的是……」并带场景或来源。
+- **列表与段落**：列表承载并列信息；段承担 **转折、限定、递进**——别为了「简洁」把文章磨成 bullet 墙。
+
+### 少用（除非有意反讽）
+
+记笔记口吻（「今天刷到……」）、无信息帽子段、厂商 PR 整段粘贴、假关联、满屏「可能也许」又不给核实路径。
+
+**不确定时**：写清楚依据断在哪一层（只看到官推 / 只看到二级报道），写「以官方为准」或「待二次核实」，别假装定论。
+
+## 产出前自检
+
+- [ ] 十秒内能答：发生了什么？为什么要关心？
+- [ ] 事实是否都能指回来源？
+- [ ] 价值段有没有 **你的** 判断，而不只是官稿压缩？
+- [ ] 关联段落是真翻过现有内容写出来的吗？
+- [ ] 来源块是否在底部、格式整齐？**来源** 前无孤行 `---`？
+- [ ] 读起来像 **一篇短稿**，不像 checklist 填空？