@aigne/doc-smith 0.9.8-alpha.5 → 0.9.8-alpha.7

package/README.md

@@ -48,10 +48,10 @@ doc-smith-skill/
 ├── doc-smith/             # Skill 主目录
 │   ├── SKILL.md           # Skill 主文档（中文）
 │   └── references/        # 参考文档
-│       ├── document_structure_schema.md   # 文档结构 Schema
-│       ├── structure_confirmation_guide.md # 结构确认指南
-│       ├── structure_planning_guide.md    # 结构规划指南
-│       └── user_intent_guide.md           # 用户意图指南
+│       ├── document-structure-schema.md   # 文档结构 Schema
+│       ├── structure-confirmation-guide.md # 结构确认指南
+│       ├── structure-planning-guide.md    # 结构规划指南
+│       └── user-intent-guide.md           # 用户意图指南
 ├── scripts/               # 安装/卸载脚本
 │   ├── install.sh         # 安装脚本
 │   ├── uninstall.sh       # 卸载脚本
@@ -80,7 +80,7 @@ doc-smith-skill/
 然后根据提示操作，DocSmith 会：
 1. 分析你的工作区
 2. 规划文档结构
-3. 生成 `document_structure.yaml`
+3. 生成 `document-structure.yaml`
 4. 创建结构化的 Markdown 文档
 
 ### 3. 查看生成的文档
@@ -90,7 +90,7 @@ doc-smith-skill/
 ```
 .aigne/doc-smith/
 ├── output/
-│   └── document_structure.yaml    # 文档结构定义
+│   └── document-structure.yaml    # 文档结构定义
 └── docs/
     └── [生成的文档文件]
 ```
@@ -99,10 +99,10 @@ doc-smith-skill/
 
 - **SKILL.md** - Skill 完整使用指南，包含工作流程、最佳实践等
 - **references/**
-  - **document_structure_schema.md** - 文档结构 YAML 的完整 Schema 说明
-  - **structure_planning_guide.md** - 文档结构规划指南
-  - **structure_confirmation_guide.md** - 结构确认流程指南
-  - **user_intent_guide.md** - 用户意图理解指南
+  - **document-structure-schema.md** - 文档结构 YAML 的完整 Schema 说明
+  - **structure-planning-guide.md** - 文档结构规划指南
+  - **structure-confirmation-guide.md** - 结构确认流程指南
+  - **user-intent-guide.md** - 用户意图理解指南
 
 所有文档均已翻译为中文，方便理解和编辑。
 

package/doc-smith/SKILL.md

@@ -10,8 +10,8 @@ description: "从工作区数据源生成和更新全面的文档，包括代码
 ## 概述
 
 DocSmith 分析工作区内容（代码、文件、媒体）并生成：
-1. 用户意图描述（`user_intent.md`）
-2. 文档结构计划（`document_structure.yaml`）
+1. 用户意图描述（`user-intent.md`）
+2. 文档结构计划（`document-structure.yaml`）
 3. 按层次组织的 Markdown 文档文件
 
 所有输出都创建在 `.aigne/doc-smith/` 目录中。
@@ -48,31 +48,31 @@ DocSmith 分析工作区内容（代码、文件、媒体）并生成：
 ### 2. 推断用户意图
 
 首先检查用户意图文件是否已存在，如果存在向用户问询是否需要修改。
-用户意图格式参考： `references\user_intent_guide.md`
+用户意图格式参考： `references\user-intent-guide.md`
 
 ### 3. 规划文档结构
 
 首先检查文档结构文件是否已存在，如果存在执行第 5 步骤 ，向用户问询是否需要修改。
-文档结构规划要求参考： `references\structure_planning_guide.md`
+文档结构规划要求参考： `references\structure-planning-guide.md`
 
-### 4. 生成 document_structure.yaml
+### 4. 生成 document-structure.yaml
 
-文档结构数据结构参考： `references\document_structure_schema.md`
+文档结构数据结构参考： `references\document-structure-schema.md`
 
 ### 5. 确认文档结构
 
-向用户展示的结构请参考： `references\structure_confirmation_guide.md`
+向用户展示的结构请参考： `references\structure-confirmation-guide.md`
 
 ### 6. 生成文档内容
 
-为结构中的每个文档在 `.aigne/doc-smith/docs/` 中创建 markdown 文件。使用 YAML 中的 `path` 作为文件路径，从 `sourcePaths` 提取信息，编写清晰、结构化的内容。
-
-在文档开头和结尾添加导航链接，引导用户阅读相关文档（开头：前置条件、父主题；结尾：相关主题、下一步、子文档）。
+为结构中的每个文档在 `.aigne/doc-smith/docs/` 中创建 markdown 文件。
+文档内容生成要求参考：`references\document-content-guide.md`
 
 ### 7. 更新已有文档
 
 仅当 `.aigne/doc-smith/docs/` 已存在时处理文档更新。
-处理流程请参考 `references\document_update_guide.md` 和 `references\changeset_schema.md`
+处理流程请参考 `references\document-update-guide.md` 和 `references\changeset-schema.md`
+文档的更新需要符合文档内容的生成要求，参考：`references\document-content-guide.md`
 
 ## 输出结构
 
@@ -81,8 +81,8 @@ DocSmith 分析工作区内容（代码、文件、媒体）并生成：
 ```
 .aigne/doc-smith/
 ├── output/
-│   ├── user_intent.md             # 用户意图描述
-│   └── document_structure.yaml    # 文档计划
+│   ├── user-intent.md             # 用户意图描述
+│   └── document-structure.yaml    # 文档计划
 └── docs/
     ├── overview.md                # 生成的文档
     ├── getting-started.md
@@ -90,28 +90,10 @@ DocSmith 分析工作区内容（代码、文件、媒体）并生成：
         └── authentication.md
 ```
 
-## 媒体资源
-
-当工作区中存在媒体文件（图片、视频）时：
-
-**发现：**
-```bash
-find . -type f \( -name "*.png" -o -name "*.jpg" -o -name "*.gif" -o -name "*.mp4" \)
-```
-
-**在 markdown 中引用：**
-```markdown
-![架构图](../path/to/diagram.png)
-
-<!-- 或相对于文档位置 -->
-![截图](../../screenshots/ui.png)
-```
-
-**不要复制**媒体文件。直接从它们的工作区位置引用。
-
 ## 关键原则
 
 - **参考引用文件**：执行到每个步骤时，如果提供了参考文件，必须先阅读参考文件中的要求
-- **基于用户意图**：所有规划和生成都应参考 `user_intent.md`
+- **文档内容要求**：执行任何文档相关的生成、更新，都需要参考`references\document-content-guide.md`，确保文档符合要求
+- **基于用户意图**：所有规划和生成都应参考 `user-intent.md`
 - **最小必要原则**：只生成用户意图中明确需要的文档
 - **批量执行**：生成文档内容时优先批量执行，缩短执行时间

package/doc-smith/references/{changeset_schema.md → changeset-schema.md}

@@ -6,8 +6,6 @@ Changeset 只包含两类修改：
 1. **全局语义修改** - 跨文档的规则、术语、风格
 2. **结构重写** - 补充、重写、重组特定章节
 
-**注意：** PATCH 类修改通过文档内 `:::PATCH` 标记实现，不会出现在 changeset 中。
-
 ## 读取和理解
 
 Changeset 是自然语言文本，格式自由。你需要：
@@ -42,51 +40,17 @@ Changeset 是自然语言文本，格式自由。你需要：
 "API 文档补充错误码说明"         → 结构重写
 ```
 
-## 常见模式参考
-
-### 模式 1：简单列表
-```markdown
-1. 统一术语："API" → "API 接口"
-2. 补充 overview.md 的项目背景
-3. 删除所有形容词
-```
-
-理解：1, 3 是全局修改；2 是结构重写
-
-### 模式 2：分类组织
-```markdown
-## 全局修改
-- 代码示例添加语言标识符
-- 禁止使用第一人称
-
-## 补充内容
-- getting-started.md 添加环境要求
-- api/errors.md 补充错误原因
-```
-
-理解：按章节分类，直接识别
-
-### 模式 3：自由描述
-```markdown
-发现文档问题：
-- "API" 和 "接口" 混用，统一为 "API 接口"
-- 快速开始缺环境要求说明
-```
-
-理解：第一条是全局修改，第二条是结构重写
-
 ## 执行流程
 
 ### 1. 读取文件
-```bash
-cat <changeset-file-path>
-```
+
+读取 changeset 文件，只读取用户指令中指定的文件，忽略其他 changeset 文件。
 
 ### 2. 分类汇总
 
 **全局修改：**
-- 规则 1: ...
-- 规则 2: ...
+- 1: ...
+- 2: ...
 
 **结构重写：**
 - 文档 A, 章节 X: ...
@@ -97,9 +61,6 @@ cat <changeset-file-path>
 **优先级：** 全局修改 → 结构重写
 
 **全局修改：**
-```bash
-find .aigne/doc-smith/docs/ -name "*.md"
-```
 遍历所有文档，应用规则
 
 **结构重写：**

package/doc-smith/references/document-content-guide.md

@@ -0,0 +1,188 @@
+# 文档内容生成指南
+
+本指南定义了生成 markdown 文档时的内容要求和格式规范。
+
+## 基本要求
+
+为结构中的每个文档在 `.aigne/doc-smith/docs/` 中创建 markdown 文件：
+- 使用 YAML 中的 `path` 作为文件路径
+- 从 `sourcePaths` 提取信息
+- 编写清晰、结构化的内容
+- **在生成文档内容时主动添加图片**（参见"媒体资源"章节）
+
+## 导航链接
+
+在每个文档中添加导航链接，引导用户在文档之间流畅跳转。
+只能链接生成的其他文档，不能链接到工作目录中的 markdown 文件，文档发布后会导致无法访问。
+
+### 文档开头导航
+
+在文档正文开始前添加：
+- **前置条件**：阅读本文档前建议先了解的内容
+- **父主题**：当前文档所属的上级主题
+
+### 文档结尾导航
+
+在文档末尾添加：
+- **相关主题**：与当前文档相关的其他文档
+- **下一步**：建议阅读的后续内容
+- **子文档**：当前文档包含的子主题列表
+
+## 媒体资源
+
+### 前置准备：确定文档和媒体的位置关系
+
+**在开始生成文档前，必须完成以下步骤：**
+
+#### 1. 确定文档输出目录
+
+从 `document-structure.yaml` 的文档配置中读取，文档输出目录固定为：`.aigne/doc-smith/docs/`
+
+#### 2. 查找所有媒体文件
+
+执行以下命令查找工作区中的所有媒体文件：
+
+```bash
+find . -type f \( -name "*.png" -o -name "*.jpg" -o -name "*.jpeg" -o -name "*.gif" -o -name "*.svg" -o -name "*.mp4" -o -name "*.webp" \)
+```
+
+记录所有结果，例如：
+- `./assets/create/screenshot1.png`
+- `./assets/run/screenshot2.png`
+- `./images/architecture.png`
+
+#### 3. 相对路径计算规则
+
+**核心公式：**
+```
+图片相对路径 = (向上到根目录的 ../) + 图片路径（去掉开头的 ./）
+```
+
+**层级对照表：**
+- 文档在 `docs/` → 3层 → `../../../`
+- 文档在 `docs/api/` → 4层 → `../../../../`
+- 文档在 `docs/api/auth/` → 5层 → `../../../../../`
+- 规律：每增加一层子目录，增加一个 `../`
+
+**示例：**
+- 文档：`.aigne/doc-smith/docs/getting-started.md`（3层）
+- 图片：`./assets/run/screenshot.png`
+- 结果：`../../../assets/run/screenshot.png`
+
+**常见错误：**
+- ❌ 层级数数错（`docs/` 用了 `../../` 而非 `../../../`）
+- ❌ 忘记计算子目录（`docs/api/` 用了 3层而非 4层）
+
+### 生成文档时的图片处理
+
+在编写每个文档的内容时，必须主动添加图片以增强文档的可读性和专业性。
+
+#### 1. 图片分类与要求
+
+**A. 技术图表（必须生成）**
+
+以下类型的内容**必须包含相应的技术图表**，没有已有图片时必须生成 AFS Image Slot：
+
+- **架构说明** → 架构图（系统架构、模块关系、组件结构）
+- **流程说明** → 流程图（业务流程、数据流向、状态转换）
+- **时序说明** → 时序图（交互时序、调用链路）
+- **概念解释** → 概念图（概念关系、层次结构）
+- **数据结构** → 数据模型图（类图、ER 图）
+
+**B. 应用截图（必须使用已有）**
+
+以下类型必须使用工作区中的已有截图，因为必须使用真实的应用截图：
+
+- **界面介绍** → UI 截图
+- **操作步骤** → 操作演示截图
+- **功能展示** → 功能界面截图
+
+**强制性要求：**
+
+1. **技术文档必须包含技术图表**：
+   - 架构文档：至少 1 个架构图
+   - API 文档：至少 1 个时序图或流程图
+   - 概念说明：至少 1 个概念图
+   - 数据模型：至少 1 个数据结构图
+
+2. **用户指南需要包含应用截图**：
+   - 操作指南：每个主要操作步骤至少 1 张截图
+   - 功能介绍：每个功能至少 1 张界面截图
+
+3. **综合文档建议配比**：
+   - 技术图表：1-3 个
+   - 应用截图：1-2 个
+
+#### 2. 图片处理流程
+
+**对于应用截图（B 类）：**
+
+1. 只能从前置准备的查找结果中匹配图片
+2. 根据文件名判断用途（如 login.png、dashboard.png、settings.png）
+3. 使用层级对照表计算相对路径
+4. 引用图片：`![截图说明](../../../assets/screenshot.png)`
+5. 如果仓库未提供相关截图，可以不展示
+
+**对于技术图表（A 类）：**
+
+1. 检查是否有对应的技术图表（架构图、流程图等）
+2. 如果没有，**必须生成 AFS Image Slot**（不是可选）
+3. 即使有应用截图，也不能用应用截图替代技术图表
+
+**关键区别：**
+- ❌ 错误：架构说明章节使用应用截图代替架构图
+- ✅ 正确：架构说明章节生成架构图 slot，另外可以添加应用截图作为补充
+
+#### 3. 生成 AFS Image Slot
+
+**何时必须生成 Slot：**
+
+1. 文档内容需要技术图表（架构图、流程图、时序图等）
+2. 工作区中没有对应的技术图表
+3. 即使有应用截图，也需要生成技术图表 slot
+
+AFS Image Slot Instructions 
+
+Use an AFS image slot only when you want the framework to generate a new image.
+
+Slot format (single line):
+<!-- afs:image id="architecture-overview" desc="..." -->
+
+Optional stable intent key (for reuse across edits or documents):
+<!-- afs:image id="architecture-overview" key="aigne-cli-architecture" desc="..." -->
+
+Rules:
+- Insert a slot only for new image generation.
+  If the source already provides an image (existing URL/path/asset), reference it directly; do not create a slot.
+- id is required and must be a semantic identifier describing the image’s role or position
+  (e.g. architecture-overview, core-flow, deployment-banner).
+  It must be unique in the same document and match: [a-z0-9._-]+.
+- desc is required, concise, double-quoted, and must not contain ".
+  It describes what the image should depict.
+- key is optional. Use a short, stable token ([a-z0-9._-]+) when you want the same image intent to be reused across sections or documents.
+
+### 图片使用检查清单
+
+生成每个文档时，确认以下项目：
+
+**技术图表检查：**
+- [ ] 架构说明章节是否包含架构图？（没有则生成 slot）
+- [ ] 流程说明章节是否包含流程图？（没有则生成 slot）
+- [ ] 时序说明章节是否包含时序图？（没有则生成 slot）
+- [ ] 概念解释章节是否包含概念图？（没有则生成 slot）
+
+**应用截图检查：**
+- [ ] 是否有可用的应用截图可以引用？
+- [ ] 引用路径是否按层级对照表正确计算？
+
+**数量检查：**
+- [ ] 技术文档是否至少包含 1 个技术图表？
+- [ ] 用户指南是否包含足够的应用截图？
+
+## 内容组织原则
+
+1. **层次清晰**：使用恰当的标题层级（H1-H6）
+2. **段落简洁**：每个段落专注于单一主题
+3. **代码示例**：提供实用的代码示例和说明
+4. **列表使用**：用列表组织并列信息
+5. **强调重点**：使用粗体、引用等方式突出重要信息

package/doc-smith/references/{document_structure_schema.md → document-structure-schema.md}

@@ -1,6 +1,6 @@
 # 文档结构 Schema
 
-本参考定义了 `document_structure.yaml` 的完整 schema。
+本参考定义了 `document-structure.yaml` 的完整 schema。
 
 ## 完整的 YAML 结构
 

package/doc-smith/references/{document_update_guide.md → document-update-guide.md}

@@ -43,18 +43,21 @@
 **处理方式：**
 1. 扫描所有文档查找 `:::PATCH` 标记
 2. 读取 PATCH 内的修改指令
-3. 执行精确替换
+3. 在指定位置完成 PATCH要求的修改，可能包含：替换原始内容、删除内容、新增内容
 4. 删除整个 PATCH 标记
 
 **PATCH 标记格式：**
 ```markdown
 ::: PATCH
-修改说明或新内容
+# Original
+DocSmith 直接修改用户文档并写回到原项目。
+
+# Revised
+DocSmith 永远不直接 touch 用户原始 repo，而是
+在独立 workspace 中生成版本化产物，再通过 patch 合并。
 :::
 ```
 
-**来源：** 仅通过文档内标记（不会出现在 Changeset 文件中）
-
 ## 三种输入方式处理
 
 ### 方式 1：自然语言修改请求
@@ -80,7 +83,7 @@
 
 **重要：**
 - 格式自由，自然语言描述
-- 参见 `references\changeset_schema.md` 了解识别规则
+- 参见 `references\changeset-schema.md` 了解识别规则
 
 ### 方式 3：文档内 PATCH 标记
 
@@ -133,10 +136,6 @@ ls -la .aigne/doc-smith/docs/
 **执行优先级：** 全局修改 → 结构重写 → PATCH
 
 **全局修改：**
-```bash
-# 获取所有文档
-find .aigne/doc-smith/docs/ -name "*.md"
-```
 对每个文档：
 - 读取内容
 - 应用规则（替换、删除、添加）

package/doc-smith/references/{structure_confirmation_guide.md → structure-confirmation-guide.md}

@@ -71,7 +71,7 @@
 
 ### 反馈类型
 
-1. **删除文档**：从 document_structure.yaml 删除条目，如果是父文档则连同子文档一起删除
+1. **删除文档**：从 document-structure.yaml 删除条目，如果是父文档则连同子文档一起删除
 2. **添加文档**：确定位置、title、description、path、sourcePaths 和 icon（如果是顶层文档）
 3. **调整层次**：合并/拆分子文档，或调整父子关系
 4. **修改内容范围**：更新 description 和 sourcePaths

package/doc-smith/references/{structure_planning_guide.md → structure-planning-guide.md}

@@ -6,7 +6,7 @@
 
 **规划必须依据用户意图**
 
-在规划文档结构时，持续参考 `user_intent.md` 中的内容：
+在规划文档结构时，持续参考 `user-intent.md` 中的内容：
 - **目标用户决定文档类型**：技术开发者需要 API 参考，最终用户需要使用指南
 - **使用场景决定文档范围**：快速上手只需核心功能，深入学习才需要完整架构
 - **侧重点决定详细程度**：使用指南型文档重实践轻原理，参考手册型文档要全面覆盖
@@ -15,11 +15,11 @@
 
 ### ❌ 不看用户意图，直接按代码结构规划
 
-导致文档大而全，不聚焦用户需求。应该先参考 user_intent.md，只为用户需要的模块创建文档。
+导致文档大而全，不聚焦用户需求。应该先参考 user-intent.md，只为用户需要的模块创建文档。
 
 ### ❌ 规划了用户不需要的文档
 
-浪费资源生成无用文档。应该严格按照 user_intent.md 中的"文档侧重点"规划。
+浪费资源生成无用文档。应该严格按照 user-intent.md 中的"文档侧重点"规划。
 
 ### ❌ 文档粒度与用户需求不匹配
 
@@ -32,7 +32,7 @@
 只规划用户意图中明确需要的文档。
 
 **检查清单**：
-- [ ] 这个文档是否在 user_intent.md 的使用场景中？
+- [ ] 这个文档是否在 user-intent.md 的使用场景中？
 - [ ] 这个文档是否符合文档侧重点？
 - [ ] 如果去掉这个文档，用户会缺失重要信息吗？
 
@@ -41,7 +41,7 @@
 优先覆盖用户的主要使用场景。
 
 **优先级排序**：
-1. user_intent.md 中明确提到的场景
+1. user-intent.md 中明确提到的场景
 2. 对目标用户最重要的功能
 3. 可选的高级特性
 
@@ -107,7 +107,7 @@ API 参考拆分为用户、订单、支付三个子文档，因为每个类别
 
 ## 结构评估清单
 
-在创建 document_structure.yaml 之前，对每个可能的嵌套结构使用此清单：
+在创建 document-structure.yaml 之前，对每个可能的嵌套结构使用此清单：
 
 ### 支持拆分的信号
 

package/doc-smith/references/{user_intent_guide.md → user-intent-guide.md}

@@ -18,7 +18,7 @@
 
 确定文档类型（使用指南型、参考手册型、快速上手型、架构说明型）。
 
-## user_intent.md 模板
+## user-intent.md 模板
 
 ```markdown
 # 用户意图
@@ -64,12 +64,12 @@
 
 ### 默认流程
 
-1. **自动生成**：基于工作区分析，自动推断用户意图并生成 user_intent.md
+1. **自动生成**：基于工作区分析，自动推断用户意图并生成 user-intent.md
 2. **展示意图**：向用户展示推断的完整意图
 3. **使用 AskUserQuestion 工具确认**：
    - 问题："用户意图是否符合您的需求？"
    - 选项："✅ 确认，开始规划文档结构"
-4. **接收反馈**：如果用户选择调整或通过 Other 提供具体需求，更新 user_intent.md
+4. **接收反馈**：如果用户选择调整或通过 Other 提供具体需求，更新 user-intent.md
 5. **重新展示**：展示更新后的完整意图
 6. **循环确认**：重复步骤 3-5，直到用户确认
 7. **进入下一步**：用户确认后，才开始规划文档结构
@@ -161,12 +161,12 @@ Agent: 收到确认，开始规划文档结构...
 
 ### 处理反馈
 
-根据用户反馈更新 user_intent.md 的对应部分（目标用户、使用场景、文档侧重点），必要时完全重写。每次修改后必须重新展示完整意图并询问确认。
+根据用户反馈更新 user-intent.md 的对应部分（目标用户、使用场景、文档侧重点），必要时完全重写。每次修改后必须重新展示完整意图并询问确认。
 
 ## 关键原则
 
 1. **基于证据推断**：从工作区内容（代码结构、README、配置文件）中寻找线索
-2. **保持简洁**：user_intent.md 应该简洁明了，避免冗长
+2. **保持简洁**：user-intent.md 应该简洁明了，避免冗长
 3. **可修改性**：用自然语言编写，用户易于理解和调整
 4. **多轮确认**：支持用户多轮调整，每次修改后重新展示完整意图并确认
 5. **用户确认后才继续**：绝对不要在用户确认前开始规划文档结构

package/doc-smith.yaml

@@ -1,100 +1,26 @@
-type: ai
+type: "@aigne/agent-library/agent-skill-manager"
 name: docsmith
-keep_text_in_tool_uses: true
 task_render_mode: collapse
-instructions:
-  - role: system
-    url: ./main-system-prompt.md
 
-input_key: message
-skills:
-  - type: function
-    name: askUserQuestion
-    description: |
-      Use this tool when you need to ask the user questions during execution. This allows you to:
-      1. Gather user preferences or requirements
-      2. Clarify ambiguous instructions
-      3. Get decisions on implementation choices as you work
-      4. Offer choices to the user about what direction to take.
-
-      Usage notes:
-      - The system automatically adds an "✏️ Other" option to all questions, allowing users to provide custom text input. DO NOT add your own "Other", "需要调整", or similar options - they will cause duplication.
-      - Only provide the specific action options (e.g., "✅ Confirm"). The "Other" option is handled by the system.
-      - Use multiSelect: true to allow multiple answers to be selected for a question
-      - If you recommend a specific option, make that the first option in the list and add "(Recommended)" at the end of the label
-    input_schema:
-      type: object
-      properties:
-        questions:
-          type: array
-          items:
-            type: object  
-            properties:
-              question:
-                type: string
-                description: The complete question to ask
-              header:
-                type: string
-                description: Short label(max 12 chars)
-              options:
-                type: array
-                items:
-                  type: string
-                description:
-                  Available choices (2 ~ 4 options)
-              # multiSelect:
-              #   type: boolean
-              #   description: Allow multiple selections
-            required:
-              - question
-              - header
-      required:
-        - questions
-    process: |
-      const {questions} = input
-
-      const answers = []
-      const OTHER_OPTION = '✏️ Other'
-
-      for (const item of questions) {
-        let answer
-
-        if (item?.options?.length) {
-          answer = await options.prompts.select({
-            message: item.question,
-            choices: [
-              ...item.options.map(option => ({
-                name: option,
-                description: option,
-                value: option
-              })),
-              {
-                name: OTHER_OPTION,
-                description: 'Enter your own response',
-                value: OTHER_OPTION
-              }
-            ]
-          })
+model:
+  cache_config:
+    autoBreakpoints:
+      lastMessage: true
 
-          if (answer === OTHER_OPTION) {
-            answer = await options.prompts.input({
-              message: 'Please enter your response:'
-            })
-          }
-        } else {
-          answer = await options.prompts.input({
-            message: item.question
-          })
-        }
-
-        answers.push({question: item.question, answer})
-      }
-
-      return {answers}
+history_config:
+  enabled: true
 
+input_key: message
+skills:
+  - type: "@aigne/agent-library/ask-user-question"
 
 afs:
   modules:
+    - module: history
+      options:
+        storage:
+          url: file:./.aigne/history.db
+
     - module: local-fs
       options:
         name: workspace

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aigne/doc-smith",
-  "version": "0.9.8-alpha.5",
+  "version": "0.9.8-alpha.7",
   "description": "AI-driven documentation generation tool built on the AIGNE Framework",
   "publishConfig": {
     "access": "public"

package/main-system-prompt.md

@@ -1,56 +0,0 @@
-You are an interactive CLI tool that helps users according to your "Output Style" below, which describes how you should respond to user queries. Use the instructions below and the tools available to you to assist the user.
-
-IMPORTANT: You must NEVER generate or guess URLs for the user unless you are confident that the URLs are for helping the user with programming. You may use URLs provided by the user in their messages or local files.
-
-# Looking up your own documentation:
-
-When the user directly asks about any of the following:
-- how to use Claude Code (eg. "can Claude Code do...", "does Claude Code have...")
-- what you're able to do as Claude Code in second person (eg. "are you able...", "can you do...")
-- about how they might do something with Claude Code (eg. "how do I...", "how can I...")
-- how to use a specific Claude Code feature (eg. implement a hook, write a slash command, or install an MCP server)
-- how to use the Claude Agent SDK, or asks you to write code that uses the Claude Agent SDK
-
-# Tone and style
-- Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.
-- Your output will be displayed on a command line interface. Your responses should be short and concise. You can use Github-flavored markdown for formatting, and will be rendered in a monospace font using the CommonMark specification.
-- Output text to communicate with the user; all text you output outside of tool use is displayed to the user. Only use tools to complete tasks. Never use tools like Bash or code comments as means to communicate with the user during the session.
-- NEVER create files unless they're absolutely necessary for achieving your goal. ALWAYS prefer editing an existing file to creating a new one. This includes markdown files.
-- Do not use a colon before tool calls. Your tool calls may not be shown directly in the output, so text like "Let me read the file:" followed by a read tool call should just be "Let me read the file." with a period.
-
-# AFS Context
-
-{{ $afs.description }}
-
-```yaml alt="AFS Modules"
-{{ $afs.modules | yaml.stringify }}
-```
-
-# Asking questions as you work
-
-You have access to the askUserQuestion tool to ask the user questions when you need clarification, want to validate assumptions, or need to make a decision you're unsure about. When presenting options or plans, never include time estimates - focus on what each option involves, not how long it takes.
-
-# Skill usage
-
-When the user requests you to perform tasks, check if any of the available skills can help complete the task more effectively. Skills provide specialized capabilities and domain knowledge.
-
-## Loading skill resources on demand
-
-Skills may include reference documents (guides, schemas, examples) in a `references/` directory. To optimize performance and context usage:
-
-1. **Start with the main skill file** (e.g., `SKILL.md`) - it contains the workflow overview and references to detailed guides
-2. **Load reference documents only when needed** - read specific guides only when you reach the step that requires them
-3. **Don't preload all resources** - avoid reading all reference files at the start of a task
-
-# Doing tasks
-The user will primarily request you perform software engineering tasks. This includes solving bugs, adding new functionality, refactoring code, explaining code, and more. For these tasks the following steps are recommended:
-- NEVER propose changes to code you haven't read. If a user asks about or wants you to modify a file, read it first. Understand existing code before suggesting modifications.
-- Use the askUserQuestion tool to ask questions, clarify and gather information as needed.
-- Be careful not to introduce security vulnerabilities such as command injection, XSS, SQL injection, and other OWASP top 10 vulnerabilities. If you notice that you wrote insecure code, immediately fix it.
-- Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused.
-  - Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability. Don't add docstrings, comments, or type annotations to code you didn't change. Only add comments where the logic isn't self-evident.
-  - Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.
-  - Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task—three similar lines of code is better than a premature abstraction.
-- Avoid backwards-compatibility hacks like renaming unused \`_vars\`, re-exporting types, adding \`// removed\` comments for removed code, etc. If something is unused, delete it completely.
-
-IMPORTANT: Complete tasks fully. Do not stop mid-task or leave work incomplete. Do not claim a task is too large, that you lack time, or that context limits prevent completion. You have unlimited context through summarization. Continue working until the task is done or the user stops you.