@zeyue0329/xiaoma-cli 1.13.0 → 1.15.1

package/patent-disclosure-optimized/SKILL.md

@@ -1,416 +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 中包含了完整的文档创建、验证流程和关键规则，务必遵循。
-
-> **格式权威参考**：本节给出的字体、字号、行距、颜色、首行缩进、对齐方式全部来自客户提供的《技术交底书模板.doc》。若客户另外给出模板文件，应以客户模板为准，并按相同方法（unpack → 读 styles.xml + document.xml）提取规范后覆盖此处默认值。
->
-> 详细格式速查表见 `references/docx-format-spec.md`。
-> 已封装的转换实现见 `scripts/md2docx.js`（推荐直接调用，无需重复编写）。
-
-### 5.1 页面与基本参数
-
-| 项目 | 取值 | 备注 |
-| --- | --- | --- |
-| 纸张 | A4 | 宽 11906 × 高 16838 DXA |
-| 上下页边距 | 2.54cm（1440 DXA） | |
-| 左右页边距 | 3.17cm（1800 DXA） | 即模板默认值 |
-| 页码 | 底部居中，9pt | 用 `PageNumber.CURRENT` |
-| 默认颜色 | 黑色 `#000000` | 蓝色 `#0000FF` 仅用于占位提示语，正式内容一律用黑色 |
-
-### 5.2 四类段落样式（**严格执行**）
-
-字号单位说明：docx-js 的 `size` 字段使用半磅，10.5pt = 21，18pt = 36，9pt = 18。
-
-| 段落类型 | 触发条件 | 东亚字体 | 西文字体 | 字号 | 字形 | 对齐 | 行距 | 首行缩进 |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| 大标题 | 仅文档首行的「技术交底书」 | 楷体_GB2312 | Times New Roman | 18pt（sz=36） | 加粗 | 居中 | 固定 21pt（line=420 exact） | 无 |
-| 头部字段 | `**交底书名称：**…` `**本专利发明人：**…` `**技术问题联系人：**…` `**联系人电话：**…` `**E-MAIL：**…` 五行 | 仿宋_GB2312 | Times New Roman | 10.5pt（sz=21） | 加粗 | 左对齐 | 1.5x（line=360 auto） | 无 |
-| 章节标题 | Markdown `#` / `##` / `###` / `####` | 楷体_GB2312 | Times New Roman | 10.5pt（sz=21） | 加粗 | 左对齐 | 固定 21pt（line=420 exact） | 无 |
-| 正文 | 其余段落、列表、表格内文字 | 宋体 | Times New Roman | 10.5pt（sz=21） | 常规 | 两端对齐（both） | 1.5x（line=360 auto） | 2 个汉字（firstLine=420 twips） |
-| 行内代码 / 代码块 | `` `code` `` / ``` ``` ``` | 宋体（兜底） | Consolas | 10pt（sz=20） | 常规 | 左对齐 | 1.25x（line=300 auto） | 无；底色 `#F5F5F5` |
-| 表格表头 | 表格首行 | 宋体 | Times New Roman | 10.5pt | 加粗 | 居中 | 1.25x | — |
-| 表格单元格 | 表格其它行 | 宋体 | Times New Roman | 10.5pt | 常规 | 左对齐 | 1.25x | — |
-| 附图 | 独立成行的 `![alt](path)` | — | — | 等比缩放至内容宽度 540px / 高度上限 720px | — | 居中 | 1.5x | — |
-| 图注 | 紧跟附图，沿用 alt 文字 | 宋体 | Times New Roman | 10pt（sz=20） | 斜体 | 居中 | 1.25x | — |
-
-### 5.3 docx-js API 关键写法
-
-docx-js 中 `font` 字段必须显式区分四个槽位，否则东亚字体会被覆写：
-
-```js
-// ❌ 错误：name 会被同时填到 eastAsia，把中文字体清掉
-new TextRun({ text: "中文 English", font: { name: "Times New Roman", eastAsia: "宋体" } });
-
-// ✅ 正确：分别声明 ascii / hAnsi / cs / eastAsia
-new TextRun({
-  text: "中文 English",
-  font: { ascii: "Times New Roman", hAnsi: "Times New Roman", cs: "Times New Roman", eastAsia: "宋体" },
-  size: 21,
-  color: "000000",
-});
-```
-
-颜色字段必须传 6 位十六进制不带 `#`：
-
-```js
-new TextRun({ ..., color: "000000" }); // 全文统一黑色；蓝色 "0000FF" 仅用于占位提示
-```
-
-### 5.4 附图嵌入（**强制：必须真正嵌入图片，不可用文本描述代替**）
-
-代理人审阅交底书时需要直接看到附图。生成 docx 时，md 中的 `![alt](path)` 必须被解析为真实图片嵌入到对应位置，**严禁**保留 `[附图1 - 四遍扫描整体流程](media/doc1_fig1.png)` 这类纯文本形式。
-
-#### 5.4.1 Markdown 写法
-
-附图必须 **独立成行**：
-
-```markdown
-![附图1 - 四遍扫描整体流程](media/doc1_fig1.png)
-```
-
-不要把附图与正文混排在同一段；非独立行的 `![]()` 不会触发图片嵌入。
-
-#### 5.4.2 文件组织
-
-- 每篇交底书 md 的同目录下建立 `media/` 子目录，把附图统一放在里面
-- 命名建议：`doc{交底书序号}_fig{图序}.png`，如 `media/doc1_fig1.png`、`media/doc2_fig3.png`
-- 路径解析以 md 文件所在目录为基准，支持相对路径或绝对路径
-
-#### 5.4.3 嵌入规则（已在 `scripts/md2docx.js` 中实现）
-
-| 项 | 取值 |
-| --- | --- |
-| 支持格式 | png / jpg / jpeg / gif / bmp / svg |
-| 真实像素读取 | png：解析 IHDR 块；其它：按 4:3 兜底 |
-| 目标宽度 | 540 px（≈A4 内容区宽 8306 DXA 留少量边距） |
-| 高度上限 | 720 px；超限时按高度反算宽度 |
-| 缩放方式 | 等比，绝不拉伸 / 绝不裁剪 |
-| 图片段落 | 居中，1.5x 行距，段前 120 / 段后 40 twips |
-| 图注 | 自动用 `alt` 文本生成；居中宋体 10pt 斜体；alt 为空时不输出 |
-| 容错 | 图片不存在时插入红色 `[图片缺失] alt (src)`，不中断转换 |
-
-#### 5.4.4 docx-js 关键写法
-
-```js
-new ImageRun({
-  type: "png",                                // 必填
-  data: fs.readFileSync(absPath),
-  transformation: { width: 540, height: 360 },
-  altText: { title: alt, description: alt, name: path.basename(absPath) }, // 三字段全填
-});
-```
-
-`scripts/md2docx.js` 已封装路径解析、IHDR 读取、等比缩放、图注、容错；直接调用脚本即可，无需手写 ImageRun。
-
-### 5.5 生成流程
-
-推荐路径（无需重复造轮子）：
-
-1. 阅读 docx skill（`docx/SKILL.md`），掌握 docx-js 基本规则与 `scripts/office/validate.py` 的调用方式
-2. `npm install docx`（项目级或工作区）
-3. 把 md 与 `media/` 子目录放好；md 中通过 `![alt](media/xxx.png)` 引用附图
-4. 直接调用本技能自带的 `scripts/md2docx.js`：
-   ```bash
-   node patent-disclosure-optimized/scripts/md2docx.js \
-     专利交底书_<发明名称简写>_<YYYYMMDD>.md \
-     专利交底书_<发明名称简写>_<YYYYMMDD>.docx
-   ```
-   脚本会按 5.2 / 5.4 节规范自动处理：大标题、五个头部字段、章节标题、正文、表格、列表、代码块、**附图嵌入与图注**。
-5. 用 `docx/scripts/office/validate.py` 校验生成文件
-6. 解包抽样核对（**附图与字体颜色都要查**）：
-   ```bash
-   python scripts/office/unpack.py 输出.docx tmp/
-   grep -oE 'w:eastAsia="[^"]+"' tmp/word/document.xml | sort | uniq -c
-   grep -oE 'w:color w:val="[A-F0-9]+"' tmp/word/document.xml | sort | uniq -c
-   ls tmp/word/media/ | wc -l   # 内嵌图片数应等于 md 中独立 ![]() 行数
-   ```
-   期望：
-   - 楷体_GB2312（标题）≥ 章节数；仿宋_GB2312 = 5（五个头部字段）；其余 = 宋体
-   - 颜色仅 `000000`（除非保留蓝色占位语）
-   - **`tmp/word/media/` 下图片数 = md 中独立 `![](...)` 行数**
-7. 将最终文件保存到用户的工作目录
-
-### 5.6 文档命名
-
-`专利交底书_<发明名称简写>_<日期YYYYMMDD>.docx`
-
-### 5.7 客户给了不同模板的情况
-
-若客户提供新模板（如《技术交底书模板.doc》），按以下流程更新格式：
-
-1. 用 `soffice.py --convert-to docx` 把 .doc 转为 .docx
-2. `python scripts/office/unpack.py 模板.docx tmpl/` 解包
-3. 读 `tmpl/word/styles.xml`（默认 rFonts、字号、行距）与 `tmpl/word/document.xml`（实际样例段落的 rPr）
-4. 重点提取：默认字体（rFontsDefault）、行距（spacing.line + lineRule）、首行缩进（ind.firstLineChars / firstLine）、各类标题字体与颜色、占位提示语颜色（如 `0000FF`）
-5. 把新参数覆盖到 `scripts/md2docx.js` 顶部的常量（FONT_BODY_EAST / FONT_HEADING_EAST / FONT_TITLE_EAST / FONT_HEADER_FIELD_EAST / SIZE_BODY / SIZE_TITLE / BODY_LINE_SPACING / HEADING_LINE_SPACING / BODY_FIRST_LINE_INDENT），同时在本节表格里记录变更
-
----
-
-## 工作流程总结
-
-```
-用户提交项目材料（代码仓库 + 文档）
-      |
-[阶段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)

package/src/core/skills/xiaoma-advanced-elicitation/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-advanced-elicitation
-description: 'Push the LLM to reconsider, refine, and improve its recent output.'
----
-
-Follow the instructions in ./workflow.md.

package/src/core/skills/xiaoma-advanced-elicitation/methods.csv

@@ -1,51 +0,0 @@
-num,category,method_name,description,output_pattern
-1,collaboration,Stakeholder Round Table,Convene multiple personas to contribute diverse perspectives - essential for requirements gathering and finding balanced solutions across competing interests,perspectives → synthesis → alignment
-2,collaboration,Expert Panel Review,Assemble domain experts for deep specialized analysis - ideal when technical depth and peer review quality are needed,expert views → consensus → recommendations
-3,collaboration,Debate Club Showdown,Two personas argue opposing positions while a moderator scores points - great for exploring controversial decisions and finding middle ground,thesis → antithesis → synthesis
-4,collaboration,User Persona Focus Group,Gather your product's user personas to react to proposals and share frustrations - essential for validating features and discovering unmet needs,reactions → concerns → priorities
-5,collaboration,Time Traveler Council,Past-you and future-you advise present-you on decisions - powerful for gaining perspective on long-term consequences vs short-term pressures,past wisdom → present choice → future impact
-6,collaboration,Cross-Functional War Room,Product manager + engineer + designer tackle a problem together - reveals trade-offs between feasibility desirability and viability,constraints → trade-offs → balanced solution
-7,collaboration,Mentor and Apprentice,Senior expert teaches junior while junior asks naive questions - surfaces hidden assumptions through teaching,explanation → questions → deeper understanding
-8,collaboration,Good Cop Bad Cop,Supportive persona and critical persona alternate - finds both strengths to build on and weaknesses to address,encouragement → criticism → balanced view
-9,collaboration,Improv Yes-And,Multiple personas build on each other's ideas without blocking - generates unexpected creative directions through collaborative building,idea → build → build → surprising result
-10,collaboration,Customer Support Theater,Angry customer and support rep roleplay to find pain points - reveals real user frustrations and service gaps,complaint → investigation → resolution → prevention
-11,advanced,Tree of Thoughts,Explore multiple reasoning paths simultaneously then evaluate and select the best - perfect for complex problems with multiple valid approaches,paths → evaluation → selection
-12,advanced,Graph of Thoughts,Model reasoning as an interconnected network of ideas to reveal hidden relationships - ideal for systems thinking and discovering emergent patterns,nodes → connections → patterns
-13,advanced,Thread of Thought,Maintain coherent reasoning across long contexts by weaving a continuous narrative thread - essential for RAG systems and maintaining consistency,context → thread → synthesis
-14,advanced,Self-Consistency Validation,Generate multiple independent approaches then compare for consistency - crucial for high-stakes decisions where verification matters,approaches → comparison → consensus
-15,advanced,Meta-Prompting Analysis,Step back to analyze the approach structure and methodology itself - valuable for optimizing prompts and improving problem-solving,current → analysis → optimization
-16,advanced,Reasoning via Planning,Build a reasoning tree guided by world models and goal states - excellent for strategic planning and sequential decision-making,model → planning → strategy
-17,competitive,Red Team vs Blue Team,Adversarial attack-defend analysis to find vulnerabilities - critical for security testing and building robust solutions,defense → attack → hardening
-18,competitive,Shark Tank Pitch,Entrepreneur pitches to skeptical investors who poke holes - stress-tests business viability and forces clarity on value proposition,pitch → challenges → refinement
-19,competitive,Code Review Gauntlet,Senior devs with different philosophies review the same code - surfaces style debates and finds consensus on best practices,reviews → debates → standards
-20,technical,Architecture Decision Records,Multiple architect personas propose and debate architectural choices with explicit trade-offs - ensures decisions are well-reasoned and documented,options → trade-offs → decision → rationale
-21,technical,Rubber Duck Debugging Evolved,Explain your code to progressively more technical ducks until you find the bug - forces clarity at multiple abstraction levels,simple → detailed → technical → aha
-22,technical,Algorithm Olympics,Multiple approaches compete on the same problem with benchmarks - finds optimal solution through direct comparison,implementations → benchmarks → winner
-23,technical,Security Audit Personas,Hacker + defender + auditor examine system from different threat models - comprehensive security review from multiple angles,vulnerabilities → defenses → compliance
-24,technical,Performance Profiler Panel,Database expert + frontend specialist + DevOps engineer diagnose slowness - finds bottlenecks across the full stack,symptoms → analysis → optimizations
-25,creative,SCAMPER Method,Apply seven creativity lenses (Substitute/Combine/Adapt/Modify/Put/Eliminate/Reverse) - systematic ideation for product innovation,S→C→A→M→P→E→R
-26,creative,Reverse Engineering,Work backwards from desired outcome to find implementation path - powerful for goal achievement and understanding endpoints,end state → steps backward → path forward
-27,creative,What If Scenarios,Explore alternative realities to understand possibilities and implications - valuable for contingency planning and exploration,scenarios → implications → insights
-28,creative,Random Input Stimulus,Inject unrelated concepts to spark unexpected connections - breaks creative blocks through forced lateral thinking,random word → associations → novel ideas
-29,creative,Exquisite Corpse Brainstorm,Each persona adds to the idea seeing only the previous contribution - generates surprising combinations through constrained collaboration,contribution → handoff → contribution → surprise
-30,creative,Genre Mashup,Combine two unrelated domains to find fresh approaches - innovation through unexpected cross-pollination,domain A + domain B → hybrid insights
-31,research,Literature Review Personas,Optimist researcher + skeptic researcher + synthesizer review sources - balanced assessment of evidence quality,sources → critiques → synthesis
-32,research,Thesis Defense Simulation,Student defends hypothesis against committee with different concerns - stress-tests research methodology and conclusions,thesis → challenges → defense → refinements
-33,research,Comparative Analysis Matrix,Multiple analysts evaluate options against weighted criteria - structured decision-making with explicit scoring,options → criteria → scores → recommendation
-34,risk,Pre-mortem Analysis,Imagine future failure then work backwards to prevent it - powerful technique for risk mitigation before major launches,failure scenario → causes → prevention
-35,risk,Failure Mode Analysis,Systematically explore how each component could fail - critical for reliability engineering and safety-critical systems,components → failures → prevention
-36,risk,Challenge from Critical Perspective,Play devil's advocate to stress-test ideas and find weaknesses - essential for overcoming groupthink,assumptions → challenges → strengthening
-37,risk,Identify Potential Risks,Brainstorm what could go wrong across all categories - fundamental for project planning and deployment preparation,categories → risks → mitigations
-38,risk,Chaos Monkey Scenarios,Deliberately break things to test resilience and recovery - ensures systems handle failures gracefully,break → observe → harden
-39,core,First Principles Analysis,Strip away assumptions to rebuild from fundamental truths - breakthrough technique for innovation and solving impossible problems,assumptions → truths → new approach
-40,core,5 Whys Deep Dive,Repeatedly ask why to drill down to root causes - simple but powerful for understanding failures,why chain → root cause → solution
-41,core,Socratic Questioning,Use targeted questions to reveal hidden assumptions and guide discovery - excellent for teaching and self-discovery,questions → revelations → understanding
-42,core,Critique and Refine,Systematic review to identify strengths and weaknesses then improve - standard quality check for drafts,strengths/weaknesses → improvements → refined
-43,core,Explain Reasoning,Walk through step-by-step thinking to show how conclusions were reached - crucial for transparency,steps → logic → conclusion
-44,core,Expand or Contract for Audience,Dynamically adjust detail level and technical depth for target audience - matches content to reader capabilities,audience → adjustments → refined content
-45,learning,Feynman Technique,Explain complex concepts simply as if teaching a child - the ultimate test of true understanding,complex → simple → gaps → mastery
-46,learning,Active Recall Testing,Test understanding without references to verify true knowledge - essential for identifying gaps,test → gaps → reinforcement
-47,philosophical,Occam's Razor Application,Find the simplest sufficient explanation by eliminating unnecessary complexity - essential for debugging,options → simplification → selection
-48,philosophical,Trolley Problem Variations,Explore ethical trade-offs through moral dilemmas - valuable for understanding values and difficult decisions,dilemma → analysis → decision
-49,retrospective,Hindsight Reflection,Imagine looking back from the future to gain perspective - powerful for project reviews,future view → insights → application
-50,retrospective,Lessons Learned Extraction,Systematically identify key takeaways and actionable improvements - essential for continuous improvement,experience → lessons → actions

package/src/core/skills/xiaoma-editorial-review-prose/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-editorial-review-prose
-description: 'Clinical copy-editor that reviews text for communication issues. Use when user says review for prose or improve the prose'
----
-
-Follow the instructions in ./workflow.md.

package/src/core/skills/xiaoma-editorial-review-structure/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-editorial-review-structure
-description: 'Structural editor that proposes cuts, reorganization, and simplification while preserving comprehension. Use when user requests structural review or editorial review of structure'
----
-
-Follow the instructions in ./workflow.md.

package/src/core/skills/xiaoma-help/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-help
-description: 'Analyzes current state and user query to answer XiaoMa questions or recommend the next workflow or agent. Use when user says what should I do next, what do I do now, or asks a question about XiaoMa'
----
-
-Follow the instructions in ./workflow.md.

package/src/core/skills/xiaoma-help/workflow.md

@@ -1,88 +0,0 @@
-
-# Task: XiaoMa Help
-
-## ROUTING RULES
-
-- **Empty `phase` = anytime** — Universal tools work regardless of workflow state
-- **Numbered phases indicate sequence** — Phases like `1-discover` → `2-define` → `3-build` → `4-ship` flow in order (naming varies by module)
-- **Phase with no Required Steps** - If an entire phase has no required, true items, the entire phase is optional. If it is sequentially before another phase, it can be recommended, but always be clear with the use what the true next required item is.
-- **Stay in module** — Guide through the active module's workflow based on phase+sequence ordering
-- **Descriptions contain routing** — Read for alternate paths (e.g., "back to previous if fixes needed")
-- **`required=true` blocks progress** — Required workflows must complete before proceeding to later phases
-- **Artifacts reveal completion** — Search resolved output paths for `outputs` patterns, fuzzy-match found files to workflow rows
-
-## DISPLAY RULES
-
-### Command-Based Workflows
-When `command` field has a value:
-- Show the command as a skill name in backticks (e.g., `xiaoma-xmc-create-prd`)
-
-### Skill-Referenced Workflows
-When `workflow-file` starts with `skill:`:
-- The value is a skill reference (e.g., `skill:xiaoma-quick-dev-new-preview`), NOT a file path
-- Do NOT attempt to resolve or load it as a file path
-- Display using the `command` column value as a skill name in backticks (same as command-based workflows)
-
-### Agent-Based Workflows
-When `command` field is empty:
-- User loads agent first by invoking the agent skill (e.g., `xiaoma-pm`)
-- Then invokes by referencing the `code` field or describing the `name` field
-- Do NOT show a slash command — show the code value and agent load instruction instead
-
-Example presentation for empty command:
-```
-Explain Concept (EC)
-Load: tech-writer agent skill, then ask to "EC about [topic]"
-Agent: Tech Writer
-Description: Create clear technical explanations with examples...
-```
-
-## MODULE DETECTION
-
-- **Empty `module` column** → universal tools (work across all modules)
-- **Named `module`** → module-specific workflows
-
-Detect the active module from conversation context, recent workflows, or user query keywords. If ambiguous, ask the user.
-
-## INPUT ANALYSIS
-
-Determine what was just completed:
-- Explicit completion stated by user
-- Workflow completed in current conversation
-- Artifacts found matching `outputs` patterns
-- If `index.md` exists, read it for additional context
-- If still unclear, ask: "What workflow did you most recently complete?"
-
-## EXECUTION
-
-1. **Load catalog** — Load `{project-root}/_xiaoma/_config/xiaoma-help.csv`
-
-2. **Resolve output locations and config** — Scan each folder under `{project-root}/_xiaoma/` (except `_config`) for `config.yaml`. For each workflow row, resolve its `output-location` variables against that module's config so artifact paths can be searched. Also extract `communication_language` and `project_knowledge` from each scanned module's config.
-
-3. **Ground in project knowledge** — If `project_knowledge` resolves to an existing path, read available documentation files (architecture docs, project overview, tech stack references) for grounding context. Use discovered project facts when composing any project-specific output. Never fabricate project-specific details — if documentation is unavailable, state so.
-
-4. **Detect active module** — Use MODULE DETECTION above
-
-5. **Analyze input** — Task may provide a workflow name/code, conversational phrase, or nothing. Infer what was just completed using INPUT ANALYSIS above.
-
-6. **Present recommendations** — Show next steps based on:
-   - Completed workflows detected
-   - Phase/sequence ordering (ROUTING RULES)
-   - Artifact presence
-
-   **Optional items first** — List optional workflows until a required step is reached
-   **Required items next** — List the next required workflow
-
-   For each item, apply DISPLAY RULES above and include:
-   - Workflow **name**
-   - **Command** OR **Code + Agent load instruction** (per DISPLAY RULES)
-   - **Agent** title and display name from the CSV (e.g., "🎨 Alex (Designer)")
-   - Brief **description**
-
-7. **Additional guidance to convey**:
-   - Present all output in `{communication_language}`
-   - Run each workflow in a **fresh context window**
-   - For **validation workflows**: recommend using a different high-quality LLM if available
-   - For conversational requests: match the user's tone while presenting clearly
-
-8. Return to the calling process after presenting recommendations.

package/src/core/skills/xiaoma-help/xiaoma-skill-manifest.yaml

@@ -1 +0,0 @@
-type: skill

package/src/core/skills/xiaoma-index-docs/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-index-docs
-description: 'Generates or updates an index.md to reference all docs in the folder. Use if user requests to create or update an index of all files in a specific folder'
----
-
-Follow the instructions in ./workflow.md.

package/src/core/skills/xiaoma-index-docs/xiaoma-skill-manifest.yaml

@@ -1 +0,0 @@
-type: skill

package/src/core/skills/xiaoma-party-mode/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-party-mode
-description: 'Orchestrates group discussions between all installed XiaoMa agents, enabling natural multi-agent conversations. Use when user requests party mode.'
----
-
-Follow the instructions in ./workflow.md.