3.0 KiB
3.0 KiB
| name | description |
|---|---|
| doc | 渐进式文档生成器。首次只写精炼梗概（≤300字），后续通过迭代不断完善。 |
Doc - 渐进式文档生成器
核心理念：文档是缝缝补补长出来的，不是一步到位写出来的。首次只写最重要的梗概，后续通过讨论和迭代逐步完善。
当用户调用 /doc 或 /doc <指令> 时，执行以下步骤：
1. 理解需求
如果用户提供了参数，使用该描述。否则询问要写什么文档。
快速确认（已知的不重复问）：
| 项目 | 默认值 |
|---|---|
| 文档主题 | 用户指令 |
| 输出路径 | 询问用户 |
| 作者署名 | 询问用户 |
简短讨论文档边界：列出你理解的覆盖范围，标注不确定的点，让用户拍板。
你是执笔人，不是决策者。"写什么、不写什么"由用户决定。
2. 快速调研
聚焦调研，不求面面俱到：
- 扫描相关代码和现有文档
- 提取核心概念、关键接口、主要数据流
- 了解项目现有文档风格（命名、格式）
调研完成后，用 2-3 句话告诉用户你发现了什么，有什么存疑的点。不需要正式的大纲确认环节，直接写梗概，快速拿到反馈比完美大纲更重要。
3. 生成梗概
3.1 写作原则
首次写作（默认模式）：
- 言简意赅，建议控制在 300 字以内
- 只写最重要的骨架：是什么、为什么、怎么用
- 留白是刻意的，后续迭代会填充细节
- 不需要面面俱到，抓住核心价值
迭代补充（用户再次调用 /doc 指向同一文件时）：
- 读取现有内容，在此基础上增量补充
- 递增版本号，更新
updated日期 - 每次迭代聚焦一个方面，不要一次补太多
3.2 文档头部
---
title: {文档标题}
version: v1.0
created: {YYYY-MM-DD}
updated: {YYYY-MM-DD}
author: {作者署名}
---
3.3 内容要求
- 准确：基于实际代码，不编造
- 精炼：一句话能说清的不用两句
- 实用：面向读者，提供可操作的信息
- 善用表格、代码块、ASCII 图示（但首次不强求）
4. 保存并输出
保存到用户指定路径。如果文件已存在，先询问是覆盖还是增量更新。
输出摘要：
文档: {标题} | 版本: v1.0 | 路径: {path}
字数: ~{N}字（首版梗概）
后续可以通过 /doc 继续补充完善。
主人，用不用我沉淀 or git 提交？
工作流总览
/doc <指令>
│
├── 1. 理解需求（简短确认主题、路径、署名）
├── 2. 快速调研（聚焦核心，不求全面）
├── 3. 生成梗概（≤300字，抓骨架）
└── 4. 保存输出（鼓励后续迭代）
注意事项
- 少即是多：首版宁短勿长，300 字是指导建议而非硬限制
- 鼓励迭代：每次
/doc都是一次对话机会，文档在讨论中成长 - 不做代码改动：本 skill 只生成文档
- 风格一致：与项目已有文档风格保持一致