| name | story-wiki |
| description | 从设计文档生成精简的 Wiki 文档。TRIGGER: 当用户说'生成wiki'、'总结为wiki'、'写wiki文档'、'导出wiki'时使用。 |
Phase 0: 初始化环境
先调用 /story-init 完成工作环境初始化。
- 门禁:
/story-init 完成后方可继续,若已执行则跳过。
Phase 1 定位源文档
从 story 目录下总览/需求文档提取核心信息,生成面向团队阅读的 Wiki。
目标读者:项目组成员(策划、程序、QA)。语言简洁、无冗余、禁止哲学说明、实事求是。
- 读取
<slug_dir> 下总览文件;不存在 → 提示用户先用 /story-consolidate,结束流程。
必须得到用户确认才进入下一步。
Phase 2 确认输出结构
向用户确认 Wiki 章节。默认结构:
- 需求简介 — 一段话概述系统做什么、核心状态/模式
- 功能说明 — 每个子功能用文字 + mermaid 图辅助:
- 触发条件与判定逻辑
- 关键参数与可选模式
- 边界条件处理
- 性能考虑
- 网络同步方案
- 配置方法 — ConfigData 属性表、触发配置、CVar 表、调试绘制说明
用户可增删章节。必须确认后进入下一步。
Phase 3 生成文档
写作原则
- 每个功能先 1~3 句描述做什么/怎么触发/核心逻辑,再用图表辅助
- 前置条件用文字串联,不用列表堆砌
- 判定逻辑用 mermaid flowchart,时序用 sequenceDiagram,参数/配置用表格
- mermaid 节点文本要短:缩写或中文概括
- 禁止伪代码:所有逻辑用 mermaid 图或文字描述
- 禁止哲学说明
- 不含实现文件列表
- 实事求是:只写源文档中有的内容
格式规范
- 一级标题:系统名称
- 二级标题:章节编号 + 名称(如
## 1. 需求简介)
- 三/四级标题:子功能编号 + 名称
- 章节间用
--- 分隔
- 表格对齐,mermaid 标注语言
Phase 4 写入文档
- 输出 wiki 文档
- 已存在同名文件 → 询问覆盖还是新建
- 写完后提醒用户打开确认