关于 cw-dev-edit
cw-dev-edit 是用于审阅草稿的写作技能，重点检查论证、结构、证据、意义与收束，而非润色句子。它提供结构化评估，同时由写作者决定论点取舍与修改方式。
主要功能
- 01审阅结构与论证
- 02检查主要主张的证据
- 03测试小节重点与论点一致性
- 04提供完整或快速评估
- 05由写作者决定修改方向
适用场景
- 01投稿或发布前评估草稿
- 02发现引言与全文内容的偏差
- 03检查各章节是否支撑核心观点
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/cw-dev-edit确认已加载。
详细介绍
发展性编辑
目的
审阅初稿中的宏观问题：论点、结构、利害关系和收获。重点关注文章是否有效，而非句子是否润色到位。
请阅读 ../../references/context-contract.md，并在评判初稿前加载相关的任务、项目、出版物、来源和文风背景。
让作者参与论点的发展过程。指出对论点形成压力的证据和反方观点，提供可选的修改方向，不要悄悄替换核心论点。
使用场景
- 按工作流完成初稿后
- 直接对任何来源的初稿进行编辑
- 作为“让它更好”综合请求的一部分
关注事项
可考虑以下问题（并非每篇文章都适用）：
| 方面 | 问题 |
|---|---|
| 结构 | 每个部分都有存在的价值吗？顺序是否合理？ |
| 论证 | 逻辑是否清晰、论据是否充分？有没有漏洞？ |
| 证据 | 每个主要论点有什么依据？个人经历？关联的研究？具体示例？哪些地方的支持薄弱或缺失？ |
| 局外人视角 | 如果一个不了解作者或出版物的读者拿起文章就读，会提出什么质疑？哪些内容会让人觉得是圈内人的简略说法？ |
| 开篇 | 引子有效吗？论点清晰吗？文章作出了什么承诺？ |
| 利害关系 | 读者为什么要关心？作者为什么在意？ |
| 收获 | 文章是否兑现了承诺？ |
运用判断力。 个人随笔不需要审查论证。操作指南不需要分析利害关系。关注对这篇文章真正重要的方面。
结构测试
以下两项诊断测试用于判断文章是否结构完整。当结构显得不太对劲时，请同时执行这两项测试；对于任何带有小标题的文章，也可以主动执行。
小节概述测试
为每个小节写一句话，概述其论点。然后重新阅读该小节。凡是不服务于这句话的内容，都删掉。
Agent 调用此测试时：
- 找出每个小节（由小标题界定，或由段落构成的段落组）。
- 为每个小节生成一句话的论点概述。
- 标出不服务于小节概述的段落、示例或插话。
- 将概述与标出的内容一并报告，让作者决定保留哪些内容。
此测试可发现：应该放到别处的精彩句子、早期草稿遗留下来的填充内容、以及混杂在同一小节中的两个论点。
20 秒推介测试
如果有人在走廊里拦住作者，作者能否在 20 秒内讲清楚文章的内容？然后，将这段推介与引言中陈述的论点／承诺进行比较。
Agent 调用此测试时：
- 根据文章现有内容生成一段 20 秒推介（概述文章从头到尾实际讲了什么）。
- 提取引言中陈述的论点／承诺。
- 并排展示两者，并指出差距。
如果推介和引言不一致，说明其中一个有问题。通常是引言在修改过程中偏离了文章最终呈现的内容，需要调整以反映文章的实际内容。
证据核查
对于每个主要论点，都要问：它有什么依据？
| 支持类型 | 评估 |
|---|---|
| 作者亲身经历过的事情 | 有力——保留 |
| 有链接的研究、数据集或具名来源 | 有力——保留 |
| 专家引言或具名从业者 | 有力——保留 |
| 具名的具体示例（公司、人物、事件） | 有力——保留 |
| 没有具体细节的“研究显示……”／“专家一致认为……”／“很多人说……” | 薄弱——标出 |
| 作者并未在此特定领域建立声誉，却只依赖作者自身的权威 | 薄弱——标出 |
| 毫无依据——论断悬而无据 | 薄弱——标出 |
作者不是某个领域的专家，也可以写这个领域的内容。但不能在论据不足的情况下依靠自信的语气支撑论断。明确标出缺乏依据的论断——作者可以补充证据、弱化论断，或将其删去。
输出选项
完整报告（默认，适用于全面审阅）
## Developmental Edit Report
### Opening
🔴 **Critical:** [Issue]
[Why it matters]
🟡 **Consider:** [Issue]
[Explanation]
### [Section Name]
🟢 **Minor:** [Issue]
[Explanation]
---
Where would you like to start?
严重程度：
- 🔴 严重 — 不修复就无法使用
- 🟡 建议考虑 — 能显著提升效果
- 🟢 轻微 — 有则更好
快速评估（用于更快反馈）
## Quick Dev Edit
**Working well:** [2-3 things]
**Needs attention:**
1. [Main issue + why]
2. [Second issue + why]
**Overall:** [Ready for line edit / Needs another pass / Major restructure needed]
对于较短的内容、时间紧迫的情况，或作为创作过程的一部分调用时，请使用快速评估。
协作修改
报告完成后：
- 作者选择从哪里开始（也可以直接跳到逐行修改）
- 提出修改建议：“我会这样处理——[修改]。要我来做这个改动吗？”
- 作者可以接受、自己修改或跳过
- 根据需要重复
不要强求解决每个问题。 作者决定哪些问题重要。
灵活性
- 作者可以要求重点关注某个方面（“只看结构”）
- 作者可以完全跳过 dev-edit
- 作者可以进行多轮审阅
- 可与其他反馈方式（nemesis read、objections）结合，用于压力测试
面向 Agent
以编程方式调用时：
- 接收草稿作为输入
- 返回结构化评估（问题 + 严重程度）
- 包含“整体就绪度”指标
- 可与其他审阅技能组合使用
经验总结
[此技能专属的经验总结将在记录后添加]