c456-cli 0.4.0 → 0.6.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "c456-cli",
-  "version": "0.4.0",
+  "version": "0.6.0",
   "description": "C456 CLI - 内容录入与整理工具",
   "type": "module",
   "bin": {
@@ -8,15 +8,15 @@
   },
   "files": [
     "dist",
-    "docs",
-    "skills",
-    "README.md"
+    "README.md",
+    "skills"
   ],
   "scripts": {
     "build": "node scripts/build.js",
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
+    "@inquirer/prompts": "^7.10.1",
     "cfonts": "^3.3.1",
     "commander": "^12.1.0",
     "open": "^10.1.0",

package/skills/c456-cli/SKILL.md

@@ -22,24 +22,27 @@ description: >-
 **推荐**：在目标项目根目录执行（内部调用官方 **`npx skills add`**，需本机可执行 `npx`）：
 
 ```bash
-c456 skill install
+c456 skills install
 ```
 
-私人知识库场景可**一条命令**装齐 **karpathy-wiki**、**c456-llm-wiki** 与 **c456-cli**：
+- **交互终端**：出现**多选菜单**——**`c456-cli` 始终会装**；**`karpathy-wiki`（卡帕西目录约定）**为固定可选项 **[0]**；其余 **`skills/` 下以 `c456-` 为前缀的技能**按序号动态列出（随本包发布更新）。
+- **免交互**：直接跟技能 id，仍会**自动包含 `c456-cli`**，例如：
 
 ```bash
-c456 skill install --with-wiki
+c456 skills install c456-signal-product-vs c456-signal-researcher
 ```
 
-上述流程均为 **`npx skills add` 从网络拉取**（先 `baklib-tools/skills` 的 **karpathy-wiki**，再 GitHub 源的 **c456-llm-wiki** 与 **c456-cli**）。详见 [`docs/private-knowledge-base.md`](../../docs/private-knowledge-base.md) §3。
+- **非交互终端**（无 TTY、且未传技能 id）：仅安装 **`c456-cli`**，并在 stderr 提示可用「显式 id」方式多装。
 
-仅装 **c456-cli**、不要 Wiki 套件时：
+私人知识库场景可**一条命令**装齐 **karpathy-wiki**、**c456-llm-wiki** 与 **c456-cli**：
 
 ```bash
-c456 skill install
+c456 skills install --with-wiki
 ```
 
-顺序为：仅依次尝试 **`c456-cli`** 的 GitHub 源；**失败则退出**（无本地包复制）。可用 **`-C/--cwd`**、**`-g`**、**`-a`**、**`--copy`**，语义与 `skills add` 一致（`-a` 用于指定 Agent，如 `cursor`、`claude-code` 等）。
+上述流程均为 **`npx skills add` 从网络拉取**（`--with-wiki` 时先 `baklib-tools/skills` 的 **karpathy-wiki**，再 GitHub 源的 **c456-llm-wiki** 与 **c456-cli**）。详见 [`docs/private-knowledge-base.md`](../../docs/private-knowledge-base.md) §3。
+
+安装顺序（含菜单多选时）：**karpathy-wiki**（若选）→ **c456-llm-wiki**（若选，优先于其它 `c456-*`）→ 其余所选 **`c456-*`** → **`c456-cli`**。失败则退出（无本地包复制）。可用 **`-C/--cwd`**、**`-g`**、**`-a`**、**`--copy`**，语义与 `skills add` 一致（`-a` 用于指定 Agent，如 `cursor`、`claude-code` 等）。
 
 也可自行执行：
 
@@ -77,7 +80,7 @@ npx skills add . --skill c456-cli -y
 7. **自媒体账号默认收录为渠道**：用户要收录 **YouTube / 抖音 / 小红书 / B 站 / 微博** 等**自媒体账号主页或频道**时，**默认使用 `c456 intake new -k channel`**（不要用 `-k tool`），并配合 `-u <主页或频道 URL>`；需要服务端按 URL 自动填资料段时再加 `--auto-resolve-url`。仅做「不落库的 URL 资料预览/抓取」时用 `c456 fetch profile -p social_account -u "<url>"`。
 8. **渠道（及 tool）必须带至少一条「资料」**：`-k channel` 或 `-k tool` 时，服务端要求 **profile_data 里至少有一条资料段**（例如主页 **URL**、**媒体账号** 等对应 facet），常见做法是 `-u <url>` 并加 **`--auto-resolve-url`** 让服务端生成资料段；如需手写 **`--profile-data-json`**，**必须先阅读** [references/intake-profile-data-json.md](references/intake-profile-data-json.md)（含各 `profile_id`、必填字段与最小 JSON 示例）。**不能只写标题/正文而不提供 URL/资料段**，否则会 **422 校验失败**（提示含「至少添加一个资料段或图标」等）。
 9. **素材库与列表图标**：上传、插入正文、设置 tool/channel 列表图标（`list_icon_url`）见 [references/media-library-and-icons.md](references/media-library-and-icons.md)；CLI：`c456 asset …`、`c456 intake update … --profile-data-json-file`。
-10. **工具 / 渠道介绍里的产品截图**：优先 **`c456 browser start`**（持久 profile：`~/.cache/c456-cli/chrome-profile`，可保留登录态）→ 需要时在窗口内登录 → **`c456 screenshot <url> [-o .tmp/…]`** 复用 CDP；结束用 **`c456 browser stop`**。无长会话时可只跑 **`c456 screenshot <url>`**（可省略 **`-o`**，在当前目录按 URL 生成文件名）。然后 **`c456 asset upload`** → **`markdownSnippet`** 写入 **`--body-file`**。详见 [references/product-screenshots-for-intake.md](references/product-screenshots-for-intake.md)（**不用** IDE MCP；不强制安装 Playwright 自带 Chromium，见 README）。
+10. **工具 / 渠道介绍里的产品截图**：优先 **`c456 browser start`**（持久 profile：`~/.cache/c456-cli/chrome-profile`，可保留登录态）→ 需要时在窗口内登录 → **`c456 screenshot <url> [-o .tmp/…]`** 复用 CDP；结束用 **`c456 browser stop`**。无长会话时可只跑 **`c456 screenshot <url>`**（可省略 **`-o`**，在当前目录按 URL 生成文件名）。然后 **`c456 asset upload`** → **`markdownSnippet`** 写入 **`--body-file`**。**产品官网 / 落地页首屏类截图一律只做视窗截图**：**不要**加 **`-f` / `--full-page`**（默认即为视口高度；整页长图上传后素材处理与阅读体验均易变差）。**仅当**收录时的**产品链接**为 **RubyGems / npm 等包注册表页**（如 **`-u`** 或资料中的包页 URL），并需要**基于该包页**为介绍配截图时：**`c456 screenshot` 的 URL 优先**用 **`c456 fetch profile -p package_registry -u "<该包页完整 URL>"`** 解析出的 **GitHub 仓库根页**（`https://github.com/owner/repo`），**不要**优先直接对 **rubygems.org/gems/…** 或 **www.npmjs.com/package/…** 截图（侧栏多、README 首屏弱；仓库页与 CLI 隐藏文件表一致）。若产品链接已是 **GitHub / 官网 / 文档站**等，或用户**指定了其它截图目标 URL**，则**按该 URL 截图**，**不适用**本条「包页 → GitHub」规则。详见 [references/product-screenshots-for-intake.md](references/product-screenshots-for-intake.md)（**不用** IDE MCP；不强制安装 Playwright 自带 Chromium，见 README）。
 
 ## 命令速查
 
@@ -85,14 +88,14 @@ npx skills add . --skill c456-cli -y
 
 - `c456 config set-key <token> [-g]` / `set-url <url> [-g]` / `show [-g]` / `reset [-g] [-f]`（`-g` = 仅全局 `~/.config/c456`；默认 = 项目 `.c456-cli`）
 
-**技能 `skill`**
+**技能 `skills`**
 
-- `c456 skill install [--with-wiki] [-C <cwd>] [-g] [-a <agent>] [--copy]`（仅 `npx skills add`；`--with-wiki` 时装 karpathy-wiki、c456-llm-wiki 与 c456-cli，见 docs/private-knowledge-base.md §3）
+- `c456 skills install [[skillIds...]] [--with-wiki] [-C <cwd>] [-g] [-a <agent>] [--copy]`（仅 `npx skills add`；无参数且为 TTY 时多选菜单；传 `skillIds` 免交互；`--with-wiki` 时装 karpathy-wiki、c456-llm-wiki 与 c456-cli，见 docs/private-knowledge-base.md §3）
 
 **浏览器（系统 Chrome + CDP）**
 
 - `c456 browser start [-p 端口]` · `stop` · `status`（持久 profile 默认 `~/.cache/c456-cli/chrome-profile`）
-- `c456 screenshot <url> [-o <path>] [--full-page] [--viewport 1280x720] [--wait-after-load ms] [--no-reuse]`（默认 **`--wait-after-load 3000`** 便于 JS/动画；`0` 为不等待；省略 `-o` 时按 URL 生成文件名；默认复用 `browser start`）
+- `c456 screenshot <url> [-o <path>] [--full-page] [--viewport 1280x720] [--wait-after-load ms] [--no-reuse] [--keep-github-files-table]`（默认 **`--wait-after-load 3000`**；**github.com** 默认隐藏 README 上方「文件与目录」表格以突出说明；**产品官网介绍勿加 `--full-page`**，保持视窗截图）
 
 **收录 `intake`**
 
@@ -120,7 +123,7 @@ npx skills add . --skill c456-cli -y
 
 **资料 `fetch`**
 
-- `c456 fetch profile -u <url> -p <profile_id>`（`profile_id` 必填；否则 API 返回「不支持的资料类型」）
+- `c456 fetch profile -u <url> -p <profile_id>`（`profile_id` 必填；否则 API 返回「不支持的资料类型」）。**仅当**你要以**包页 URL 作为产品链接**去截介绍图、且已对该 URL 使用 **`package_registry`** 拉元数据时：若解析结果中含 **GitHub 仓库** 链接，**`c456 screenshot` 可优先使用该仓库根 URL**（非此场景勿生搬），见 [references/product-screenshots-for-intake.md](references/product-screenshots-for-intake.md)。
 
 `profile_id` 类型含义：
 
@@ -129,6 +132,17 @@ npx skills add . --skill c456-cli -y
 - `github_origin`：代码仓库（GitHub/GitLab/Gitee）
 - `social_account`：社交账号主页/频道（YouTube/抖音/小红书等）
 
+## 子技能（references/）
+
+| 子技能 | 用途 | 触发条件 |
+|--------|------|---------|
+| **c456-signal-researcher**（正文仅在 LLM Wiki 仓库 `.cursor/skills/c456-signal-researcher/SKILL.md`） | 以新闻研究员视角生成 signal：事实 → 价值 → 关联 → 来源 | 写信号、收录新闻、发布行业动态 |
+| [intake-profile-data-json](references/intake-profile-data-json.md) | profile_data 字段定义与校验 | 手写 `--profile-data-json` |
+| [media-library-and-icons](references/media-library-and-icons.md) | 素材库上传、正文插图、列表图标 | 配图与图标流程 |
+| [product-screenshots-for-intake](references/product-screenshots-for-intake.md) | 产品截图最佳实践 | tool/channel 收录配图 |
+| [douyin-channel-intake](references/douyin-channel-intake.md) | 抖音渠道收录特殊说明 | 抖音账号收录 |
+| [content-syntax-kramdown](references/content-syntax-kramdown.md) | C456 富文本语法 | 生成/写入正文内容 |
+
 ## 更完整的说明
 
 见各命令的 `--help` 与本仓库 `README.md`、`DEVELOPMENT.md`。
@@ -149,6 +163,6 @@ CLI `--help` 中会用 `type: <type_name>` 标注字段类型；Agent 在生成/
 - **自媒体 / 社交账号**（主页、频道页）：**一律按渠道收录** → `-k channel`；抖音场景补充说明见 [references/douyin-channel-intake.md](references/douyin-channel-intake.md)。
 - **渠道 / 工具**：新建时务必带上 **至少一种结构化资料**（常见：`-u` + `--auto-resolve-url`，或 `--profile-data-json`），否则服务端会因缺少资料段而拒绝保存。
 - **`--profile-data-json`**：键名与校验规则与 Web 端一致，**不要编造字段**；完整说明与示例见 [references/intake-profile-data-json.md](references/intake-profile-data-json.md)（优先自动解析，其次再手写）。**仅改列表图标**见 [references/media-library-and-icons.md](references/media-library-and-icons.md)。
-- **软件 / 产品 / 仓库 / 包页**：一般用 `-k tool`（或用户明确要当「工具资料」收录时）。
-- **产品界面进介绍**：优先 **`c456 browser` + `c456 screenshot`**（见 [references/product-screenshots-for-intake.md](references/product-screenshots-for-intake.md)）→ `asset upload` → `body`（`--body-file`）；**不用** IDE MCP。
+- **软件 / 产品 / 仓库 / 包页**：一般用 `-k tool`（或用户明确要当「工具资料」收录时）。**仅当** **`-u` 或资料中的「产品链接」** 为 **RubyGems / npm 等包注册表页**，且需要**基于该包页**为正文配产品截图时，**`c456 screenshot` 优先**对 **`c456 fetch profile -p package_registry -u "<该包页>"`** 解析出的 **GitHub 仓库根页**截图；包站主要作解析入口。**产品链接非包页**（已是 GitHub、独立官网等）或用户指定其它截图目标时，**按实际 URL**，勿套用本条。详见 [references/product-screenshots-for-intake.md](references/product-screenshots-for-intake.md)「包管理器」节。
+- **产品界面进介绍**：优先 **`c456 browser` + `c456 screenshot`**（见 [references/product-screenshots-for-intake.md](references/product-screenshots-for-intake.md)）→ `asset upload` → `body`（`--body-file`）；**不用** IDE MCP。**官网 / 落地页截图仅视窗**，勿 `-f`。
 

package/skills/c456-cli/references/product-screenshots-for-intake.md

@@ -2,11 +2,31 @@
 
 在收录 **`-k tool`** 或 **`-k channel`** 时，若介绍（`body` / Markdown）需要**真实界面**佐证（官网首屏、产品工作台、渠道主页关键区等），**优先使用 c456-cli 内置命令**（系统 Chrome + `playwright-core` 走 CDP，**不**随包下载 Chromium）：`c456 browser start` 持久 profile → 需要登录时先手动在窗口内登录 → **`c456 screenshot <url> [-o .tmp/…]`** 复用同一浏览器；无长会话需求时可直接 **`c456 screenshot <url>`**（一次性起停；不传 **`-o`** 时在当前目录按 URL 生成文件名）。再经 **`c456 asset upload`** 把图插入正文。
 
+## 视窗 vs 整页（产品官网务必视窗）
+
+- **`c456 screenshot` 默认**即为**当前视口**高度（浏览器窗口可见区域），**不要**为产品官网 / 落地页介绍图加 **`-f` / `--full-page`**。
+- **`--full-page`** 会截取整页可滚动高度；长图上传素材库后体积与展示质量往往更差，**除非用户明确要求整页归档**，否则 Agent 在「产品官网截图」场景**一律省略**该选项。
+
+## GitHub 仓库页（自动隐藏「文件与目录」表）
+
+- **`c456 screenshot`** 在 **github.com** / **www.github.com** 上，于截图前在页面内对目标节点设置 **`display: none !important`**（隐藏 **`table[aria-labelledby="folders-and-files"]`** 等），首屏更突出 README；并配合 **`load`** 与最长约 15s 的节点等待，减轻「表格尚未挂载就执行隐藏」的问题。
+- 若用户或场景需要保留该表格：命令行加 **`--keep-github-files-table`**。
+- 调试 DOM / 隐藏是否生效：加 **`--pause`**（交互式终端），截图前后各按一次 Enter，期间不关闭截图用标签页。
+
+## 包管理器上的工具（RubyGems、npm 等）
+
+以下规则**仅当**收录时的**产品链接**为 **gem / npm 包注册表页**（例如 **`tool new -u`** 或 `profile_data` 中的包页 URL），且 Agent 需要**基于该包页**为介绍正文截产品图时适用；**产品链接已是 GitHub、官网、文档站等**时，**直接对给定链接**（或用户指定的 URL）截图即可，**不要**强行先绕到包站再套本流程。
+
+- 在上述前提下，**`c456 screenshot` 的 URL 优先选**从该包页解析出的 **GitHub 仓库根页**（例如 `https://github.com/rails/rails`），与上节「仓库页突出 README」一致，且 CLI 会隐藏文件表。
+- **不要**把 **rubygems.org/gems/…** 或 **www.npmjs.com/package/…**（及 **npmjs.com**）**作为首选截图地址**（侧栏与元数据占比大，README 在首屏往往不如仓库根页清晰）。
+- **如何拿到 GitHub URL**：对**作为产品链接的那条** gem / npm 包页执行 **`c456 fetch profile -p package_registry -u "<包页完整 URL>"`**，在返回 JSON 中查找 **repository、homepage、bugs、metadata 里的源码/repo 字段**（以实际 API 返回为准），择 **`github.com` 的 `owner/repo` 根路径**用于截图。若无 GitHub（仅 GitLab/Gitee 或闭源），再退化为官方文档站或包页本身。
+- 已直接持有仓库 URL 时，可用 **`c456 fetch profile -p github_origin -u "<仓库 URL>"`** 做资料校验或补充，截图仍对同一 **`https://github.com/...`** 执行即可。
+
 也可在仓库内保留 **自建 Playwright 脚本**（`page.screenshot` 写 `.tmp/`）作为补充；**不推荐 IDE 浏览器 MCP**，以降低配置成本。
 
 ## 适用场景
 
-- 工具：产品落地页、文档站、SaaS 控制台（需已登录则由用户说明或跳过敏感区）。
+- 工具：产品落地页、文档站、SaaS 控制台（需已登录则由用户说明或跳过敏感区）。**当且仅当产品链接为包注册表页且需据此截图时**，开源库 / 包的介绍图 URL **优先** GitHub 仓库根页（见上节「包管理器」）。
 - 渠道：平台内频道/主页的**公开可见**区域（遵守平台 ToS；不要对需付费墙或强反爬页面硬截）。
 
 ## 推荐流程（与 CLI 衔接）
@@ -15,7 +35,7 @@
 
 1. **`c456 browser start`**：在本机选空闲端口，启动**有头**系统 Chrome；用户数据目录默认 **`~/.cache/c456-cli/chrome-profile`**（可用 `XDG_CACHE_HOME` 改缓存根），**同一路径多次启动可保留 Cookie / 登录态**。状态写入同目录下的 `browser-daemon.json`（含 CDP `http://127.0.0.1:<port>`）。
 2. 在打开的窗口中访问需登录的站点并完成登录（若不需要可跳过）。
-3. **`c456 screenshot <https://…> [-o .tmp/capture.png]`**：通过 CDP 新开页导航并截图；**默认复用**上一步的 Chrome；省略 **`-o`** 时在当前目录生成「URL 安全化片段 + 时间戳」的 `.png`。**`c456 browser stop`**：结束该 Chrome 并删除 daemon 记录、释放端口。
+3. **`c456 screenshot <https://…> [-o .tmp/capture.png]`**：通过 CDP 新开页导航并截图；**默认复用**上一步的 Chrome；省略 **`-o`** 时在当前目录生成「URL 安全化片段 + 时间戳」的 `.png`。**产品官网 / 落地页介绍用图保持默认即可，不要加 `-f`/`--full-page`（视窗截图）。** **`c456 browser stop`**：结束该 Chrome 并删除 daemon 记录、释放端口。
 4. 若**不需要**保留会话、只要一张图：可直接 **`c456 screenshot <url>`** 或带 **`-o`**（无 `browser start` 时 CLI 会**临时**起 Chrome、截图后关闭并删除临时 profile）；加 **`--no-reuse`** 可强制走该一次性路径。
 5. **上传素材库**：`c456 asset upload -f .tmp/capture.png` → 取 **`markdownSnippet`**。
 6. **写入介绍正文**：合并进 Markdown，用 **`--body-file`** 传给 `c456 intake new` / `intake update`。

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

@@ -3,8 +3,10 @@ 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, or ingesting content to wiki and c456.com.
+  bidirectional sync, orphan_local, remote-deleted local sync, or ingesting
+  content to wiki and c456.com.
 ---
 
 # LLM Wiki + C456 双向同步
@@ -13,6 +15,16 @@ description: >-
 
 在 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** 自检一遍。
+
 ## 四层架构
 
 ```
@@ -54,6 +66,10 @@ AGENTS.md（Schema） ← 定义 AI 如何组织 Wiki
 
 **关键原则**：`c456-sync/` 与 `wiki/` 之间不用 symlink。关联通过 Frontmatter 引用 + `wiki/c456-meta.yml` 实现。
 
+### c456-sync 与上行正文（执行摘要）
+
+`c456-sync/` 虽是镜像层，正文须视同 **对外读者可读版本**：事实可核对、结构清晰、有推荐结论与诚实边界、CTA 明确；细节与表格见 **`AGENTS.md` §1.3**。
+
 ---
 
 ## 页面类型
@@ -167,12 +183,16 @@ date: 2026-05-08
 
 ### 双向同步
 
-**c456-sync/ 目录**：作为 C456 镜像层，按五类型分目录存储。
+**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` 重发。
+
 ### 状态流转
 
 ```
@@ -227,7 +247,7 @@ C456 ↔ 本地映射总索引。记录每个 C456 ID 的 `sync_path`、`wiki_pa
 
 - **c456-title**：`品牌名 | 定位 · 特色后缀`
 - **c456-summary**：一句话概括核心价值
-- **正文**：包含核心功能模块表、安装方式、适用场景
+- **正文**：包含核心功能模块表、安装方式、适用场景；并自检 **`AGENTS.md` §1.3**（对外可读、可推荐、不夸大）。
 - **实体页**：包含关键属性表（官网、GitHub、stars、许可证、语言）、核心功能、差异化亮点、竞品对比
 - **来源摘要**：包含核心信息、关键功能、开源信息
 

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`。