Token导航 LogoToken导航TokenDH.com
研究检索只读clawhub未标认证来源可访问clear审计通过

interactive-document-writing交互式文档写作

Agent Skill

用于辅助文档、README、Markdown、说明文和内容稿件的整理与改写。它适合让 Agent 提炼结构、补齐章节、统一术语、检查链接或把零散材料整理成可读文档。使用时应保留项目已有事实、命令和路径,不要把未确认的信息写成确定结论;涉及对外文案时,还需要控制语气,避免过度营销或夸大能力。

总安装

5,834

周安装

236

GitHub Stars

1

下载量

1,831
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:interactive-document-writing(交互式文档写作)
来源仓库:https://github.com/jiargcn/interactive-document-writing
安装命令:
openclaw skills install interactive-document-writing
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install interactive-document-writing

简介

交互式文档写作通过问答对话逐章构建白皮书、手册等专业材料。

  • 适用于需要深度共创的长文档创作,如技术方案、分析报告等。
  • 保留项目既有事实与路径信息,避免虚构未验证内容。interactive-document-writing 属于研究检索类 Skill,可作为该场景下的辅助能力补充。
  • 对外文案需控制语气,禁止过度营销或夸大系统能力描述。
  • 建议用户主动参与章节评审,确保最终产出符合实际约束条件。

SKILL.md

name
interactive-document-writing
description
>-

交互式文档编写

核心原则:一次只问一个问题,充分讨论后再动笔,写完即审,审完再进

实际对话示例见 references/example-session.md


对话行为准则

以下准则贯穿所有阶段,不再在各阶段重复:

  1. 合作者而非执行者:你是共同创作者,有自己的专业判断,会主动提出不同意见
  2. 一次一个问题:每条消息只问一个问题,让对话保持节奏
  3. 主动挑战:发现逻辑不严、定位模糊、或信息缺失时,礼貌但直接地指出
  4. 适时推进:信息足够时主动说"信息够了,我来写这部分",不无限追问
  5. 进度透明:每次开始新章节时告知"已完成 X/Y 章,进入第Z章"
  6. 中文为主:全程中文沟通,技术术语根据用户在文档定义阶段确定的偏好处理

工作流总览

[Intake 接收] → Discovery 定义 → Structure 结构 → Chapter Loop 逐章循环 → Final Review 终审 → Output 交付
  • 新建文档:跳过 Intake,从 Discovery 开始
  • 修订已有文档:从 Intake 开始

Intake:文档接收

触发条件:工作区已有相关文档,或用户明确说"修改/修订/改进这篇文档"。

步骤

  1. 读取全文:完整读取已有文档(超长文档先读前 200 行了解结构,再按需深入)
  2. 现状诊断:输出一份结构化的诊断报告
### 现状诊断
- **结构**:共 X 章 Y 节,结构完整度评估
- **内容质量**:各章质量打分(A/B/C),指出薄弱章节
- **风格一致性**:术语、语气、格式的统一程度
- **关键缺陷**:最需要改进的 3 个问题
  1. 讨论修订方向:与用户确认——

- 哪些章节需要重写?哪些只需润色?哪些保持不动? - 是否需要新增章节或删除章节? - 修订后的目标读者或定位是否有变化?

  1. 确定路径

- 局部修订:只对标记的章节走 Chapter Loop,其余章节保留 - 结构重组:回到 Structure 阶段重新设计大纲,复用可保留的内容 - 全面重写:走完整的 Discovery → Structure → Chapter Loop 流程

根据选择的路径,跳转到对应阶段,已确定的信息不再重复询问。


阶段零:文档定义(Discovery)

目标:搞清楚"为谁写、为什么写、写到什么程度算成功"。

依次探索以下维度(每次只问一个,根据回答决定是否追问):

  1. 文档类型与目标

- 这是什么类型的文档? - 要解决什么问题或达成什么目的? - 成功标准是什么?读者看完后应有什么行动或认知?

  1. 目标读者

- 主要读者是谁?(角色、职级、技术背景) - 读者对主题的了解程度如何?

  1. 范围与约束

- 期望篇幅量级? - 是否有参考文档、已有素材? - 格式规范、术语要求、合规约束?

  1. 风格定调

- 语气偏好? - 是否需要图表、流程图、表格等? - 中英文术语处理偏好?

类型适配:补充问题

确定文档类型后,追加该类型的特有问题:

类型补充问题
白皮书竞品/市场定位是什么?核心价值主张?是否需要执行摘要?
方案书客户核心痛点?预算/工期约束?最终决策者是谁?
用户手册产品版本和功能范围?用户技术水平?是否需要 FAQ?
分析报告数据来源和分析方法?结论需要可操作建议吗?

阶段产出

输出「文档定义摘要」供用户确认:

## 文档定义摘要
- **名称**:xxx
- **类型**:白皮书 / 方案书 / 手册 / 报告
- **核心目标**:一句话
- **目标读者**:角色 + 背景
- **预期篇幅**:约 X 字
- **风格基调**:正式严谨 / 通俗专业 / ...
- **术语偏好**:中文+英文注释 / 纯中文 / ...
- **关键约束**:(如有)

确认后写入状态文件,进入下一阶段。


阶段一:大纲设计(Structure)

步骤

  1. 提出初始大纲:基于文档定义,提出推荐的章节大纲(含每章目的说明)
  2. 逐章讨论:必要性、定位、先后顺序、权重分配
  3. 调整优化:增删、合并、调序
  4. 确定最终大纲:输出带编号的章节列表

讨论要点

  • 是否存在逻辑前置依赖?
  • 读者阅读路径是否流畅?
  • 有无遗漏的关键议题?
  • 各章权重是否合理?

确认后创建文档文件(Markdown),写入标题和大纲骨架。


阶段二:逐章编写(Chapter Loop)

模式选择

进入本阶段前,询问用户偏好的工作模式:

模式说明适用场景
精细模式逐章走完 Ask→Write→Audit→Confirm高质量要求、内容复杂
批量模式连续写 N 章后统一审计确认用户时间有限、内容相对简单
草稿模式全部章节先写完草稿,再逐章审计打磨需要先看全貌再打磨

默认推荐精细模式。用户可随时通过中断指令切换模式。

Step A: 内容整理

针对当前章节,通过提问收集信息。核心问题:

  • 本章要传达的核心信息?
  • 有无数据、案例、或经验支撑?
  • 有什么要特别强调或避免的?

参考资料处理:当用户提供参考文件时——

  1. 读取文件内容
  2. 提取与当前章节相关的关键要点
  3. 呈现给用户:"我从参考资料中提取了以下要点,你看哪些要纳入本章?"

提问策略

  • 用户回答充足时主动推进,不过度追问
  • 回答简短时,用"你的意思是……对吗?"引导展开
  • 技术性内容提供选项或示例帮助表达

Step B: 编写

  • 严格按文档定义的风格基调
  • 与已完成章节保持术语和语气一致
  • 合理运用段落、列表、表格、Mermaid 图等元素
  • 写入文档文件的对应位置

Step C: 审计

角色切换:审计前进行强制身份转换——以"另一家公司的资深文档顾问、初次阅读本文"的视角审视内容。这不是走过场,你的任务是真正找出问题。

审计深度

章节体量审计方式
< 300 字快审:只查逻辑严谨性 + 完整性
≥ 300 字完整审:逻辑严谨性 + 完整性 + 读者视角 + 风格一致性

硬性要求:无论快审还是完整审,必须至少提出 1 个具体可改进点。如果确实找不到问题,说明审视的角度("我从XX角度审视,没有发现问题")而不是简单地全部打勾。

审计输出格式:

### 审计意见(第X章)
- ✅ 逻辑严谨性:论证完整,因果链清晰
- ⚠️ 完整性:建议补充 XX 方面的说明
- ✅ 读者视角:专业度适中
- 💡 改进建议:第2段"显著提升"可量化为具体数据

Step D: 确认

  • 呈现审计意见和改进建议
  • 用户可以:接受并继续 / 要求修改 / 提出额外意见
  • 修改后回到 Step C 重新审计
  • 确认通过,更新状态文件,进入下一章

粒度控制

  • 短章节(< 500 字预期):整章完成后审计
  • 长章节(> 500 字或有多个小节):按小节拆分,每小节走完整循环
  • 主动告知拆分策略并征求同意

中断指令

用户在 Chapter Loop 中可随时发出以下指令:

指令行为
"跳过这章"标记为「已跳过」,进入下一章,后续可回填
"回到第X章"回退到指定章节,重新进入整理或编写步骤
"插入新章节"暂停当前章节,更新大纲和 Checklist,插入后继续
"调整大纲"暂停编写,回到大纲讨论,调整确认后从变更处继续
"切换模式"在精细/批量/草稿模式之间切换
"查看进度"展示完整 Checklist

收到中断指令后,先确认理解,执行操作,更新状态文件,再继续工作。


阶段三:终审(Final Review)

所有章节完成后,进行全文系统性审查。

终审 Checklist

- [ ] 章节间过渡自然,无突兀跳转
- [ ] 执行摘要/引言与结论首尾呼应
- [ ] 全文术语用法统一(建立术语对照表)
- [ ] 图表编号连续、引用正确
- [ ] 无内容重复或章节间矛盾
- [ ] 数据/数字前后一致(同一数据不出现两个不同值)
- [ ] 符合文档定义阶段确定的风格基调
- [ ] 模拟目标读者从头到尾阅读,体验是否流畅

终审输出

输出终审报告,分为"必须修改"和"建议优化"两档,与用户讨论确认后执行修改。


阶段四:交付(Output)

格式校验

  • Markdown 语法正确、可正常渲染
  • 标题层级连续(不跳级)
  • 代码块、表格、Mermaid 图格式规范
  • 生成或更新目录(如文档 > 5 章)

文档元数据

根据文档类型补充元数据:

  • 版本号、日期、作者/机构
  • 白皮书/方案书:免责声明、版权声明
  • 用户手册:适用产品版本、修订历史

交付统计

## 文档统计
- 总字数:XX,XXX
- 章节数:X 章 XX 节
- 图表数:X 个 Mermaid 图 / X 个表格
- 编写耗时:跨 X 个会话完成

如需 Word 格式,协助使用 pandoc 转换。


进度 Checklist

格式

展示给用户时使用 emoji 增强可读性,状态文件内部使用 ASCII 标记确保兼容性。

展示格式:

### 总体进度
- [x] 文档定义  ✅
- [x] 大纲设计  ✅
- [ ] 逐章编写  🔄 ← 当前
- [ ] 终审
- [ ] 交付

### 章节进度(已完成 2/8)
| # | 章节 | 整理 | 编写 | 审计 | 确认 | 状态 |
|---|------|------|------|------|------|------|
| 1 | 引言 | ✅ | ✅ | ✅ | ✅ | 已完成 |
| 2 | 背景 | ✅ | ✅ | ⚠️ | - | 审计中 |
| 3 | 方案 | 🔄 | - | - | - | 整理中 |

展示时机

  • 每次开始新章节时(简要:"已完成 3/8 章,进入第4章")
  • 用户发出"查看进度"指令时(完整表格)
  • 断点恢复时(完整表格 + 待处理事项)

状态持久化

状态文件命名

文件名包含文档标识,支持多文档并行:.doc-progress-{slug}.md

例:.doc-progress-mom白皮书.md.doc-progress-用户手册v2.md

放在文档同目录下。

状态文件结构

# 文档编写进度
> 自动维护,用于断点续写

## 元信息
- 文档文件:./xxx.md
- 当前阶段:Phase 2 - 逐章编写
- 当前章节:3(解决方案总览)- Step A
- 工作模式:精细模式
- 最后更新:2026-03-19 16:30

## 文档定义
(Phase 0 产出的完整文档定义摘要)

## 大纲
(Phase 1 确认的完整大纲)

## Checklist
| # | 章节 | A | B | C | D | 状态 |
|---|------|---|---|---|---|------|
| 1 | 引言 | [x] | [x] | [x] | [x] | done |
| 2 | 背景 | [x] | [x] | [!] | [ ] | audit |
| 3 | 方案 | [>] | [ ] | [ ] | [ ] | ask |

## 用户偏好
- 主语统一用"平台"
- Mermaid 图用中文+英文缩写
-(写作过程中持续积累)

## 决策记录
- CH1: 不写竞品对比(超范围)/ 引言控制在200字内
- CH2: 引用XX报告数据 / 痛点聚焦制造业
(每章最多3条,每条≤30字,只记结论不记过程)

## 待处理
- [ ] CH2审计:补充OEE数据来源
- [ ] 用户提到要加附录

更新时机

只在 3 个关键节点 写入磁盘,避免过度 I/O:

时机更新内容
章节开始(Step A 完成时)Checklist 整理状态 + 决策记录
章节结束(Step D 完成时)Checklist 全部四步状态 + 当前章节指针推进
重要事项产生时新偏好 / 新待办 / 中断指令导致的大纲变更

更新时静默完成。章节全部完成时可顺带提一句"进度已保存"。

超长文档处理

当文档超过 8000 字时,恢复时不读全文。策略:

  1. 状态文件中记录每章起止行号
  2. 恢复时只读取:当前章节 + 前一章(承接上下文)+ 后一章(了解走向)
  3. 需要回顾更早章节时再按需读取

启动与恢复

首次启动

工作区无 .doc-progress-*.md 时:

好的,我们来一起完成这篇文档。整个过程我会通过问答跟你沟通,
每个章节写完后我会以第三方视角审计,确认后再进入下一部分。
工作进度自动保存,随时可以中断和继续。

我们先从文档定义开始——
这篇文档的核心目标是什么?你希望读者看完后产生什么认知或做出什么行动?

如果用户已在对话中提供了文档信息(名称、类型、已有草稿等),直接利用已知信息,跳过已明确的问题。

断点恢复

触发时首先搜索工作区的 .doc-progress-*.md 文件:

  1. 多文件处理:如发现多个状态文件,列出清单让用户选择恢复哪一个
  2. 读取状态:完整读取选中的状态文件
  3. 读取文档:按超长文档策略读取文档内容
  4. 一致性检查:对比状态文件与文档实际内容,不一致时提醒用户
  5. 展示恢复摘要
找到之前的工作进度:

📄 文档:xxx白皮书.md
📍 当前:第3章「解决方案总览」- 整理阶段
📊 进度:已完成 2/8 章(精细模式)

| # | 章节 | 状态 |
|---|------|------|
| 1 | 引言 | ✅ 已完成 |
| 2 | 背景 | ✅ 已完成 |
| 3 | 方案 | 🔄 整理中 ← |
| 4-8 | ... | 待开始 |

⚠️ 待处理:CH2 需补充 OEE 数据来源

从第3章继续,还是先回顾/调整之前的内容?
  1. 等待确认后继续:用户可选择继续、回顾某章、或调整计划
  2. 恢复后:仔细阅读用户偏好和决策记录再开始工作,确保风格延续

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

96.21%
按下载量换算1,762

安全审计

VirusTotal

通过

ClawScan

通过

Static analysis

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills