@zeyue0329/xiaoma-cli 1.12.0 → 1.15.0

package/docs/roadshow/05-/346/212/200/346/234/257/345/256/236/347/216/260/344/270/216/345/210/233/346/226/260/344/272/256/347/202/271.md

@@ -1,205 +0,0 @@
-# 技术实现与创新亮点
-
-## 1. Step-File 微架构 — 防上下文丢失机制
-
-**问题**: LLM 在长对话中容易丢失上下文，导致执行偏离
-**解决方案**: Step-File 微架构
-
-```mermaid
-flowchart TD
-    subgraph "传统方式"
-        T1[长提示词] --> T2[上下文膨胀] --> T3[执行偏离]
-    end
-
-    subgraph "Step-File 架构"
-        S1["workflow.md 入口"] --> S2["仅加载 step-01"]
-        S2 -->|完成后卸载| S3["仅加载 step-02"]
-        S3 -->|完成后卸载| S4["仅加载 step-03"]
-        S4 --> S5["..."]
-    end
-```
-
-**核心设计**:
-- 每次仅一个步骤文件在内存中
-- 步骤间通过状态变量传递信息
-- 前端元数据（frontmatter）跟踪进度
-- 阶段边界摘要防止信息丢失
-- 强制从磁盘重新读取（Fresh Reads）而非依赖记忆
-
-## 2. 配置驱动的 IDE 安装架构
-
-**问题**: 支持 25+ IDE 平台，每个平台有不同的目录结构和配置格式
-**解决方案**: 统一配置驱动
-
-```mermaid
-flowchart LR
-    PC["platform-codes.yaml\n平台注册表"] --> CDI["ConfigDrivenIdeSetup\n统一安装器"]
-    CDI --> C1[".claude/skills/"]
-    CDI --> C2[".cursor/skills/"]
-    CDI --> C3[".cline/skills/"]
-    CDI --> C4[".windsurf/skills/"]
-    CDI --> CN["... 25+ 平台"]
-```
-
-**设计优势**:
-- 零自定义代码：新增 IDE 只需在 YAML 中添加配置
-- 统一行为：所有平台使用相同安装逻辑
-- 灵活适配：支持不同目录结构、模板类型、技能格式
-- 遗留兼容：自动迁移旧版安装路径
-
-每个平台配置包含:
-```yaml
-platform_name:
-  name: "平台名称"
-  preferred: true/false
-  category: cli/ide
-  installer:
-    target_dir: .platform/skills
-    template_type: default
-    skill_format: true
-    ancestor_conflict_check: true
-```
-
-## 3. 占位符替换系统
-
-**问题**: 安装到不同项目需要动态配置
-**解决方案**: 安装时占位符替换
-
-支持的占位符:
-| 占位符 | 替换值 |
-|--------|--------|
-| `{_xiaoma}` | 实际 xiaoma 文件夹名 |
-| `{project-root}` | 项目根目录 |
-| `{module}` | 模块标识符 |
-| `{version}` | XiaoMa 版本号 |
-| `{date}` | 安装日期 |
-
-**嵌套变量引用**: 变量可以引用其他模块变量
-```
-output_folder: "_xiaoma-output"
-planning_artifacts: "{output_folder}/planning-artifacts"  # 解析为 _xiaoma-output/planning-artifacts
-```
-
-应用范围: Markdown、YAML、JSON、JS、TS、Shell 文件（二进制文件跳过）
-
-## 4. Manifest 驱动发现机制
-
-**问题**: IDE 需要知道安装了哪些智能体、工作流、技能
-**解决方案**: CSV 清单注册表
-
-生成的清单文件:
-| 清单 | 内容 | 用途 |
-|------|------|------|
-| agent-manifest.csv | 所有智能体元数据 | IDE 智能体发现 |
-| workflow-manifest.csv | 所有工作流元数据 | 工作流触发 |
-| task-manifest.csv | 所有任务元数据 | 任务执行 |
-| files-manifest.csv | 所有已安装文件 | 完整性校验 |
-
-**优势**: 无需运行时文件系统扫描，单一事实来源
-
-## 5. Zod Schema 验证体系
-
-**问题**: 智能体 YAML 定义需要严格的格式和语义校验
-**解决方案**: Zod 运行时类型验证
-
-验证规则:
-- 触发器格式: kebab-case 或复合格式 `XX or fuzzy match on trigger-name`
-- 描述前缀匹配: `[XX]` 必须与触发器快捷键一致
-- 触发器唯一性: 同一智能体内不允许重复
-- 模块作用域: 从文件路径推导并强制执行
-
-测试覆盖:
-- 50 个测试用例（18 个有效 + 32 个无效）
-- 目标 100% 分支覆盖率
-
-## 6. 质量门禁体系
-
-```mermaid
-flowchart LR
-    CODE[代码变更] --> LF["lint-staged\nHusky 钩子"]
-    LF --> L1["ESLint\nJS + YAML"]
-    LF --> L2["Prettier\n格式化"]
-
-    subgraph "npm run quality"
-        T1["test:schemas\nSchema验证测试"]
-        T2["test:refs\n交叉引用验证"]
-        T3["test:install\n安装组件测试"]
-        T4["validate:schemas\nSchema验证"]
-        T5["lint\nESLint零警告"]
-        T6["lint:md\nMarkdown检查"]
-        T7["format:check\nPrettier检查"]
-    end
-
-    L1 --> T1
-    L2 --> T1
-    T1 --> T2 --> T3 --> T4 --> T5 --> T6 --> T7
-    T7 --> PASS["质量通过"]
-```
-
-**零容忍策略**: `--max-warnings=0`，任何警告都会阻断
-
-## 7. 多智能体编排与状态管理
-
-### 批处理与重试循环
-
-```mermaid
-flowchart TD
-    INIT[流水线初始化] --> DISC[发现下一个故事]
-    DISC --> DEV[开发实现]
-    DEV --> REVIEW[代码评审]
-    REVIEW --> QA[QA测试]
-    QA -->|通过| CHECK{更多故事?}
-    QA -->|失败| FIX[Bug修复]
-    FIX -->|"迭代 <= 5"| QA
-    FIX -->|"迭代 > 5"| HALT["停止"]
-    CHECK -->|是| DISC
-    CHECK -->|否| DONE["全部完成"]
-```
-
-**状态持久化机制**:
-- `pipeline_status`: 流水线整体状态
-- `current_story_key`: 当前故事标识
-- `fix_iteration`: Bug 修复迭代计数
-- `stories_completed`: 完成故事计数
-- 批处理模式下循环重置 `current_story_path`
-
-### 角色切换协议
-流水线中智能体角色动态切换：
-- 每个步骤加载对应智能体的 persona
-- 角色切换时生成阶段摘要
-- 后续步骤从磁盘重新读取（而非依赖前序角色的记忆）
-
-## 8. Party 模式 — 多智能体群组讨论
-
-**创新点**: 在回顾等场景中，多个智能体以对话形式参与讨论
-
-格式示例:
-```
-xiaofen (业务分析师): 从需求角度看，这个Sprint...
-xiaojia (架构师): 架构决策方面...
-xiaokai (开发工程师): 实现过程中...
-```
-
-**设计原则**:
-- 心理安全：无指责文化
-- 聚焦系统和流程，而非个人
-- 结构化输出：史诗回顾 + 下一史诗准备
-
-## 9. 智能故事上下文引擎
-
-创建故事时，系统进行穷尽式信息收集:
-
-```mermaid
-flowchart TD
-    EPIC["epics.md"] --> SC[故事上下文引擎]
-    PRD["prd.md"] --> SC
-    ARCH["architecture.md"] --> SC
-    UX["ux-design.md"] --> SC
-    PREV["前序故事\n实现经验"] --> SC
-    GIT["Git 历史\n最近提交"] --> SC
-    WEB["Web 研究\n最新技术版本"] --> SC
-
-    SC --> STORY["story-file.md\n开发者不会犯错的\n完备上下文"]
-```
-
-**目标**: 提供足够完备的上下文，使开发智能体无需回溯任何历史即可正确实现

package/docs/roadshow/06-/350/267/257/346/274/224/346/200/273/347/273/223/344/270/216/346/274/224/347/244/272/345/273/272/350/256/256.md

@@ -1,167 +0,0 @@
-# 路演总结与演示建议
-
-## 1. 产品价值总结（面向管理层）
-
-### 核心价值主张
-
-XiaoMa-CLI 实现了 **AI 驱动的全流程敏捷开发**，将传统需要多人协作数周完成的软件开发流程，通过 9 个 AI 智能体的协同自动化，显著提升交付效率。
-
-### 业务价值
-
-- **效率提升**: 从需求到交付的全流程自动化，减少人工干预
-- **质量保障**: 多层质量门禁（PRD 验证、实施就绪检查、代码评审、QA 测试）
-- **标准化**: 统一的开发流程和文档标准
-- **可扩展**: 支持 25+ AI IDE 平台，适应不同团队工具偏好
-- **低门槛**: 一键安装，无需复杂配置
-
-### 适用场景
-
-- 新项目从零到一的快速启动
-- 棕地项目（已有代码库）的 AI 增强开发
-- 团队敏捷流程的标准化和自动化
-- AI 辅助代码评审和质量保障
-
-## 2. 技术创新总结（面向技术负责人）
-
-### 架构创新
-
-| 创新点               | 解决的问题           | 技术方案                          |
-| -------------------- | -------------------- | --------------------------------- |
-| Step-File 微架构     | LLM 长对话上下文丢失 | 步骤文件隔离 + 状态持久化         |
-| 配置驱动 IDE 安装    | 多平台适配复杂度     | 统一 YAML 配置 + 零代码扩展      |
-| 多智能体编排         | 复杂流程协调         | 流水线状态机 + 角色切换           |
-| 穷尽式上下文引擎     | 开发偏离需求         | 多源信息聚合到 Story 文件         |
-| Manifest 驱动发现    | IDE 集成发现机制     | CSV 清单 + 运行时零扫描           |
-| Zod Schema 验证      | 智能体定义一致性     | 运行时类型校验 + 100%覆盖         |
-
-### 技术指标
-
-- **零警告策略**: ESLint --max-warnings=0
-- **50 个 Schema 测试用例**: 18 有效 + 32 无效
-- **占位符系统**: 支持嵌套变量引用
-- **批处理重试**: Bug 修复最多 5 次迭代
-- **Fresh Reads 机制**: 始终从磁盘读取最新状态
-
-## 3. 核心数据指标
-
-```mermaid
-mindmap
-  root((XiaoMa-CLI))
-    智能体系统
-      9 个专业智能体
-      完整敏捷团队模拟
-      动态角色切换
-    工作流引擎
-      26 个结构化工作流
-      5 个开发阶段
-      3 条自动化流水线
-    技能库
-      12 个核心技能
-      50+ 工作流技能
-    平台支持
-      25+ AI IDE 平台
-      配置驱动零代码
-    质量体系
-      7 层质量门禁
-      50 个验证用例
-```
-
-## 4. 建议演示路径
-
-### 路径一：快速概览（15 分钟）
-
-适用于高管汇报、跨部门沟通等需要快速传递核心信息的场景。
-
-1. **开场**（2 分钟）: 项目定位和价值主张
-2. **架构总览**（3 分钟）: 两层架构 + 模块系统
-3. **智能体展示**（5 分钟）: 9 个智能体角色介绍 + 协作关系图
-4. **流水线演示**（3 分钟）: 自动全流程流水线的三阶段编排
-5. **总结**（2 分钟）: 核心数据指标 + 未来方向
-
-### 路径二：深度汇报（30 分钟）
-
-适用于技术委员会评审、项目立项答辩等需要深入了解技术方案的场景。
-
-1. **开场与背景**（3 分钟）: 问题域 + 产品定位
-2. **架构设计**（5 分钟）: 两层架构 + 模块系统 + CLI 安装流程
-3. **智能体系统**（7 分钟）: 9 个智能体详解 + Schema 验证 + Sidecar 记忆
-4. **工作流引擎**（7 分钟）: 5 阶段 26 工作流 + Step-File 微架构
-5. **自动化流水线**（5 分钟）: AR + ASP + AFP 三条流水线
-6. **技术创新**（3 分钟）: 核心创新亮点
-
-### 路径三：技术深潜（45 分钟）
-
-适用于技术团队内部分享、开发者大会等需要深入技术细节和现场演示的场景。
-
-在路径二基础上增加：
-
-- 现场安装演示（`npx @zeyue0329/xiaoma-cli install`）
-- 单故事开发全流程 Live Demo
-- 代码评审流程演示
-- 多 IDE 平台适配展示
-
-## 5. 演示建议
-
-### 关键演示要点
-
-1. **智能体人格化**: 展示每个智能体的角色定位和沟通风格差异，让观众感受到"团队协作"的真实感
-2. **流水线编排**: 重点展示 AFP（全流程流水线）如何自动编排多个智能体完成从需求到交付的全过程
-3. **质量门禁链**: 展示从 PRD 验证到代码评审的完整质量保障链，强调"AI 不仅写代码，更保障代码质量"
-4. **一键安装**: 演示 `npx xiaoma-cli install` 的交互式安装流程，突出"即插即用"的低门槛优势
-5. **多 IDE 支持**: 展示同一套智能体在 Claude Code 和 Cursor 中的无缝使用
-
-### 视觉建议
-
-- 使用本系列文档中的 Mermaid 图表作为 PPT 信息图基础
-- 智能体关系图适合作为核心展示页，能直观传递"AI 敏捷团队"的概念
-- 三大流水线流程图适合分页展示，每页聚焦一条流水线的价值
-- 状态机图适合解释 Story 生命周期，帮助观众理解开发全流程
-
-### 演示环境准备
-
-- 提前在演示机上安装好 Node.js v20+ 和目标 AI IDE
-- 准备一个干净的示例项目用于现场安装演示
-- 确保网络环境稳定（需要 npm 包下载）
-- 准备离线备份方案（提前录制演示视频）
-
-## 6. Q&A 预备问题
-
-### 管理层可能的提问
-
-| 问题                         | 建议回答方向                                                       |
-| ---------------------------- | ------------------------------------------------------------------ |
-| 与现有开发流程如何兼容？     | 支持棕地项目，渐进式采用，不强制替换现有流程                       |
-| 成本和 ROI？                 | 一键安装零额外成本，通过自动化减少重复工作，提升开发者产能         |
-| 数据安全？                   | 所有处理在本地完成，不上传代码到第三方服务，数据不出开发环境       |
-| 团队学习曲线？               | 交互式安装 + 帮助技能 + 技能等级适配（初级/中级/专家）            |
-| 支持的编程语言？             | 语言无关，支持任何编程语言的项目                                   |
-| 如何衡量引入后的效果？       | 可从需求到交付周期、代码评审通过率、文档完整度等维度进行对比       |
-
-### 技术负责人可能的提问
-
-| 问题                           | 建议回答方向                                                         |
-| ------------------------------ | -------------------------------------------------------------------- |
-| 如何保证 LLM 输出质量？       | Step-File 防偏离 + 多层验证 + 穷尽式上下文 + 重试机制               |
-| 如何扩展新的智能体？           | YAML 定义 + Zod Schema 验证 + 标准化菜单系统                        |
-| 如何集成到 CI/CD？             | 提供 CLI 命令行接口，可集成到任何自动化流程                          |
-| 与其他 AI 开发工具的区别？     | 全流程覆盖（不仅仅是代码生成），多智能体协作，结构化工作流          |
-| 自定义工作流？                 | 支持自定义模块（--custom-content），可扩展智能体和工作流             |
-| 对 LLM 提供商有锁定吗？       | 框架本身与 LLM 无关，通过 AI IDE 间接调用，支持任何 IDE 背后的模型  |
-
-## 7. 路演核心信息
-
-> **一句话定位**: XiaoMa-CLI 是业界首个实现从需求到交付全流程 AI 智能体协同的敏捷开发框架
->
-> **三个关键词**: 多智能体协同 · 全流程自动化 · 即插即用
->
-> **核心差异化**: 不是简单的代码生成工具，而是模拟完整敏捷团队的 AI 开发框架
-
-### 核心信息传递优先级
-
-1. **第一优先级 — 价值定位**: XiaoMa-CLI 用 AI 智能体模拟完整敏捷团队，覆盖从需求分析到代码交付的全生命周期
-2. **第二优先级 — 技术创新**: Step-File 微架构、穷尽式上下文引擎、配置驱动多平台适配等核心技术突破
-3. **第三优先级 — 落地能力**: 一键安装、25+ IDE 支持、语言无关、零额外成本
-
-### 结束语建议
-
-> XiaoMa-CLI 代表了 AI 辅助软件开发的下一个方向：不是让 AI 替代开发者，而是让每个开发者都拥有一支完整的 AI 敏捷团队。通过结构化的工作流编排和多智能体协同，我们将"AI 写代码"升级为"AI 做工程"。

package/patent-disclosure-optimized/SKILL.md

@@ -1,298 +0,0 @@
----
-name: patent-disclosure
-description: "软件专利交底书撰写技能。从完整的软件项目（代码仓库、设计文档、需求文档等）中挖掘专利创新点，并生成符合专利代理人要求的技术交底书 Word 文档（.docx）。核心输出三要素：解决的技术问题、采用的技术手段、达到的技术效果。输出文档模拟人类开发工程师写法，去除 AI 味道。当用户提到以下任何内容时务必触发此技能：专利交底书、技术交底、专利挖掘、专利申请材料、发明创造点、从代码中提取专利、软件专利撰写、知识产权交底、创新点挖掘、写交底书、patent disclosure。即使用户只是随口问'这个项目有没有能申请专利的点'、'帮我看看能不能写个专利'、'这个功能能申请专利吗'，也应当触发本技能。也包括用户要求分析项目代码或文档来寻找可申请专利的技术方案，或者讨论某个技术实现是否有专利价值、如何将代码逻辑转化为专利方案等场景。"
-compatibility: "Requires docx skill for Word document generation. Requires bash and Node.js runtime."
----
-
-# 软件专利交底书撰写技能
-
-## 概述
-
-本技能指导 Claude 从软件项目全量材料（源代码、设计文档、需求规格、架构图等）中系统性地挖掘专利创新点，并输出规范的技术交底书 Word 文档。
-
-**执行前必读**：在开始任何工作前，先读取以下两份参考文档——它们是本技能的权威参考，遇到细节冲突时以参考文档为准：
-
-- `references/mining-principles.md` — 专利挖掘判定原则（三要素判定法、否定/肯定情形、常见规避问题）
-- `references/disclosure-template.md` — 交底书模板（章节结构、各部分撰写要求、注意事项）
-
----
-
-## 第一阶段：项目理解与材料收集
-
-拿到项目后，先建立全局认知，不要急于寻找专利点。
-
-### 1.1 扫描项目结构
-
-根据项目语言选择合适的扫描方式。优先使用 `Glob` 工具按文件类型模式匹配（如 `**/*.java`、`**/*.py`、`**/*.ts`），再用 `Read` 工具阅读关键文件。同时检查构建配置文件（pom.xml、build.gradle、package.json、pyproject.toml 等）了解技术栈。
-
-### 1.2 阅读文档材料
-
-按优先级阅读：
-1. README 和项目说明
-2. 架构设计文档、概要设计
-3. 需求规格说明书
-4. 数据库设计文档（DDL、ER图描述）
-5. 接口文档、API 说明
-
-### 1.3 分析核心代码
-
-重点关注：
-- 核心业务逻辑层（Service / Domain）
-- 自定义算法和策略模式实现
-- 中间件集成和自研组件
-- 分布式协调、缓存策略、消息处理
-- 数据库查询中的复杂逻辑（存储过程、复杂SQL）
-- 异常处理和容错机制
-
-### 1.4 现有技术调研（可选但推荐）
-
-如果环境中有搜索工具（如 Tavily MCP 或 WebSearch），可用于辅助调研：
-- 搜索同领域已有专利的技术方案，帮助定位创新点的差异化
-- 了解行业通用做法，为"技术背景"章节提供素材
-- 确认候选创新点是否已有类似公开专利
-
-### 1.5 形成项目认知备忘
-
-整理出：项目所属技术领域、整体架构模式、技术栈清单、核心业务流程、与外部系统的集成关系。
-
----
-
-## 第二阶段：专利点挖掘
-
-这是整个流程中最关键的判定环节。**必须先阅读 `references/mining-principles.md`**，其中包含完整的三要素判定法、否定情形、肯定情形示例、常见表述陷阱等核心判定标准。
-
-### 2.1 判定流程
-
-对每个候选创新点，按三要素公式自检（详见参考文档）：
-
-**因为（技术问题）** → **所以（技术手段）** → **结果（技术效果）**
-
-三步都能填满且逻辑自洽 = 合格专利点。某一步含糊或填不出来 = 不够成熟。
-
-### 2.2 关键排除项（速查）
-
-以下情况不构成合格专利方案（详细说明和示例见 `references/mining-principles.md`）：
-- 泛化业务需求、非技术问题、模糊描述
-- 非技术手段、简单组合现有技术、纯智力/管理规则
-- 仅有商业收益、运营效果、主观体验
-- 纯代码/纯公式/纯算法原理（建议走软著）
-- 直接使用开源框架的标准功能
-- 纯 CRUD 操作
-- 通用设计模式的常规应用
-
-### 2.3 高价值方向识别
-
-在软件项目中，以下方向容易产出合格专利点：
-
-- **架构层**：新型服务拆分/聚合策略、自研服务治理机制、多数据源协同一致性方案、特定场景的缓存架构
-- **算法层**：业务规则引擎实现方式、自定义数据匹配/校验算法、复杂查询优化策略、状态机流转控制逻辑
-- **流程层**：多步骤审批编排机制、异步任务调度和补偿策略、跨系统数据同步方案、批量处理分片并行策略
-- **可靠性层**：数据加密/脱敏机制、分布式锁应用和实现、幂等性保障方案、灾备和故障恢复策略
-
-### 2.4 输出候选专利点清单
-
-完成分析后，向用户呈现候选列表，每个点包含：
-- 创新点名称（一句话概括）
-- 所属模块/代码位置
-- 三要素初步描述（问题→手段→效果，各1-2句话）
-- 建议优先级（高/中/低）
-
-**在此暂停，等待用户确认要撰写哪些点后再进入下一阶段。**
-
-同时收集交底书所需的基本信息（如果用户尚未提供）：
-- 发明人姓名（可以有多位）
-- 技术问题联系人及联系方式（电话、邮箱）
-- 是否有特定的保密要求
-
----
-
-## 第三阶段：交底书撰写
-
-### 3.1 文档结构
-
-交底书结构来自 `references/disclosure-template.md`，按以下章节顺序输出：
-
-```
-交底书名称：一种基于XXX的YYY方法/系统
-发明人：（由用户提供）
-技术问题联系人：（由用户提供）
-
-该发明所属技术领域：
-术语解释：
-
-1、详细介绍技术背景，并描述已有的与本发明最相近似的实现方案
-2、现有技术的缺点是什么？针对这些缺点，说明本发明的目的
-3、本发明技术方案的详细阐述（结合附图说明）
-   3.1 基本原理
-   3.2 详细的技术方案
-4、与第1部分所述的现有技术相比，本发明有何优点
-5、本发明的关键点和欲保护点是什么？
-6、针对第3部分的技术方案，是否还有别的替代方案同样能完成发明目的？
-```
-
-### 3.2 各章节撰写要点
-
-#### 交底书名称
-格式："一种基于XXX的YYY方法/系统/装置"。体现核心技术手段和应用领域，不出现商标/产品名/公司名，控制在25字以内。
-
-#### 技术领域
-一句话说明。示例："本发明涉及计算机软件技术领域，具体涉及一种分布式系统中的数据一致性保障方法。"
-
-#### 术语解释
-列出代理人可能不理解的专业术语。英文缩写必须有中文译文。全文对同一事物叫法统一。
-
-#### 第1部分：技术背景与最相近方案
-- 描述行业中处理同类问题的通用做法（不点名竞品）
-- 客观分析现有做法的技术局限，要有技术细节支撑
-- 可以引用技术原理解释为什么现有方案存在瓶颈
-
-#### 第2部分：现有技术缺点与发明目的
-- 缺点要与本发明的优点对应——本发明不能解决的缺点不必写
-- 找不出对比方案缺点时用反推法：根据本发明优点找对应缺点
-- 缺点描述要具体：成本高、效率低、误码率高、反应速度慢等
-
-#### 第3部分：技术方案详细阐述（核心章节）
-
-这是交底书最重要的部分，代理人写权利要求书主要依赖此章节。
-
-**3.1 基本原理**：从原理层面概括说明如何解决上述技术问题。
-
-**3.2 详细技术方案**，必须做到：
-- 说明系统包括哪些模块，各模块如何连接和协作
-- 各模块分别起什么作用、完成什么功能
-- 哪个部件、哪种连接是创新点，具体描述结构细节
-- 方法类专利需说明流程步骤，从数据流角度详细描述
-- 涉及数据结构的要说明字段含义
-- 涉及算法的要描述完整逻辑流程
-- 异常场景的处理也要覆盖
-
-**容易踩的坑**（专利法第26条"充分公开"要求）：
-- 只写原理不写实现步骤——审查员无法判断方案是否可行
-- 只描述功能不说明技术手段——"功能限定"是最常见的驳回理由
-- 标准是：本领域技术人员读完后不需要额外创造性劳动就能实现
-
-#### 第4-6部分
-- **第4部分**：结合技术方案，用因果关系推理说明优点，对应第2部分发明目的
-- **第5部分**：提炼关键创新点列表（1、2、3...），对应第4部分有益效果的关键技术点
-- **第6部分**：写明替代方案（部分结构/方法步骤的替代或完整替代方案），有助于扩大保护范围
-
-#### 附图说明
-列出建议配图内容（实际绘图由用户完成）：方法专利必须提供流程图，并提供相关的系统装置图。所有附图都应有详细文字描述，附图中的标注尽量用中文。
-
----
-
-## 第四阶段：去 AI 味道——工程师写作风格
-
-专利代理人每天审阅大量交底书，AI 生成的文档有明显的"机器感"。以下风格指南帮助输出更接近真实工程师的写作习惯。
-
-### 4.1 用词替换表
-
-| 避免（AI 味道重） | 改用（工程师习惯） |
-|---|---|
-| 本发明创造性地提出了 | 本方案采用了 |
-| 显著地提升了性能 | 实测吞吐量提升约40% |
-| 巧妙地解决了 | 通过XX方式解决了 |
-| 革命性的/突破性的 | （删除，直接说效果数字） |
-| 不可忽视的优势 | 主要改进在于 |
-| 值得注意的是 | （删除，直接说） |
-| 在一个实施例中 | 以XX场景为例 |
-| 综上所述 | （一般不需要，直接写结论） |
-| 确保了系统的鲁棒性 | 当XX异常时，系统通过YY机制恢复 |
-| 本发明旨在 | 本方案的目标是 |
-| 进一步地 | 在此基础上 |
-| 需要说明的是 | （直接说，不加前缀） |
-| 可以理解的是 | （删除） |
-| 作为一种可选的实施方式 | 另一种做法是 |
-
-### 4.2 工程师句式特征
-
-- 喜欢用具体数字："响应时间从3s降到200ms"而不是"大幅提升"
-- 会提到具体技术组件："使用 Redis 的 SETNX 命令实现分布式锁"
-- 描述逻辑偏好时序结构："先...然后...最后..."
-- 解释设计决策："之所以选择XX，是因为..."、"这里用XX而不是YY，主要考虑是..."
-- 坦诚取舍："这种方式会增加约15%的内存开销，但换来了..."
-- 常用短句，段落不超过3-6句话
-- 夹杂技术术语英文原词（failover、sharding、backpressure）
-- 用括号补充说明："消息队列（本方案使用 RocketMQ）"
-
-### 4.3 内容真实感
-
-- 性能数据要合理（不写不可能的数字）
-- 技术选型符合实际生态（Java 项目不会用 Go 的库）
-- 可以轻描淡写提一句方案局限性，显示作者客观性
-- 适当使用"实际运行中"、"生产环境下"等词汇增强真实感
-
-### 4.4 自检清单
-
-撰写完成后，逐段检查：
-- [ ] 有没有"显著"、"创造性"、"巧妙"等 AI 常用评价词？删掉
-- [ ] 有没有空泛的效果描述？替换为具体数据或技术指标
-- [ ] 技术方案部分是否有纯原理或纯功能表述？补充实现细节
-- [ ] 每个技术效果是否都能追溯到具体的技术手段？建立因果链
-- [ ] 术语是否统一？同一事物是否存在多种叫法？
-- [ ] 英文缩写是否都有中文解释？
-
-### 4.5 完整段落 Before/After 示例
-
-**Before（AI 味道浓）**：
-
-> 本发明创造性地提出了一种高效的票据签收处理方法。该方法显著提升了系统的处理能力，巧妙地解决了传统方案中存在的性能瓶颈问题。通过采用先进的批量处理技术，本发明确保了系统在高并发场景下的鲁棒性，实现了革命性的性能突破。
-
-**After（工程师风格）**：
-
-> 本方案针对票据签收环节的并发处理问题，采用了请求合并+批量校验的方式。具体做法是：将200ms时间窗口内到达的签收请求合并为一个批次，对同一承兑人的票据共享额度查询结果，避免重复调用外部征信接口。实测在300笔/秒的并发压力下，单笔平均处理耗时从4.2s降到了380ms，数据库查询次数减少约65%。这种方式会引入最多200ms的额外等待，但在票据业务场景下（用户对秒级延迟不敏感）是可接受的。
-
----
-
-## 第五阶段：生成 Word 文档
-
-交底书输出为 .docx 格式。**必须先阅读 docx skill 获取 docx-js 最新的使用指南和注意事项**（路径通常在同级 skills 目录下的 `docx/SKILL.md`）。docx skill 中包含了完整的文档创建、验证流程和关键规则，务必遵循。
-
-### 5.1 文档格式要求
-
-- 纸张：A4（docx-js 默认值，无需额外设置）
-- 正文字体：宋体/SimSun 小四（12pt）
-- 英文/数字字体：Times New Roman 12pt
-- 一级标题：黑体/SimHei 三号（16pt）加粗
-- 二级标题：黑体 四号（14pt）加粗
-- 三级标题：宋体 小四（12pt）加粗
-- 行距：1.5 倍行距（line spacing: 360 = 1.5x of 240 twips for 12pt）
-- 页边距：上下 2.54cm（约1440 DXA），左右 3.17cm（约1800 DXA）
-- 页码：底部居中
-
-### 5.2 生成流程
-
-1. 阅读 docx skill（`docx/SKILL.md`），遵循其中的创建文档流程和关键规则
-2. `npm install -g docx`（如果尚未安装）
-3. 用 JavaScript 通过 docx-js 库按上述格式生成文档
-4. 使用 docx skill 中的 `scripts/office/validate.py` 脚本校验生成的文件
-5. 将最终文件保存到用户的工作目录
-
-### 5.3 文档命名
-
-`专利交底书_<发明名称简写>_<日期YYYYMMDD>.docx`
-
----
-
-## 工作流程总结
-
-```
-用户提交项目材料（代码仓库 + 文档）
-      |
-[阶段1] 扫描结构 → 读文档 → 分析核心代码 → （可选）现有技术调研 → 形成项目认知
-      → 输出：项目技术概况备忘
-      |
-[阶段2] 阅读 mining-principles.md → 三要素判定法筛选 → 排除否定情形 → 输出候选清单
-      → 输出：候选专利点列表（含优先级）
-      |
-      ⏸️  暂停：等用户确认写哪些点 + 收集发明人信息
-      |
-[阶段3] 阅读 disclosure-template.md → 按模板6章节结构逐章撰写
-      → 输出：交底书文本初稿
-      |
-[阶段4] 逐段去 AI 味道检查 → 自检清单过一遍
-      → 输出：工程师风格的终稿
-      |
-[阶段5] 阅读 docx skill → 生成 .docx → 校验 → 交付
-      → 输出：专利交底书_XXX_日期.docx
-```

package/src/core/module-help.csv

@@ -1,11 +0,0 @@
-module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs
-core,anytime,Brainstorming,BSP,,skill:xiaoma-brainstorming,xiaoma-brainstorming,false,analyst,,"Generate diverse ideas through interactive techniques. Use early in ideation phase or when stuck generating ideas.",{output_folder}/brainstorming/brainstorming-session-{{date}}.md,,
-core,anytime,Party Mode,PM,,skill:xiaoma-party-mode,xiaoma-party-mode,false,party-mode facilitator,,"Orchestrate multi-agent discussions. Use when you need multiple agent perspectives or want agents to collaborate.",,
-core,anytime,xiaoma-help,BH,,skill:xiaoma-help,xiaoma-help,false,,,"Get unstuck by showing what workflow steps come next or answering XiaoMa Method questions.",,
-core,anytime,Index Docs,ID,,skill:xiaoma-index-docs,xiaoma-index-docs,false,,,"Create lightweight index for quick LLM scanning. Use when LLM needs to understand available docs without loading everything.",,
-core,anytime,Shard Document,SD,,skill:xiaoma-shard-doc,xiaoma-shard-doc,false,,,"Split large documents into smaller files by sections. Use when doc becomes too large (>500 lines) to manage effectively.",,
-core,anytime,Editorial Review - Prose,EP,,skill:xiaoma-editorial-review-prose,xiaoma-editorial-review-prose,false,,,"Review prose for clarity, tone, and communication issues. Use after drafting to polish written content.",report located with target document,"three-column markdown table with suggested fixes",
-core,anytime,Editorial Review - Structure,ES,,skill:xiaoma-editorial-review-structure,xiaoma-editorial-review-structure,false,,,"Propose cuts, reorganization, and simplification while preserving comprehension. Use when doc produced from multiple subprocesses or needs structural improvement.",report located with target document,
-core,anytime,Adversarial Review (General),AR,,skill:xiaoma-review-adversarial-general,xiaoma-review-adversarial-general,false,,,"Review content critically to find issues and weaknesses. Use for quality assurance or before finalizing deliverables. Code Review in other modules run this automatically, but its useful also for document reviews",,
-core,anytime,Edge Case Hunter Review,ECH,,skill:xiaoma-review-edge-case-hunter,xiaoma-review-edge-case-hunter,false,,,"Walk every branching path and boundary condition in code, report only unhandled edge cases. Use alongside adversarial review for orthogonal coverage - method-driven not attitude-driven.",,
-core,anytime,Distillator,DG,,skill:xiaoma-distillator,xiaoma-distillator,false,,,"Lossless LLM-optimized compression of source documents. Use when you need token-efficient distillates that preserve all information for downstream LLM consumption.",adjacent to source document or specified output_path,distillate markdown file(s)