agentleFS
unix2dosunix2dos/skills/blog-content-editor/SKILL.md

blog-content-editor

Skill7 starsChanged 51 days agoMITView on GitHub

诊断并受控编辑完整博客草稿,经作者确认后执行删除、补充与必要重排。

The file

Files
SKILL.md

博客内容编辑

围绕原稿主线做受控内容编辑。按以下优先级判断每一项改动:

主线清楚 > 核心完整 > 结构严谨 > 文字精练

将保留作者语气作为硬约束。精练意味着没有冗余,不要求总字数减少。

职责边界

只处理已经形成连续正文、可以独立阅读的完整草稿。若输入主要是笔记、素材、提纲或排障记录,停止并建议改用 $notes-to-blog。若用户要按统一技术写作规范整体重塑语言和结构,建议改用 $blog-refine。

不要继承 $blog-refine 的工程师语气、SEO、标题编号、强制过渡或句长限制。本 skill 的权限仅限于经作者确认的删除、补充和必要重排。

严格分两个阶段执行。阶段一结束后必须暂停;收到明确执行意图前,不得输出编辑后的文章。

阶段一:诊断与编辑计划

1. 判断文章

从草稿中判断:

  • 文章类型:知识文章、观点文章、个人叙事或混合类型。
  • 目标读者。
  • 核心主张。
  • 读者读完后的预期收获。

按文章类型判断核心完整性:

  • 知识文章:读者能否理解关键概念、适用边界和必要解释。
  • 观点文章:主张能否被理由、证据和必要的反面边界支撑。
  • 个人叙事:事件、感受和转折是否共同服务表达主线。
  • 混合类型:先确定主类型,再用其他类型的标准补充检查。

只有无法从草稿可靠判断目标读者、核心主张或预期收获时,才启动关键访谈。每轮一次性询问最多三个问题;回答仍产生必要歧义时,才追加一轮。提问后暂停诊断。

2. 制定验收标准

提出 2–5 条可直接检查的本篇验收标准。标准必须针对当前文章,例如“读者能用一句话复述核心主张”或“每个关键论点都有必要支撑”,不要使用“内容更好”之类的空泛描述。

3. 建立编辑计划

只记录真正影响主线、核心完整性或结构的问题。每项必须定位原文,并说明问题的影响和建议动作:

  • 删除 D:偏离主线、边缘冷门、同义复述或没有信息增量的内容。
  • 补充 A:目标读者理解主线不可缺少、但原文缺失的内容。
  • 重排 R:通过移动、合并或拆分现有内容才能修复的论证顺序和层级问题。
  • 事实风险 F:缺少依据或需要外部核实的事实、数据、案例和引用。

不得为填满格式而制造问题。某类没有项目时明确写“无”。补充内容不得扩展边缘知识,也不得替作者编造观点、经历或材料。

4. 输出并暂停

严格使用以下结构:

## 内容诊断

### 文章判断
- 类型:
- 目标读者:
- 核心主张:
- 预期收获:

### 本篇验收标准
1. ...

### 删除清单
| ID | 原文位置或短摘录 | 问题 | 对主线的影响 | 建议动作 |
|---|---|---|---|---|
| D1 | ... | ... | ... | ... |

### 补充清单
| ID | 建议位置 | 缺失的核心内容 | 为什么不可缺少 | 建议动作 |
|---|---|---|---|---|
| A1 | ... | ... | ... | ... |

### 重排清单
| ID | 涉及位置 | 结构问题 | 对主线的影响 | 建议动作 |
|---|---|---|---|---|
| R1 | ... | ... | ... | ... |

### 事实风险
| ID | 原文位置或相关计划项 | 风险 | 处理建议 |
|---|---|---|---|
| F1 | ... | ... | ... |

### 推荐侧重点
精简为主 / 增补为主 / 综合优化 / 无需编辑

请确认要执行的项目。你可以全部接受、按 ID 部分接受、修改或拒绝清单项目。

输出后暂停。阶段一的完成条件是:诊断覆盖所有真实存在的问题,并已请求作者确认;不包含任何编辑后的正文。

阶段二:执行确认计划

收到“全部执行”“执行 D1、A2”“按我修改后的清单执行”等明确意图后,先将作者的回复解析为最终计划,再执行:

  1. 只删除、补充或重排最终计划中的项目。
  2. 保留计划外的有效内容和作者原有措辞、节奏与表达个性。
  3. 允许顺带修复明显错别字和不改变含义的病句。
  4. 保留 Frontmatter、链接、引用、代码块及其他 Markdown 元素;移动或删除这些元素必须已有确认项目。
  5. 不自动联网研究。事实缺口保持为风险或待补内容;只有作者明确允许研究后,才检索并为新增事实标明来源。
  6. 默认只返回结果,不写回本地文件。只有作者明确要求“写回”或“直接修改文件”时才编辑原文件。
  7. 将阶段一识别出的事实风险带入最终输出。只有风险内容已被删除或已有可靠来源支持时,才标记为已解决;拒绝相关编辑不等于风险消失。

若作者只修改了计划但没有表达执行意图,输出更新后的计划并再次请求确认。

阶段二输出

## 编辑后的文章

[完整 Markdown 文章]

## 修改摘要
- D1:...
- A2:...

## 未解决的事实风险
- F1:...

没有未解决风险时明确写“无”。完整交付不代表全文重写:阶段二的完成条件是每个最终确认项目均已执行、每项改动都能对应到最终计划、每个事实风险都有结论,并且计划外内容保持不变。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.