diff --git a/.claude/skills/dao-analysis b/.claude/skills/dao-analysis new file mode 120000 index 0000000..bbd5c56 --- /dev/null +++ b/.claude/skills/dao-analysis @@ -0,0 +1 @@ +/home/kang/apps/atomstorm-claude-skills/dao-analysis \ No newline at end of file diff --git a/.claude/skills/dao-analysis/SKILL.md b/.claude/skills/dao-analysis/SKILL.md deleted file mode 100644 index e705b6b..0000000 --- a/.claude/skills/dao-analysis/SKILL.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -name: dao-analysis -description: > - Structured 8-layer analysis using Dao-Method-Technique-Tool (道-法-术-器) framework. - Output: a structured insight document with 8 orthogonal layers from Why to Do, - with measurable metrics and iteration rules. - - USE WHEN: User wants to deeply analyze existing content (article, transcript, - concept, experience, system prompt, workflow) to extract layered insights. - Trigger phrases: 道法术器分析、深度分析、拆解、8层框架、extract insights、 - analyze this、break this down、这篇文章为什么火。 - - DON'T USE WHEN: - - User wants to CREATE new content from a topic → use write-article instead. - - User wants to REVIEW/CRITIQUE a draft for publishing quality → use multi-review instead. - - User wants to IMPORT an external file into vault → use import-draft instead. - - User says "写文章"、"生成草稿" → not this skill (creation ≠ analysis). ---- - -# 道-法-术-器 结构化分析技能 - -## 定位 - -将任意信息/素材/经验转化为 8 层结构化洞察体系，从"为何"到"怎么做"到"怎么迭代"，每一层正交、可证伪、可追溯。 - -## 路由规则（Use when / Don't use when） - -Use this skill when: -- 用户提供一段信息（文章、转写、笔记、经验、概念）并要求深度分析 -- 用户明确要求"道法术器分析"或"8 层框架分析" -- 用户需要从素材中提炼可执行的经验体系 -- 用户说"分析"、"拆解"、"为什么火"、"extract insights" - -Do NOT use this skill when: -- 用户想**写新文章**（从选题到草稿） → use `write-article` -- 用户想**审查/批评**已有草稿的发布质量 → use `multi-review` or `/review` -- 用户想**导入**外部文件到 vault → use `import-draft` -- 用户想**加载 vault 上下文** → use `my-world` -- 用户说"写文章"、"生成草稿"、"create a draft" → not this skill - -Edge cases: -- "分析一下这篇文章为什么火" → **this skill**（分析 = dao-analysis） -- "帮我把这篇文章改写成新文章" → **not this skill**（改写创作 = write-article） -- "审查我的草稿质量" → **not this skill**（审查 = multi-review） -- "拆解这个 system prompt 的设计思路" → **this skill**（拆解 = analysis） - -## 输入 - -用户提供以下信息（支持多种形式）： - -| 字段 | 必选 | 说明 | -|------|------|------| -| 信息 | 是 | 原文/要点/转写/URL（如提供 URL，先用 `url-to-markdown` 采集） | -| 使用场景 | 否 | 分析偏向哪个领域（管理/技术/关系/学习等） | -| 偏好语汇 | 否 | `修行`（道家隐喻）或 `中性工程化`（默认） | -| 输出范围 | 否 | `full`（全 8 层，默认）或 `quick`（仅 L0-L4 精简版） | - -## 工作流 - -### Step 1: 读取素材 - -- 若用户提供 vault 内笔记路径，使用 Obsidian CLI 读取 -- 若用户提供 URL，提示可用 `url-to-markdown` 技能先采集 -- 若用户直接粘贴文本，直接使用 - -### Step 2: 证据提取（E# 表） - -在任何分析之前，先提取 6-15 条证据，每条标注： -- 编号 E# -- 原句/要点（短摘） -- 类型：事实 / 观点 / 比喻 / 推测 -- 可信度：高 / 中 / 低（一句话理由） - -> 这是整个分析的地基。后续每个层级的每条结论都必须回溯到 E#。 - -### Step 3: 逐层分析（L0 -> L7） - -严格按顺序执行，不可跳层。每层的判别问题、输出模板、条数要求详见 `references/framework.md`。 - -**层级速览**： - -``` -L0 无极 ─ 信息边界与缺口（不立论，只定范围） -L1 太极 ─ 第一性矛盾（核心张力 A <-> B） -L2 道 ─ Why：目的/价值/取舍（D# 命题） -L3 法 ─ What：世界模型/因果假设（M# 命题） -L4 术 ─ How：原则/策略/决策规则（P# 启发式） -L5 器 ─ Do：动作/工具/话术/流程（T# 工具包） -L6 指标 ─ 加速度/速度/位移观测链 -L7 迭代 ─ 复盘模板 + 更新规则 + 7天实验 -``` - -**正交规则**：每层只回答自己的判别问题。若一条内容同时回答两个层的问题，必须拆分为两条分别归层。 - -**映射规则**：每个低层产物必须标注来自哪些高层结论（ID 引用链）。 - -``` -E# (证据) -> D# (道) -> M# (法) -> P# (术) -> T# (器) - -> 指标 - -> 迭代规则 -``` - -### Step 4: 收束总纲 - -用一句话输出：**"在 X 情境，优先 Y 而非 Z"**，标注对应 D#、M#、P#。 - -### Step 5: 输出格式化 - -- 使用 Markdown 格式，每层用 `## L{n}` 二级标题 -- 编号系统贯穿全文：E#、D#、M#、P#、T# -- quick 模式：只输出 L0-L4，省略 L5-L7 - -## 质量门禁 - -| 检查项 | 要求 | -|--------|------| -| 证据覆盖 | 每个 D#/M#/P# 至少引用 1 个 E# | -| 正交归层 | 无跨层混写（一段只回答一个层的问题） | -| 可证伪性 | 每个 M# 有明确的"若出现__则不成立"信号 | -| 映射完整 | P# 标注来源 D#+M#，T# 标注来源 P# | -| 取舍明确 | 每个 D# 有"宁可__也要__"结构 | -| 指标可测 | L6 每个指标有记录方式、周期、阈值 | - -任一检查项未通过，回退修正后再输出。 - -## 参考资料 - -完整的 8 层框架规范（每层的判别问题、输出模板、条数要求、注意事项）： -- `references/framework.md` — 在执行 Step 3 时加载此文件获取详细规范 diff --git a/.claude/skills/dao-analysis/references/framework.md b/.claude/skills/dao-analysis/references/framework.md deleted file mode 100644 index 7018f7c..0000000 --- a/.claude/skills/dao-analysis/references/framework.md +++ /dev/null @@ -1,134 +0,0 @@ -# 道-法-术-器 八层分析框架 — 完整规范 - -> 源自：`00-inbox/2026-03-02-dao-method-technique-tool-framework.md` - ---- - -## 总规则 - -- **披露顺序不可跳层**：L0 -> L1 -> L2 -> L3 -> L4 -> L5 -> L6 -> L7 -- **归层判别**：一条内容若同时回答两个层的问题，必须拆分为两条分别归层 -- **每条洞察要可落地可证伪**：必须有证据、前提、边界、可观测信号 -- **层间映射**：每个低层产物必须标注来自哪些高层结论（ID 引用） - ---- - -## 证据层（贯穿全程：先给 E# 再推导） - -在进入 L1 之前，先输出"证据表 E#（6-15 条）"： - -| 字段 | 说明 | -|------|------| -| E# | 编号 | -| 原句/要点 | 短摘 | -| 类型 | 事实 / 观点 / 比喻 / 推测 | -| 可信度 | 高 / 中 / 低（一句话理由） | - ---- - -## L0 无极：信息边界与缺口 - -> 不立论，只定范围。 - -输出： -1. **主题范围**一句话（覆盖什么、不覆盖什么） -2. **缺口清单**：若要推到"可执行经验"，还缺哪些信息（<=3 条追问） -3. **风险提示**：这份信息可能有哪些偏见/立场/样本局限（<=3 条） - ---- - -## L1 太极：第一性矛盾（统一场） - -> 回答：**"这份信息在解决哪一个核心矛盾/张力？"** - -输出： -- **核心矛盾**：A <-> B（用对立结构表达） -- **目标方向**：倾向 A 还是倾向 B？为什么（引用证据编号） - ---- - -## L2 一（道 / Why）：目的、价值、取舍 - -> 判别问题：**"什么值得？为了什么？宁可失去什么也要守住什么？"** - -输出 2-5 条，每条模板： -- **道-命题 D#**（一句话） -- **取舍结构**：宁可__也要__ / 优先__而非__ -- **证据引用**：E#... - -注意：这一层只谈"价值与目的"，不谈方法。 - ---- - -## L3 二（法 / What）：世界模型、因果假设 - -> 判别问题：**"世界/人性/组织/关系是如何运作的？因果链是什么？"** - -输出 3-7 条，每条： -- **模型/因果命题 M#**（一句话） -- **关键变量**：X、Y、Z -- **因果方向**：X -> Y（在条件 C 下） -- **证据引用**：E#... -- **可证伪信号**：若出现__则此模型可能不成立 - -注意：这一层只解释"是什么/为什么会这样"，不直接给行动步骤。 - ---- - -## L4 四（术 / How）：原则、策略、决策规则 - -> 判别问题：**"在什么条件下，应当如何选择？"** - -输出 5-12 条，每条： -- **原则/启发式 P#**（规则句：如果...就...；优先...而非...） -- **前提**：成立需要什么 -- **边界**：不适用/会反噬的情况 -- **映射**：来自 D# + M#（必须标注） -- **证据引用**：E#... - -注意：这一层给"决策规则"，不写工具模板细节。 - ---- - -## L5 八（器 / Do）：动作、工具、话术、流程 - -> 判别问题：**"我现在就能照着做吗？能否变成清单/步骤/模板？"** - -输出 3-7 个"工具包 T#"，每个包含： -- **触发场景** -- **目标** -- **步骤**（1-2-3...） -- **话术/模板**（如适用） -- **常见误用 -> 纠偏** -- **映射**：来自 P#（必须标注） - ---- - -## L6 加速度-速度-位移：指标与反馈 - -按"加速度/速度/位移"给指标，形成由高到低的观测链： - -- **加速度指标 A**（驱动变化的变化）：2 个 - - 例：学习/沟通/决策质量的提升率、冲突升级率变化 -- **速度指标 V**（行为频率与强度）：2 个 - - 例：每周复盘次数、关键对话发起次数 -- **位移指标 S**（结果与状态）：2 个 - - 例：关系质量评分、项目结果、睡眠/情绪稳定度 - -每个指标必须写清：如何记录、周期、阈值、对应哪个工具包 T#。 - ---- - -## L7 生生不息：迭代律 - -输出： -1. **复盘模板**（<=5 问） -2. **更新规则**（条件句）： - - 若出现__（信号/指标）-> 保留/增强/删除/改边界（指向 P# / T#） -3. **7 天最小实验**：做什么、记录什么、如何判定有效 - ---- - -## 最终收束 - -用一句话输出总纲：**"在 X 情境，优先 Y 而非 Z"**，并标注它对应的 D#、M#、P#。 diff --git a/.claude/skills/import-draft b/.claude/skills/import-draft new file mode 120000 index 0000000..9e3e5f4 --- /dev/null +++ b/.claude/skills/import-draft @@ -0,0 +1 @@ +/home/kang/apps/atomstorm-claude-skills/import-draft \ No newline at end of file diff --git a/.claude/skills/import-draft/SKILL.md b/.claude/skills/import-draft/SKILL.md deleted file mode 100644 index e7d2f95..0000000 --- a/.claude/skills/import-draft/SKILL.md +++ /dev/null @@ -1,183 +0,0 @@ ---- -name: import-draft -description: "Import external drafts into content-forge vault for publishing workflow. Use when the user has an existing draft file from another project or external location and wants to bring it into the content-forge production pipeline. Trigger words: import draft, 迁移草稿, 入库, 导入文章, bring into vault, move to drafts." ---- - -# Import Draft - -Import external draft files into content-forge vault's `02-drafts/` directory, preparing them for the standard publishing workflow (format → assets → review → publish). - -## When to Use - -Use this skill when: -- User has a draft written outside the vault (another project, external file, etc.) -- User says "import this draft", "migrate this article", "bring into vault" -- Draft needs to go through content-forge publishing pipeline -- Draft may need modifications (image paths, frontmatter, etc.) - -Do NOT use this skill when: -- Draft already exists in `02-drafts/` → use edit commands instead -- User wants to create new content from topic → use `write-article` skill instead - -## Workflow - -### Step 1: Read External Draft - -Read the external draft file using the Read tool. - -``` -Read the file at -``` - -Execution requirements: -- Read the complete file content -- Note the file location and any embedded resources (images, etc.) - -### Step 2: Quality Check - -Analyze the draft and list issues that need fixing before import. - -Check for: -- **Image references**: Are paths correct? Do images exist? -- **Frontmatter**: Does it exist? Is it complete? -- **Structure**: Is the markdown well-formed? -- **Content issues**: Dead links, missing sections, formatting problems - -Output format: - -```markdown -## 草稿检查报告 - -### 文件信息 -- 路径: -- 行数: -- 大小: KB - -### 🔴 必须修改（入库前） -| # | 问题 | 当前 | 建议 | -|---|------|------|------| -| 1 | ... | ... | ... | - -### 🟡 建议修改（可选） -| # | 问题 | 建议 | -|---|------|------| -| 1 | ... | ... | - -### ✅ 无问题项 -- ... -``` - -### Step 3: Wait for User Confirmation - -**CRITICAL**: Do NOT proceed to write without user confirmation. - -Ask the user: -1. Which issues to fix -2. Whether to fix now or import as-is -3. Confirmation before any vault write - -Output: -``` -请确认： -1. 需要修改哪些问题？ -2. 现在修改还是先入库再改？ -3. 确认后我将写入 vault -``` - -### Step 4: Prepare Frontmatter - -Generate standard frontmatter based on content-forge specification. - -Required fields (see `references/frontmatter-spec.md`): -- `id`, `title`, `slug`, `status`, `content_type`, `channels` -- `language`, `source_urls`, `assets`, `cover_image`, `template` -- `owner`, `created_at`, `updated_at` - -Slug generation: -- Extract from filename if possible -- Or generate from title (lowercase, hyphens, no special chars) -- Format: `YYYY-MM-DD-.md` - -### Step 5: Write to Vault - -Write the draft to `02-drafts/` directory. - -```bash -# First cd to vault directory -cd /home/kang/apps/content-forge/content-forge - -# Create the draft file -obsidian create path="02-drafts/-.md" content="" -``` - -Execution requirements: -- Must cd to vault directory first (obsidian CLI bug workaround) -- File must go to `02-drafts/` directory -- Filename must have date prefix - -### Step 6: Set Frontmatter Properties - -Set each frontmatter field using obsidian property:set. - -```bash -# Required fields -obsidian property:set path="02-drafts/-.md" name="id" value="-" -obsidian property:set path="02-drafts/-.md" name="title" value="" -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="slug" value="<slug>" -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="status" value="draft" -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="content_type" value="article" -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="channels" value='["wechat","x"]' type=list -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="language" value="zh-CN" -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="source_urls" value='[]' type=list -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="assets" value='[]' type=list -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="cover_image" value="" -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="template" value="article" -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="owner" value="content-forge" -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="created_at" value="<YYYY-MM-DD>T00:00:00+08:00" -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="updated_at" value="<YYYY-MM-DD>T00:00:00+08:00" -``` - -### Step 7: Migrate Assets (Optional) - -If the draft has images, offer to migrate them to `05-assets/<slug>/`. - -```bash -# Create assets directory -mkdir -p /home/kang/apps/content-forge/content-forge/05-assets/<slug>/ - -# Copy images -cp <external_image_paths> /home/kang/apps/content-forge/content-forge/05-assets/<slug>/ - -# Update draft's assets field -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="assets" value='["05-assets/<slug>/cover.png"]' type=list -``` - -## Output Constraints - -- Always wait for user confirmation before writing to vault -- List all issues before asking for confirmation -- Generate complete frontmatter, don't skip required fields -- Report success/failure clearly after write - -## Quality Checklist - -Before marking complete, verify: -- [ ] External draft fully read -- [ ] Quality issues listed and categorized -- [ ] User confirmed which issues to fix -- [ ] Frontmatter generated per spec -- [ ] Draft written to `02-drafts/` -- [ ] All frontmatter fields set correctly -- [ ] Assets migrated (if applicable) -- [ ] Final verification: `obsidian read path="02-drafts/<file>"` succeeds - -## Failure Handling - -- File not found: Return `[✗] 文件不存在: <path>` -- Vault not accessible: Return `[✗] Vault 不可用，请运行 obsidian vault 检查` -- Write failed: Return `[✗] 写入失败: <error>` and do not proceed -- User denies confirmation: Stop and wait for further instructions - -## References - -- `references/frontmatter-spec.md` — Complete frontmatter specification diff --git a/.claude/skills/import-draft/references/frontmatter-spec.md b/.claude/skills/import-draft/references/frontmatter-spec.md deleted file mode 100644 index 9b007b7..0000000 --- a/.claude/skills/import-draft/references/frontmatter-spec.md +++ /dev/null @@ -1,125 +0,0 @@ -# Frontmatter Specification - -## Required Fields - -All drafts in `01-topics/`, `02-drafts/`, `03-review/`, `04-published/` must contain these fields: - -```yaml ---- -id: "YYYY-MM-DD-slug" # Unique identifier, matches filename -title: "文章标题" # Display title -slug: "article-slug" # URL-friendly identifier -status: "draft" # inbox | topic | draft | formatting | review | polish | publishing | published | revision | blocked | archived -content_type: "article" # article | thread | x-post | wechat-post | infographic -channels: ["wechat", "x"] # Target publish channels -language: "zh-CN" # Language code -source_urls: [] # Original source URLs if any -assets: [] # Vault-relative paths to images/files -cover_image: "" # Path to cover image -template: "article" # Template used -owner: "content-forge" # Content owner -created_at: "YYYY-MM-DDT00:00:00+08:00" # ISO 8601 timestamp -updated_at: "YYYY-MM-DDT00:00:00+08:00" # ISO 8601 timestamp -published_at: null # Set when published ---- -``` - -## Optional Fields - -```yaml -# Cycle tracking -cycle_days: null # Days from creation to publish -stage_days: # Days spent in each stage - inbox: 0 - topic: 0 - draft: 0 - review: 0 - total: 0 - -# Promotion fields (for /promote command) -promotion_status: null # null | planned | promoting | converted | paused -promotion_channels: [] # ["newsletter", "webinar", "x-thread", "linkedin"] -holding_patterns: [] # ["email-list", "youtube", "podcast"] -conversion_type: null # null | "lead-magnet" | "webinar" | "product-sale" -repurposed_from: null # slug of original content -repurposed_to: [] # slugs of derivative content -evergreen: false # Can be re-promoted? - -# Write-article skill extensions -style: "tech_blog" # tech_blog | opinion | tutorial | social_short -audience: "developers" # Target audience -tags: [] # Content tags -source_notes: [] # Obsidian note paths used as source - -# Review & Polish (managed by /review command) -review_status: null # null | pending | in_progress | passed | failed -review_issues: [] # [{id, category, severity, description, status}] - # category: structure | factual | style | format - # severity: critical | high | medium | low -review_passed_at: null # ISO 8601 timestamp when review passed -polish_status: null # null | pending | skipped | done -polish_version: 0 # Incremented on each polish iteration -polished_at: null # ISO 8601 timestamp when polish completed -revision_count: 0 # Number of revision cycles (max 3) -revision_history: [] # [{date, issues_fixed: [], notes}] -``` - -## Status Workflow - -``` -inbox → topic → draft → formatting → review → polish → publishing → published - ↓ ↓ ↓ - revision ←───────── blocked - ↓ - archived -``` - -### Review → Polish Flow - -``` - ┌─────────────┐ - │ review │ - └──────┬──────┘ - │ - ┌────────────┼────────────┐ - ▼ ▼ ▼ - ┌──────────┐ ┌──────────┐ ┌──────────┐ - │ passed │ │ failed │ │ revision │ - └────┬─────┘ └────┬─────┘ └────┬─────┘ - │ │ │ - ▼ ▼ │ - ┌──────────┐ ┌──────────┐ │ - │ polish │ │ blocked │◄┘ - └────┬─────┘ └──────────┘ - │ ▲ - ▼ │ (revision_count > 3) - ┌──────────┐ │ - │publishing│───────────┘ - └──────────┘ -``` - -### Revision Rules - -- **Trigger**: Critical ≥ 1 OR High > 1 -- **Limit**: revision_count ≤ 3 per article -- **Overflow**: auto → blocked for human decision - -## Field Constraints - -- `id` and `slug` must be unique across all stages -- `status` can only progress forward (with exceptions for revision/blocked) -- `assets` must use vault-relative paths (e.g., `05-assets/slug/image.png`) -- `channels` determines which publish skills to use -- `created_at` never changes after initial creation -- `updated_at` changes on every modification - -## Naming Convention - -Files: `YYYY-MM-DD-<slug>.md` -- Date: creation or import date -- Slug: lowercase, hyphens only, no special chars -- Example: `2026-03-03-claude-code-auto-memory-deep-dive.md` - -Assets: `05-assets/<slug>/filename.ext` -- Assets live in a directory named after the slug -- Example: `05-assets/claude-code-auto-memory/cover.png` diff --git a/.claude/skills/multi-review b/.claude/skills/multi-review new file mode 120000 index 0000000..992e6ee --- /dev/null +++ b/.claude/skills/multi-review @@ -0,0 +1 @@ +/home/kang/apps/atomstorm-claude-skills/multi-review \ No newline at end of file diff --git a/.claude/skills/multi-review/SKILL.md b/.claude/skills/multi-review/SKILL.md deleted file mode 100644 index 23eb323..0000000 --- a/.claude/skills/multi-review/SKILL.md +++ /dev/null @@ -1,218 +0,0 @@ ---- -name: multi-review -description: > - Use MCO (Multi-CLI Orchestrator) to run parallel content review across multiple AI agents. - Output: structured findings report with severity, consensus/divergence, and actionable fixes. - - USE WHEN: User wants to review/critique an existing draft or topic for quality, - accuracy, or readability using multiple AI perspectives. - Trigger phrases: 审查、review、critique、多角度审查、cross-check、质量检查。 - - DON'T USE WHEN: - - User wants to CREATE new content from a topic → use write-article instead. - - User wants to deeply ANALYZE content structure (dao framework) → use dao-analysis instead. - - User wants to IMPORT an external file → use import-draft instead. - - User wants to see vault status → use my-world instead. - - User says "写文章"、"生成草稿"、"分析为什么火" → not this skill. ---- - -# multi-review — Multi-Agent Content Review - -Use MCO (Multi-CLI Orchestrator) to run parallel content review across multiple AI agents, combining perspectives for comprehensive feedback. - -## 路由规则（Use when / Don't use when） - -Use this skill when: -- Reviewing drafts before publication (`03-review/` stage) -- Evaluating topic quality and angles (`01-topics/` stage) -- Cross-checking technical accuracy in tech blogs -- Getting diverse feedback on content structure -- 用户说"审查我的草稿"、"review this"、"帮我检查质量" - -Do NOT use this skill when: -- 用户想**写新文章**（从选题到草稿） → use `write-article` -- 用户想**深度分析**内容（道法术器框架） → use `dao-analysis` -- 用户想**导入**外部文件到 vault → use `import-draft` -- 用户想**加载 vault 上下文** → use `my-world` - -Edge cases: -- "审查我的草稿" → **this skill**（审查 = multi-review） -- "分析这篇文章为什么火" → **not this skill**（深度分析 = dao-analysis） -- "帮我把草稿改好" → **this skill**（改好需要先审查发现问题） -- "写一篇新文章" → **not this skill**（创作 = write-article） - -## Prerequisites - -```bash -mco doctor -# Should show at least 2 providers READY -``` - -## Workflow - -### Step 1: Identify Target Content - -```bash -cd /home/kang/apps/content-forge/content-forge -obsidian files folder="02-drafts" -obsidian files folder="03-review" -``` - -### Step 2: Read Content to Review - -```bash -obsidian read path="<file-path>" -``` - -### Step 3: Run Multi-Agent Review - -Use MCO to get feedback from multiple agents: - -```bash -mco review --repo /home/kang/apps/content-forge \ - --prompt "Review the content in <file-path> for: -1. Clarity and readability -2. Technical accuracy -3. Structure and flow -4. Missing information or gaps -5. Suggestions for improvement - -Provide specific, actionable feedback." \ - --providers claude,codex \ - --target-paths content-forge/<file-path> \ - --synthesize \ - --format report -``` - -### Step 4: Synthesize Results - -When `--synthesize` is enabled, MCO will: -1. Collect findings from all agents -2. Deduplicate similar issues -3. Track which agent found what (`detected_by`) -4. Generate a consensus/divergence summary - -### Step 5: Apply Feedback - -Review the synthesized output and decide which suggestions to incorporate. Update the content manually (Golden Rule: Agents Read, Humans Write). - -## Claude Provider Configuration - -MCO-Plus supports custom configuration for the Claude provider via `--provider-permissions-json`: - -### Switch cc Environment - -Use a different cc-managed API endpoint: - -```bash -mco run --prompt "..." --providers claude \ - --provider-permissions-json '{"claude":{"cc_env":"bigmodel"}}' -``` - -Available cc environments (check with `cc ls`): -- `88` — 88code.org -- `bigmodel` — 智谱 BigModel -- `cclaude` — cclaude.codes -- `relay` — relay.nf.video -- `vibe` — vibe.codesuc.top - -### Switch Model - -Specify Claude model: - -```bash -mco run --prompt "..." --providers claude \ - --provider-permissions-json '{"claude":{"model":"opus"}}' -``` - -Model options: `opus`, `sonnet`, `haiku`, or full model name (e.g., `claude-sonnet-4-6`) - -### Combined Usage - -```bash -mco review --repo /home/kang/apps/content-forge \ - --prompt "Review this content" \ - --providers claude,codex \ - --provider-permissions-json '{"claude":{"cc_env":"bigmodel","model":"sonnet"}}' \ - --target-paths content-forge/02-drafts/<file>.md \ - --synthesize -``` - -## Output Format - -MCO returns structured findings: - -``` -=== Multi-Agent Review === -Task: Review <file-path> -Providers: claude, codex - -## Findings (deduplicated) - -### Issue 1: [description] -- Severity: High/Medium/Low -- Detected by: claude, codex -- Location: [specific section] -- Suggestion: [actionable fix] - -### Issue 2: [description] -... - -## Consensus -- Points all agents agreed on - -## Divergence -- Points where agents disagreed - -## Summary -- Total issues: X -- Critical: Y -- Suggestions: Z -``` - -## Integration with Content Pipeline - -| Stage | MCO Use Case | -|-------|--------------| -| `01-topics` | Evaluate topic quality, identify gaps | -| `02-drafts` | Pre-review feedback before human review | -| `03-review` | Parallel expert review | -| `04-published` | Post-mortem analysis for improvement | - -## Example Prompts - -### Draft Review -``` -Review this draft for clarity, accuracy, and engagement. -Focus on: technical correctness, logical flow, reader value. -``` - -### Topic Evaluation -``` -Evaluate this topic idea for: -1. Reader interest potential -2. Uniqueness vs existing content -3. Suggested angles to explore -``` - -### Technical Accuracy Check -``` -Verify all technical claims in this content. -Flag any inaccuracies or outdated information. -Suggest corrections with sources. -``` - -## Configuration - -Default providers: `claude,codex` (both ready on this system) - -To add more providers: -- `gemini` — requires Gemini CLI installed -- `opencode` — requires OpenCode installed -- `qwen` — requires Qwen Code installed - -## Reference - -- MCO-Plus Fork: https://github.com/CSZHK/mco-plus -- Original MCO: https://github.com/mco-org/mco -- cc Skill: `~/.claude/skills/cc/` (Claude Multi-Environment Manager) diff --git a/.claude/skills/my-world b/.claude/skills/my-world new file mode 120000 index 0000000..c303bd2 --- /dev/null +++ b/.claude/skills/my-world @@ -0,0 +1 @@ +/home/kang/apps/atomstorm-claude-skills/my-world \ No newline at end of file diff --git a/.claude/skills/my-world/SKILL.md b/.claude/skills/my-world/SKILL.md deleted file mode 100644 index d3ff74c..0000000 --- a/.claude/skills/my-world/SKILL.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -name: my-world -description: > - One-shot context loader for the content-forge Obsidian vault. Loads projects, - topics, drafts, knowledge graph, and current priorities into context. - - USE WHEN: User wants to see what's in the vault, check pipeline status, - or start a session with full context awareness. Trigger phrases: 加载上下文、 - vault 状态、我的世界、what's in my vault、load context、show pipeline。 - - DON'T USE WHEN: - - User wants to CREATE new content → use write-article instead. - - User wants to ANALYZE existing content deeply → use dao-analysis instead. - - User wants to REVIEW a draft → use multi-review instead. - - User wants to IMPORT an external file → use import-draft instead. - - User says "写文章"、"分析"、"审查" → not this skill (read-only context loading only). ---- - -# /my-world — Load My World - -Load the entire content-forge vault context into the current session in one shot. - -## 路由规则（Use when / Don't use when） - -Use this skill when: -- Session 开始时需要加载 vault 全量上下文 -- 需要查看当前 pipeline 状态（哪些选题/草稿/审核中） -- 需要了解知识图谱状态（orphans, dead ends, unresolved links） -- 用户说"加载上下文"、"vault 状态"、"我有什么在做" - -Do NOT use this skill when: -- 用户想**写新文章** → use `write-article` -- 用户想**分析/拆解**内容 → use `dao-analysis` -- 用户想**审查**草稿质量 → use `multi-review` -- 用户想**导入**外部文件 → use `import-draft` - -Edge cases: -- "帮我看看 vault 里有什么" → **this skill**（查看 = context loading） -- "写一篇关于 XX 的文章" → **not this skill**（创作 = write-article） -- "分析一下我的草稿" → **not this skill**（分析 = dao-analysis 或 multi-review） - -## What It Does - -1. Read vault stats (file count, tags, recent activity) -2. Scan all active content (topics, drafts, in-review) -3. Map the knowledge graph (backlinks, wikilinks, orphans) -4. Surface current priorities and blockers -5. Present a concise world-view summary - -## Important: Vault Directory - -All `obsidian` CLI commands must run from within the vault directory to auto-detect the vault: - -```bash -cd /home/kang/apps/content-forge/content-forge -``` - -Run all subsequent commands after this `cd`. The `vault=` parameter is unreliable; directory-based detection is the correct approach. - -## Execution Steps - -### Step 1: Vault Health - -```bash -cd /home/kang/apps/content-forge/content-forge -obsidian vault -obsidian files total -obsidian tags counts sort=count -``` - -### Step 2: Active Content Pipeline - -Scan each pipeline stage for active items: - -```bash -obsidian files folder="00-inbox" -obsidian files folder="01-topics" -obsidian files folder="02-drafts" -obsidian files folder="03-review" -obsidian files folder="04-published" -``` - -For each file found, read its frontmatter to extract `title`, `status`, `content_type`, `channels`: - -```bash -obsidian properties path="<file-path>" -``` - -### Step 3: Knowledge Graph - -```bash -obsidian orphans -obsidian deadends -obsidian unresolved -``` - -### Step 4: Recent Activity - -```bash -obsidian recents -``` - -### Step 5: Summarize - -Present a concise summary in this format: - -``` -=== My World === - -Vault: content-forge (X files, Y tags) - -Pipeline: - inbox: N items - topics: N items (list titles) - drafts: N items (list titles + status) - review: N items (list titles) - published: N items total - -Knowledge Graph: - Orphans: N (notes with no incoming links) - Dead ends: N (notes with no outgoing links) - Unresolved: N (broken [[wikilinks]]) - -Recent: (last 5 files touched) - -Priorities: - - (inferred from draft/review status and recency) -``` - -## Output - -A structured world-view that gives full context for the session. No files are written — this is read-only. diff --git a/.claude/skills/paper-illustration b/.claude/skills/paper-illustration new file mode 120000 index 0000000..4311430 --- /dev/null +++ b/.claude/skills/paper-illustration @@ -0,0 +1 @@ +/home/kang/apps/atomstorm-claude-skills/paper-illustration \ No newline at end of file diff --git a/.claude/skills/paper-illustration/ARCHITECTURE.md b/.claude/skills/paper-illustration/ARCHITECTURE.md deleted file mode 100644 index 207a850..0000000 --- a/.claude/skills/paper-illustration/ARCHITECTURE.md +++ /dev/null @@ -1,128 +0,0 @@ -# paper-illustration Skill Architecture - -## File Budget - -``` -.claude/skills/paper-illustration/ -├── SKILL.md ~280 行 ~1,800 字 接口层（工作流 + 约束） -├── ARCHITECTURE.md ~120 行 ~800 字 架构总览（本文件） -└── references/ - ├── illustration-taxonomy.md ~210 行 ~1,400 字 6 种图表类型分类 + prompt 模板 - ├── academic-styles.md ~185 行 ~1,200 字 5 种会议风格规范 - └── critic-checklist.md ~130 行 ~800 字 5 维度 20 项质量检查 - ───────────────── - ~925 行 ~6,000 字 总上下文消耗 -``` - -## Progressive Disclosure Architecture - -``` -Agent 加载顺序（上下文消耗） -───────────────────────────────────────────────────────────── - -第 1 层：SKILL.md（必加载，~1,800 字） -┌──────────────────────────────────────────────────────────┐ -│ frontmatter 触发匹配 + 路由规则 │ -│ 输入要求 2 必填 + 8 可选 │ -│ 决策树 figure_type 自动检测 │ -│ 路由表 figure_type → backend 映射 │ -│ 6 步工作流 摘要+指针，不含详细规则 │ -│ 8 条 NEVER 零容忍规则 │ -│ 失败处理 6 种失败模式 │ -└──────────────┬───────────────────────────────────────────┘ - │ 按需加载（只在对应 Step 触发时读取） - ▼ -第 2 层：references/（按需，~3,400 字） -┌────────────────────────┐ ┌───────────────────┐ ┌──────────────────┐ -│ illustration-taxonomy │ │ academic-styles │ │ critic-checklist │ -│ │ │ │ │ │ -│ Step 1 → §1-§6 分类 │ │ Step 3 → 风格参数 │ │ Step 5 → 评估 │ -│ Step 1 → §7 自动检测 │ │ Step 4 → 色值/字号 │ │ │ -│ Step 4 → §8 prompt 模板│ │ │ │ │ -└────────────────────────┘ └───────────────────┘ └──────────────────┘ - │ - ▼ -第 3 层：外部依赖（运行时） -┌──────────────────────────────────────────────────────────┐ -│ basic-image-gen skill AI 图像生成 │ -│ matplotlib/seaborn 代码生成（用户本地 Python） │ -│ obsidian CLI vault 资产管理 │ -└──────────────────────────────────────────────────────────┘ -``` - -## 6-Step Workflow x File Dependency Matrix - -``` -Step 名称 SKILL.md taxonomy styles checklist basic-image-gen vault -──── ──── ──────── ──────── ────── ───────── ────────────── ───── - 1 Retrieve & Classify ✓ 指令 ✓ §1-§7 ✓ obsidian read - 2 Plan Blueprint ✓ 模板 - 3 Apply Style ✓ 约束 ✓ 全文 - 4 Generate Figure ✓ 路由 ✓ §8 prompt ✓ 色值 ✓ conceptual - 5 Critic Evaluation ✓ 约束 ✓ 全文 - 6 Archive to Vault ✓ 模板 ✓ obsidian property:set -``` - -Step 4 是资源消耗峰值——同时需要 taxonomy（prompt 模板）+ styles（色值字号）+ basic-image-gen（外部 skill）。这是合理的：生成阶段是整个 skill 的核心价值所在。 - -## Content-Forge Pipeline Integration - -``` -content-forge 生产线 paper-illustration 覆盖范围 -────────────────────────────────────────────────────────────── - -S0 选题入库 ──▶ 01-topics/*.md - │ -S2 草稿生成 ──▶ write-article - │ -S4 格式清洗 ──▶ format-markdown - │ - ┌─────────────────────────────────────────────┐ - │ S5 视觉资产 │ - │ │ - │ ┌─ paper-illustration ◀── NEW (学术图表) │ - │ │ Step 1: 读取源笔记 + 分类 figure_type │ - │ │ Step 2: Figure Blueprint │ - │ │ Step 3: 风格参数（NeurIPS/ICML/...） │ - │ │ Step 4: matplotlib 代码 / AI 图像 │ - │ │ Step 5: Critic 5 维度评估 │ - │ │ Step 6: 存入 05-assets/ │ - │ │ │ - │ ├─ baoyu-cover-image（社媒封面） │ - │ ├─ baoyu-article-illustrator（博客配图） │ - │ └─ baoyu-xhs-images（小红书配图） │ - └─────────────────────────────────────────────┘ - │ -S6 审核 ──▶ /review + /multi-review - │ -S8 发布 ──▶ post-to-wechat / post-to-x -``` - -paper-illustration 与 baoyu-* 系列平级，在 S5（视觉资产）阶段按内容类型路由：学术内容走 paper-illustration，社媒内容走 baoyu-*。 - -## Differentiation Matrix - -``` - paper-illustration baoyu-article-illustrator baoyu-cover-image - ───────────────── ──────────────────────── ───────────────── -目的 信息性学术图表 装饰性博客配图 社媒封面图 -输出 图片 + 可复现代码 仅图片 仅图片 -受众 学术审稿人 博客读者 社媒用户 -文字处理 标签/坐标轴/图例 极少装饰文字 标题文字 -可复现性 必须（代码输出） 无需 无需 -后端 matplotlib + AI AI only AI only -质量检查 20 项 Critic 无结构化检查 无结构化检查 -迭代 ≤3 轮 无 无 -``` - -## Architecture Scorecard - -| Dimension | Rating | Notes | -|-----------|--------|-------| -| Progressive Disclosure | PASS | SKILL.md 摘要+指针，3 个 reference 按需加载 | -| Cross-File Consistency | PASS | 图表类型名在 SKILL.md 和 taxonomy.md 完全一致 | -| Single Responsibility | PASS | taxonomy=分类, styles=风格, checklist=评估 | -| Extensibility | PASS | 新增会议风格只需扩展 academic-styles.md | -| Vault Integration | PASS | 读取 obsidian read, 归档 property:set + 05-assets/ | -| Quality Assurance | PASS | 20 项 Critic checklist, 18/20 pass threshold, ≤3 rounds | -| Context Efficiency | PASS | 总量 ~6,000 字，Step 4 峰值 ~3 源（合理，生成阶段固有复杂度） | diff --git a/.claude/skills/paper-illustration/SKILL.md b/.claude/skills/paper-illustration/SKILL.md deleted file mode 100644 index 0a211b1..0000000 --- a/.claude/skills/paper-illustration/SKILL.md +++ /dev/null @@ -1,368 +0,0 @@ ---- -name: paper-illustration -description: > - Generate publication-quality academic paper illustrations from scientific - content. 6 figure types: architecture diagrams, data plots, conceptual - illustrations, process flows, comparison charts, result visualizations. - Outputs AI-generated images (via basic-image-gen) or reproducible code - (matplotlib/mermaid/TikZ). Academic style compliance (NeurIPS/ICML/ACL/IEEE). - - USE WHEN: User wants to create academic figures, paper illustrations, or - scientific diagrams from vault notes or raw content. - Trigger phrases: 论文插图、学术配图、paper figure、scientific illustration、 - 架构图、实验结果图、ablation figure、generate figures for paper、 - 数据可视化、流程图、对比图、概念图。 - - DON'T USE WHEN: - - User wants decorative blog illustrations → use baoyu-article-illustrator. - - User wants social media cover images → use baoyu-cover-image. - - User wants infographics for Xiaohongshu → use baoyu-xhs-images. - - User wants general AI image generation → use basic-image-gen directly. - - User says "封面"、"配图"、"社媒" without academic context → not this skill. ---- - -# Paper-Illustration: Academic Figure Generation Skill - -## Purpose - -Generate publication-quality figures from scientific content with reproducible code output. Every data-driven figure must be reproducible from code; every conceptual figure must be visually precise. - -Core principle: **Code-first, AI-image fallback** — data figures (plots, charts) always go through matplotlib/seaborn code generation (text accuracy guaranteed); conceptual figures go through `basic-image-gen` (AI excels at creative visuals). - -## Routing Rules (Use when / Don't use when) - -Use this skill when: -- User wants **academic-quality** figures for papers, presentations, or technical reports -- User says "论文插图"、"paper figure"、"实验结果图"、"ablation study plot" -- Content involves data visualization, system architecture, or scientific processes -- User needs **reproducible** figure code (matplotlib, mermaid, TikZ) - -Do NOT use this skill when: -- User wants **decorative** blog/social illustrations → `baoyu-article-illustrator` -- User wants **cover images** for articles → `baoyu-cover-image` -- User wants **infographics** for social media → `baoyu-xhs-images` or `baoyu-infographic` -- User wants **general AI images** without academic context → `basic-image-gen` -- Content has no scientific/technical structure to visualize - -Edge cases: -- "帮我画个系统架构图" with paper context → **this skill** (academic architecture diagram) -- "帮我画个系统架构图" for blog post → **not this skill** (use baoyu-article-illustrator) -- "生成实验对比图" → **this skill** (data-driven, needs reproducible code) -- "做个信息图" → **not this skill** (use baoyu-infographic) - -## Input Requirements - -Required: -- `source`: Vault note path OR raw text content describing the figure subject -- `figure_type`: One of 6 types (auto-detected if omitted, see Decision Tree below) - -Optional: -- `venue`: Academic venue style — `neurips` (default) | `icml` | `acl` | `ieee` | `nature` -- `output_format`: `code` (default for data types) | `image` (default for conceptual) | `both` -- `slug`: Asset slug for vault storage (derived from source note if omitted) -- `caption`: Figure caption (generated if omitted) -- `data`: Inline data dict/CSV for data-driven figures -- `colorblind_mode`: `true` | `false` (default: `true` — always colorblind-safe) -- `subfigures`: Number of subfigures (for multi-panel layouts) -- `dpi`: Output resolution (default: 300, minimum: 150) -- `language`: Label language — `en` (default) | `zh-CN` - -## Figure Type Decision Tree - -``` -Source content analysis - │ - ├─ Contains numeric data / experimental results? - │ ├─ Comparing methods/models? ─────────────── comparison-chart - │ ├─ Showing trends / distributions? ────────── data-plot - │ └─ Showing ablation / metrics table? ──────── result-visualization - │ - ├─ Describes a system / model architecture? - │ └─ Has components + connections? ──────────── architecture-diagram - │ - ├─ Describes a sequential process / pipeline? - │ └─ Has ordered steps + decisions? ─────────── process-flow - │ - └─ Describes an abstract concept / metaphor? - └─ Needs creative visual representation? ──── conceptual -``` - -## Figure Type → Backend Routing - -``` -figure_type Primary Backend Fallback -───────────────────── ───────────────────── ──────────────── -architecture-diagram Mermaid → basic-image-gen TikZ -data-plot matplotlib code —（code only） -conceptual basic-image-gen SVG description -process-flow Mermaid flowchart TikZ -comparison-chart matplotlib code —（code only） -result-visualization matplotlib/seaborn code —（code only） -``` - -**Key constraint**: Data-driven types (data-plot, comparison-chart, result-visualization) NEVER use AI image generation. Text on axes, labels, and legends must be pixel-perfect — only code can guarantee this. - -## Mandatory Workflow (6 Steps — No Skipping) - -### Step 1: Retrieve & Classify - -Read source content and classify figure type. Load `references/illustration-taxonomy.md` for classification guidance. - -```bash -# If source is a vault note path -cd "${VAULT_PATH:-/home/kang/apps/content-forge/content-forge}" -obsidian read path="<source_note_path>" -``` - -Actions: -- Read all source material (vault notes, inline data, referenced papers) -- Auto-detect `figure_type` using the Decision Tree above (if not provided) -- Extract key elements: entities, relationships, data points, labels -- Confirm figure_type with user if ambiguous - -Output: -``` -## Figure Classification - -- Source: [vault path or "inline content"] -- Detected type: [figure_type] -- Key elements: [list of entities/data points] -- Confidence: [high/medium/low] -- [?] Ambiguous — suggest [type_a] or [type_b], awaiting user choice (if low confidence) -``` - -### Step 2: Plan the Figure (Blueprint) - -Generate a structured Figure Blueprint describing the visual composition. - -Blueprint format: -```yaml -figure_blueprint: - type: <figure_type> - title: "<descriptive title>" - caption: "<self-contained caption describing content and key findings>" - dimensions: - width: <inches> - height: <inches> - aspect_ratio: "<W:H>" - layout: - grid: "<NxM>" # for subfigures - elements: - - id: "element_1" - type: "<box|arrow|label|axis|legend|...>" - content: "<text or data reference>" - position: "<relative position description>" - data_mapping: # for data-driven types only - x_axis: "<variable name>" - y_axis: "<variable name>" - series: ["<method_1>", "<method_2>"] - error_bars: true/false - text_elements: - labels: ["<label_1>", "<label_2>"] - annotations: ["<annotation_1>"] -``` - -Constraints: -- Every text element must be explicitly listed (no implicit labels) -- Data mappings must reference actual data from Step 1 -- Caption must be self-contained (understandable without reading the paper) - -### Step 3: Apply Academic Style - -Load `references/academic-styles.md` and apply venue-specific styling to the Blueprint. - -Style augmentation adds: -- Color palette (hex values, colorblind-safe) -- Font family and sizes (axis labels, titles, legends) -- Line widths and marker styles -- Figure size constraints (single-column vs double-column) -- Caption format (numbered, style-specific) - -Output: Enhanced Blueprint with all visual parameters specified as concrete values (no "use default" — every parameter must be a number or hex code). - -### Step 4: Generate Figure - -Route to the appropriate backend based on figure_type. - -#### 4a. Code-based generation (data-plot, comparison-chart, result-visualization) - -Generate complete, runnable Python code: - -```python -import matplotlib.pyplot as plt -import matplotlib -import numpy as np -# import seaborn as sns # if needed - -# --- Style Configuration (from Step 3) --- -matplotlib.rcParams.update({ - 'font.family': '<font_family>', - 'font.size': <base_size>, - 'axes.labelsize': <label_size>, - 'axes.titlesize': <title_size>, - 'legend.fontsize': <legend_size>, - 'figure.dpi': <dpi>, -}) - -# --- Data --- -# <data from Step 1, hardcoded for reproducibility> - -# --- Plot --- -fig, ax = plt.subplots(figsize=(<width>, <height>)) - -# <plotting code> - -# --- Labels & Legend --- -ax.set_xlabel('<x_label>') -ax.set_ylabel('<y_label>') -ax.legend(loc='best', frameon=True) - -# --- Output --- -plt.tight_layout() -plt.savefig('<slug>_fig.png', dpi=<dpi>, bbox_inches='tight') -plt.savefig('<slug>_fig.pdf', bbox_inches='tight') # vector format -plt.show() -``` - -**Code output rules**: -- Print code to terminal (NEVER write .py files to vault) -- All data must be inline (no external file references) -- Must include both raster (PNG) and vector (PDF) save commands -- Must include `tight_layout()` and explicit DPI -- Must include all imports at the top - -#### 4b. Mermaid-based generation (architecture-diagram, process-flow) - -Generate Mermaid code, then optionally render via `basic-image-gen` for high-quality output: - -```mermaid -graph TD - A[Component A] --> B[Component B] - B --> C{Decision} - C -->|Yes| D[Output 1] - C -->|No| E[Output 2] -``` - -For AI-enhanced rendering: -- Convert Mermaid to a detailed text description -- Use `basic-image-gen` with academic-style prompt (from Step 3) -- Prompt template: see `references/illustration-taxonomy.md` - -#### 4c. AI image generation (conceptual) - -Use `basic-image-gen` with a carefully engineered prompt: -- Include all text elements from Blueprint (labels, annotations) -- Specify exact colors from venue palette -- Request "clean, minimalist, scientific illustration style" -- Specify "white background, no decorative elements, no shadows, no 3D effects" - -### Step 5: Critic Evaluation - -Load `references/critic-checklist.md` and evaluate the generated figure. - -5 dimensions, 20 items — every item scored PASS/FAIL: -- **Clarity** (5 items): caption, labels, hierarchy, overlap, whitespace -- **Accuracy** (4 items): data fidelity, encoding, axes, error bars -- **Style** (5 items): palette, colorblind, grayscale, fonts, size -- **Reproducibility** (3 items): code completeness, imports, output config -- **Caption** (3 items): content description, key findings, subfigure refs - -Evaluation output: -``` -## Critic Evaluation — Round N/3 - -| Dimension | Score | Issues | -|-----------------|-------|--------| -| Clarity | 4/5 | [!] Legend overlaps data points | -| Accuracy | 4/4 | — | -| Style | 5/5 | — | -| Reproducibility | 3/3 | — | -| Caption | 2/3 | [!] Missing key finding in caption | - -Overall: REVISE (16/20, threshold: 18/20) - -Revision actions: -1. Move legend to upper-left corner -2. Add "Method A outperforms by 12%" to caption -``` - -**Iteration rules**: -- Threshold: 18/20 to PASS -- Maximum 3 revision rounds -- Each revision must address ALL flagged issues -- If round 3 still fails: output with `[!] Quality warning` and list remaining issues - -### Step 6: Archive to Vault - -Store final assets and update vault metadata. - -```bash -cd "${VAULT_PATH:-/home/kang/apps/content-forge/content-forge}" - -# Create asset directory (if source is vault note) -# mkdir -p "05-assets/<slug>/" - -# For code-based figures: user runs the code, saves output to 05-assets/<slug>/ -# For AI-generated figures: basic-image-gen saves to 05-assets/<slug>/ - -# Update source note's frontmatter (if vault note) -obsidian property:set path="<source_note_path>" name="assets" \ - value='["05-assets/<slug>/<filename>.png"]' -``` - -Output summary: -``` -## Figure Generation Complete - -[✓] Type: <figure_type> -[✓] Backend: <matplotlib|mermaid|basic-image-gen> -[✓] Critic: PASS (score/20) — round N -[✓] Assets: 05-assets/<slug>/<filename>.{png,pdf} -[✓] Code: <printed to terminal | N/A> - -Caption: -"Figure N. <caption text>" -``` - -## NEVER Rules (8 Items — Zero Tolerance) - -1. **NEVER** use AI image generation for data-driven figures (data-plot, comparison-chart, result-visualization). Text on axes, labels, and legends is unreliable in AI-generated images. Always use matplotlib/seaborn code. - -2. **NEVER** use more than 7 distinct colors in a single figure. Beyond 7, use patterns (hatching, markers, line styles) to differentiate series. Color is a scarce resource. - -3. **NEVER** rely solely on red-green distinction. Always include a secondary encoding (shape, pattern, label) for colorblind accessibility. Test with simulated deuteranopia. - -4. **NEVER** output a figure without a caption. Every figure must have a self-contained caption that describes what is shown and highlights key findings. - -5. **NEVER** generate matplotlib code without `plt.tight_layout()` and explicit DPI setting. Clipped labels and low-resolution output are publication-rejection-worthy bugs. - -6. **NEVER** use decorative elements: drop shadows, 3D effects, gradients, bevels, or ornamental borders. Academic figures must be clean, flat, and information-dense. - -7. **NEVER** skip the Critic evaluation step (Step 5). Even if the figure "looks fine", run the 20-item checklist. Visual intuition misses subtle issues. - -8. **NEVER** write code files (.py, .mmd) to the vault. Code output goes to terminal. Only image assets (.png, .pdf, .svg) go to `05-assets/`. Vault is for content, not code. - -## Output Constraints - -- All code output is printed to terminal, not saved as files -- Image assets go to `05-assets/<slug>/` with vault-relative paths -- Default language for labels: English (override with `language: zh-CN`) -- Default colorblind mode: ON (override with `colorblind_mode: false`) -- Default DPI: 300 (minimum 150, recommended 300-600 for print) -- Caption language matches `language` parameter -- Vector format (PDF) always generated alongside raster (PNG) for code-based figures - -## Failure Handling - -- Missing source content: `[?] Missing input: source` — stop and ask -- Ambiguous figure_type: `[?] Cannot determine figure type` — present options, ask user -- `basic-image-gen` unavailable: `[✗] Image generation failed` — fall back to Mermaid/TikZ code -- Data insufficient for plot: `[?] Insufficient data` — request specific data points -- Critic fails after 3 rounds: `[!] Quality warning: <remaining_issues>` — output with disclaimer -- `obsidian` CLI failure: `[✗] <command> failed: <error>` — stop subsequent steps - -## Reference Files - -- `references/illustration-taxonomy.md` — 6 figure types: structure, routing, prompt templates, decision tree -- `references/academic-styles.md` — Venue-specific styles: NeurIPS/ICML/ACL/IEEE/Nature with hex colors, fonts, sizes -- `references/critic-checklist.md` — 5 dimensions x 20 items: Clarity, Accuracy, Style, Reproducibility, Caption diff --git a/.claude/skills/paper-illustration/assets/.gitkeep b/.claude/skills/paper-illustration/assets/.gitkeep deleted file mode 100644 index e69de29..0000000 diff --git a/.claude/skills/paper-illustration/references/README.md b/.claude/skills/paper-illustration/references/README.md deleted file mode 100644 index 17fabde..0000000 --- a/.claude/skills/paper-illustration/references/README.md +++ /dev/null @@ -1,21 +0,0 @@ -# paper-illustration Reference Files - -This directory contains detailed documentation that supplements SKILL.md. - -## Files - -- `illustration-taxonomy.md` — 6 figure types: structure templates, routing rules, prompt engineering, auto-detection heuristics -- `academic-styles.md` — Venue-specific visual parameters: NeurIPS/ICML/ACL/IEEE/Nature with hex colors, fonts, sizes -- `critic-checklist.md` — 5 dimensions x 20 items quality evaluation: Clarity, Accuracy, Style, Reproducibility, Caption - -## Loading Rules - -1. **illustration-taxonomy.md**: Load at Step 1 (Retrieve & Classify) and Step 4 (Generate Figure) -2. **academic-styles.md**: Load at Step 3 (Apply Style) and Step 4 (Generate Figure) -3. **critic-checklist.md**: Load at Step 5 (Critic Evaluation) - -## Guidelines - -1. **Single Source**: Don't duplicate content from SKILL.md -2. **Load on Demand**: Claude reads these files only at the relevant Step -3. **Cross-References**: Each file notes which SKILL.md sections reference it diff --git a/.claude/skills/paper-illustration/references/academic-styles.md b/.claude/skills/paper-illustration/references/academic-styles.md deleted file mode 100644 index 88a279a..0000000 --- a/.claude/skills/paper-illustration/references/academic-styles.md +++ /dev/null @@ -1,281 +0,0 @@ -# Academic Styles Reference - -> Loaded by Step 3 (Apply Academic Style). Provides venue-specific visual parameters: colors, fonts, sizes, spacing, caption format. Every value is concrete — no "use default". - -## Table of Contents - -1. [Universal Rules](#1-universal-rules) -2. [NeurIPS Style (Default)](#2-neurips-style-default) -3. [ICML Style](#3-icml-style) -4. [ACL Style](#4-acl-style) -5. [IEEE Style](#5-ieee-style) -6. [Nature Style](#6-nature-style) -7. [Color Palettes Quick Reference](#7-color-palettes-quick-reference) -8. [Font Sizes Quick Reference](#8-font-sizes-quick-reference) - ---- - -## 1. Universal Rules - -These apply to ALL venues. Venue-specific sections override where noted. - -### Colorblind Safety - -- Primary encoding: color + shape/pattern (never color alone) -- Forbidden pairs: pure red (#FF0000) vs pure green (#00FF00) -- Mandatory test: simulate deuteranopia — all series still distinguishable -- Maximum distinct colors per figure: 7 (use hatching/markers beyond 7) - -### Grayscale Compatibility - -- Figure must remain interpretable when printed in grayscale -- Use varying lightness values, not just hue differences -- Add patterns (hatching, dots) to filled regions as backup encoding - -### Typography - -- Minimum font size: 8pt at final print size -- Label font size: 9-10pt -- Title font size: 10-12pt (if shown on figure) -- Legend font size: 8-9pt -- All text must survive 50% reduction without becoming illegible - -### Resolution - -- Raster output: minimum 300 DPI (600 DPI recommended for print) -- Vector output: PDF preferred (no rasterization artifacts) -- Always generate both PNG (300 DPI) and PDF - -### Layout - -- Margins: sufficient whitespace around all elements (no clipped text) -- Always call `plt.tight_layout()` or equivalent -- Grid lines: light gray (#CCCCCC), thin (0.5pt), behind data -- Axis spines: visible top and right spines optional (NeurIPS removes them) - ---- - -## 2. NeurIPS Style (Default) - -**Page width**: 5.5" (single column), 11.0" (full width) -**Figure width**: 5.5" (single), 2.6" (half) - -### Color Palette (seaborn "muted" inspired, 7 colors) - -| Index | Name | Hex | RGB | Use | -|-------|---------|-----------|-----------------|-----| -| 0 | Blue | `#4878D0` | (72, 120, 208) | Primary / "Ours" | -| 1 | Orange | `#EE854A` | (238, 133, 74) | Secondary / Baseline | -| 2 | Green | `#6ACC64` | (106, 204, 100) | Tertiary | -| 3 | Red | `#D65F5F` | (214, 95, 95) | Alert / Worst | -| 4 | Purple | `#956CB4` | (149, 108, 180) | Additional | -| 5 | Brown | `#8C613C` | (140, 97, 60) | Additional | -| 6 | Pink | `#DC7EC0` | (220, 126, 192) | Additional | - -### Fonts - -- Family: `serif` (Times New Roman or similar) -- Body: 10pt, Labels: 9pt, Legend: 8pt, Title: 11pt -- matplotlib: `'font.family': 'serif'` - -### Axes - -- Remove top and right spines: `ax.spines['top'].set_visible(False)` -- Tick direction: `out` -- Tick length: 4pt -- Grid: `alpha=0.3, linestyle='--', linewidth=0.5` - -### Caption Format - -``` -Figure N: <Description>. <Key finding>. -``` - ---- - -## 3. ICML Style - -**Page width**: 6.75" (single column), 13.5" (full width) -**Figure width**: 6.75" (single), 3.25" (half) - -### Color Palette (cooler tones) - -| Index | Name | Hex | Use | -|-------|-----------|-----------|-----| -| 0 | Dark Blue | `#1F77B4` | Primary / "Ours" | -| 1 | Orange | `#FF7F0E` | Secondary | -| 2 | Teal | `#2CA02C` | Tertiary | -| 3 | Crimson | `#D62728` | Alert | -| 4 | Violet | `#9467BD` | Additional | -| 5 | Sienna | `#8C564B` | Additional | -| 6 | Gray | `#7F7F7F` | Neutral/Baseline | - -### Fonts - -- Family: `serif` (Computer Modern / Times) -- Body: 10pt, Labels: 9pt, Legend: 8pt -- matplotlib: `'font.family': 'serif', 'mathtext.fontset': 'cm'` - -### Caption Format - -``` -Figure N. <Description>. <Key finding>. -``` - ---- - -## 4. ACL Style - -**Page width**: 6.0" (single column) -**Figure width**: 6.0" (single), 2.9" (half) - -### Color Palette (warm academic) - -| Index | Name | Hex | Use | -|-------|------------|-----------|-----| -| 0 | Royal Blue | `#2166AC` | Primary | -| 1 | Warm Red | `#B2182B` | Secondary | -| 2 | Teal | `#35978F` | Tertiary | -| 3 | Gold | `#DFC27D` | Highlight | -| 4 | Purple | `#762A83` | Additional | -| 5 | Dark Gray | `#525252` | Neutral | - -### Fonts - -- Family: `serif` (Times New Roman) -- Body: 10pt, Labels: 9pt, Legend: 8pt -- matplotlib: `'font.family': 'serif'` - -### Special Notes - -- NLP figures often include text examples — ensure text is readable -- Attention heatmaps: use sequential colormap (`Blues` or `YlOrRd`) -- Dependency trees: horizontal layout preferred - -### Caption Format - -``` -Figure N: <Description>. -``` - ---- - -## 5. IEEE Style - -**Page width**: 3.5" (single column), 7.16" (double column) -**Figure width**: 3.5" (single), 7.16" (full) - -### Color Palette (high contrast, traditional) - -| Index | Name | Hex | Use | -|-------|----------|-----------|-----| -| 0 | Blue | `#0072B2` | Primary | -| 1 | Orange | `#E69F00` | Secondary | -| 2 | Green | `#009E73` | Tertiary | -| 3 | Red | `#CC79A7` | Alert (pink-red, colorblind-safe) | -| 4 | Sky Blue | `#56B4E9` | Additional | -| 5 | Vermilion| `#D55E00` | Additional | -| 6 | Black | `#000000` | Baseline/Reference | - -**Note**: This is the Wong colorblind-safe palette, recommended for all IEEE publications. - -### Fonts - -- Family: `sans-serif` (Helvetica / Arial) -- Body: 8pt, Labels: 8pt, Legend: 7pt, Title: 9pt -- matplotlib: `'font.family': 'sans-serif'` - -### Special Notes - -- IEEE is stricter on figure size due to two-column format -- Single-column figures: max 3.5" wide — everything must be readable at this size -- Prefer subfigure grids over wide panoramic figures -- Line width: minimum 1pt (thin lines disappear in print) - -### Caption Format - -``` -Fig. N. <Description>. -``` - ---- - -## 6. Nature Style - -**Page width**: 3.5" (single column), 7.2" (double column) -**Figure width**: 3.5" (single), 7.2" (full) - -### Color Palette (Nature-inspired, elegant) - -| Index | Name | Hex | Use | -|-------|-----------|-----------|-----| -| 0 | Nature Blue | `#3B4CC0` | Primary | -| 1 | Nature Red | `#B40426` | Secondary | -| 2 | Nature Green| `#1B7837` | Tertiary | -| 3 | Gold | `#F2C14E` | Highlight | -| 4 | Teal | `#008080` | Additional | -| 5 | Dark Gray | `#404040` | Neutral | - -### Fonts - -- Family: `sans-serif` (Helvetica / Arial) -- Body: 7pt, Labels: 7pt, Legend: 6pt, Title: 8pt -- matplotlib: `'font.family': 'sans-serif', 'font.size': 7` - -### Special Notes - -- Nature has the strictest size limits — maximize information density -- Prefer panel layouts (a, b, c, d) with lowercase bold letters -- Panel labels: **a**, **b**, **c** at top-left of each subfigure -- Color: used sparingly, key data only — backgrounds always white - -### Caption Format - -``` -Figure N | <Title in bold>. <Description>. a, <Panel a description>. b, <Panel b description>. -``` - ---- - -## 7. Color Palettes Quick Reference - -### matplotlib Code Snippets - -```python -# NeurIPS (default) -COLORS_NEURIPS = ['#4878D0', '#EE854A', '#6ACC64', '#D65F5F', '#956CB4', '#8C613C', '#DC7EC0'] - -# ICML -COLORS_ICML = ['#1F77B4', '#FF7F0E', '#2CA02C', '#D62728', '#9467BD', '#8C564B', '#7F7F7F'] - -# ACL -COLORS_ACL = ['#2166AC', '#B2182B', '#35978F', '#DFC27D', '#762A83', '#525252'] - -# IEEE (Wong colorblind-safe) -COLORS_IEEE = ['#0072B2', '#E69F00', '#009E73', '#CC79A7', '#56B4E9', '#D55E00', '#000000'] - -# Nature -COLORS_NATURE = ['#3B4CC0', '#B40426', '#1B7837', '#F2C14E', '#008080', '#404040'] -``` - -### Choosing "Ours" Color - -Convention: the first color in each palette (index 0, a shade of blue) is used for "our method". This creates visual prominence and is consistent with reader expectations. - ---- - -## 8. Font Sizes Quick Reference - -| Venue | Body | Labels | Legend | Title | Min | -|---------|------|--------|--------|-------|-----| -| NeurIPS | 10pt | 9pt | 8pt | 11pt | 8pt | -| ICML | 10pt | 9pt | 8pt | 10pt | 8pt | -| ACL | 10pt | 9pt | 8pt | 10pt | 8pt | -| IEEE | 8pt | 8pt | 7pt | 9pt | 7pt | -| Nature | 7pt | 7pt | 6pt | 8pt | 6pt | - -**Rule of thumb**: If in doubt, use larger font sizes. Reviewers complain about unreadable figures far more often than oversized text. - ---- - -*Cross-reference: SKILL.md §Step 3, §NEVER Rules #2 #3 #6* diff --git a/.claude/skills/paper-illustration/references/critic-checklist.md b/.claude/skills/paper-illustration/references/critic-checklist.md deleted file mode 100644 index 17ae3cf..0000000 --- a/.claude/skills/paper-illustration/references/critic-checklist.md +++ /dev/null @@ -1,185 +0,0 @@ -# Critic Checklist Reference - -> Loaded by Step 5 (Critic Evaluation). 5 dimensions, 20 items. Each scored PASS/FAIL. Threshold: 18/20 to pass. Maximum 3 revision rounds. - -## Table of Contents - -1. [Scoring Rules](#scoring-rules) -2. [Dimension 1: Clarity (5 items)](#dimension-1-clarity-5-items) -3. [Dimension 2: Accuracy (4 items)](#dimension-2-accuracy-4-items) -4. [Dimension 3: Style (5 items)](#dimension-3-style-5-items) -5. [Dimension 4: Reproducibility (3 items)](#dimension-4-reproducibility-3-items) -6. [Dimension 5: Caption (3 items)](#dimension-5-caption-3-items) -7. [Evaluation Output Template](#evaluation-output-template) -8. [Revision Protocol](#revision-protocol) - ---- - -## Scoring Rules - -- Each item: PASS (1 point) or FAIL (0 points) -- Total: 20 points maximum -- Pass threshold: 18/20 (90%) -- Maximum revision rounds: 3 -- Each revision must address ALL flagged FAIL items -- Items not applicable to the figure type: auto-PASS (e.g., error bars for conceptual figures) - ---- - -## Dimension 1: Clarity (5 items) - -| ID | Check | PASS Criteria | Common FAIL | -|----|-------|---------------|-------------| -| C1 | Caption self-explanatory | Reader understands figure without reading paper body | Caption says only "Results" with no detail | -| C2 | Labels readable | All text >= minimum font size at print dimensions | 6pt text on IEEE single-column figure | -| C3 | Visual hierarchy | Most important data visually prominent (size, color, position) | All lines same weight, "Ours" indistinguishable | -| C4 | No overlapping elements | Labels, legends, data points, annotations do not occlude each other | Legend sits on top of data region | -| C5 | Adequate whitespace | Margins around figure, between subfigures, around legends | Elements crammed to edges, no breathing room | - -### How to Fix Common FAIL - -- **C1**: Add "showing that [method] achieves [X]% improvement over [baseline]" to caption -- **C2**: Increase font size or reduce figure complexity (fewer elements) -- **C3**: Use thicker lines / brighter colors for "Ours", thinner / muted for baselines -- **C4**: Relocate legend (outside plot area, or to whitespace region) -- **C5**: Add `plt.tight_layout(pad=1.5)` or increase figure dimensions - ---- - -## Dimension 2: Accuracy (4 items) - -| ID | Check | PASS Criteria | Common FAIL | -|----|-------|---------------|-------------| -| A1 | Data fidelity | Plotted values exactly match source data (spot-check 3 points) | Transposed rows/columns, wrong method assigned to line | -| A2 | Encoding faithful | Visual encoding matches data semantics (e.g., larger bar = larger value) | Inverted y-axis without indicator, log scale unlabeled | -| A3 | Axes honest | No truncated axes without break markers; scale is fair | Y-axis starts at 90% making 1% difference look huge | -| A4 | Error bars correct | Error bars represent stated metric (std, sem, CI) and are labeled | Error bars present but unlabeled, or wrong metric | - -### How to Fix Common FAIL - -- **A1**: Cross-reference code data arrays with source table, print values to verify -- **A2**: Check axis direction, scale type (linear/log), and legend-to-data mapping -- **A3**: Start y-axis at 0, or use axis break (`//`) marker if truncated -- **A4**: Add "(mean +/- std, n=5)" to caption or legend - ---- - -## Dimension 3: Style (5 items) - -| ID | Check | PASS Criteria | Common FAIL | -|----|-------|---------------|-------------| -| S1 | Palette matches venue | Colors from venue-specific palette in academic-styles.md | Using matplotlib default colors instead of venue palette | -| S2 | Colorblind safe | All series distinguishable under simulated deuteranopia | Red and green lines only differ by hue | -| S3 | Grayscale compatible | Figure readable when desaturated (for B&W printing) | Two series both map to medium gray | -| S4 | Font compliant | Font family and sizes match venue specification | Sans-serif used for NeurIPS (should be serif) | -| S5 | Size compliant | Figure fits within venue column width at stated dimensions | 8" wide figure for IEEE single-column (max 3.5") | - -### How to Fix Common FAIL - -- **S1**: Replace colors with hex values from `references/academic-styles.md` -- **S2**: Add secondary encoding (markers: o, s, ^, D, v) alongside color -- **S3**: Add line styles (solid, dashed, dotted, dash-dot) as tertiary encoding -- **S4**: Update `matplotlib.rcParams['font.family']` -- **S5**: Adjust `figsize` to venue constraints - ---- - -## Dimension 4: Reproducibility (3 items) - -| ID | Check | PASS Criteria | Common FAIL | -|----|-------|---------------|-------------| -| R1 | Code complete | Code runs without modification (all data inline, no external files) | References `data.csv` that doesn't exist | -| R2 | Imports present | All required imports listed at top of code | Missing `import seaborn as sns` | -| R3 | Output configured | Explicit DPI, savefig with bbox_inches='tight', both PNG and PDF | No savefig, or missing DPI, or only PNG | - -**Scope**: Only applies to code-based figures (data-plot, comparison-chart, result-visualization). Auto-PASS for AI-generated figures. - -### How to Fix Common FAIL - -- **R1**: Replace file reads with inline data arrays (`np.array([...])`) -- **R2**: Run code mentally — every function call must have its import -- **R3**: Add `plt.savefig('fig.png', dpi=300, bbox_inches='tight')` + PDF variant - ---- - -## Dimension 5: Caption (3 items) - -| ID | Check | PASS Criteria | Common FAIL | -|----|-------|---------------|-------------| -| P1 | Content described | Caption describes WHAT the figure shows (not just "Results") | "Figure 1: Comparison." — no detail | -| P2 | Key finding stated | Caption highlights the main takeaway for the reader | Describes setup but not conclusion | -| P3 | Subfigures referenced | Multi-panel figures: each panel described in caption (a, b, c) | 4 panels but caption only mentions "left" and "right" | - -### How to Fix Common FAIL - -- **P1**: Structure as "Figure N: [verb] [what]. [context]." e.g., "Figure 3: Comparison of training convergence across 5 methods on CIFAR-10." -- **P2**: Add final sentence: "Method A converges 2x faster than the strongest baseline." -- **P3**: Add "(a) Training loss. (b) Validation accuracy. (c) Inference latency." - ---- - -## Evaluation Output Template - -``` -## Critic Evaluation — Round N/3 - -| Dim. | Items | Score | Failed IDs | Issues | -|-----------------|-------|-------|------------|--------| -| Clarity | 5 | X/5 | [CX] | [description] | -| Accuracy | 4 | X/4 | [AX] | [description] | -| Style | 5 | X/5 | [SX] | [description] | -| Reproducibility | 3 | X/3 | [RX] | [description] | -| Caption | 3 | X/3 | [PX] | [description] | -|-----------------|-------|-------|------------|--------| -| **Total** | **20**| **X/20** | | | - -Verdict: PASS (>= 18) / REVISE (< 18) - -[If REVISE:] -Revision actions: -1. [Fix for failed item 1] -2. [Fix for failed item 2] -... -``` - ---- - -## Revision Protocol - -### Round Management - -``` -Round 1: Initial evaluation - ↓ REVISE → apply fixes -Round 2: Re-evaluate ALL items (not just failed ones) - ↓ REVISE → apply fixes -Round 3: Final evaluation - ↓ REVISE → output with [!] Quality warning - ↓ PASS → proceed to Step 6 -``` - -### Rules - -1. Each round evaluates ALL 20 items fresh (fixes can introduce new issues) -2. Revision must address every FAIL item — no "defer to next round" -3. After round 3, if still < 18/20: - - Output the figure with explicit warning - - List all remaining FAIL items - - Suggest user manual review -4. A PASS in any round immediately proceeds to Step 6 (no unnecessary iterations) - -### Quality Warning Format - -``` -[!] Quality warning: Figure output with 2 unresolved issues after 3 revision rounds. - -Remaining issues: -- [S2] Colorblind safety: series 3 and 5 may be confusing under deuteranopia -- [C4] Minor legend overlap with rightmost data point - -Recommendation: Manual review before submission. -``` - ---- - -*Cross-reference: SKILL.md §Step 5, §NEVER Rule #7* diff --git a/.claude/skills/paper-illustration/references/illustration-taxonomy.md b/.claude/skills/paper-illustration/references/illustration-taxonomy.md deleted file mode 100644 index 005f9cf..0000000 --- a/.claude/skills/paper-illustration/references/illustration-taxonomy.md +++ /dev/null @@ -1,291 +0,0 @@ -# Illustration Taxonomy Reference - -> Loaded by Step 1 (Retrieve & Classify). Provides structure templates, routing rules, prompt engineering guidance, and auto-detection heuristics for all 6 figure types. - -## Table of Contents - -1. [Architecture Diagram](#1-architecture-diagram) -2. [Data Plot](#2-data-plot) -3. [Conceptual Illustration](#3-conceptual-illustration) -4. [Process Flow](#4-process-flow) -5. [Comparison Chart](#5-comparison-chart) -6. [Result Visualization](#6-result-visualization) -7. [Auto-Detection Heuristics](#7-auto-detection-heuristics) -8. [Prompt Engineering Templates](#8-prompt-engineering-templates) - ---- - -## 1. Architecture Diagram - -**Purpose**: Show system components and their interconnections. Common in ML papers (model architecture), systems papers (distributed systems), and software engineering papers. - -**Structural template**: -- Top-level: input → processing layers → output -- Each layer: named box with internal description -- Connections: directed arrows with optional labels (data type, tensor shape) -- Optional: skip connections, attention mechanisms, residual paths - -**Key elements to extract**: -- Named components (encoder, decoder, attention head, loss function) -- Data flow direction (left-to-right or top-to-bottom) -- Tensor shapes / data dimensions at each stage -- Grouping (which components form a module) - -**Backend**: Mermaid (structure) → `basic-image-gen` (polished rendering) - -**Exemplar description** (text-based reference): -> A Transformer encoder-decoder diagram: input embeddings feed into N stacked encoder blocks (each containing multi-head self-attention + feed-forward + layer norm), connected by residual arrows. Decoder blocks mirror the structure with added cross-attention. All arrows are labeled with tensor dimensions. Clean white background, consistent box sizing, horizontal flow. - -**Common mistakes**: -- Too many components crammed into one figure — split into overview + detail figures -- Arrows crossing without clear layering — use consistent flow direction -- Missing dimension annotations — reviewers need to verify tensor shapes - ---- - -## 2. Data Plot - -**Purpose**: Visualize quantitative experimental results. The most common figure type in empirical papers. - -**Subtypes**: -- Line plot (trends over epochs, hyperparameter sweeps) -- Bar chart (discrete comparisons, ablation results) -- Scatter plot (correlation, embedding visualization) -- Histogram (distribution of scores, latency) -- Box plot (variance across runs, statistical comparison) -- Heatmap (attention weights, confusion matrices) - -**Structural template**: -- X-axis: independent variable (clearly labeled with units) -- Y-axis: dependent variable (clearly labeled with units) -- Legend: method names, consistent with paper text -- Error bars / confidence intervals: when multiple runs exist -- Grid: light gray, no heavy gridlines - -**Key elements to extract**: -- Data values (exact numbers from tables or inline) -- Variable names and units -- Method/baseline names (must match paper text exactly) -- Number of runs / seeds (for error bars) - -**Backend**: matplotlib/seaborn code — NEVER AI image generation - -**Common mistakes**: -- Truncated y-axis without break marker — misleading visual -- Missing error bars when results vary across seeds -- Legend covering data points — move to whitespace area -- Inconsistent method colors across subfigures - ---- - -## 3. Conceptual Illustration - -**Purpose**: Explain abstract ideas, metaphors, or high-level intuitions that cannot be expressed as data or architecture. - -**Structural template**: -- Central metaphor / visual analogy -- Labeled regions or entities -- Visual encoding of relationships (proximity, size, color) -- Minimal text annotations (key terms only) - -**Key elements to extract**: -- Core concept and its visual metaphor -- Entities and their relationships -- Any text that must appear in the figure -- Target impression (what should the reader understand at a glance) - -**Backend**: `basic-image-gen` (AI excels at creative visual metaphors) - -**Exemplar description**: -> A clean scientific illustration showing knowledge distillation: a large "Teacher" network (detailed, multi-layered structure) on the left, connected by flowing arrows labeled "soft labels" to a smaller, simpler "Student" network on the right. The teacher is rendered in deep blue, the student in teal. White background, no decorative elements, all text in sans-serif font. - -**Common mistakes**: -- Too abstract — reviewers need to understand without reading the caption -- Decorative clutter (gradients, shadows) — breaks academic norms -- Text too small or embedded in complex visuals — must be readable at print size - ---- - -## 4. Process Flow - -**Purpose**: Show sequential steps, decision points, and branching logic. Common in method sections and algorithm descriptions. - -**Structural template**: -- Start/end: rounded rectangles -- Process steps: rectangles with action descriptions -- Decisions: diamonds with yes/no branches -- Data stores: cylinders or parallelograms -- Flow: top-to-bottom or left-to-right, consistent direction - -**Key elements to extract**: -- Ordered steps (numbered or sequential) -- Decision points and their conditions -- Parallel branches (if any) -- Loop/iteration indicators -- Input/output at boundaries - -**Backend**: Mermaid flowchart (primary), TikZ (fallback) - -**Exemplar description**: -> A training pipeline flowchart: "Raw Data" → "Preprocessing" → "Feature Extraction" → diamond "Validation Loss Decreasing?" → Yes: "Continue Training" (loops back) → No: "Early Stop" → "Evaluate on Test Set" → "Report Results". Clean boxes with consistent padding, single-color scheme, directional arrows. - -**Common mistakes**: -- Too many steps in one diagram — split into phases -- Inconsistent box sizes — standardize width -- Missing decision labels (yes/no/condition) - ---- - -## 5. Comparison Chart - -**Purpose**: Compare multiple methods, models, or configurations across shared metrics. The "table as a figure" pattern. - -**Subtypes**: -- Grouped bar chart (methods × metrics) -- Radar/spider chart (multi-dimensional comparison) -- Parallel coordinates (many dimensions) -- Table with heatmap coloring (for many metrics) - -**Structural template**: -- X-axis: methods/models (categorical) -- Y-axis: metric value (numerical) -- Grouping: by metric or by method -- Highlighting: best result bolded or starred -- Baseline: horizontal dashed line for reference method - -**Key elements to extract**: -- Method names (must match paper text) -- Metric names and values -- Which method is "ours" (for highlighting) -- Baseline/reference method -- Statistical significance markers (if applicable) - -**Backend**: matplotlib code — NEVER AI image generation - -**Common mistakes**: -- Too many methods/metrics in one chart — split or use table -- No baseline reference line — hard to judge improvement -- Inconsistent ordering — sort by performance or alphabetically - ---- - -## 6. Result Visualization - -**Purpose**: Show qualitative or semi-quantitative results: attention maps, feature visualizations, generated samples, ablation grids. - -**Subtypes**: -- Attention heatmap overlay -- Feature map / activation visualization -- Sample grid (generated vs real) -- Ablation grid (each cell = one config) -- Confusion matrix -- t-SNE / UMAP embedding plots - -**Structural template**: -- Grid layout: rows = conditions, columns = samples/metrics -- Consistent cell sizing -- Row/column headers clearly labeled -- Color scale legend (for heatmaps) -- Highlight: circles or boxes around key regions - -**Key elements to extract**: -- What each row/column represents -- Color scale meaning and range -- Which samples to highlight and why -- Grid dimensions (rows × columns) - -**Backend**: matplotlib/seaborn code (heatmaps, grids), `basic-image-gen` (overlays on real images) - -**Common mistakes**: -- Missing color scale legend — uninterpretable -- Grid cells too small at print size — ensure readability -- No row/column labels — reader cannot identify conditions - ---- - -## 7. Auto-Detection Heuristics - -Keyword-based classification from source content: - -| Keywords / Patterns | Detected Type | -|---|---| -| "accuracy", "F1", "BLEU", "%", table of numbers, "vs", "baseline" | comparison-chart | -| "epoch", "learning rate", "loss curve", "over time", "trend" | data-plot | -| "architecture", "encoder", "decoder", "layer", "module", "block" | architecture-diagram | -| "step 1", "then", "if...then", "pipeline", "workflow", "algorithm" | process-flow | -| "ablation", "heatmap", "attention map", "feature map", "t-SNE" | result-visualization | -| "intuition", "concept", "metaphor", "analogy", "overview" | conceptual | - -**Confidence scoring**: -- 3+ keywords from one category → HIGH confidence -- 2 keywords → MEDIUM confidence -- 1 keyword or keywords from multiple categories → LOW confidence (ask user) - -**Tie-breaking rules**: -- Numeric data present → prefer data-driven types (data-plot > comparison-chart > result-visualization) -- No numeric data → prefer structural types (architecture-diagram > process-flow > conceptual) - ---- - -## 8. Prompt Engineering Templates - -### For `basic-image-gen` (architecture-diagram, conceptual) - -**Base template**: -``` -Create a publication-quality scientific illustration for an academic paper. - -Subject: {description_from_blueprint} - -Style requirements: -- Clean white background -- No decorative elements (no shadows, no 3D, no gradients) -- Flat design with consistent line weights -- Colors: {palette_from_academic_styles} -- All text in {font_family}, minimum {min_font_size}pt equivalent -- Professional academic illustration style - -Text elements that MUST appear legibly: -{list_all_labels_and_annotations} - -Layout: {layout_description} -Aspect ratio: {width}:{height} -``` - -### For architecture diagrams specifically - -**Architecture template**: -``` -Create a clean technical architecture diagram for a research paper. - -Components (left to right / top to bottom): -{component_list_with_descriptions} - -Connections: -{arrow_descriptions_with_labels} - -Style: flat design, {venue} conference style, colors {hex_values}, -sans-serif labels, consistent box sizing, white background. -No decorative elements. Print-ready at {width}" x {height}". -``` - -### For conceptual illustrations - -**Concept template**: -``` -Create a minimalist scientific concept illustration. - -Core concept: {concept_description} -Visual metaphor: {metaphor_description} - -Must include these labeled elements: -{element_list} - -Style: clean, academic, flat design. Colors: {hex_values}. -White background, no gradients or shadows. -All text must be clearly readable at small print size. -``` - ---- - -*Cross-reference: SKILL.md §Decision Tree, §Figure Type → Backend Routing* diff --git a/.claude/skills/paper-illustration/scripts/.gitkeep b/.claude/skills/paper-illustration/scripts/.gitkeep deleted file mode 100644 index e69de29..0000000 diff --git a/.claude/skills/write-article b/.claude/skills/write-article new file mode 120000 index 0000000..a93b53f --- /dev/null +++ b/.claude/skills/write-article @@ -0,0 +1 @@ +/home/kang/apps/atomstorm-claude-skills/write-article \ No newline at end of file diff --git a/.claude/skills/write-article/ARCHITECTURE.md b/.claude/skills/write-article/ARCHITECTURE.md deleted file mode 100644 index 2e9a1f3..0000000 --- a/.claude/skills/write-article/ARCHITECTURE.md +++ /dev/null @@ -1,173 +0,0 @@ -# write-article Skill 生产架构总览 - -## 文件体量 - -``` -.claude/skills/write-article/ -├── SKILL.md ~330 行 ~2,000 字 接口层（工作流 + 约束） -└── references/ - ├── material-anchors.md ~150 行 ~1,000 字 素材锚点（四类锚点 + 脚手架 + 编织规则） - ├── content-quality.md ~275 行 ~1,800 字 质量框架（标题/去AI味/完读率/素材密度） - ├── writing-styles.md 122 行 ~750 字 风格模板（5 种） - └── personas.md 145 行 ~650 字 人格配置（1 个 + 扩展模板） - ───────────────── - ~1,022 行 ~6,200 字 总上下文消耗 -``` - -## 渐进式披露架构 - -``` -Agent 加载顺序（上下文消耗） -───────────────────────────────────────────────────────────── - -第 1 层：SKILL.md（必加载，~1,600 字） -┌──────────────────────────────────────────────────────────┐ -│ frontmatter 触发匹配 + 依赖声明 │ -│ 目标 流量池公式 + 质量底线 │ -│ 输入要求 5 必填 + 7 可选 + style×persona 矩阵 │ -│ 7 步工作流 摘要+指针，不含详细规则 │ -│ 输出约束 6 条硬性规则 │ -│ 失败处理 3 种失败模式 │ -│ 风格参考 5 个文件指针 │ -└──────────────┬───────────────────────────────────────────┘ - │ 按需加载（只在对应 Step 触发时读取） - ▼ -第 2 层：references/（按需，~4,200 字） -┌──────────────────────┐ ┌────────────────────┐ ┌──────────────────┐ ┌───────────────┐ -│ material-anchors.md │ │ content-quality.md │ │ writing-styles.md│ │ personas.md │ -│ │ │ │ │ │ │ │ -│ Step 1b → §1-§3 │ │ Step 3 → §1 标题 │ │ Step 4 → 选风格 │ │ Step 2 → 激活 │ -│ 素材锚点+脚手架 │ │ Step 4a → §2 去AI │ │ │ │ │ -│ Step 4 → §4 编织 │ │ Step 4b → §3 完读率│ │ │ │ │ -│ Step 7 → §4.4 门禁 │ │ Step 7 → §4 门禁 │ │ │ │ │ -└──────────────────────┘ └────────────────────┘ └──────────────────┘ └───────────────┘ - │ - ▼ -第 3 层：vault 内文件（仅 lizi_kk 风格触发） -┌──────────────────────────────────────────────────────────┐ -│ templates/author-style-lizi-kk.md 详细风格指南 │ -│ personal-context/ (5 篇) 已发表文章参考 │ -│ 通过 obsidian read 读取，不占 skill 上下文 │ -└──────────────────────────────────────────────────────────┘ -``` - -架构判定：三层分离合理。SKILL.md 是接口，references 是实现，vault 文件是数据。Agent 不需要一次性加载全部 4,400 字。 - -## 7 步工作流 × 文件依赖矩阵 - -``` -Step 名称 SKILL.md content-quality writing-styles personas material-anchors vault 文件 -──── ──── ──────── ─────────────── ────────────── ──────── ──────────────── ────────── - 1a 读取素材 ✓ 指令 ✓ obsidian read - 1b 提取素材锚点 ✓ 约束 ✓ §1-§3 锚点+脚手架 - 2 激活人格 ✓ 格式 ✓ 激活 - 3 标题工程 ✓ 约束 ✓ §1 详细公式 - 4 生成草稿 ✓ 约束 ✓ §2 去AI味 ✓ 选风格 ✓ 口吻 ✓ §4 编织规则 ✓ lizi_kk 模板 - ✓ §3 完读率 ✓ personal-context - 5 创建文件 ✓ 模板 ✓ obsidian create - 6 验证 frontmatter ✓ 清单 ✓ obsidian read - 7 质量检查 ✓ 门禁 ✓ §4 完整清单 ✓ §4.4 素材密度 -``` - -Step 4 是资源消耗峰值——同时需要 5 个参考源。这是合理的，因为生成草稿是整个 skill 的核心价值所在。 - -## 跨文件一致性检查 - -``` -检查项 结果 备注 -───────────────────────────────────────────────────────────── -风格数量声明一致 ✓ SKILL.md "5种" = writing-styles.md "5类" -persona 数据一致（20000+） ✓ personas.md:27 = personas.md:75 -frontmatter 字段对齐 CLAUDE.md §4.2 ✓ 14 个必填字段全覆盖 -门禁清单覆盖所有质量维度 ✓ 基础(4) + 标题(3) + 去AI味(8) + 完读率(6) + 素材密度(6) = 27 项 -SKILL.md 指针与 content-quality.md 章节对应 ✓ §1/§2/§3/§4（含§4.4素材密度）均有对应引用 -SKILL.md 指针与 material-anchors.md 对应 ✓ §1-§3(Step 1b) + §4(Step 4) + §4.4(Step 7) -material-anchors.md 锚点类型与示例完整 ✓ 4 类锚点均有 personal-context + 苍何爆款双源示例 -writing-styles.md 每个风格结构统一 ✓ 全部包含 语气/结构/禁忌 三节 -personas.md 扩展模板完整 ✓ 有 YAML 模板 + 4 步新增指南 -vault 路径使用 $VAULT_PATH 可配置 ✓ ${VAULT_PATH:-default} -``` - -## 数据流全景图 - -``` -用户输入 SKILL.md 工作流 输出 -┌────────────┐ ┌────────────────────────┐ ┌─────────────┐ -│ topic │ │ │ │ │ -│ style │──▶ Step 1a: obsidian read ──▶│ 事实边界确认 │ │ 02-drafts/ │ -│ audience │ Step 1b: 素材锚点提取 ──▶ │ 素材脚手架（≥3锚点） │ │ YYYY-MM-DD │ -│ source_notes│ Step 2: persona 激活 ──▶ │ 口吻锁定（可选） │ │ -slug.md │ -│ tags │ │ │ │ │ -│ [persona] │ Step 3: 标题工程 ──────▶ │ ≥5 候选 → 评分 → 选定 │ │ frontmatter │ -│ [intensity]│ │ │ │ + 正文 │ -│ [title] │ Step 4: 生成草稿 ──────▶ │ 素材编织 × 风格模板 │ │ │ -│ [slug] │ │ × 去AI味 × 完读率 │ │ 27 项门禁 │ -│ [cta] │ Step 5: obsidian create ─▶│ frontmatter + body │──▶ Step 7 ──▶ │ 全部通过 │ -│[mat_sources]│ Step 6: 回读验证 ────────▶│ 字段完整性修补 │ └─────────────┘ -└────────────┘ └────────────────────────┘ - - ┌──────────────────────────────────────────────────────────────────┐ -参考文件调用： │ material-anchors.md ← Step 1b, 4, 7 │ - │ content-quality.md ← Step 3, 4a, 4b, 7 │ - │ writing-styles.md ← Step 4 │ - │ personas.md ← Step 2 │ - │ vault/templates/ ← Step 4 (仅 lizi_kk) │ - │ vault/personal-context/ ← Step 1a, 4 (亲历锚点 + lizi_kk) │ - └──────────────────────────────────────────────────────────────────┘ -``` - -## 与 content-forge 全链路对接 - -``` -content-forge 生产线 write-article 覆盖范围 -────────────────────────────────────────────────────────────── - -S0 选题入库 ──▶ 01-topics/*.md - │ - ▼ -S1 外链采集 ──▶ url-to-markdown（可选） - │ - ▼ - ┌──────────────────────────────────────────┐ - │ S2 草稿生成 ──▶ write-article │ - │ Step 1a: 读取素材 + vault 搜索 │ - │ Step 1b: 提取素材锚点 ◀── NEW │ - │ Step 2: 人格激活 │ - │ Step 3: 标题工程 │ - │ Step 4: 生成草稿 (素材编织+去AI味+完读率) │ - │ Step 5: 写入 02-drafts │ - │ Step 6: 验证 frontmatter │ - │ Step 7: 质量门禁 (27项) ◀── NEW │ - │ │ - │ S3 状态标记 ──▶ status: draft │ - └──────────────────────────────────────────┘ - │ - ▼ -S4 格式清洗 ──▶ format-markdown - │ -S5 视觉资产 ──▶ baoyu-cover-image / baoyu-article-illustrator - │ -S6 审核 ──▶ /review + /multi-review + /challenge - │ -S7 润色 ──▶ polish - │ -S8 发布 ──▶ post-to-wechat / post-to-x - │ -S9 归档 ──▶ 04-published/*.md -``` - -write-article 覆盖 S2-S3（选题→草稿），是全链路中**上下文消耗最大、创意密度最高**的环节。标题工程和质量门禁的加入，把原来"写完就交"变成了"写完过检才交"。 - -## 架构评分 - -| 维度 | 评分 | 说明 | -|------|------|------| -| 渐进式披露 | PASS | SKILL.md 摘要+指针，不再重复 reference 内容 | -| 跨文件一致性 | PASS | 数据、字段、章节引用全部对齐 | -| 单一职责 | PASS | 每个 reference 文件只管一件事 | -| 可扩展性 | PASS | personas.md 有扩展模板，writing-styles.md 可加新风格 | -| 可移植性 | PASS | `$VAULT_PATH` 可配置，不再硬编码 | -| 质量保障 | PASS | 27 项门禁（基础4 + 标题3 + 去AI味8 + 完读率6 + 素材密度6），任一失败即打回 | -| 上下文效率 | WARN | 总量 6,200 字合理，但 Step 4 峰值同时需 5 个源 | - -整体评价：数据结构（5 文件分层）决定了算法（7 步工作流）的优雅——每个 Step 只去找自己需要的 reference，不多加载一个字。material-anchors.md 的加入把质量防线从单层（表达）扩展为双层（内容+表达），Step 1b 的素材脚手架确保"先有素材，再有文章"。唯一的 WARN 是 Step 4 的峰值加载，但这是生成阶段的固有复杂度，没有更简单的方法。 diff --git a/.claude/skills/write-article/SKILL.md b/.claude/skills/write-article/SKILL.md deleted file mode 100644 index fde0344..0000000 --- a/.claude/skills/write-article/SKILL.md +++ /dev/null @@ -1,369 +0,0 @@ ---- -name: write-article -description: > - Generate articles from Obsidian vault topics, optimized for traffic pool entry - (click-through × dwell time × completion rate). Output: a publish-ready draft - in 02-drafts/ with complete frontmatter, passing 27-item quality gate - (material density + title + de-AI + completion rate). - - USE WHEN: User wants to create new long-form content (tech blog, opinion piece, - tutorial, social post, lizi_kk-style article) from a structured topic in 01-topics/. - Trigger phrases: 写文章、写作、生成草稿、技术博客、观点文、教程、社交短文、 - article、blog post、draft、人格写作、栗子KK风格。 - - DON'T USE WHEN: - - User wants to analyze/deconstruct existing content → use dao-analysis instead. - - User wants to review/critique an existing draft → use multi-review or /review instead. - - User wants to import an external draft into vault → use import-draft instead. - - User wants to load vault context → use my-world instead. - - User wants to edit an existing draft in 02-drafts/ → use obsidian CLI directly. - - User says "分析"、"拆解"、"审查"、"导入" without creation intent → not this skill. ---- - -# Write-Article：Obsidian 文章写作技能 - -## 目标 - -用统一流程产出**能进流量池**的可发布草稿。 - -核心公式：**点击率 × 停留时长 × 完读率 = 流量池入场券**。三项相乘，任一项为零则全盘归零。详见 `references/content-quality.md`。 - -质量底线： -- 标题：候选 ≥5 个，评分 ≥18/25 -- 去 AI 味：零容忍黑名单词汇，人味注入 ≥5 项 -- 完读率：Hook 前 3 句到位，段间钩子不断，结尾金句+CTA - -## 路由规则（Use when / Don't use when） - -Use this skill when: -- User wants to **create new content** from a topic brief in `01-topics/` -- User says "写文章"、"生成草稿"、"write an article"、"create a draft" -- User specifies a style (tech_blog, opinion, tutorial, social_short, lizi_kk) -- User provides source notes and wants a publish-ready draft - -Do NOT use this skill when: -- User wants to **analyze** existing content (article, transcript, concept) → use `dao-analysis` -- User wants to **review/critique** a draft for quality → use `multi-review` or `/review` command -- User wants to **import** an external draft into the vault → use `import-draft` -- User wants to **load vault context** or see what's in the vault → use `my-world` -- User wants to **edit** an existing draft (fix typos, update sections) → use `obsidian` CLI directly -- User wants to **format** a draft for publishing → use `format-markdown` (baoyu skill) - -Edge cases: -- "帮我把这篇笔记改写成文章" → **this skill** (creation from notes = write-article) -- "分析一下这篇文章为什么火" → **not this skill** (analysis = dao-analysis) -- "审查我的草稿" → **not this skill** (review = multi-review) -- "把 atomstorm 项目里的文章导入 vault" → **not this skill** (import = import-draft) - -## 输入要求 - -必须提供： -- `topic`：文章主题（1 句话） -- `style`：`tech_blog` | `opinion` | `tutorial` | `social_short` | `lizi_kk` -- `audience`：目标读者 -- `source_notes`：至少 1 个 Obsidian note 路径（vault 相对路径） -- `tags`：1-5 个标签 - -可选： -- `persona`：人格激活（`栗子KK`），深度扮演作者身份 -- `intensity`：人格强度 `light` | `medium` | `heavy`（默认 medium） -- `title`：文章标题（如未提供，Step 3 强制生成候选） -- `slug`：文件 slug（英文短横线） -- `length_target`：目标字数或段落数 -- `cta`：结尾行动建议 -- `publish_channel`：发布渠道 -- `material_sources`：额外素材文件路径列表（vault 相对路径），用于补充素材锚点 - -> **风格与人格联动**：当 `style: lizi_kk` 时，自动加载 vault 内 `templates/author-style-lizi-kk.md` 和 `personal-context/` 参考文章，无需额外指定参数。 - -**`style` 与 `persona` 交互矩阵**： - -| 组合 | 行为 | -|------|------| -| `style: lizi_kk` 无 `persona` | 仅应用风格模板（结构+语言特征），不深度扮演 | -| `persona: 栗子KK` 无 `style: lizi_kk` | 人格口吻叠加到所选风格上（如 tech_blog + 栗子KK 语气） | -| 两者都设置 | 完整集成：风格模板 + 人格深度扮演（推荐） | - -## 强制工作流（7 步，不得跳步） - -### Step 1a：读取素材 - -逐个读取 `source_notes` 中的笔记，并搜索 vault 中相关素材，确认事实边界。 - -```bash -# 必须先 cd 到 vault 目录（CLAUDE.md §6.1 强制要求） -cd "${VAULT_PATH:-/home/kang/apps/content-forge/content-forge}" - -# 读取指定源笔记 -obsidian read path="<source_note_path_1>" -obsidian read path="<source_note_path_2>" - -# 搜索 vault 中相关素材（关键词来自 topic） -obsidian search query="<topic关键词>" - -# 读取匹配的 personal-context/ 文章（亲历锚点来源） -obsidian read path="personal-context/<matching_article>.md" - -# 读取匹配的 09-viral-examples/ 案例（案例/数据锚点来源） -obsidian read path="09-viral-examples/<matching_example>.md" - -# 读取用户额外指定的素材（如有 material_sources 参数） -obsidian read path="<material_source_path>" -``` - -执行要求： -- `source_notes` 中每个路径都要读取。 -- 主动搜索 vault 中与 topic 相关的素材（`personal-context/`、`00-inbox/`、`09-viral-examples/`）。 -- 未读完素材前，禁止进入写作。 -- 素材来源优先级见 `references/material-anchors.md` §2。 - -### Step 1b：提取素材锚点 - -从 Step 1a 读取的所有素材中，提取四类素材锚点并输出素材脚手架。 - -详细规则见 `references/material-anchors.md`。核心约束： - -- **总锚点 ≥3**，**Type A（亲历）≥1**，**Type B 或 C（数据/案例）≥1** -- 必须输出结构化素材脚手架（格式见 `references/material-anchors.md` §3） -- 素材不足时输出 `[?] 素材不足：缺少 <具体类型>`，**禁止进入 Step 2** - -输出格式： -``` -## 素材脚手架 - -### Type A 亲历锚点 -1. [锚点描述] — 来源: [vault路径] -... - -### Type B 数据锚点 -1. [数据 + 来源归属] — 来源: [vault路径或URL] -... - -### Type C 案例锚点 -1. [命名实体 + 分析要点] — 来源: [vault路径或URL] -... - -### Type D 观察锚点 -1. [引用/对话 + 归属] — 来源: [vault路径] -... - -### 统计 -- 总锚点: X 个 -- Type A: X 个 ✓/✗（≥1） -- Type B|C: X 个 ✓/✗（≥1） -- 判定: 通过 / [?] 素材不足 -``` - -### Step 2：激活人格（可选） - -如果提供了 `persona` 参数，按 `references/personas.md` 激活对应人格。 - -**激活确认格式**： -``` -收到，创作者。'栗子KK' 人格已上线（强度：medium）。 - -> 风格预览：说实话，这个坑我踩了不下10次，今天终于有空聊聊。 - -等待您的创作指令。 -``` - -**人格参数**： -- `persona`: 人格名称（目前支持 `栗子KK`） -- `intensity`: `light` | `medium` | `heavy`（默认 medium） - -### Step 3：标题工程 - -标题决定 80% 的点击率。**禁止只写一个标题直接用。** - -完整流程见 `references/content-quality.md` §1。核心约束： - -- 生成 **≥5 个候选标题**，覆盖不同公式（经历+数字+痛点 / 成本+悬念+真相 / 反常识 / 99%+反差 / 身份锚定） -- 每个候选命中**五要素 ≥3 项**（第一人称"我"、具体数字、张力词、信息缺口、身份锚定） -- **评分 ≥18/25**（5 维度 × 1-5 分：好奇心缺口、情绪冲击、身份共鸣、具体度、可信度） -- 标题 **≤35 字**（微信折叠阈值） -- 禁止学术腔、泛泛而谈、标题党 - -输出格式： -``` -候选标题： -1. [标题] — 评分: XX/25 — 命中要素: [列表] -2. [标题] — 评分: XX/25 — 命中要素: [列表] -... - -✦ 最终选定: [标题]（原因: ...） -``` - -### Step 4：生成文章草稿 - -按 `references/writing-styles.md` 选择对应风格模板生成正文。 -如果激活了人格，同时应用 `references/personas.md` 的人格设定。 - -**素材先行原则**（详见 `references/material-anchors.md` §4）： -- 正文必须围绕 Step 1b 的素材脚手架构建，每个主要论点必须锚定到具体素材。 -- Hook 第 1 句必须直接包含 ≥1 素材锚点（优先 Type A 或 Type B）。不是"前 3 句"，是"第 1 句"——铺垫后置。 -- 每个主要章节（H2/编号段落）至少引用 ≥1 个锚点。 -- 结尾回扣开头锚点，形成首尾呼应。 -- 所有事实性断言必须追溯到素材锚点，或标记 `[?]` 待验证。 - -**风格联动规则**： -- 当 `style: lizi_kk` 时，必须额外通过 `obsidian read path="templates/author-style-lizi-kk.md"` 读取风格指南，并参考 `personal-context/` 目录的已发表文章（这些文件位于 vault 内，需在 vault 目录下执行 CLI）。 - -#### 4a. 去 AI 味（强制） - -详细规则见 `references/content-quality.md` §2。核心执行项： - -- **黑名单零容忍**：开头/过渡/结尾废话出现即重写（完整黑名单见 §2.1） -- **意义膨胀零容忍**：删除"里程碑意义"、"划时代"、"引领新范式"等空洞修饰（§2.1） -- **模糊引用零容忍**：所有"研究表明"、"业内人士"必须给出具体来源，否则删除（§2.1） -- **打破 AI 结构**：段落长短交替（每连续 3 段必须有 ≥1 段 ≤2 句话）、打破对称、语气变化、偶尔不完整句、禁止绕路表述（§2.2） -- **禁止抽象过度**：每个抽象观点后必须紧跟一个具体场景（含时间/地点/数字/工具名），禁止连续两个以上的纯观点段落（§2.2） -- **禁止聚合清单**：禁止在结尾或独立章节使用"我的N个思考/感悟/总结"式编号列表，洞察必须散布在正文中（§2.2） -- **人味注入 ≥5 项**：不规则段落、口语化、括号吐槽、具体数字、个人经历、反问句、混合情绪、刻意凌乱等（完整清单 12 项见 §2.3） -- **二次审计**：门禁检查后，通读全文自问"哪里一眼看出 AI 写的"→列出→修复（§2.4） - -#### 4b. 完读率优化（强制） - -详细规则见 `references/content-quality.md` §3。核心执行项： - -- **前 3 句 Hook**：反直觉结论 / 真金白银 / 身份挑战 / 悬念制造（禁止背景介绍、自我介绍、目录式开头） -- **段间钩子**：每个 section 尾部制造"未完成感" -- **小标题有信息量**：不是"第一步"而是"第一步：这个操作让90%的人栽跟头" -- **阅读节奏**：每 300-500 字视觉断点，每连续 3 段必须有 ≥1 段 ≤2 句话，代码块 ≤15 行 -- **结尾工程**：回扣开头 + 金句 + 具体 CTA - -执行要求： -- 只使用已读取素材中的事实。 -- 观点必须有论证链，不得堆砌口号。 -- 内容结构必须匹配所选风格的"结构"要求。 -- 人格激活时，口吻必须符合人格的 `voice_signature` 和 `catchphrases`。 - -### Step 5：创建草稿文件 - -将 frontmatter + 正文一次性写入 `02-drafts/` 目录，减少 CLI 调用开销。 - -```bash -obsidian create path="02-drafts/<YYYY-MM-DD>-<slug>.md" content="--- -id: '<YYYY-MM-DD>-<slug>' -title: '<title>' -slug: '<slug>' -status: draft -content_type: article -channels: - - wechat - - x -language: zh-CN -source_urls: [] -assets: [] -cover_image: '' -template: article -owner: content-forge -created_at: '<YYYY-MM-DD>T00:00:00+08:00' -updated_at: '<YYYY-MM-DD>T00:00:00+08:00' -style: '<style>' -audience: '<audience>' -tags: - - '<tag1>' - - '<tag2>' -source_notes: - - '<note1.md>' ---- - -<ARTICLE_BODY>" -``` - -执行要求： -- 目标目录必须是 `02-drafts/`。 -- 文件名必须包含日期前缀与 slug。 -- frontmatter 必填字段对齐 CLAUDE.md §4.2（id, title, slug, status, content_type, channels, language, source_urls, assets, cover_image, template, owner, created_at, updated_at）。 -- 正文必须是 Markdown，可直接发布或二次编辑。 - -### Step 6：验证 frontmatter - -创建完成后，回读文件确认 frontmatter 完整性。 - -```bash -obsidian read path="02-drafts/<YYYY-MM-DD>-<slug>.md" -``` - -如果回读发现 frontmatter 字段缺失或格式异常，使用 `property:set` 逐项修补： - -```bash -obsidian property:set path="02-drafts/<YYYY-MM-DD>-<slug>.md" name="<field>" value="<value>" -``` - -必填字段检查清单（对齐 CLAUDE.md §4.2）： -- `id`, `title`, `slug`, `status`, `content_type`, `channels`, `language` -- `source_urls`, `assets`, `cover_image`, `template`, `owner` -- `created_at`, `updated_at` - -### Step 7：质量检查 - -逐项验证并输出 `[✓]` 或 `[✗]`，**任一项 `[✗]` 时停止交付并修复**。 - -完整门禁清单见 `references/content-quality.md` §4。 - -#### 基础门禁 - -- [ ] 所有 `source_notes` 已执行 `obsidian read` -- [ ] 草稿已通过 `obsidian create` 写入 `02-drafts/` -- [ ] frontmatter 必填字段完整（Step 6 回读验证通过） -- [ ] 不存在事实捏造与无依据断言 - -#### 标题门禁（§4.1） - -- [ ] 候选标题 ≥5 个 -- [ ] 最终标题评分 ≥18/25，命中五要素 ≥3 项 -- [ ] 标题 ≤35 字 - -#### 去 AI 味门禁（§4.2） - -- [ ] 前 50 字无黑名单词汇 -- [ ] 无"首先...其次...最后"四段式 -- [ ] 结尾无"综上所述/希望有帮助" -- [ ] 无意义膨胀词汇（"里程碑意义"、"划时代"、"深远影响"） -- [ ] 无模糊引用（"业内人士表示"、"研究表明"须给出处） -- [ ] 相邻段落字数差异 >20%（至少 3 组） -- [ ] 人味注入清单命中 ≥5 项（含混合情绪/刻意凌乱） -- [ ] 二次审计通过（自问"哪里一眼看出AI"→ 无残留） - -#### 完读率门禁（§4.3） - -- [ ] 前 3 句完成 Hook -- [ ] 每个 section 尾部有段间钩子 -- [ ] 小标题有信息量 -- [ ] 每 300-500 字有视觉断点 -- [ ] 结尾有金句 + 具体 CTA -- [ ] 全文无超过 15 行的代码块 - -#### 素材密度门禁（§4.4） - -- [ ] 素材脚手架已在 Step 1b 输出，总锚点 ≥3 -- [ ] 亲历锚点（Type A）≥1 -- [ ] 数据/案例锚点（Type B/C）≥1 -- [ ] 第 1 句包含 ≥1 素材锚点（非标题，正文首句） -- [ ] 每个主要章节引用 ≥1 锚点 -- [ ] 无未标注来源的事实性断言（或已标 `[?]`） - -## 输出约束 - -- 输出仅包含文章草稿及必要元数据，不输出无关解释。 -- 文章语言默认中文，除非用户显式要求其他语言。 -- 禁止编造数据、案例、引文、实验结果。 -- 未确认的事实必须标记 `[?]`，并明确缺失项。 -- 结构必须符合所选风格规范（见 `references/writing-styles.md`）。 -- 段落应可读，避免空泛套话与重复表达。 - -## 失败处理 - -- 缺少必要输入时，返回：`[?] 缺失输入：<字段名>`，并停止写入。 -- `obsidian` 命令失败时，返回：`[✗] <命令> 失败：<错误信息>`，并停止后续步骤。 -- 如果无法确定风格，默认使用 `tech_blog`，同时显式告知用户。 - -## 风格参考 - -- `references/material-anchors.md` — 素材锚点规范（四类锚点 + 脚手架 + 编织规则） -- `references/content-quality.md` — 流量池质量框架（标题工程 + 去AI味 + 完读率 + 素材密度） -- `references/writing-styles.md` — 5 种写作风格模板 -- `references/personas.md` — 人格化配置（栗子KK） -- vault 内 `templates/author-style-lizi-kk.md` — 栗子KK 详细风格指南（通过 `obsidian read` 读取） -- vault 内 `personal-context/` — 已发表文章参考（5 篇） diff --git a/.claude/skills/write-article/references/content-quality.md b/.claude/skills/write-article/references/content-quality.md deleted file mode 100644 index 9677ad0..0000000 --- a/.claude/skills/write-article/references/content-quality.md +++ /dev/null @@ -1,273 +0,0 @@ -# Content Quality Reference - -流量池入场公式：**点击率 × 停留时长 × 完读率**。三项相乘，任一项为零则全盘归零。 - ---- - -## 1. 标题工程（决定 80% 点击率） - -### 1.1 标题生成规则 - -**强制要求**：每篇文章必须生成 ≥5 个候选标题，从中选出最佳。禁止只写一个标题直接用。 - -### 1.2 已验证的标题公式 - -从 `personal-context/` 5 篇已发表高流量文章提炼： - -| 公式 | 已验证案例 | 结构拆解 | -|------|-----------|---------| -| **经历+数字+致命痛点** | "做了两年AI Agent，我发现99%的AI Agent项目都死在了Message Flow设计上" | 时间成本 → 数字冲击 → 死因 | -| **金钱成本+悬念+真相** | "烧了2000美金在AI写代码上，我发现了一个残酷真相" | 烧钱 → 好奇心缺口 → 真相 | -| **数字+反常识+结果** | "我研究了OpenClaw的8个反常识设计，终于明白这个Agent为什么能火爆全球" | 量化研究 → 反常识 → 因果 | -| **99%+反差+具体痛点** | "我发现市面上99%教你用Claude Code的，连最基本的CLAUDE.md都不会用" | 全网否定 → 反差 → 具体短板 | -| **成本+里程碑+权威背书** | "4个月烧了2万刀Token...Sam Altman预言的超级个体，可能真的来了" | 真金白银 → 成果 → 大佬站台 | - -### 1.3 标题五要素检查 - -每个候选标题必须命中 ≥3 项： - -``` -□ 第一人称"我" — 降低防御感，建立亲近（5/5 篇命中） -□ 具体数字 — 99%、2000美金、8个、两年（5/5 篇命中） -□ 张力词 — 死在、残酷真相、反常识、不会用、终于（5/5 篇命中） -□ 信息缺口 — 读完标题不知道答案，必须点进去（4/5 篇命中） -□ 身份锚定 — 目标读者能立刻对号入座（3/5 篇命中） -``` - -### 1.4 标题禁忌 - -- **禁止**：泛泛而谈（"AI 编程的一些思考"） -- **禁止**：没有数字的标题（"浅谈 Agent 架构设计"） -- **禁止**：学术腔（"基于 XX 的 YY 研究与实践"） -- **禁止**：标题党但正文接不住（标题 10 分正文 3 分 = 负口碑） -- **禁止**：超过 35 字（微信标题折叠阈值约 35 字，X 更短） - -### 1.5 标题评分表 - -生成候选标题后，按以下维度打分（1-5 分），总分 ≥18 分才可使用： - -| 维度 | 1分 | 3分 | 5分 | -|------|-----|-----|-----| -| 好奇心缺口 | 读完标题就知道答案 | 大概猜到方向 | 完全猜不到，必须点进去 | -| 情绪冲击 | 平淡无感 | 有点意思 | "卧槽真的假的" | -| 身份共鸣 | 跟我无关 | 有点相关 | "这说的不就是我吗" | -| 具体度 | 模糊抽象 | 有方向 | 有数字、有场景、有细节 | -| 可信度 | 像营销号 | 像自媒体 | 像真人分享真实经历 | - ---- - -## 2. 去 AI 味（决定可信度和停留时长） - -### 2.1 AI 味废话黑名单（零容忍） - -以下表达一旦出现，读者大脑自动切换为"又是AI写的"→关闭页面： - -**开头废话**（前 3 句出现 = 直接关页面）： -- "在当今快速发展的XX领域" -- "随着XX的不断发展/日益普及" -- "在这个XX的时代" -- "让我们一起来看看/探讨" -- "你是否曾经想过" - -**过渡废话**（段落间出现 = 像在读说明书）： -- "值得注意的是" -- "不可否认的是" -- "众所周知" -- "接下来我将从以下几个方面" -- "首先...其次...再次...最后"（四段式必死） - -**结尾废话**（最后出现 = 像在交作业）： -- "总的来说/综上所述/总而言之" -- "希望本文对你有所帮助" -- "以上就是关于XX的全部内容" -- "感谢阅读，期待你的反馈" - -**意义膨胀**（Significance Inflation — 把平凡事写成史诗）： -- "具有里程碑意义的"、"划时代的"、"引领了XX新范式/新潮流" -- "深刻改变了XX格局"、"具有深远的影响" -- "XX的崛起标志着..."、"在XX进程中扮演着关键角色" -- "不可磨灭的贡献"、"开创性的实践" - -> 来源：Wikipedia "Signs of AI writing" — Significance Inflation。AI 倾向于把一切描述为"重大"、"关键"、"深远"，因为统计上这些词在训练数据中最安全。 - -**模糊引用**（Vague Attributions — 没有来源的权威感）： -- "业内人士表示/指出"、"有观点认为"、"据了解" -- "专家普遍认为"、"研究表明"（不指名哪个研究） -- "越来越多的人开始..."、"许多开发者发现..." -- "有人说"、"据报道"（不给出处） - -> 来源：Wikipedia "Signs of AI writing" — Vague Attributions。对比人类写法："根据 2024 年 Stack Overflow 调查，67% 的开发者..."——必须有名有姓有数据。 - -### 2.2 AI 结构性特征（必须打破） - -| AI 特征 | 人类写法 | -|---------|---------| -| 段落长度均匀（每段都是 3-4 句） | 长短交替：有些段只有一句话，有些段 5-6 句 | -| 完美对称的并列结构 | 刻意打破对称：3 个论据篇幅可以是 40%/35%/25% | -| 每个观点都有"一方面...另一方面" | 直接选边站："说白了就是 XX" | -| 语气从头到尾一模一样 | 突然加速/突然停顿/突然吐槽 | -| 所有句子都是完整句 | 偶尔用不完整句："结果呢？" "就这？" | -| 过渡词密集且规律 | 有些段落之间零过渡，直接跳 | -| 绕路表述替代"是"（copula avoidance） | 直接用"是"/"有"。"XX 扮演着关键角色" → "XX 很关键" | -| 所有观点都中立客观、两边讨好 | 选边站、有态度、有矛盾感 | -| 抽象观察替代具体场景（abstraction excess） | 每个抽象观点后紧跟具体场景（含时间/地点/数字/工具名） | -| 结尾聚合式"我的N个思考"编号列表 | 洞察散布在正文段落中，不在结尾堆成清单 | - -### 2.3 人味注入清单（每篇必须 ≥5 项） - -``` -□ 不规则段落长度 — 每连续 3 段中 ≥1 段 ≤2 句话；全文 ≥3 个单句段落 -□ 口语化混入 — "说白了"、"讲真"、"你猜怎么着" -□ 括号吐槽/补充 — "（别问我怎么知道的）"、"（踩了3天的坑）" -□ 突然语气转换 — 正经分析中突然来一句"等等，这不对" -□ 具体数字替代模糊词 — 不说"很多"，说"我测试了 47 次" -□ 个人经历锚点 — "上周我在做 XX 的时候" -□ 反问句 — "你觉得这合理吗？" -□ 自我纠正 — "不对，我刚才说的不够准确，应该是..." -□ 类比/比喻 — 技术概念用生活场景解释 -□ 情绪词 — "崩溃"、"真香"、"离谱"、"服了" -□ 混合情绪/不确定 — "说实话我也不确定"、"这件事我很矛盾"、"又爽又怕" -□ 刻意凌乱 — 偶尔跑题的补充、半成形的想法、不完美的收束 -``` - -### 2.4 AI 味检测自检 - -生成草稿后，执行以下检测： - -1. **开头检测**：前 50 字是否包含 §2.1 黑名单词汇？→ 命中即重写开头 -2. **过渡检测**：是否使用"首先...其次...最后"四段式？→ 命中即重组结构；是否存在"我的N个思考/感悟/总结"聚合编号列表？→ 命中即拆散到正文段落中 -3. **结尾检测**：最后 50 字是否包含 §2.1 结尾废话？→ 命中即重写结尾 -4. **节奏检测**：相邻 3 段字数差异 <20%？→ 插入短段；连续 3 段无 ≤2 句短段？→ 强制插入单句段落打破节奏 -5. **人味计数**：§2.3 清单命中项 <5？→ 人味不足，补充注入 -6. **二次审计**：通读全文，自问"什么地方一眼就看出是 AI 写的？"→ 列出残留 AI 痕迹 → 逐项修复 → 如有修改，从第 1 步重跑一遍 - -> 二次审计来源：Humanizer skill 的 "Final audit pass"。一次检测抓不完所有问题——修复 A 可能引入 B，必须循环。 - ---- - -## 3. 完读率优化（决定算法推荐权重） - -### 3.1 前 3 句定生死（Hook 工程） - -读者在前 3 句决定是否继续。首屏必须完成一件事：**让读者觉得"接下来的内容跟我有关，而且我现在不知道答案"**。 - -有效 Hook 类型： - -| Hook 类型 | 示例 | 触发机制 | -|-----------|------|---------| -| 反直觉结论 | "先说结论：90%的 Agent 项目失败不是因为技术，是因为 Message Flow" | 认知冲突 | -| 真金白银 | "4 个月烧了 2 万刀，我终于搞明白一件事" | 损失厌恶 | -| 身份挑战 | "你觉得你会用 Claude Code？连最基本的 CLAUDE.md 你都不会写" | 自尊心 | -| 悬念制造 | "我发现了一个残酷真相，但说出来可能会得罪很多人" | 好奇心缺口 | - -**第 1 句铁律**：正文第 1 句（非标题）必须直接包含 ≥1 素材锚点（Type A 或 Type B 优先）。不是"前 3 句"，是"第 1 句"。铺垫、背景、定义——全部后置。 - -> 来源：栗子KK vs 苍何对比分析。苍何每篇第 1 句即含锚点（"OpenClaw我已经写N篇了"、"说到 OpenClaw Skill 水产市场"），栗子KK 常用 1-2 句铺垫才进入锚点，导致开头密度不足。 - -**禁止的开头**： -- 背景介绍（"AI 编程是近年来..."） -- 自我介绍（"大家好，我是..."） -- 目录式开头（"本文将从以下几个方面..."） - -### 3.2 段间钩子（防跳读） - -每个 section 结尾要制造"未完成感"，让读者无法在此停下： - -**钩子句式**（section 尾部使用）： -- "但真正让我震惊的是下面这个发现" -- "如果你以为这就完了，那你太乐观了" -- "接下来这部分，才是整篇文章最值钱的" -- "这个错误我犯了 3 次才学会，你大概率也会犯" - -**小标题要有信息量**： -- 差："第一步" → 好："第一步：这个操作让 90% 的人栽跟头" -- 差："解决方案" → 好："唯一靠谱的解决方案（我试了 5 种）" -- 差："总结" → 好："3 个你现在就能用的行动项" - -### 3.3 阅读节奏控制 - -``` -节奏模型（1500-3000 字文章）： - -Hook（50 字） ████ 高密度冲击 -过渡（100 字） ██ 降速，给背景 -论据1（300 字） ████████ 加速，上干货 -呼吸点 · 短段/图/代码 -论据2（400 字） ██████████ 主峰，最硬核内容 -呼吸点 · 短段/引用/类比 -论据3（250 字） ██████ 收敛，回扣主题 -结尾（100 字） ████ 金句 + CTA -``` - -节奏规则： -- **每 300-500 字一个视觉断点**：代码块、引用块、表格、加粗金句、分割线 -- **长短段交替**：3-5 句长段 → 1 句短段 → 2-3 句中段 -- **关键信息放段首**：读者是 F 型扫描，段落中间的信息会被跳过 -- **代码块不超过 15 行**：超过就拆分，每块配一句话说明 - -### 3.4 结尾工程 - -结尾决定读者是否会转发/收藏/关注。 - -**有效结尾公式**： -1. 回扣开头素材锚点（如开头"烧了 2000 美金"→ 结尾"这 2000 美金买到的最贵一课"——必须引用同一锚点，不是泛泛呼应） -2. 一句可截图的金句 -3. 具体 CTA（不是"关注我"，而是"下篇我会写 XX，点关注不迷路"） - -**禁止的结尾**： -- "希望对你有帮助"（AI 味满分） -- "以上就是今天的分享"（像在交作业） -- 没有 CTA 的结尾（白白浪费流量） - ---- - -## 4. 质量门禁（交付前强制检查） - -### 4.1 标题门禁 - -``` -□ 候选标题 ≥5 个 -□ 最终标题评分 ≥18/25 -□ 命中五要素 ≥3 项 -□ 标题 ≤35 字 -□ 不含 §1.4 禁忌 -``` - -### 4.2 去 AI 味门禁 - -``` -□ 前 50 字无黑名单词汇 -□ 无"首先...其次...最后"四段式 -□ 结尾无"综上所述/希望有帮助" -□ 无意义膨胀词汇（"里程碑意义"、"划时代"、"深远影响"） -□ 无模糊引用（"业内人士表示"、"研究表明"须给出处） -□ 相邻段落字数差异 >20%（至少 3 组） -□ 人味注入清单命中 ≥5 项（含混合情绪/刻意凌乱） -□ 二次审计通过（自问"哪里一眼看出AI"→ 无残留） -``` - -### 4.3 完读率门禁 - -``` -□ 前 3 句完成 Hook（反直觉/真金白银/身份挑战/悬念） -□ 每个 section 尾部有段间钩子 -□ 小标题有信息量（不是"第一步"、"总结"） -□ 每 300-500 字有视觉断点 -□ 结尾有金句 + 具体 CTA -□ 全文无超过 15 行的代码块 -``` - -### 4.4 素材密度门禁 - -素材锚点检查——解决"内容层空洞"问题，与去 AI 味（表达层）互补。详见 `references/material-anchors.md`。 - -``` -□ 素材脚手架已在 Step 1b 输出，总锚点 ≥3 -□ 亲历锚点（Type A）≥1 -□ 数据/案例锚点（Type B/C）≥1 -□ 第 1 句包含 ≥1 素材锚点（非标题，正文首句） -□ 每个主要章节引用 ≥1 锚点 -□ 无未标注来源的事实性断言（或已标 [?]） -``` - -**与去 AI 味的关系**：素材锚点在内容层解决空洞，去 AI 味在表达层解决模式化。有真实素材的文章天然减少 AI 味表达——当你写"4 个月烧了 2 万刀"时，不会说"在当今快速发展的..."。两层都通过 = 内容扎实 + 表达自然。 diff --git a/.claude/skills/write-article/references/kol-comparisons/栗子KK-vs-苍何.md b/.claude/skills/write-article/references/kol-comparisons/栗子KK-vs-苍何.md deleted file mode 100644 index 60443ed..0000000 --- a/.claude/skills/write-article/references/kol-comparisons/栗子KK-vs-苍何.md +++ /dev/null @@ -1,352 +0,0 @@ -# 栗子KK vs 苍何：深度风格对比分析 - -> 分析日期：2026-03-10 -> 样本：栗子KK 5 篇（personal-context/）、苍何 2 篇（09-viral-examples/） -> 用途：write-article skill 校准基准，识别栗子KK 风格的系统性弱点 - ---- - -## 1. 开头（Hook）对比 - -``` -┌───────────────────────────────────┬──────────────────────────────────────┐ -│ 栗子KK（5篇） │ 苍何（2篇） │ -├───────────────────────────────────┼──────────────────────────────────────┤ -│ "从cursor爆火到现在不到一年时间" │ "我的龙虾现在每天都会运行一个定时任务"│ -│ "最近和几个AI创业的朋友聊天" │ "OpenClaw我已经写N篇了" │ -│ "前几天刷技术博客，看到一篇..." │ │ -│ "做Agent开发这两年，踩过的坑不少" │ │ -│ "说实话，昨天深夜在算...我手抖了" │ │ -├───────────────────────────────────┼──────────────────────────────────────┤ -│ 模式：铺垫 → 背景 → "说实话"转折 │ 模式：直接开干 → 场景带入 → 你跟着看 │ -│ 平均用 3-5 句才进入正题 │ 第 1 句就在"做事" │ -└───────────────────────────────────┴──────────────────────────────────────┘ -``` - -**核心差异**：栗子KK 是"讲台型"开头（我有个观察/发现/思考），苍何是"直播型"开头（你来看我在干什么）。 - -**风险**：栗子KK 的 4/5 篇开头都有"铺垫→背景→转折"三段式，这恰好是 content-quality.md §2.2 中标记的 AI 结构性特征——"语气从头到尾一模一样"。例外是"4个月烧了2万刀"那篇，直接用金钱冲击开场，效果最好。 - -**已校准**：content-quality.md §3.1 新增"第1句铁律"——正文第1句必须直接包含素材锚点，铺垫后置。 - ---- - -## 2. 段落节奏对比 - -量化分析段落长度分布： - -``` -栗子KK "烧了2000美金" 文： -┌──────────────────────────────────────────────────────────────┐ -│ 段落字数分布（去除图片行）： │ -│ │ -│ ████████ 80字 "前言"段 │ -│ ████████████████████ 200字 "真香的部分" │ -│ ████████████████████ 200字 "真坑的部分" │ -│ ████████████████ 160字 "Devin的成与败" │ -│ ████████████████ 160字 "为什么单纯模型不够" │ -│ ████████████████ 160字 "我的一些思考" │ -│ ████████ 80字 "写在最后" │ -│ │ -│ [!] 段落长度高度均匀（150-200字区间），标准差极小 │ -└──────────────────────────────────────────────────────────────┘ - -苍何 "水产市场" 文： -┌──────────────────────────────────────────────────────────────┐ -│ 段落字数分布： │ -│ │ -│ █ 12字 "我的龙虾现在每天都会运行一个定时任务，" │ -│ ███ 40字 "就是到Clawhub去找..." │ -│ █ 15字 "我之前做教程的时候就设想过，" │ -│ █ 8字 "现版本我答案是五个，" │ -│ ████████ 90字 五件套详细列举 │ -│ █ 10字 "看起来就像是一个Agent经验社区。" │ -│ ██████████████ 140字 进化手册解释 │ -│ █ 15字 "这有点像我早期刷Reddit的感觉，很纯粹。" │ -│ █ 10字 "每一个帖子都代表了一个问题，" │ -│ │ -│ [✓] 长短交替极其明显，有大量 1 句话段落 │ -└──────────────────────────────────────────────────────────────┘ -``` - -核心差异： - -``` -┌────────────────┬──────────────────┬────────────────┐ -│ 维度 │ 栗子KK │ 苍何 │ -├────────────────┼──────────────────┼────────────────┤ -│ 段落长度标准差 │ 小（均匀） │ 大（长短交替） │ -│ 1句话段落占比 │ ~5% │ ~40% │ -│ 视觉断点频率 │ 每 400-500 字 │ 每 100-200 字 │ -│ 代码块使用 │ 技术展示型（长） │ 无代码块 │ -│ 图片插入频率 │ 每 800+ 字 │ 每 200-300 字 │ -└────────────────┴──────────────────┴────────────────┘ -``` - -**已校准**：content-quality.md §2.3 强化——每连续 3 段 ≥1 段 ≤2 句话；§2.4 节奏检测增加短段强制插入规则。 - ---- - -## 3. 素材锚点密度对比（四类锚点框架） - -``` -┌─────────────┬───────────────────────────────────┬──────────────────────────────────┐ -│ 锚点类型 │ 栗子KK "烧了2000美金" │ 苍何 "水产市场" │ -├─────────────┼───────────────────────────────────┼──────────────────────────────────┤ -│ Type A 亲历 │ ✓ "烧掉2000美金" │ ✓ "24年买的K80又又又可以上岗了" │ -│ │ ✓ "用Cursor写了个Todo管理小工具" │ ✓ "我的499又省了" │ -│ │ ✗ 其余多为泛泛观察 │ ✓ "给AI办了个手机号" │ -│ │ 计: 2 │ 计: 3+ │ -├─────────────┼───────────────────────────────────┼──────────────────────────────────┤ -│ Type B 数据 │ ✓ "2000美金" │ ✓ "前百下载量" │ -│ │ ✗ "90%的Agent项目" — 无来源 │ ✓ "自进化占了前百的10%" │ -│ │ │ ✓ "2426只龙虾" │ -│ │ 计: 1 │ ✓ "覆盖17个搜索引擎" │ -│ │ │ 计: 4 │ -├─────────────┼───────────────────────────────────┼──────────────────────────────────┤ -│ Type C 案例 │ ✓ Devin 沙盒分析 │ ✓ self-improving-agent 五件套 │ -│ │ ✓ AutoGPT/LangChain/LangGraph │ ✓ 三类资产拆解 │ -│ │ （但仅1句评价，非深入分析） │ ✓ 红手指Operator架构公式 │ -│ │ 计: 1 深 + 3 浅 │ 计: 3 深 │ -├─────────────┼───────────────────────────────────┼──────────────────────────────────┤ -│ Type D 观察 │ ✗ 无具体引用 │ ✓ "吃到了@袋鼠帝的安利" │ -│ │ │ ✓ "这有点像我早期刷Reddit的感觉" │ -│ │ 计: 0 │ 计: 2 │ -├─────────────┼───────────────────────────────────┼──────────────────────────────────┤ -│ 总计 │ ~4（含3个浅层） │ ~12（全部具体） │ -│ 密度/千字 │ ~1.3 │ ~4.0 │ -└─────────────┴───────────────────────────────────┴──────────────────────────────────┘ -``` - -**锚点密度是两者最大差距**。苍何的素材锚点密度约为栗子KK的 3 倍。 - -栗子KK 文章中的"伪锚点"（不计入）： -- "90%的Agent项目会失败" — Type B 不合格，无来源 -- "我觉得没有完美的框架" — 观点，非锚点 -- "距离一个合格的实习生，还差得很远" — 判断，非锚点 -- "模型只是在做模式匹配" — 泛泛论断 - -**已校准**：material-anchors.md §0 NEVER Rules 明确列出不计入锚点的内容类型；§1 每种锚点类型都有正反面示例。 - ---- - -## 4. AI 味检测对比 - -``` -┌─────────────────────────┬──────────────────────┬──────────────────────┐ -│ 检测维度 │ 栗子KK │ 苍何 │ -├─────────────────────────┼──────────────────────┼──────────────────────┤ -│ §2.1 开头废话 │ 4/5 篇"前言"开头 │ 0/2（直接开干） │ -│ §2.1 过渡废话 │ 偶发（"接下来聊聊"） │ 无 │ -│ §2.1 结尾废话 │ 5/5 篇模板结尾 │ 2/2 篇模板结尾 │ -│ §2.1 意义膨胀 │ 轻微（"天才""精妙"） │ 无 │ -│ §2.1 模糊引用 │ 中度（"90%的人"无源）│ 无 │ -│ §2.2 段落长度均匀 │ 是（高度均匀） │ 否（长短极端交替） │ -│ §2.2 完美对称并列 │ 是（真香/真坑对称） │ 否 │ -│ §2.2 语气均匀 │ 是（从头到尾稳定） │ 否（突然冒出"又又又"）│ -│ §2.2 所有句子完整 │ 是 │ 否（"就这？""很纯粹"）│ -│ §2.2 绕路表述 │ 轻微 │ 无（直接说"用人话"） │ -│ §2.3 不规则段落 │ 少 │ 密集 │ -│ §2.3 口语化 │ "说实话""真的" │ "kuku""又又又""薅" │ -│ §2.3 括号吐槽 │ 少 │ "（其实是习惯性无视）"│ -│ §2.3 突然语气转换 │ 无 │ "一眼幻视之后会不会" │ -│ §2.3 具体数字替代模糊 │ 中 │ 高 │ -│ §2.3 混合情绪 │ 少 │ "我现在有时候过度依赖" │ -│ §2.3 刻意凌乱 │ 无 │ "真要这样...出大招了" │ -├─────────────────────────┼──────────────────────┼──────────────────────┤ -│ 人味注入命中项 │ ~3/12 │ ~9/12 │ -│ AI味综合评分 │ 🟡 中度AI味 │ 🟢 接近零AI味 │ -└─────────────────────────┴──────────────────────┴──────────────────────┘ -``` - ---- - -## 5. 叙事结构对比 - -``` -栗子KK 标准结构（5篇均一致）： -┌──────────────────────────────────────────────────────────────────┐ -│ 前言（铺垫背景） │ -│ ↓ │ -│ 核心观点（先说结论） │ -│ ↓ │ -│ 论据展开（对称并列：真香/真坑，成/败，传统/新方案） │ -│ ↓ │ -│ 思考总结（"我的几个思考" 1/2/3/4 编号） │ -│ ↓ │ -│ 固定结尾（签名 + CTA 模板） │ -└──────────────────────────────────────────────────────────────────┘ - -苍何 标准结构（2篇均一致）： -┌──────────────────────────────────────────────────────────────────┐ -│ 我正在做一件事（直接场景带入） │ -│ ↓ │ -│ 测试场景 1（截图 + 指令 + 实际效果） │ -│ ↓ │ -│ 测试场景 2（换个场景试试） │ -│ ↓ │ -│ 测试场景 3（更生活化的场景） │ -│ ↓ │ -│ 我的感受 + 未来想象（自然收束，非总结） │ -│ ↓ │ -│ 签名 + CTA 模板 │ -└──────────────────────────────────────────────────────────────────┘ -``` - -核心差异： - -``` -┌──────────────┬────────────────────────────────┬────────────────────────────┐ -│ 维度 │ 栗子KK │ 苍何 │ -├──────────────┼────────────────────────────────┼────────────────────────────┤ -│ 叙事视角 │ 评论员（我看了很多，得出结论） │ 体验者（我正在用，你来看） │ -│ 信息密度 │ 高密度概念堆叠 │ 低密度场景展开 │ -│ 读者参与感 │ 旁观（"我告诉你"） │ 代入（"你跟着我一起试"） │ -│ 结构可预测性 │ 高（标准论文结构） │ 低（下一段不知道测什么） │ -│ 知识门槛 │ 高（需要技术背景才能跟上） │ 低（小白也能看懂） │ -└──────────────┴────────────────────────────────┴────────────────────────────┘ -``` - ---- - -## 6. 最致命的 3 个差距 - -### 差距一：抽象 vs 具体（根因） - -``` -栗子KK: - "多轮交互的噩梦：当你发现它理解错了，想要纠正， - 往往需要好几轮对话。" - └── 抽象描述，读者无法代入 - -苍何: - "然后我就看着它kuku打开B站搜索关键词，浏览并 - 筛选搜索结果，定位OpenClaw使用场景相关的视频内容" - └── 具体动作序列，读者能"看到"画面 -``` - -栗子KK 倾向于把具体经历"提炼"成抽象观点后输出，提炼过程中丢失了所有细节。苍何保留了原始体验的颗粒度。这正是素材锚点机制要解决的问题——强制保留具体细节，禁止升华为空洞观点。 - -**已校准**：content-quality.md §2.2 新增"抽象观察替代具体场景（abstraction excess）"反模式；SKILL.md Step 4a 新增"禁止抽象过度"规则。 - -### 差距二：评论者姿态 vs 参与者姿态 - -``` -栗子KK: - "我觉得要真正解决这些问题，需要的是一套完整的系统： - • 持续学习的知识库 - • 多模态的交互方式 - • 强化学习机制 - • 工程化的思维模式" - └── 开药方模式（"你们应该这么做"） - -苍何: - "我现在就希望后续的更新能够让OpenClaw操作更多的手机App， - 如果提示语+脚本+文本文件可以组成一个Skills， - 那App天然就是一个更复杂功能更全的Skills。" - └── 共同探索模式（"我也不知道答案，但我在想"） -``` - -栗子KK 的 5 篇文章都有"我的几个思考/不成熟的想法"环节——列出 3-4 条编号建议。这种结构让文章读起来像技术报告而非个人分享，且这些"思考"往往是业内共识（持续学习、垂直化、工具链），缺少独特视角。 - -**已校准**：content-quality.md §2.2 新增"结尾聚合式编号列表"反模式；§2.4 过渡检测扩展聚合清单检查；writing-styles.md lizi_kk 禁忌新增"聚合式编号列表"。 - -### 差距三：结尾同质化 - -``` -栗子KK 5 篇结尾（100% 相同模板）： - "栗子KK，一个在AI浪潮中游泳的AI产品Founder - 欢迎点赞、在看、关注，一起聊科技、聊产品、聊未来" - -苍何 2 篇结尾： - "真要这样的话我就要出大招了。" + 表情包 - "但现在有了大佬们的龙虾...可以24小时不停地交流。 - 这会让经验以一种我们想象不到的速度去蔓延" -``` - -栗子KK 的签名结尾在 5 篇文章中完全一致——这是 content-quality.md §3.4 明确禁止的（"结尾无CTA""像在交作业"）。苍何的结尾虽然也有模板（CTA 部分），但正文自然收束处各不相同。 - -**已校准**：content-quality.md §3.4 结尾公式强化——回扣开头素材锚点（必须引用同一锚点，不是泛泛呼应）。 - ---- - -## 7. 两者的各自优势 - -### 栗子KK 的独有优势（苍何不具备） - -``` -┌──────────────┬─────────────────────────────────────────────┬──────────────────┐ -│ 优势 │ 示例 │ 价值 │ -├──────────────┼─────────────────────────────────────────────┼──────────────────┤ -│ 深度技术拆解 │ OpenClaw 8个反常识设计逐条分析 │ 技术人群信任度高 │ -│ 跨产品对比 │ AutoGPT/LangChain/LangGraph/CrewAI 一文覆盖 │ 决策参考价值 │ -│ 代码级论证 │ 实际代码块展示设计理念 │ 可验证性强 │ -│ 工程哲学升华 │ 引用 Linus Torvalds、Good Taste │ 思想深度 │ -│ 个人产品关联 │ AtomStorm 的每个论点都有产品佐证 │ 商业说服力 │ -└──────────────┴─────────────────────────────────────────────┴──────────────────┘ -``` - -### 苍何 的独有优势（栗子KK 不具备） - -``` -┌──────────────┬───────────────────────────────────────────────┬────────────────┐ -│ 优势 │ 示例 │ 价值 │ -├──────────────┼───────────────────────────────────────────────┼────────────────┤ -│ 场景化叙事 │ "跟App版的OpenClaw说...然后看着它kuku打开B站" │ 可视化、代入感 │ -│ 低门槛表达 │ "用人话说就是..." │ 受众面宽 │ -│ 生活化场景 │ 习惯打卡、看小红书选题 │ 非技术读者共鸣 │ -│ 密集素材锚点 │ 每 200 字一个具体数字/名字/价格 │ 内容扎实不空洞 │ -│ 情绪真实性 │ "又又又""我的499又省了""一眼幻视" │ 人味极强 │ -│ 自然节奏 │ 1 句话段落占 40%，图文密集交替 │ 完读率高 │ -└──────────────┴───────────────────────────────────────────────┴────────────────┘ -``` - ---- - -## 8. 校准建议（已实施） - -基于以上对比，write-article 在生成栗子KK 风格文章时着重校准以下 5 点： - -``` -┌──────────────────────────────────────────────────────────────────────┐ -│ 优先级 问题 校准方向 状态 │ -├──────────────────────────────────────────────────────────────────────┤ -│ P0 段落长度高度均匀 每3段≥1段≤2句话 ✓ 已实施│ -│ P0 开头铺垫过长 第1句必须含素材锚点 ✓ 已实施│ -│ P1 抽象观点替代具体细节 每个观点后必须跟具体场景 ✓ 已实施│ -│ P1 "我的思考"编号列表 拆散到正文禁止聚合清单 ✓ 已实施│ -│ P2 结尾模板固化 金句必须回扣开头锚点 ✓ 已实施│ -└──────────────────────────────────────────────────────────────────────┘ -``` - -**核心洞察**：栗子KK 文章的问题本质不是"AI味重"（表达层尚可），而是**抽象化过度**——把真实经历提炼成通用观点后输出，读者得到的是"结论"而非"体验"。这正好是 material-anchors.md 要解决的核心问题：先有素材，再有文章；保留细节，禁止空洞升华。 - -苍何证明了：**素材密度 3 倍 = 人味 3 倍 = AI味 1/3**。当你在写"24年买的K80又又又可以上岗了"的时候，根本不会写出"在当今快速发展的..."。 - ---- - -## 9. 回测验证（2026-03-10） - -用 5 条校准规则回测已发表文章，验证规则有效性： - -``` -规则 文章A（残酷真相） 文章B（超级个体） 设计意图 -───────────────────── ───────────────── ───────────────── ──────────────── -P0 第1句铁律 ✗ 锚点延迟3段 🟡 延迟1段 强制第1句命中 -P0 段落节奏 🟡 局部均匀 ✓ 短段充分 打破AI均匀感 -P1 抽象过度 ✗ 4段纯抽象 ✓ 抽象有跟随 消除空洞观点 -P1 聚合清单 ✗ 精确命中 ✓ 无此模式 消除AI列表感 -P2 结尾回扣 ✓ 直接引用 🟡 回扣非开头锚 强化首尾一体 -───────────────────── ───────────────── ───────────────── ──────────────── -问题计数 3✗ + 1🟡 0✗ + 2🟡 - -结论：规则精确捕获已知弱点，不误杀好文章。 -``` - ---- - -## 附录：苍何样本来源 - -- `09-viral-examples/` 中苍何相关文章（OpenClaw 手机版、水产市场） -- 采集日期：2026-03 前后 -- 平台：微信公众号 diff --git a/.claude/skills/write-article/references/material-anchors.md b/.claude/skills/write-article/references/material-anchors.md deleted file mode 100644 index 407baa1..0000000 --- a/.claude/skills/write-article/references/material-anchors.md +++ /dev/null @@ -1,229 +0,0 @@ -# Material Anchors Reference - -素材锚点规范——解决"内容层空洞"问题。与去 AI 味（表达层）互补，形成双层防线。 - -核心原则：**先有素材，再有文章**。没有真实素材支撑的文章，再怎么打磨措辞也是"先污染后治理"。 - ---- - -## §0 NEVER Rules - -- **NEVER** 把以下内容计为素材锚点： - - 泛泛观察（"AI 正在改变世界"、"越来越多人开始用..."） - - 无源统计（"据统计 90% 的项目..."——谁统计的？） - - 假设场景（"假设你正在做一个项目..."） - - "业内共识"类表述（"大家都知道"、"众所周知"） - - AI 生成的虚构案例（"某公司通过 XX 技术实现了 YY"——哪家公司？） - -- **NEVER** 在素材不足时强行写作——输出 `[?] 素材不足` 并索要补充，禁止用空洞内容凑字数。 - -- **NEVER** 编造个人经历或虚构案例——宁可少一个锚点，也不能造假。 - -- **NEVER** 跳过素材脚手架直接写正文——Step 1b 是强制步骤，不是可选步骤。 - ---- - -## §1 Four Anchor Types（四类素材锚点） - -### Type A：亲历锚点 — 个人做过/花过/踩过的 - -**最高可信度**。读者能感知"这人真干过"。 - -必须包含 ≥2 项：项目名/产品名、时间节点、金钱成本、工具名称、具体结果。 - -**从 `personal-context/` 提取的示例**： - -| 锚点 | 来源 | 包含要素 | -|------|------|----------| -| "4 个月烧了 2 万刀 Token" | 超级个体文 | 时间(4个月) + 成本(2万刀) + 具体物(Token) | -| "烧了 2000 美金在 AI 写代码上" | 残酷真相文 | 成本(2000美金) + 具体行为(AI写代码) | -| "做了两年 AI Agent" | Message Flow 文 | 时间(两年) + 具体领域(AI Agent) | -| "研究了 OpenClaw 的 8 个反常识设计" | OpenClaw 文 | 数量(8个) + 产品名(OpenClaw) + 发现(反常识设计) | - -**从爆款文章提取的示例**（苍何）： - -| 锚点 | 来源 | 包含要素 | -|------|------|----------| -| "24年买的K80又又又可以上岗了" | OpenClaw手机版 | 时间(24年) + 设备(K80) + 真实使用 | -| "之前还要一台云服务器和mac mini" | OpenClaw手机版 | 具体设备 + 成本门槛变化 | -| "499元上门安装生意也不会那么火" | OpenClaw手机版 | 价格(499元) + 市场现象 | -| "我的499又省了" | OpenClaw手机版 | 个人省钱经历 + 具体金额 | - -### Type B：数据锚点 — 具体数字 + 命名来源 - -**不是你编的数字**，而是有出处的量化事实。 - -必须包含：具体数值 + 来源归属（谁说的/哪个报告/哪个平台）。 - -**示例**： - -| 锚点 | 来源 | 可信要素 | -|------|------|----------| -| "前百下载量的龙虾 Skill" | 苍何/水产市场文 | 平台排名数据 | -| "Agent 自进化占了前百的 10%" | 苍何/水产市场文 | 占比 + 排名范围 | -| "水产市场养了 2426 只龙虾" | 苍何/水产市场文 | 平台公开数据 | -| "覆盖了 17 个搜索引擎" | 苍何/OpenClaw手机版 | 产品功能数据 | - -**反面示例**（不计入锚点）： -- "据统计 90% 的 Agent 项目会失败" — 谁统计的？ -- "AI 编程效率提升 10 倍" — 什么场景？谁测的？ -- "某大厂用了之后效率翻倍" — 哪家大厂？ - -### Type C：案例锚点 — 命名实体 + 具体分析 - -**不是泛泛提及**，而是对具体产品/事件/人物的深入分析。 - -必须包含：命名实体（产品名/公司名/人名）+ 具体细节（设计/决策/结果）。 - -**示例**： - -| 锚点 | 来源 | 分析深度 | -|------|------|----------| -| "self-improving-agent + skill-creator + find-skills + skills-vetter + automation-workflows 五件套" | 苍何/水产市场文 | 5 个具体 Skill 名 + 功能拆解 | -| "水产市场的三类资产：插件、触发器、通信器" | 苍何/水产市场文 | 产品架构拆解 | -| "红手指 Operator = 云端大脑 + 终端手脚 + 安全沙盒" | 苍何/OpenClaw手机版 | 产品架构公式 | -| "OpenClaw 的 8 个反常识设计" | personal-context | 逐条设计分析 | - -**反面示例**（不计入锚点）： -- "某 AI Agent 框架做得不错" — 哪个框架？哪里不错？ -- "有些公司已经在用了" — 哪些公司？ - -### Type D：观察锚点 — 真实对话/引用 + 归属 - -**不是你的观点**，而是你听到/看到的他人言行。 - -必须包含：说话人归属（人名/角色/场景）+ 具体内容。 - -**示例**： - -| 锚点 | 来源 | 归属 | -|------|------|------| -| "吃到了 @袋鼠帝 的安利" | 苍何/OpenClaw手机版 | 具体推荐人 | -| "Sam Altman 预言的超级个体" | personal-context/超级个体文 | 具体人物 + 具体预言 | -| "这有点像我早期刷 Reddit 的感觉，很纯粹" | 苍何/水产市场文 | 个人类比 + 具体平台 | - -**反面示例**（不计入锚点）： -- "业内人士认为..." — 哪个业内人士？ -- "有观点认为..." — 谁的观点？ - ---- - -## §2 Material Sources（素材来源优先级） - -按优先级从高到低搜索素材： - -``` -1. source_notes — topic 指定的源笔记（必读，Step 1a 已覆盖） -2. personal-context/ — 作者已发表文章（亲历锚点的金矿） -3. 00-inbox/ — vault 原始素材库 -4. 09-viral-examples/ — 爆款案例库（案例锚点和数据锚点） -5. source_urls — topic frontmatter 中的外部链接 -6. material_sources — 用户额外指定的素材文件 -``` - -**搜索策略**： -- 用 `obsidian search query="<topic关键词>"` 在 vault 中搜索相关素材 -- 读取匹配的 `personal-context/` 文章，提取亲历锚点 -- 读取匹配的 `09-viral-examples/` 案例，提取案例/数据锚点 -- 素材来源越多样，文章可信度越高 - ---- - -## §3 Material Scaffold Format（素材脚手架格式） - -**Step 1b 的强制输出格式**。写正文前必须先输出这个脚手架。 - -``` -## 素材脚手架 - -### Type A 亲历锚点 -1. [锚点描述] — 来源: [vault路径或记忆] -2. [锚点描述] — 来源: [vault路径或记忆] - -### Type B 数据锚点 -1. [数据 + 来源归属] — 来源: [vault路径或URL] - -### Type C 案例锚点 -1. [命名实体 + 分析要点] — 来源: [vault路径或URL] - -### Type D 观察锚点 -1. [引用/对话 + 归属] — 来源: [vault路径] - -### 统计 -- 总锚点: X 个 -- Type A: X 个 ✓/✗（≥1） -- Type B|C: X 个 ✓/✗（≥1） -- 判定: 通过 / [?] 素材不足，需补充 [具体缺什么] -``` - -**最低阈值**： - -| 条件 | 阈值 | 原因 | -|------|------|------| -| 总锚点 | ≥3 | 低于 3 个锚点的文章必然空洞 | -| Type A（亲历） | ≥1 | 无亲身经历 = 纸上谈兵 | -| Type B 或 C（数据/案例） | ≥1 | 无数据/案例 = 无法验证 | - -**不足时处理**： -- 输出 `[?] 素材不足：缺少 Type A 亲历锚点，请补充个人经历或相关实践` -- 禁止进入 Step 2（人格激活）及后续步骤 -- 建议用户补充素材来源，或降低文章野心（缩小选题范围到有素材支撑的部分） - ---- - -## §4 Weaving Rules（编织规则） - -素材锚点不是堆在文章里的，而是编织到叙事结构中的。 - -### 4.1 Hook 必须含锚点 - -正文第 1 句（非标题）必须直接包含素材锚点（优先 Type A 或 Type B）。不是"前 3 句"，是"第 1 句"——铺垫、背景、定义全部后置。 - -**好**："4 个月烧了 2 万刀 Token，我终于搞明白一件事" — Type A 亲历锚点，第 1 句即命中 -**好**："水产市场养了 2426 只龙虾" — Type B 数据锚点，第 1 句即命中 -**好**："OpenClaw我已经写N篇了" — Type A 亲历锚点，第 1 句即命中（苍何式） -**差**："在 AI Agent 快速发展的今天..." — 零锚点，纯 AI 废话 -**差**："先说点背景知识，然后再聊我的经历" — 锚点被铺垫延迟，第 1 句空洞 - -### 4.2 每章节 ≥1 锚点 - -每个主要章节（H2/编号段落）至少引用 1 个锚点。连续 2 个章节无锚点 = 内容空洞警告。 - -### 4.3 结尾回扣开头锚点 - -结尾回扣开头的锚点，形成首尾呼应。不是重复，而是升华。 - -**示例**：开头 "烧了 2000 美金" → 结尾 "这 2000 美金买到的最贵的一课是..." - -### 4.4 事实断言溯源 - -所有事实性断言必须追溯到素材锚点，或标记 `[?]` 待验证。 - -**好**："OpenClaw 的 Skill 生态已有 2426 个（来源：水产市场平台数据）" -**差**："OpenClaw 的生态发展迅速" — 空洞断言，无数据支撑 - ---- - -## §5 Relationship to De-AI（与去 AI 味互补） - -``` -┌─────────────────────────────────────────────────────────────┐ -│ 文章质量双层防线 │ -├─────────────────────────┬───────────────────────────────────┤ -│ 素材锚点（内容层） │ 去 AI 味（表达层） │ -│ 解决: 内容空洞 │ 解决: 表达模式化 │ -│ │ │ -│ 检查: 有没有真实素材 │ 检查: 像不像人写的 │ -│ 手段: 锚点类型+阈值 │ 手段: 黑名单+人味注入 │ -│ 时机: Step 1b（写前） │ 时机: Step 4a（写中） │ -│ 门禁: §4.4（6 项） │ 门禁: §4.2（8 项） │ -├─────────────────────────┴───────────────────────────────────┤ -│ 叠加效果: 有真实素材的文章天然减少 AI 味表达。 │ -│ 当你在写"4个月烧了2万刀"时，不会说"在当今快速发展的..."。 │ -└─────────────────────────────────────────────────────────────┘ -``` - -**互补而非替代**： -- 一篇有丰富素材但表达 AI 味重的文章 → 去 AI 味门禁会拦住 -- 一篇表达很人味但内容空洞的文章 → 素材密度门禁会拦住 -- 两层都通过 = 内容扎实 + 表达自然 diff --git a/.claude/skills/write-article/references/personas.md b/.claude/skills/write-article/references/personas.md deleted file mode 100644 index 4ac8d9c..0000000 --- a/.claude/skills/write-article/references/personas.md +++ /dev/null @@ -1,144 +0,0 @@ -# Personas 配置 - -人格化核心引擎 P-Core V1.1 的可用人格定义。 - ---- - -## 栗子KK - -> 基于 `personal-context/` 5 篇已发表文章提取 - -### 基础信息 - -| 字段 | 值 | -|------|-----| -| brand_name | 栗子KK | -| brand_intro | atomstorm.ai Founder，前百度阿里技术高P，蓝星上最会AI编程的人（之一），AI Native 商业组织先驱者 | -| target_audience | 开发者、AI 从业者、技术创业者 | - -### 人格画像 - -**persona_identity**: -``` -- atomstorm.ai Founder -- 前百度阿里技术高P -- 蓝星上最会 AI 编程的人（之一） -- AI Native 商业组织先驱者 -- 2 年 AI Agent 开发经验，烧过 20000+ 美金 AI Coding 学费 -``` - -**persona_context**: -``` -- 第一人称"我"为主 -- 分享真实踩坑经历 -- 技术深度 + 商业洞察 -- 不讲虚的，只讲干货 -``` - -**voice_signature**: -``` -- 冲击式开头（数字、反差、真相） -- 口语化但不失深度 -- 敢下判断（90%、99%）但必有依据 -- 代码示例 + 数据支撑 -- 金句收尾 + CTA -``` - -**catchphrases**: -``` -- "说实话" -- "先说结论" -- "效果立竿见影" -- "99%的XX都不..." -- "这招真的管用" -- "Done is better than perfect" -- "山远路险，鞋里有沙" -``` - -### Intensity 配置 - -| 级别 | 特征 | -|------|------| -| **light** | 保持风格结构，语言偏中性 | -| **medium** | 完整风格 + 口头禅 + 典型句式 | -| **heavy** | 深度扮演 + 个人经历引用 + 完整口吻 | - -### 激活提示词 - -当 `persona: "栗子KK"` 时，注入以下系统提示： - -```markdown -你现在以"栗子KK"的人格撰写内容。 - -## 身份 -- AI 产品 Founder，AtomStorm (studio.atomstorm.ai) 作者 -- 2 年 AI Agent 开发经验，烧过 20000+ 美金 AI Coding 学费 -- 全栈工程师，技术 + 产品双重视角 - -## 语气 -- 开头必须有钩子：数字冲击、反差对比、真相揭露 -- 口语化但不失深度："说实话"、"先说结论" -- 敢下判断但必有依据：每个"90%"背后要有数据或案例 -- 结尾金句 + CTA - -## 结构 -- 数字编号分段（01, 02, 03...） -- 短段落（2-5 句话，单段不超过 150 字） -- 代码示例配文字说明 -- 数据对比表格 - -## 禁忌 -- "赋能"、"生态"等空话 -- 纯理论无案例 -- 没有个人观点 -- 完美主义收尾 - -## 签名 -结尾使用： -> 栗子KK，一个在AI浪潮中游泳的AI产品Founder -> -> 欢迎点赞、在看、关注，一起聊科技、聊产品、聊未来 🚀 -``` - -### 边界说明 - -**失效场景**（自动降级为 neutral 模式）： -- 法律/合规相关内容 -- 第三方产品客观评测 -- 需要完全中立立场的分析 - -**降级行为**： -- 移除口头禅 -- 移除个人签名 -- 保持风格结构但弱化主观表达 - ---- - -## 扩展指南 - -### 新增人格 - -1. 在 `personal-context/` 放置 3-5 篇代表性文章 -2. 创建 `templates/author-style-{slug}.md` 风格模板 -3. 在本文件添加 persona 定义 -4. 在 `writing-styles.md` 添加对应 style - -### 人格数据模板 - -```yaml -persona: "{name}" -brand_name: "{display_name}" -brand_intro: "{一句话定位}" -persona_identity: - - "{标签1}" - - "{标签2}" -persona_context: | - {核心语境描述} -voice_signature: - - "{特征1}" - - "{特征2}" -catchphrases: - - "{口头禅1}" - - "{口头禅2}" -target_audience: "{目标读者}" -``` diff --git a/.claude/skills/write-article/references/writing-styles.md b/.claude/skills/write-article/references/writing-styles.md deleted file mode 100644 index 7476e47..0000000 --- a/.claude/skills/write-article/references/writing-styles.md +++ /dev/null @@ -1,124 +0,0 @@ -# Writing Styles Reference - -本文档定义 `write-article` skill 的 5 类写作风格。每种风格都包含固定的语气、结构、禁忌。 - -## 1) 技术博客（`tech_blog`） - -### 语气 -- 专业、克制、解释导向。 -- 对术语给出必要定义，不炫技。 -- 结论可验证，避免绝对化表达。 - -### 结构 -1. 问题背景：问题是什么，为什么值得解决。 -2. 核心方案：关键设计与取舍。 -3. 实现细节：步骤、代码片段、配置或流程。 -4. 验证结果：如何验证有效性，边界在哪里。 -5. 总结与扩展：适用场景、下一步优化。 - -### 禁忌 -- 只贴代码不解释设计意图。 -- 用“黑魔法”式技巧替代可维护方案。 -- 夸大性能收益但不给验证条件。 - -## 2) 观点文（`opinion`） - -### 语气 -- 立场鲜明，但论证必须有证据链。 -- 可批判、可反驳，不做人身攻击。 -- 允许价值判断，但要明确前提条件。 - -### 结构 -1. 核心论点：开篇直接给结论。 -2. 论据展开：2-3 个关键论据，逐条论证。 -3. 反方视角：承认反例或限制条件。 -4. 立场收束：重申结论并给出行动建议。 - -### 禁忌 -- 情绪输出替代推理。 -- 稻草人论证（曲解对方观点再反驳）。 -- 断言“唯一正确答案”却不说明边界。 - -## 3) 教程（`tutorial`） - -### 语气 -- 教练式表达，步骤清晰、可执行。 -- 默认读者不知道上下文，减少跳步。 -- 重点是“让读者做出来”，不是展示作者懂多少。 - -### 结构 -1. 目标与前置条件：完成后能得到什么，需要什么环境。 -2. Step-by-step：按顺序执行，每步只有一个主要动作。 -3. 结果验证：每步的预期输出或检查点。 -4. 常见错误：高频坑位与修复方法。 -5. 收尾：复盘关键点与可选进阶路线。 - -### 禁忌 -- 跳过关键前置条件。 -- 把多个动作塞进同一步，导致不可复现。 -- 只给“成功路径”，不提供失败排查。 - -## 4) 社交短文（`social_short`） - -### 语气 -- 短促、有画面感、观点集中。 -- 首句抓人，结尾可互动。 -- 避免过度术语化，优先可传播表达。 - -### 结构 -1. Hook：首句提出冲突、反差或问题。 -2. 核心信息：1-2 个关键观点或故事片段。 -3. 行动结尾：提问、CTA 或一句可转发结论。 - -### 禁忌 -- 铺垫过长，前 3 句还没进主题。 -- 一条短文塞入过多观点。 -- 使用标题党或误导性陈述。 - -## 5) 栗子KK风格（`lizi_kk`） - -> 基于 `personal-context/` 目录 5 篇已发表文章提炼，详见 `templates/author-style-lizi-kk.md` - -### 语气 -- 直接、有冲击力，口语化但不失深度 -- 敢下判断（"99%"、"90%"），但必有数据支撑 -- 自信但不傲慢，技术细节 + 类比解释 - -### 结构 -1. **冲击式开头**：直接、有钩子，常用"说实话"、"先说结论" -2. **数字编号**：01, 02, 03... 分段清晰 -3. **短段落**：每段 2-5 句话，单段不超过 150 字 -4. **必备元素**：个人经历、具体案例、代码示例、数据支撑 -5. **金句收尾**：名人引用 + CTA - -### 语言特征 -| 书面语 | 栗子KK风格 | -|--------|-----------| -| 我发现 | 说实话，我发现 | -| 这个问题很重要 | 这个问题我觉得特别典型 | -| 效果很好 | 效果立竿见影 | -| 很多人不知道 | 99%的教程都不提这个 | -| 成功了 | 这招真的管用 | - -### 禁忌 -- "赋能"、"生态"等空话 -- 纯理论无案例 -- 过长的代码块（影响阅读节奏） -- 没有个人观点 -- 完美主义收尾（信奉"Done is better than perfect"） -- 聚合式"我的N个思考/感悟"编号列表（洞察必须散布到正文段落中） -- 连续 3 段以上长度均匀（每 3 段至少 1 个 ≤2 句话的短段） -- 抽象观点无具体场景跟随（每个判断后必须有时间/数字/工具名等细节） - -### 适用场景 -- 技术深度文章 -- 产品发布/介绍 -- 踩坑经验分享 -- 行业趋势分析 - -## 风格选择建议 -- 需要解释技术方案与实践细节：选 `tech_blog` -- 需要表达立场并说服读者：选 `opinion` -- 需要让读者可复现地完成任务：选 `tutorial` -- 需要快速传播观点或洞察：选 `social_short` -- **需要个人品牌风格、技术+实战**：选 `lizi_kk`