ClawHub
Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

Writing Pipeline

内容再创作管线：输入参考资料 → AI 生成中文初稿 → 人工改稿 → 系统对比学习写作偏好 → 多平台格式输出。 支持自动路由——根据输入材料特征自动匹配最合适的写作风格。

MIT-0 · Free to use, modify, and redistribute. No attribution required.
⭐ 0 · 15 · 0 current installs · 0 all-time installs
by@shing19
MIT-0
Security Scan
VirusTotalVirusTotal
Suspicious
View report →
OpenClawOpenClaw
Suspicious
medium confidence
!
Purpose & Capability
The skill declares a content re‑writing pipeline and its file layout; most read/write operations (saving references, drafts, metadata) align with that purpose. However, the SKILL.md explicitly instructs the agent — after user confirmation — to 'execute updates' to other writing-style skill files (i.e., modify other skills' files/config). That capability is broader than a pipeline's typical remit and is not reflected in any declared requirements or config paths, creating a privilege/scope mismatch.
!
Instruction Scope
The instructions perform many filesystem operations (create project dirs, save references and sidecar JSON, copy drafts to final.md, write README.md, output assets). They also instruct using other skills (deepreader, x_search, viewpoint-extractor, infographic-gen, wechat-cover, xiaohongshu-cards, and various writing-style-* skills). Most actions are reasonable for a pipeline, but two items stand out as problematic: (1) the snippet showing an import/use of deepreader_skill (implies executing or importing external code), and (2) the explicit flow to edit other skills' files after diff analysis. The SKILL.md does not constrain or document how those cross-skill modifications are authorized or audited.
✓
Install Mechanism
This is instruction-only with no install spec and no bundled code — lower risk in terms of arbitrary code installation. No external download URLs or install scripts are present.
ℹ
Credentials
The skill declares no required environment variables or credentials, which is consistent with being an orchestration/instruction-only skill. However, it expects to call multiple helper skills (deepreader, x_search, etc.) that in practice may require API keys or access tokens. The skill does not declare or request those credentials nor does it state who provides them. That omission can lead to surprising behavior if those helper skills prompt for or use credentials.
!
Persistence & Privilege
always:false is appropriate, but the documented ability to propose and then 'execute corresponding skill file updates' grants this skill potential write/modify access to other skills' code/config. Allowing a skill to programmatically change other skills increases blast radius and should be explicitly authorized, logged, and restricted — none of which is described here.
What to consider before installing
This skill mostly does what it says (draft → review → publish) but contains two noteworthy risks: (1) it instructs the agent to modify other 'writing-style' skills after learning from edits, and (2) it orchestrates many helper skills (deepreader, x_search, infographic-gen, etc.) without declaring their credentials or access requirements. Before installing: 1) Confirm you trust the owner/source (unknown here). 2) Verify how the platform enforces user confirmation — ensure the agent cannot auto-confirm updates that modify other skills. 3) Back up the skill directories and any writing-style skills that could be changed. 4) Audit the helper skills (deepreader, x_search, etc.) to see whether they require API keys or have network/exfil behavior. 5) If you allow updates to other skills, require explicit, per-change user approval and maintain an audit log. If you cannot verify those controls, treat this skill as higher risk and consider running it in a restricted environment or refusing permission to modify other skills.

Like a lobster shell, security has layers — review code before you run it.

Current versionv1.0.0
Download zip
latestvk9795rd4798zfgcpe9zdrtvbnn83zdj7

License

MIT-0
Free to use, modify, and redistribute. No attribution required.
Termshttps://spdx.org/licenses/MIT-0.html

SKILL.md

Writing Pipeline

内容再创作管线。三个阶段：Draft → Review → Publish。

Stage 1: Draft（生成初稿）

步骤

  1. 创建文章目录

    projects/writing/articles/YYYY-MM-DD-{slug}/

  2. 保存参考材料（含 comment/highlight） 将用户提供的参考资料保存到 references/ 子目录。

    comment 机制（新增，必做）：

    • 若参考资料存在行内评论 sidecar（如 references/*.comments.json），必须一并保存，不可丢失。
    • 评论中带有 highlight 的片段视为“强信号素材”，在 Stage 1 写初稿时必须优先吸收。
    • 先生成一份素材提炼清单 references/reference-notes.md，按如下结构整理：
      • must-include：被 highlight 的原句/要点（后文必须落入初稿）
      • angle：评论给出的写作角度、争议点、可展开问题
      • evidence：可直接引用的数据、案例、事实
      • avoid：评论中明确标注不建议采用的表达

    X/Twitter 链接处理： 如果参考材料中包含 x.com 或 twitter.com 链接，使用 deepreader skill 抓取推文内容（FxTwitter API，无需 API key），保存为 references/tweet-{id}.md。用法：

    from deepreader_skill import run
result = run("https://x.com/user/status/123456")

  3. X 搜索：查询相关事实与事件 用 x_search 搜索与参考材料相关的关键词、人物、事件，获取最新信息：

    • 从参考材料中提取 2-3 个核心关键词
    • 调用 x_search 查询，收集近期相关讨论、事实、数据
    • 将搜索结果摘要保存到 references/x-search-results.md
    • 生成初稿时将搜索结果作为补充上下文，确保内容基于最新事实

  4. 自动路由：匹配写作风格 分析输入材料的特征，匹配最合适的 writing-style skill：

    输入材料 → 提取特征(domain, content_type, tone) → 匹配 style skill → 确认

    路由规则（按优先级）：

    1. 用户明确指定 style → 直接使用
    2. 未指定 → AI 分析材料特征，与每个 style skill 的 routing metadata 匹配
    3. 选择匹配度最高的 skill，向用户确认后加载

    匹配矩阵：

    输入特征→ 推荐风格
    技术论文、产品发布、AI 模型writing-style-huasheng
    创业故事、人物传记writing-style-huasheng
    方法论、工具教程、how-towriting-style-baoyu
    AI 工具评测、写作技巧writing-style-baoyu
    哲学思辨、人生设计、意义探讨writing-style-dankoe
    跨领域框架、自我提升、身份探讨writing-style-dankoe
    长文摘要、知识提取、结构化转述writing-style-zhengliu
    表达欲过强的文章、信息提取困难writing-style-zhengliu

    路由分析流程：

    1. 识别材料的主题领域(domain)
   → tech/AI/product → huasheng 候选
   → writing/productivity/tools → baoyu 候选
   → psychology/identity/meaning → dankoe 候选

2. 识别内容类型(content_type)
   → explainer/biography → huasheng 候选
   → methodology/how-to/opinion → baoyu 候选
   → essay/thought-piece/philosophical → dankoe 候选

3. 识别语气倾向(tone)
   → narrative/data-driven → huasheng
   → teaching/metaphor-driven → baoyu
   → philosophical/provocative → dankoe
   → structured/fact-driven/extractive → zhengliu

4. 检查蒸馏触发条件（优先级高于风格匹配）
   → 用户明确要求"蒸馏/提取/结构化转述" → zhengliu
   → 原文篇幅长 + 信息密度低 + 表达欲强 → zhengliu 候选

5. 综合三个维度，选择匹配度最高的 skill
6. 如果两个 skill 匹配度接近，列出两个选项让用户选择

  5. 选题讨论（必做，不可跳过）

    提供 3-4 个选题方向，每个包含：

    选题 N：标题
- 核心角度：一句话说清楚文章讲什么
- 核心比喻：（如使用宝玉风格）贯穿全文的比喻
- 结构预览：3-5 个章节标题 + 预计字数分配
- 优势：为什么这个角度好
- 风险：可能的问题或难点

    标题原则——共鸣式标题： 标题的目标不是概括内容，而是说出读者心里那句没说出口的话。 找到目标读者普遍存在但很少被说清楚的困惑/痛点/感受，用一句话替他们问出来。 读者看到标题的反应应该是"对！我也是这样！"→ 然后点进来。

    其他规则：

    • 每个选题的角度必须明显不同，不能是同一个思路换个说法
    • 等用户选择后再进入下一步，不要自行决定
    • 用户可以选某个选题、混合多个选题、或提出全新方向

  6. 生成初稿（reference + comment 联合驱动） 用户确认选题后，加载匹配的 writing-style skill，基于 references/ 与 references/reference-notes.md 联合生成初稿，保存为 draft-v1.md。

    • 硬约束：所有 must-include（highlight 片段）必须在初稿中被明确吸收（可改写措辞，但核心信息不能丢）
    • 若某个 highlight 与其他证据冲突，必须在文中给出说明，且在草稿末尾加“冲突说明”小节
    • 如有多轮风格迭代，按 draft-v0.md、draft-v1.md、draft-v2.md 递增保留各版本
    • 初稿完成后，必须立刻复制最新 draft 为 final.md，供用户直接在终稿编辑器中改稿（cp draft-vN.md final.md）
    • 若 final.md 已存在且非空，不覆盖；仅在缺失或空文件时执行复制

  7. 提取观点与生成信息图（可选，也可在 Stage 2 后执行） a. 加载 viewpoint-extractor skill，从初稿中提取 3-5 个核心观点 b. 保存 viewpoints.yaml 到文章目录 c. 加载 infographic-gen skill，为每个观点生成信息图 d. 输出到 output/infographics/{slug}.jpg

    此步骤可推迟到 final.md 完成后再执行，用终稿提取的观点更准确。

  8. 写入元数据 创建 README.md：

    ---
title: 文章标题
date: YYYY-MM-DD
style_skill: writing-style-xxx
sub_template: 子模板名（如适用）
source_materials:
  - references/xxx.md
status: draft
---

    状态字段约束（必须遵守）

    • 仅允许：draft / reviewed / ready / published / deprecated
    • 禁止写自定义状态（例如 draft-generated），前端状态徽章不会识别

参考资料 comment 文件约定（新增）

  • references/*.comments.json 视为参考资料的 sidecar 评论文件，存储高亮与讨论线程。
  • 执行 Stage 1/2/3 时，不要删除或覆盖这些 sidecar 文件。
  • 写初稿时必须优先读取 sidecar 中的 highlight 与 comment，再结合原文 reference 生成内容。
  • 若缺失 sidecar 但用户明确说“我做了高亮/评论”，先在 references/reference-notes.md 记录该缺口并提示补充。

文章目录结构

articles/YYYY-MM-DD-{slug}/
  README.md              # 元数据
  references/            # 参考材料
    *.comments.json      # 参考资料行内评论 sidecar（含 highlight）
    reference-notes.md   # 从 reference+comment 提炼出的素材清单
  draft-v1.md            # AI 初稿
  final.md               # 人工终稿（Stage 2）
  final.comments.json    # 终稿行内评论（前端编辑器 sidecar 数据）
  diff-analysis.md       # 差异分析（Stage 2）
  viewpoints.yaml        # 观点提取结果（viewpoint-extractor skill 生成）
  output/                # 多平台输出（Stage 3）
    infographics/        # 信息图（infographic-gen skill 生成）
      {slug-1}.jpg
      {slug-2}.jpg
    blog/
      article.md
    wechat/
      article.md
      cover.jpg           # 微信封面（wechat-cover skill 生成）
    xiaohongshu/
      text.md             # 发帖文本（编辑推荐语）
      cards/              # 文转图卡片（xiaohongshu-cards skill 生成）
        01.jpg, 02.jpg, ...
    jike/
      article.md
    twitter/
      article.md

Stage 2: Review（人工改稿 + 学习）

前置条件

用户已将改稿保存为 final.md

如果改稿在前端完成，目录中可能存在 final.comments.json（终稿行内评论数据）。该文件用于编辑协作，不参与平台分发。

步骤

  1. 执行 Diff-and-Learn 详见 references/diff-learn.md

  2. 生成差异分析 将分析结果保存为 diff-analysis.md

  3. 提议 Skill 更新 根据差异分析，提出对应 writing-style skill 的更新建议：

    • 新增的禁止项
    • 需要调整的风格要点
    • 新发现的偏好规则

    必须先向用户确认后再执行更新

  4. 更新元数据 将 README.md 中 status 改为 reviewed

文件约定（重要）

  • final.comments.json 是 final.md 的 sidecar 文件，存储 inline comment 线程。
  • 执行 Stage 2 / Stage 3 时，不要删除或覆盖 final.comments.json。
  • 多平台输出只读取正文（final.md），不要把评论内容写入平台文案。
  • 复制/迁移文章目录时，建议连同 final.comments.json 一并保留，避免评论线程丢失。

Stage 3: Publish（多平台输出）

步骤

  1. 读取终稿 加载 final.md（如无则用最新 draft）

  2. 原文图片统一上传 R2 并回写终稿（必做）

    • 扫描文章目录下图片资产（至少包含 images/，可扩展到其他本地图片目录）
    • 用 r2-upload skill 批量上传，生成 output/r2-image-mapping.json（相对路径 → R2 URL）
    • 将 final.md 里的本地图片路径统一替换为 R2 URL
    • 若原文图片较多（例如案例集），在 final.md 里补充“原文图集”章节，确保可直接复用

  3. 选择目标平台 让用户选择输出平台（可多选）：

    • 微信公众号 (wechat)
    • 小红书 (xiaohongshu)
    • 即刻 (jike)
    • 推特 (twitter)
    • 博客 (blog)

  4. 加载 Formatter 并生成 对每个目标平台，加载 projects/writing/formatters/{platform}.md，按规则生成格式化内容。

    • 小红书：额外加载 xiaohongshu-editor-pick skill 生成编辑推荐语风格的发帖文本，并必须运行 xiaohongshu-cards skill 生成文转图卡片（小红书是图文平台，卡片是必做输出）

  5. 保存输出 按平台分目录保存到 output/{platform}/：

    • blog/article.md
    • wechat/article.md
    • xiaohongshu/text.md（发帖文本）
    • jike/article.md
    • twitter/article.md

  6. 插入信息图到全平台文章（如 output/infographics/ 存在且非空，必做）

    信息图必须插入到每个平台文章的对应内容段落位置（不是堆在末尾）。 根据信息图的 slug 和 viewpoints.yaml 中的 title，找到文章中对应的章节，在该章节标题前插入。

    上传：

    • 用 r2-upload skill 批量上传 output/infographics/ 到 R2，获取 R2 URL
    • 用 wechat-upload skill 批量上传到微信素材库，获取 mmbiz.qpic.cn URL
    • 按文件名顺序记录 R2 URL 和微信 URL 的对应关系

    插入（全平台，每个都要做）：

    • blog：![alt](R2 URL) 插入到对应段落前
    • wechat：![alt](mmbiz URL) 插入到对应段落前。微信不支持外链图片，必须用微信素材库 URL
    • jike：📊 R2 URL 纯文本行，插入到对应段落前（即刻是纯文本平台）
    • twitter：📊 R2 URL 纯文本行，插入到对应段落前
    • xiaohongshu：见步骤 8 的小红书卡片生成流程（信息图嵌入卡片图片中）

  7. 微信图片链接替换（当目标平台包含 wechat 时，必做）

    • 用 wechat-upload skill 批量上传文章图片（至少包含 images/ 与 output/infographics/）
    • 保存映射到 output/wechat/image-mapping.json（相对路径/R2 URL → {media_id, url}）
    • 将 output/wechat/article.md 中所有图片链接替换为微信素材库 URL（mmbiz.qpic.cn）
    • 校验：output/wechat/article.md 不得残留 R2/GitHub 等外链图片 URL

  8. 生成图片资产（必做）

    • 微信封面（必做）：用 wechat-cover skill → output/wechat/cover.jpg
      • 默认风格：Claymation 3D mascot + flat UI mockup（详见 wechat-cover SKILL.md）
      • prompt = 默认风格前缀 + 文章主题描述 + no text
      • flash 模型优先，失败换 pro
      • 生成后必须用 wechat-upload skill 上传到微信素材库，记录 media_id 和微信 URL 到 output/wechat/image-mapping.json（key 为 cover.jpg）。微信公众号封面图必须使用微信素材库中的图片
    • 小红书卡片（必做）：用 xiaohongshu-cards skill → output/xiaohongshu/cards/*.jpg
      • 如果 output/infographics/ 存在且非空，必须将信息图嵌入卡片：
        1. cp final.md final.md.bak（备份原文）
        2. 在 final.md 对应段落位置插入信息图的 markdown 图片引用（![alt](R2 URL)）
        3. 运行 xiaohongshu-cards 生成脚本（脚本会渲染 markdown 中的图片到卡片中）
        4. mv final.md.bak final.md（还原原文）
      • 卡片生成脚本的 HTML 模板已有 .card-flow img 样式，会自动渲染内嵌图片

  9. 更新元数据 将 README.md 中 status 改为 ready（中文：已就绪），记录发布平台

    状态约束（强制）：

    • 完成全平台内容产出后，只能标记为 ready，禁止自动改为 published
    • published 仅在用户明确要求“已发布/已实际发布”时才可使用

自动路由详解

Style Skill 的 Routing Metadata

每个 writing-style skill 的 YAML frontmatter 包含 routing 字段：

routing:
  content_types: [...]     # 擅长的内容类型
  domains: [...]           # 擅长的领域
  tone: [...]              # 语气特征
  best_for: "..."          # 一句话描述最佳场景

路由算法

输入：参考材料文本
输出：推荐的 style skill 名称

1. 分析材料特征
   - domain: 从关键词、主题、术语判断领域
   - content_type: 从结构、目的判断内容类型
   - tone: 从语气、目标读者判断期望语调

2. 计算匹配度
   对每个 style skill:
     domain_match = 材料 domain ∩ skill routing.domains
     type_match = 材料 content_type ∩ skill routing.content_types
     tone_match = 材料期望 tone ∩ skill routing.tone
     score = domain_match * 2 + type_match * 2 + tone_match * 1

3. 选择 score 最高的 skill
   - 如果最高分 skill 唯一 → 推荐该 skill
   - 如果两个 skill 分数接近（差距 < 20%）→ 列出两个让用户选
   - 如果所有 skill 分数都很低 → 提示用户手动选择

当前可用 Style Skills

Skill擅长关键词
writing-style-huasheng技术解读、人物叙事、产品评测AI, 深度学习, 创业, 数据驱动
writing-style-baoyu方法论、教程、观点输出写作, 工具, 生产力, 比喻驱动
writing-style-dankoe思辨文章、框架构建、身份探讨心理学, 控制论, 意义, 跨领域
writing-style-zhengliu知识蒸馏、结构化转述、长文摘要任意领域, 四层结构, 数据优先, 信息提取

快速命令

  • 开始新文章：提供参考材料，管线自动进入 Stage 1
  • 提交改稿：告知 final.md 已就绪，管线进入 Stage 2
  • 发布：指定目标平台，管线进入 Stage 3

Files

2 total
Select a file
Select a file to preview.

Comments

Loading comments…