Skill v1.0.0

version: "1.0.0" name: blog-draft description: 从想法和资源出发起草博客文章。当用户想要写博客文章、从研究中创建内容或草拟文章时使用。引导完成研究、头脑风暴、大纲制定和带版本控制的迭代式写作流程。

用户输入

$ARGUMENTS

你必须先考虑用户输入再继续操作。用户应提供:

• 想法/主题:博客文章的主要概念或主题
• 资源:URL、文件或参考资料(可选但推荐)
• 目标受众:博客文章的读者群体(可选)
• 语调/风格:正式、随意、技术性等(可选)

重要:如果用户请求更新已有的博客文章,跳过步骤 0-8,直接从步骤 9开始。先读取现有的草稿文件,然后进入迭代流程。

执行流程

按以下顺序逐步执行。不要跳过步骤或在需要用户确认的地方未经批准就继续。

步骤 0:创建项目文件夹

1. 使用以下格式生成文件夹名:YYYY-MM-DD-短主题名称

• 使用今天的日期
• 从主题生成短小、URL 友好的 slug(小写、连字符分隔、最多 5 个词)

1. 创建文件夹结构:

`` blog-posts/ └── YYYY-MM-DD-短主题名称/ └── resources/ ``

1. 创建文件夹后向用户确认再继续。

步骤 1:研究与资料收集

1. 在博客文章目录中创建 resources/ 子文件夹

1. 对每个提供的资源:

• URL:获取关键信息并保存到 resources/ 的 markdown 文件中
• 文件:阅读并在 resources/ 中总结
• 主题:使用网络搜索收集最新信息

1. 对每个资源,在 resources/ 中创建摘要文件:

• resources/source-1-[简称].md
• resources/source-2-[简称].md
• 等等

1. 每个摘要应包含:

```markdown # 来源:[标题/URL]

## 要点

• 要点 1
• 要点 2

## 相关引用/数据

• 引用或统计数据 1
• 引用或统计数据 2

## 与主题的关系 简要说明相关性 ```

1. 向用户展示研究摘要。

步骤 2:头脑风暴与澄清

1. 基于想法和研究资源,展示:

• 从研究中识别出的主要主题
• 博客文章的潜在角度
• 应该涵盖的关键要点
• 需要澄清的信息缺口

1. 提出澄清问题:

• 你希望读者获得的核心收获是什么?
• 研究中有哪些重点想强调?
• 目标篇幅?(短篇:500-800 字,中篇:1000-1500 字,长篇:2000+ 字)
• 有哪些要点需要排除?

1. 等待用户回复后再继续。

步骤 3:提出大纲

1. 创建包含以下内容的结构化大纲:

```markdown # 博客文章大纲:[标题]

## 元信息

• 目标受众:[谁]
• 语调:[风格]
• 目标篇幅:[字数]
• 核心收获:[关键信息]

## 建议结构

### 开头/引言

• 吸引人的开场白
• 背景铺垫
• 论点陈述

### 第一部分:[标题]

• 要点 A
• 要点 B
• 来自 [来源] 的支持证据

### 第二部分:[标题]

• 要点 A
• 要点 B

[继续所有章节...]

### 结论

• 关键要点总结
• 行动号召或最终思考

## 引用来源

• 来源 1
• 来源 2

```

1. 向用户展示大纲并请求批准或修改建议。

步骤 4:保存已批准的大纲

1. 用户批准大纲后,将其保存到博客文章文件夹中的 OUTLINE.md。

1. 确认大纲已保存。

步骤 5:提交大纲(如果在 git 仓库中)

1. 检查当前目录是否为 git 仓库。

1. 如果是:

• 暂存新文件:博客文章文件夹、资源和 OUTLINE.md
• 创建提交,消息为:docs: Add outline for blog post - [主题名]
• 推送到远程仓库

1. 如果不是 git 仓库,跳过此步并告知用户。

步骤 6:撰写草稿

1. 基于已批准的大纲,撰写完整的博客文章草稿。

1. 严格按照 OUTLINE.md 的结构进行。

1. 包含:

• 吸引人的引言和开头
• 清晰的章节标题
• 来自研究的支持证据和示例
• 章节间流畅的过渡
• 有力的结论和核心收获
• 引用:所有对比、统计数据和数据点必须引用原始来源

1. 将草稿保存为博客文章文件夹中的 draft-v0.1.md。

1. 格式要求:

```markdown # [博客文章标题]

[可选:副标题或标语]

[包含内联引用的完整内容...]

## 参考文献

• [1] 来源 1 标题 - URL 或引用
• [2] 来源 2 标题 - URL 或引用
• [3] 来源 3 标题 - URL 或引用

```

1. 引用要求:

• 每个数据点、统计或对比必须有内联引用
• 使用编号引用 [1]、[2] 等,或命名引用 [来源名称]
• 将引用链接到文末的参考文献部分
• 示例:"研究表明 65% 的开发者偏好 TypeScript [1]"
• 示例:"React 渲染速度比 Vue 快 20% [React Benchmarks 2024]"

步骤 7:提交草稿(如果在 git 仓库中)

1. 检查是否在 git 仓库中。

1. 如果是:

• 暂存草稿文件
• 创建提交,消息为:docs: Add draft v0.1 for blog post - [主题名]
• 推送到远程仓库

1. 如果不是 git 仓库,跳过并告知用户。

步骤 8:展示草稿供审阅

1. 向用户展示草稿内容。

1. 请求反馈:

• 整体印象如何?
• 哪些部分需要扩展或精简?
• 是否需要调整语调?
• 是否有遗漏信息?
• 具体的编辑或重写建议?

1. 等待用户回复。

步骤 9:迭代或定稿

如果用户请求修改:

1. 记录所有修改需求
2. 返回步骤 6,做如下调整:

• 递增版本号(v0.2、v0.3 等)
• 整合所有反馈意见
• 保存为 draft-v[X.Y].md
• 重复步骤 7-8

如果用户批准:

1. 确认最终草稿版本
2. 可选:按用户要求重命名为 final.md
3. 总结博客文章创建过程:

• 创建的总版本数
• 版本间的关键变更
• 最终字数
• 创建的文件列表

版本跟踪

所有草稿都保留增量版本号:

• draft-v0.1.md -- 初始草稿
• draft-v0.2.md -- 第一轮反馈后
• draft-v0.3.md -- 第二轮反馈后
• 等等

这样可以追踪博客文章的演进过程,并在需要时回退。

输出文件结构

blog-posts/
└── YYYY-MM-DD-主题名/
    ├── resources/
    │   ├── source-1-名称.md
    │   ├── source-2-名称.md
    │   └── ...
    ├── OUTLINE.md
    ├── draft-v0.1.md
    ├── draft-v0.2.md(如有迭代)
    └── draft-v0.3.md(如有更多迭代)

质量提示

• 开头吸引人:以提问、令人惊讶的事实或相关场景开始
• 行文流畅:每段应与下一段自然衔接
• 证据支撑:用研究数据支撑论点
• 引用规范:始终引用以下来源:
• 所有统计数据(例如:"根据 [来源],75% 的...")
• 产品/服务/方案之间的对比(例如:"X 比 Y 快 2 倍 [来源]")
• 关于市场趋势、研究发现或基准测试的事实声明
• 使用内联引用格式:[来源名称] 或 [作者, 年份]
• 语调一致:全文保持一致的语调风格
• 篇幅控制:尊重目标字数要求
• 易读性:使用短段落,适当使用列表
• 结尾有力:以明确的行动号召或引人深思的问题结束

注意事项

• 始终在大纲标注的检查点等待用户批准
• 保留所有草稿版本以便追溯历史
• 当提供了 URL 时使用网络搜索获取最新信息
• 如果资源不足,向用户请求更多信息或建议补充研究
• 根据目标受众调整语调(技术类、通用类、商务类等)