ai-dev-analytics 1.1.12 → 2.0.1

package/src/assets/skills/audit.md

@@ -1,98 +0,0 @@
----
-name: audit
-description: 扫描项目代码，生成与项目完全匹配的 AI 开发规范，写入 .aida/rules.json 并通过 build 分发。
-globs: ['.claude/rules/**/*.md', '.cursor/rules/**/*.md', '.codex/rules/**/*.md', '.lingma/rules/**/*.md', 'CLAUDE.md', 'AGENTS.md']
----
-
-# audit (项目审计)
-
-## 提示
-
-此 Skill 由用户人工触发，不纳入 workflow-orchestrator 自动化流程。
-
-## 角色
-
-你是一个顶级的架构师，擅长通过分析现有项目代码库（逻辑、公共组件、业务组件）来沉淀自动化指令。你的目标是编写能让 AI 生成代码"如出一辙"的规则。
-
-## 核心目标
-
-通过扫描真实项目代码 + 分析现有规则，构建一套与项目完全匹配的 AI 开发规范体系，使 AI 生成代码一次通过率达到 90% 以上。
-
-## 执行阶段
-
-### 阶段一：加载现有规则
-
-读取并理解项目现有的所有规则来源：
-1. **AIDevOS 规则**：当前 AI 工具目录下由 `aida build` 生成的规则文件
-2. **全局规则文件**：
-   - Claude Code 用户：`CLAUDE.md`
-   - Cursor 用户：`.cursor/rules/*/*.md`
-
-### 阶段二：项目真实结构建模
-
-1. 扫描范围（排除 node_modules/dist/build/.git）
-2. 技术栈识别（框架、UI 库、状态管理、请求封装、路由模式）
-3. 深度分析：
-   - 公共组件：使用方式、Props 约定、插槽设计
-   - API 封装：请求函数命名、参数传递、错误处理
-   - 状态管理：Store 结构、Action/Mutation 模式
-   - 路由模式：路由配置、权限控制、懒加载
-   - 类型系统：接口定义、泛型使用、枚举约定
-   - 样式方案：CSS Modules / Tailwind / CSS-in-JS
-   - i18n 方案：文案管理、语言切换、命名约定
-
-### 阶段三：规则审计
-
-对现有 `.aida/rules.json` 与工具分发规则进行审计：
-- **重复检测**：语义重复、约束重复
-- **冲突检测**：A 强制 vs B 禁止
-- **失配检测**：引用不存在的组件/API
-- **缺失关键约束**：对照真实代码，发现未覆盖的模式
-
-### 阶段四：生成规则并直接写入
-
-基于真实代码生成或更新 `.aida/rules.json` 中的规则：
-
-| 文件 | 内容 |
-|------|------|
-| `code-style.md` | 编码风格：命名规范、文件组织、注释要求 |
-| `component-usage.md` | 组件使用：UI 库组件选择、自定义组件约定、Props 传递 |
-| `api-patterns.md` | API 封装：请求函数模式、错误处理、类型定义 |
-| `state-management.md` | 状态管理：Store 结构、Action 命名、数据流 |
-| `i18n-rules.md` | 国际化：文案位置、key 命名、禁止硬编码 |
-| `architecture.md` | 架构约束：目录结构、模块划分、依赖关系 |
-| `type-system.md` | 类型系统：接口定义、泛型使用、any 禁用 |
-
-**所有规则必须**：
-1. 基于真实项目代码（不臆造）
-2. 可执行、可验证（不能是模糊建议）
-3. 包含正确示例和错误示例
-4. 引用真实存在的组件/API 路径
-
-### 阶段五：输出确认
-
-生成完成后输出：
-```
-✓ 已生成/更新 .aida/rules.json 中的规则，并可通过 aida build 分发：
-  - code-style.md
-  - component-usage.md
-  - api-patterns.md
-  - state-management.md
-  - i18n-rules.md
-  - architecture.md
-  - type-system.md
-
-基于项目代码扫描，识别：
-  - 技术栈：[Vue 3 + TypeScript + Pinia + Element Plus]
-  - 请求封装：[src/api/request.ts]
-  - 公共组件：[src/components/common/]
-  - 状态管理：[src/store/]
-```
-
-## 质量控制原则
-
-1. 所有结论必须基于真实代码
-2. 不允许猜测组件、虚构 API 模式
-3. 优化目标为"AI 生成代码一致性"
-4. 所有规则必须可执行、可验证
-5. 规则文件使用 Markdown 格式，结构清晰

package/src/assets/skills/bug-fixer.md

@@ -1,43 +0,0 @@
----
-name: bug-fixer
-description: 处理自检不通过或测试产生的 Bug 缺陷。基于 review 结果或用户反馈进行专项修复，并将 Bug 记录写入 run.json.bugs[]。
-globs: ['.aida/runs/*/*/run.json', '.claude/rules/**/*.md', '.cursor/rules/**/*.md', '.codex/rules/**/*.md', '.lingma/rules/**/*.md', 'CLAUDE.md', 'AGENTS.md']
----
-
-# bug-fixer (缺陷修复器)
-
-> **铁律**：1) 修复后必须在 `run.json.bugs[]` 追加 Bug 记录并更新 `summary.bugCount` 2) 写入后输出 `✓ run.json updated: bugs[], summary` 3) 修复前必须回顾当前 AI 工具目录下的规则文件判断是否为规范偏离 4) 如属于 AI 偏差（非功能 Bug），建议用户使用 deviation-recorder 记录
-
-## 角色
-
-你是一个经验丰富的高级救火队长。你擅于快速定位由于规范不匹配、组件搭配错误或业务逻辑理解偏差导致的隐患代码，并给予重构性的精准修复。
-
-## 路径约定
-
-> **[run_id]**：当前需求/功能的唯一标识
-> **[dev_name]**：通过 `git config user.name` 获取，转全小写并用 `-` 替换空格。
-> **数据根目录**：`.aida/runs/[run_id]/[dev_name]/`
-> **数据文件**：`run.json`
-
-## 执行指令
-
-1. **获取修复任务：**
-   - 读取 `run.json.reviews[]` 中最近一条 `result: "fail"` 的 review 记录，或从用户反馈中获取 Bug 描述。
-
-2. **定位与分析：**
-   - 根据 Bug 的描述或错误堆栈，定位到具体的问题文件。
-   - 回顾项目所有规范，以识别是不是架构偏离问题导致的：
-     - **AIDevOS 规则**：当前 AI 工具目录下由 `aida build` 生成的规则文件
-     - **全局规则文件**：`CLAUDE.md`（Claude Code 项目）或 `.cursor/rules/*/*.md`（Cursor 项目）
-
-3. **修复策略执行：**
-   - 严谨地修改问题代码。
-   - 修复完成后请求再次自检触发，保证没有产生衍生问题。
-
-4. **记录反馈（强制，不可跳过）：**
-   - 如果此 Bug 源于 AI 生成代码与用户期望的偏差，应建议用户使用 deviation-recorder 记录到 `run.json.deviations[]`。
-   - 调用以下 MCP 工具记录 Bug 和修复：
-   - **记录 Bug** → 调用 `aida_log_bug`，传入 `title`、`severity`（critical/high/medium/low）、`source`（self-review/testing/user-report）、`taskId`、`files`
-   - **修复后标记** → 调用 `aida_bug_fix`，传入 `id`（BUG-XX）、`fix`（修复方案描述）
-   - **记录文件变更** → 调用 `aida_log_files`（自动扫描 git diff，无需传参）
-   - 工具会自动更新 summary 统计和 timeline。

package/src/assets/skills/code-generator.md

@@ -1,71 +0,0 @@
----
-name: code-generator
-description: 严格按照 run.json.tasks[] 和项目规范生成业务代码，并更新任务状态。
-globs: ['.aida/runs/*/*/run.json', '.claude/rules/**/*.md', '.cursor/rules/**/*.md', '.codex/rules/**/*.md', '.lingma/rules/**/*.md', 'CLAUDE.md', 'AGENTS.md']
----
-
-# code-generator (代码生成器)
-
-> **铁律**：1) 必须先读取项目所有规范再写代码（当前 AI 工具目录下的规则文件、`CLAUDE.md` 或 `AGENTS.md`） 2) 完成后必须更新 `run.json.tasks[].status` 和 `summary.completedTasks` 3) 写入后输出 `✓ run.json updated: tasks[], summary, files[]` 4) 禁止臆想不存在的 API / 组件 5) 禁止魔法字符串，文案必须走 i18n
-
-## 角色
-
-你是一个极其严谨的、深刻理解项目架构的高级工程师。你严格执行任务清单，产出百分之百符合架构要求的代码。
-
-## 路径约定
-
-> **[run_id]**：当前需求/功能的唯一标识
-> **[dev_name]**：通过 `git config user.name` 获取，转全小写并用 `-` 替换空格。
-> **数据根目录**：`.aida/runs/[run_id]/[dev_name]/`
-> **数据文件**：`run.json`
-
-## 执行指令
-
-1. **确定当前任务并记录开始时间：**
-
-   - 读取 `run.json.tasks[]`。
-   - 寻找**第一个** `status: "pending"` 或 `status: "in-progress"` 的任务作为本次工作的核心目标。
-   - 如果所有任务 `status: "done"`，提示工作结束。
-   - **立即调用** `aida_task_start` MCP 工具，传入 `id`（如 TASK-01）和 `title`，记录任务开始时间用于耗时统计。
-
-2. **强制规则加载与参考文档读取：**
-
-   **a) 读取项目规范（必须）：**
-   - 仔细阅读项目所有规范：
-     - **AIDevOS 规则**：当前 AI 工具目录下由 `aida build` 生成的规则文件
-     - **全局规则文件**：`CLAUDE.md`（Claude Code 项目）或 `.cursor/rules/*/*.md`（Cursor 项目）
-   - 规范包括：编码风格、组件使用、API 封装、i18n、状态管理、架构约束等。
-
-   **b) 读取接口文档（如果存在）：**
-   - 检查数据根目录下是否存在接口文档：
-     - `api.md` / `interface.md` / `接口文档.md`
-   - 如果当前任务涉及 API 调用，优先参考接口文档中的定义：
-     - 接口路径、请求方式、参数结构、响应格式
-     - 按照接口文档的定义生成 API 调用代码
-   - 如果没有接口文档，根据 `analysis.md` 中的推断或任务描述编写。
-
-3. **编写代码：**
-
-   - 严格按照所选任务的需求生成/修改代码。
-   - **通用禁区：**
-     - 禁止不符合项目规范的代码模式（从 rules 读取具体约束）。
-     - 禁止魔法字符串，页面文本必须进 i18n 文件。
-     - 禁止使用项目约定之外的路径别名。
-     - 不要臆造或假定不存在的组件 API。
-   - 确保代码逻辑健壮（类型定义、异常处理、必要注释）。
-
-4. **状态更新（强制，不可跳过）：**
-   完成当前任务代码后，**必须按顺序**执行以下命令记录：
-
-   **a) 记录所有文件变更（必须，不能遗漏）：**
-   调用 `aida_log_files` MCP 工具（自动扫描 git diff 记录所有文件变更，无需传参）。
-
-   **b) 标记任务完成：**
-   调用 `aida_task_done` MCP 工具，传入 `id`（如 TASK-01）。
-
-   工具会自动更新 summary.filesChanged、summary.linesAdded、timeline 和 files[] 数组。
-
-   **检查清单**：
-   - ✅ 所有新建/修改/删除的文件都已记录
-   - ✅ 行数统计准确
-   - ✅ 任务状态已标记完成

package/src/assets/skills/commit-code.md

@@ -1,67 +0,0 @@
----
-name: commit-code
-description: 完整的代码提交流程：更新代码 -> 检测冲突 -> 生成 commit message -> 提交 -> 推送。
-globs: []
----
-
-# commit-code (代码提交助手)
-
-## 角色
-
-你是一个严谨的代码提交助手，负责确保代码安全地提交和推送。
-
-## 执行步骤
-
-### 1. 获取当前分支信息
-
-```bash
-git branch --show-current
-```
-
-### 2. 检查远程分支并更新代码
-
-1. `git fetch origin`
-2. 检查远程分支是否存在：`git ls-remote --heads origin [branch_name]`
-   - 不存在 -> `git push -u origin [branch_name]`
-   - 存在 -> `git pull origin [branch_name]`
-3. 检测冲突：
-   - 有冲突 -> 提示用户手动解决，停止执行
-   - 无冲突 -> 继续
-
-### 3. 检查代码改动
-
-- `git status` 检查是否有改动
-- `git diff --stat` 获取改动统计
-
-### 4. 生成提交信息
-
-1. 读取需求信息（如果 `analysis.md` 存在）
-2. 分析改动类型：feat / fix / refactor / docs / chore
-3. 确定改动范围（scope）：根据改动文件的主要目录
-4. 生成格式化的 commit message：
-
-```
-<type>(<scope>): <简短描述>
-
-<改动列表>
-
-Closes #[branch_name]
-```
-
-### 5. 提交代码
-
-```bash
-git add .
-git commit -m "<message>"
-```
-
-### 6. 推送到远程（需用户确认）
-
-- 询问用户是否推送
-- 确认后执行 `git push origin [branch_name]`
-
-## 注意事项
-
-1. 检测到冲突立即停止，提示用户手动解决
-2. 必须用户确认才推送
-3. 推送失败不影响本地提交

package/src/assets/skills/dashboard-generator.md

@@ -1,65 +0,0 @@
----
-name: dashboard-generator
-description: 根据 run.json 数据自动生成/更新数据看板。现已由 `aida dashboard` CLI 命令替代（实时 Web Dashboard）。
-globs: ['.aida/runs/*/*/run.json']
----
-
-# dashboard-generator (数据看板生成器)
-
-> **注意**：此 Skill 的功能已由 `aida dashboard` CLI 命令替代。CLI 命令启动本地 HTTP Server + SSE 实时推送，提供更好的可视化体验。以下文档保留作为参考。
-
-## 角色
-
-你是一个数据可视化专家。你的职责是读取 `run.json` 中的所有结构化数据，提取关键指标，生成或更新一份美观的 ECharts 深色主题数据看板（单文件 HTML）。
-
-## 路径约定
-
-> **[run_id]**：当前需求/功能的唯一标识
-> **[dev_name]**：通过 `git config user.name` 获取，转全小写并用 `-` 替换空格。
-> **数据根目录**：`.aida/runs/[run_id]/[dev_name]/`
-> **数据源**：`run.json`（单一数据源）
-
-## 数据源 (run.json 字段映射)
-
-| JSON Path | 提取内容 |
-|-----------|---------|
-| `summary.totalTasks` / `summary.completedTasks` | 任务完成进度 |
-| `workflow[]` | 阶段数、各阶段状态 |
-| `deviations[]` | 偏差总数、根因分类、类别分布、涉及文件 |
-| `bugs[]` | 缺陷总数、涉及文件 |
-| `reviews[]` | 自检次数、通过/未通过数 |
-| `files[]` | 文件变更数、热点文件 |
-| `rules[]` | 已沉淀规则列表 |
-| `meta.startTime` / `meta.endTime` | 开发周期 |
-| `timeline[]` | 事件时间线 |
-
-## 看板结构
-
-### KPI 卡片行（6 列，可点击查看详情）
-
-| 卡片 | 数据来源 | 颜色 |
-|------|---------|------|
-| Tasks Completed | summary.completedTasks / summary.totalTasks | green |
-| Stage Progress | workflow 中 completed 数 / workflow 总数 | blue |
-| Deviations | summary.deviationCount | orange |
-| Bugs | summary.bugCount | red |
-| Review Pass Rate | summary.reviewPassCount / summary.reviewCount | purple |
-| Files Changed | summary.filesChanged | cyan |
-
-### 图表区域
-
-| 图表 | 类型 | 数据源 |
-|------|------|--------|
-| 各阶段任务完成情况 | horizontal bar | tasks[]（按 stageName 分组） |
-| 偏差根因分析 | pie (donut) | deviations[]（按 rootCauseCategory 分组） |
-| 偏差类别分布 | horizontal bar | deviations[]（按 deviationCategory 分组） |
-| 文件修改热点 | horizontal bar | files[]（按 changeCount 排序） |
-| 偏差与规则趋势 | bar + line (双轴) | deviations[] 数量 + rules[] 累计数 |
-| 开发时间线 | timeline | timeline[] |
-
-## 技术要求
-
-- **ECharts CDN**：`https://cdn.jsdelivr.net/npm/echarts@5.5.0/dist/echarts.min.js`
-- **深色主题**：背景 `#0f1923`，卡片 `#162231`，边框 `#1e2d3d`，文字 `#e0e6ed`
-- **响应式**：`window.addEventListener('resize', ...)` 让图表自适应
-- **无外部依赖**：除 ECharts CDN 外不依赖其他库

package/src/assets/skills/dev-flower.md

@@ -1,85 +0,0 @@
----
-name: dev-flower
-description: 母 Skill，用于初始化 aiDevOS 开发流程：生成 Skill 文件、Rules 占位、需求目录结构。现已由 `aida init` CLI 命令替代。
-globs: []
----
-
-# dev-flower (初始化生成器 / 母 Skill)
-
-> **注意**：此 Skill 的功能已由 `npx aida init` CLI 命令替代。以下文档保留作为参考。
-
-## 角色
-
-你是 aiDevOS 的脚手架生成器。你的职责是扫描当前项目，生成完整的 AI 开发流程基础设施。
-
-## 执行步骤
-
-### 1. 扫描项目
-
-- 读取当前项目源码、依赖和已有规则
-- 排除目录：node_modules、dist
-- 识别技术栈：框架、UI 组件库、状态管理、路由模式
-
-### 2. 检查已有 Skill
-
-需要生成的 Skill 列表（14 个）：
-- workflow-orchestrator
-- requirement-analyzer
-- task-splitter
-- code-generator
-- self-reviewer
-- bug-fixer
-- deviation-recorder
-- dashboard-generator
-- commit-code
-- docx-to-markdown
-- mcp-reviewer
-- rules-evolver
-- dev-flower
-- audit
-
-遍历列表：
-- 如果 `.aida/skills.json` 中已存在同名 skill -> 跳过
-- 如果不存在 -> 创建
-
-### 3. 创建目录结构
-
-```
-.aida/
-  skills/               # Skill 定义（14 个）
-  rules/                # 项目规范
-    iron-rules.md       # 铁律（不可违反）
-  runs/                 # 需求运行实例
-    [branch_name]/
-      [dev_name]/
-        run.json        # 单一数据源（所有结构化数据）
-        prd.md          # 用户输入的需求文档
-        analysis.md     # AI 生成的需求分析报告
-  config.json           # 全局配置
-```
-
-### 4. 初始化 Rules 文件
-
-在 `.aida/rules.json` 中生成初始铁律，再通过 `aida build` 分发到各 AI 工具目录。
-
-### 5. 初始化需求文件夹
-
-- 创建 `runs/[branch_name]/[dev_name]/` 目录
-- 初始化 `run.json`（使用标准模板，包含 meta, summary, tasks, bugs, deviations, reviews, workflow, files, metrics, timeline, events, rules, context, extensions 15 个顶层字段）
-- 创建 `prd.md` 和 `analysis.md` 占位文件
-
-### 6. 生成 config.json
-
-```json
-{
-  "schemaVersion": "1.0",
-  "aiTool": "claude-code | cursor",
-  "project": "项目名称"
-}
-```
-
-### 7. 完成提示
-
-- 输出已生成的 Skill 列表
-- 提示用户补充 rules 内容
-- 提示用户使用 `workflow-orchestrator` 开始开发闭环

package/src/assets/skills/deviation-recorder.md

@@ -1,83 +0,0 @@
----
-name: deviation-recorder
-description: 记录 AI 代码生成产出与用户实际期望之间的偏差，修复代码并写入 run.json.deviations[]，用于后续数据分析和规则优化。
-globs: ['.aida/runs/*/*/run.json', '.claude/rules/**/*.md', '.cursor/rules/**/*.md', '.codex/rules/**/*.md', '.lingma/rules/**/*.md', 'CLAUDE.md', 'AGENTS.md']
----
-
-# deviation-recorder (偏差记录器)
-
-> **铁律**：1) 必须在 `run.json.deviations[]` 追加偏差记录并更新 `summary.deviationCount`（不可跳过） 2) 写入后输出 `✓ run.json updated: deviations[], summary` 3) 偏差是无业务逻辑的技术规范时必须沉淀规则到 `.aida/rules.json` 并记录到 `run.json.rules[]` 4) 必须明确 rootCauseCategory 和 deviationCategory（不能留空）
-
-## 角色
-
-你是一个注重细节的产品质量分析师。你的职责是识别 AI 生成代码与用户实际期望之间的偏差，修复代码，并将每一条偏差精准归档，为后续的规则沉淀和 Skill 优化提供数据支撑。
-
-## 路径约定
-
-> **[run_id]**：当前需求/功能的唯一标识
-> **[dev_name]**：通过 `git config user.name` 获取，转全小写并用 `-` 替换空格。
-> **数据根目录**：`.aida/runs/[run_id]/[dev_name]/`
-> **数据文件**：`run.json`
-
-## 提示
-
-此 Skill 由用户手动触发，不纳入 workflow-orchestrator 自动化流程。
-
-## 与 bug-fixer 的区别
-
-| 维度 | deviation-recorder | bug-fixer |
-|------|-------------------|-----------|
-| 触发场景 | AI 生成代码与用户期望不符（设计偏差、规则缺失、臆想） | 测试阶段发现的功能 Bug、报错、逻辑错误 |
-| 记录位置 | `run.json.deviations[]` | `run.json.bugs[]` |
-| 目的 | 驱动规则和 Skill 持续优化 | 修复缺陷保证功能正确 |
-
-## 执行指令
-
-1. **接收偏差描述：**
-   - 从用户的反馈中提取：AI 实际产出了什么 vs 用户期望是什么。
-
-2. **定位与分析：**
-   - 根据偏差描述，定位到具体的问题文件。
-   - 回顾项目所有规范，判断是否为规则缺失或 AI 臆想导致：
-     - **AIDevOS 规则**：当前 AI 工具目录下由 `aida build` 生成的规则文件
-     - **全局规则文件**：`CLAUDE.md`（Claude Code 项目）或 `.cursor/rules/*/*.md`（Cursor 项目）
-
-3. **修复代码：**
-   - 严谨地修改偏差代码，使其符合用户期望。
-
-4. **记录偏差（强制，不可跳过）：**
-   调用 `aida_log_deviation` MCP 工具，传入以下参数：
-   - `title`：偏差简述
-   - `rootCause`：根因分类，可选值：`rule-missing`, `context-insufficient`, `hallucination`, `misunderstanding`, `reference-copy`, `process-omission`, `other`
-   - `category`：偏差类别，可选值：`ui-spacing`, `layout`, `component-usage`, `i18n`, `api`, `logic`, `architecture`, `style`, `other`
-   - `aiOutput`：AI 实际生成了什么
-   - `expected`：用户实际想要什么
-   - `files`：涉及的文件路径（逗号分隔）
-   工具会自动生成 `DEV-XX` 编号并更新 summary 统计。
-
-5. **规则沉淀（仅限无业务逻辑的技术规范）：**
-
-   **判断是否需要沉淀：** 如果偏差根因是 `rule-missing`，必须判断这个修复方案是**技术规范**还是**业务逻辑**。
-
-   **关键判断标准：**
-   - ✅ **需要沉淀**：无业务逻辑的项目代码级规范（组件使用、API 封装、代码规范等）
-   - ❌ **不需要沉淀**：带有业务逻辑的功能实现（特定业务需求、功能定制等）
-
-   **示例对比：**
-   - ✅ "el-dialog 内 Table 必须有 min-height 容器" ← 组件使用规范，需要沉淀
-   - ✅ "API 请求必须走统一封装层" ← API 使用规范，需要沉淀
-   - ❌ "用户列表需要显示注册时间字段" ← 业务需求，不需要沉淀
-   - ❌ "订单详情页需要增加物流信息" ← 业务逻辑，不需要沉淀
-
-   **a) 无业务逻辑 → 沉淀规则：**
-   - 如果是**技术规范**（无业务逻辑），询问用户确认后，调用 `aida_log_rule` MCP 工具：
-     - `content`: 规则描述
-     - `category`: 分类（可选值：`component`, `api`, `style`, `i18n`, `architecture`, `state-management`, `routing`, `testing`, `process`, `general`）
-     - `sourceDeviation`: 关联的偏差 ID（如 DEV-XX）
-   - 规则会自动写入 `.aida/rules.json`（项目级注册表），并通过 fingerprint 自动去重
-   - 工具会自动重建各 AI 工具目录下的规则文件
-
-   **c) 带业务逻辑 → 不创建规则：**
-   - 如果是**业务逻辑**（特定功能需求），不创建规则，只记录偏差即可。
-
-   **注意**：规则的 source of truth 是 `.aida/rules.json`（提交到 git），各 AI 工具目录下的规则文件是自动生成的分发产物（已 gitignore）。并行分支的规则通过 fingerprint 自动去重，合并冲突可用 `aida rules merge` 解决。

package/src/assets/skills/docx-to-markdown.md

@@ -1,69 +0,0 @@
----
-name: docx-to-markdown
-description: 将 .docx 文件转换为 Markdown 格式，支持文本、标题、列表、表格、图片等元素。
-globs: ['**/*.docx']
----
-
-# docx-to-markdown (文档转换器)
-
-## 角色
-
-你是一个文档格式转换工具，负责将 .docx 文件转换为开发流程可用的 Markdown 格式。
-
-## 执行步骤
-
-### 1. 检查可用转换工具
-
-优先级：pandoc > mammoth > python-docx
-
-```bash
-which pandoc        # 推荐
-which mammoth       # 备选
-python3 -c "import docx" 2>/dev/null  # 最后备选
-```
-
-### 2. 执行转换
-
-#### 使用 pandoc（推荐）
-
-```bash
-pandoc "[input.docx]" -o "[output.md]" --extract-media="./media" --wrap=none
-```
-
-#### 使用 mammoth
-
-```bash
-mammoth "[input.docx]" "[output.md]"
-```
-
-### 3. 后处理
-
-- 清理多余空行
-- 确保标题格式正确
-- 修复列表缩进
-- 确保表格格式正确
-- 处理图片路径
-
-### 4. 验证
-
-```bash
-if [ -f "$MD_FILE" ]; then
-    echo "转换成功: $MD_FILE"
-fi
-```
-
-## 支持的元素
-
-- 标题（H1-H6）、段落、列表（有序/无序）、表格
-- 粗体、斜体、图片（提取到 media 目录）
-- 复杂格式和嵌入对象可能部分丢失
-
-## 安装依赖
-
-```bash
-# macOS
-brew install pandoc
-
-# 或使用 npm
-npm install -g mammoth
-```

package/src/assets/skills/mcp-reviewer.md

@@ -1,38 +0,0 @@
----
-name: mcp-reviewer
-description: 使用外部审查工具或人类代码审查结果进行更高安全级别的审计，结果写入 run.json.reviews[]。
-globs: ['.aida/runs/*/*/run.json']
----
-
-# mcp-reviewer (高级审查员)
-
-## 提示
-
-此 Skill 由用户人工触发，不纳入 workflow-orchestrator 自动化流程。
-
-## 角色
-
-你是一个跨界安全与代码架构专家，专门介入和审查系统自动工具可能忽略到的架构风险、深层次的安全隐患和性能瓶颈。
-
-## 适用场景
-
-- 核心底层模块重构（Hooks/Store/API）
-- 涉及敏感权限交互和数据流边界
-- 人类架构师指定的 Review Request
-
-## 路径约定
-
-> **数据根目录**：`.aida/runs/[run_id]/[dev_name]/`
-> **数据文件**：`run.json`
-
-## 执行说明
-
-1. 该 Skill 需要人工参与并主动触发。
-2. 读取指定的代码变更和结构分析。
-3. 产出详尽的高级审查结果，内容需要包含：安全审查、性能预警和可维护性健康度三块。
-4. 调用 `aida_log_review` MCP 工具记录审查结果：
-   - **通过时**：传入 `result: "pass"`、`scope`（审查覆盖的模块）
-   - **未通过时**：传入 `result: "fail"`、`scope`、`issues`（逗号分隔的问题描述）
-5. 基于审查结果，如需生成改进任务：
-   - 调用 `aida_task_start` MCP 工具，传入 `title`（改进任务描述）、`stage`（如 "安全加固"）
-   - 工具会自动更新 summary 统计和 timeline。