@agile-team/wl-skills-kit 1.2.0 → 2.1.0

package/files/.github/skills/{prototype-scan → core/prototype-scan}/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: prototype-scan
-description: "Use when: analyzing Axure exported HTML prototype files to extract page inventory, classify interaction patterns, identify reusable components, and produce a structured page checklist for Vue development. Also supports detailed design documents (MD/Word) as input. Triggers on: prototype analysis, axure scan, page inventory, 原型解析, 页面清单, axure转vue, 详设文档, design doc, 详细设计."
+description: "Use when: analyzing Axure exported HTML prototype files to extract page inventory, classify interaction patterns, identify reusable components, and produce a structured page checklist for Vue development. Also supports detailed design documents (MD/Word) or natural language descriptions as input. Triggers on: prototype analysis, axure scan, page inventory, 原型解析, 页面清单, axure转vue, 详设文档, design doc, 详细设计, 口述需求, 自然语言建页面, natural language page request, 建个页面, 写个页面, 口头描述页面."
 ---
 
 # Skill: 原型解析（prototype-scan）
@@ -11,8 +11,92 @@ description: "Use when: analyzing Axure exported HTML prototype files to extract
 
 ## 触发
 
-- **模式 A（Axure）**：提供 Axure HTML 文件包目录，AI 全量扫描 HTML
-- **模式 B（详设文档）**：提供 MD/Word/表格格式的详细设计文档，AI 解析结构化字段
+| 模式 | 输入 | 典型场景 |
+|------|------|----------|
+| **模式 0（自然语言）** | 用户口述需求，无文件 | 日常对话："帮我建一个客户管理页面，有XX字段" |
+| **模式 A（Axure）** | Axure HTML 文件包目录 | 已有原型设计，AI 全量扫描 HTML |
+| **模式 B（详设文档）** | MD/Word/表格格式的详细设计文档 | 已有详细设计文档，AI 解析结构化字段 |
+
+---
+
+## 模式 0 — 自然语言转 page-spec（内部步骤）
+
+> **核心原则**：模式 0 是 AI 的**内部推导流程**，不输出中间 JSON 给用户。
+> AI 从口述中提取信息 → 内部构建 page-spec JSON → 直接传递给 page-codegen 消费。
+> **不向用户索要文件**，用注释标注不确定项即可。
+
+### 1. 提取关键信息
+
+从用户口述中识别以下实体（缺省则用默认值）：
+
+| 实体 | 识别关键词示例 | 默认值 |
+|------|---------------|--------|
+| 页面中文名 | "XX页面" / "XX管理" / "XX档案" | 必须由用户提供 |
+| 交互模式 | 见下方映射表 | `LIST` |
+| 服务缩写 | "生产"→pm, "精整"→mmwr, "销售"→sale, "人力"→hrms, "基础"→base | 从目标路径推断 |
+| 资源名 | 从中文名推断 CamelCase | 自动推断 |
+| 目录名 | 从中文名推断 kebab-case | 自动推断 |
+
+### 2. 关键词 → 交互模式映射
+
+| 用户关键词 | 推断模式 |
+|-----------|----------|
+| "列表" / "查询" / "管理页" / 无特殊说明 | `LIST` |
+| "主从" / "明细" / "上下表" | `MASTER_DETAIL` |
+| "树形" / "左树右表" | `TREE_LIST` |
+| "表单" / "详情" / "多Tab表单" | `DETAIL_TABS` |
+| "独立表单" / "路由表单" / "复杂表单" | `FORM_ROUTE` |
+| "变更历史" / "变更记录" | `CHANGE_HISTORY` |
+| "记录表单" / "无分页" | `RECORD_FORM` |
+| "工位" / "操作站" | `OPERATION_STATION` |
+
+### 3. 内部构建 page-spec 骨架
+
+AI 根据提取的信息，内部构建 page-spec JSON（**不输出给用户**）：
+
+```jsonc
+{
+  "pageName": "[用户说的中文名]",
+  "kebabName": "[推断的kebab-case]",
+  "pattern": "[推断的交互模式，默认LIST]",
+  "path": "views/[域]/[模块]/[子模块]/[kebab-name]/",
+  "query": [
+    // 从用户描述中提取；未提及 → 基于资源名推断 1-2 个（如"名称"、"编码"）
+  ],
+  "toolbar": [
+    // 默认: 新增(primary) + 删除(danger)；用户提及"导出""导入"等则追加
+  ],
+  "columns": [
+    // 从用户描述中提取；未逐一列举 → 基于资源语义推断 5-8 个常见字段
+  ],
+  "operations": [
+    // 默认: 编辑 + 删除；用户提及"查看""审批"等则调整
+  ],
+  "features": {
+    "tabSwitch": false, "viewSwitch": false, "hiddenMenu": false
+  },
+  "notes": [
+    "[模式0] 字段英文名为AI推断值，请确认",
+    "[模式0] dictCode 为推断值，请后端确认"
+  ]
+}
+```
+
+### 4. 降级与默认值原则
+
+| 信息缺失项 | 默认策略 |
+|-----------|----------|
+| 交互模式 | `LIST`（最常见的列表查询页） |
+| 查询字段 | 基于业务资源名推断 1-2 个（"名称"、"编码"） |
+| 工具栏按钮 | `[新增(primary), 删除(danger)]` |
+| 表格列 | 基于资源语义推断 5-8 个常见字段（编码、名称、类型、状态、创建时间等） |
+| 操作列 | `[编辑, 删除]` |
+| 字段英文名 | AI 推断 camelCase，notes 标注"字段名为推断值" |
+| 字典 code | 状态类字段自动标注推断 dictCode，notes 标注"dictCode 为推断值" |
+| 子表 | 不生成（用户未提及则不推断） |
+| Tab/视角切换 | 关闭（`false`） |
+
+> 构建完成后，直接进入输出流程（同模式 A/B），为 page-codegen 提供标准 page-spec JSON。
 
 ---
 

package/files/.github/skills/core/prototype-scan/USAGE.md

@@ -0,0 +1,95 @@
+# 使用指南：prototype-scan（原型扫描）
+
+> **谁读这个文档**：团队成员（产品/前端/后端）
+> **AI 触发文件**：同目录 `SKILL.md`（无需手动阅读）
+
+---
+
+## 这个 Skill 解决什么问题
+
+把零散的需求来源（HTML/PDF 原型、详设文档、口述需求、PRD），**结构化为一份《页面清单》**，作为后续 `api-contract` 和 `page-codegen` 的输入。
+
+---
+
+## 何时使用
+
+- 产品经理给你一组 HTML 原型，要做成页面
+- 拿到 Word/PDF 详设文档，需要拆解出多少个页面、各自有哪些字段
+- 业务方口述需求："给我加一个客户档案的页面，能查能改能审批……"
+- 想梳理一个模块到底有哪些页面、各自什么类型
+
+---
+
+## 触发关键词
+
+`扫描原型` / `解析原型` / `页面清单` / `详设文档` / `口述需求` / `建个页面` / `写个页面`
+
+---
+
+## 标准对话示例
+
+### 示例 1：HTML 原型扫描
+
+```
+你：扫描 docs/prototypes/客户管理/ 下的所有原型，生成页面清单。
+AI：[读取 SKILL.md → 输出 Pre-flight 声明]
+    Pre-flight：
+    ├─ 来源：docs/prototypes/客户管理/ 共 7 个 HTML
+    ├─ 输出：reports/PROTOTYPE_SCAN_客户管理_20260426.md
+    └─ 不会生成代码
+    [扫描中... 3 分钟]
+    完成，请确认页面清单：
+    1. mmwr-customer-archive (LIST 类型) - 客户档案查询
+    2. mmwr-customer-detail (DETAIL) - 客户详情
+    ... 共 7 项
+```
+
+### 示例 2：口述需求
+
+```
+你：给生产域加个炼钢批次管理，能查能改能批量审批。
+AI：[输出 Pre-flight]
+    Pre-flight：
+    ├─ 来源：口述需求
+    ├─ 输出：reports/PROTOTYPE_SCAN_炼钢批次_20260426.md
+    └─ 类型推断：LIST + 弹窗编辑 + 行内审批
+    需向你确认 4 项：
+    1. 批次主键是 heatNo 还是 batchId？
+    2. 状态字段有哪些值（已下达/进行中/已完成/作废）？
+    3. 审批是单人审还是多级流转？
+    4. 字典码用 ms_heat_status 还是 mmsm_heat_state？
+```
+
+---
+
+## 输出物
+
+`.github/reports/PROTOTYPE_SCAN_<模块>_<YYYYMMDD>.md` —— 包含：
+
+- 页面清单表格（页面英文名 / 中文名 / 类型 / 路由 / 字段概要）
+- 各页面查询条件、表格列、表单字段的初步定义
+- 字典/弹窗/联动的猜测，标注 🟡 待确认
+
+---
+
+## 常见踩坑
+
+| 现象                        | 原因                   | 解法                                      |
+| --------------------------- | ---------------------- | ----------------------------------------- |
+| AI 凭空臆造字段             | 原型缺失或描述模糊     | 让 AI 列"待确认"清单，逐项填空再继续      |
+| 页面命名不符合 kebab-case   | AI 直接用中文/驼峰命名 | 在指令里强调 "命名遵循 standards/page.md" |
+| 同一字段在多页面命名不一致  | AI 没有跨页面对齐      | 要求生成清单后做一遍"字段一致性自检"      |
+| LIST/MASTER_DETAIL 类型错判 | 原型隐含主从结构未识别 | 显式告知"这是主从表"或贴出原型图          |
+
+---
+
+## FAQ
+
+**Q：扫描出来的页面清单可以直接用 `page-codegen` 生成代码吗？**
+A：建议先走 `api-contract` 生成 api.md，让后端确认接口字段，再 codegen。否则 data.ts 里的字段名可能和后端对不上。
+
+**Q：能不能跳过这个 Skill 直接让 AI 写代码？**
+A：可以但不推荐。Skill 的价值是**约束输出物落到统一文档**，便于团队对账。直接生成代码容易遗漏需求要点、字段命名不规范。
+
+**Q：扫描结果不对怎么办？**
+A：reports/ 下的 md 是 markdown，可以直接编辑。修改后再让 AI "基于 reports/PROTOTYPE_SCAN_xxx.md 进行 api-contract"。

package/files/.github/skills/core/template-extract/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: template-extract
+description: "Use when: extracting domain-specific page templates from existing project pages and contributing them to skills/core/page-codegen/templates/domains/. Triggers on: 提取模板, 抽取模板, 沉淀模板, 模板贡献, extract template, contribute template."
+---
+
+# Skill: 模板提取（template-extract）
+
+从现有项目的成熟页面提取领域模板，沉淀到 `.github/skills/core/page-codegen/templates/domains/`，扩充团队 AI 模板库。
+
+> **核心理念**：模板贡献门槛极低 — 开发者只需说出一个页面目录路径，AI 完成 90% 的分析和写作。
+
+---
+
+## 触发词
+
+`提取模板` / `抽取模板` / `沉淀模板` / `模板贡献` / `extract template`
+
+---
+
+## Pre-flight 声明
+
+```
+🚀 已触发技能 template-extract/SKILL.md → 从现有页面提取领域模板
+✅ 已读取 template-extract/SKILL.md      → 提取流程主规则
+✅ 已读取 templates/_index.md            → 已有模板清单（避免重复）
+✅ 已读取 standards/02-code-structure.md → 模板必须遵循的代码结构
+✅ 已读取 standards/13-platform-components.md → 模板必须遵循的平台组件合规
+```
+
+---
+
+## 执行流程
+
+### 步骤 1：开发者指定目标
+
+开发者提供一个目录路径：
+
+```
+"提取模板，目标页：src/views/produce/sjgl/mmwr-rolling-management/"
+```
+
+### 步骤 2：AI 读取目标页 4 文件
+
+```
+✅ 读取 {target}/index.vue
+✅ 读取 {target}/data.ts
+✅ 读取 {target}/index.scss
+✅ 读取 {target}/api.md（如存在）
+```
+
+### 步骤 3：AI 自动识别交互模式
+
+输出识别结论：
+
+```
+🔍 识别结果
+  - 页面包含：{2 个 BaseTable / 1 个内联 BaseForm / 4 个操作按钮}
+  - 交互模式：{双清单联动 + 内联表单 + 条件按钮}
+  - 与已有 TPL 对比：
+      ✅ 接近 TPL-OPERATION-STATION（domains/produce/）
+      ❌ 不符合 TPL-LIST / TPL-MASTER-DETAIL / TPL-RECORD-FORM
+  - 结论建议：本页面**已有相似模板**，可能是 TPL-OPERATION-STATION 的变体，
+              建议考虑增强现有模板而非新建。
+              （或：本页面是**独立新模式**，建议提取为 TPL-XXX）
+```
+
+### 步骤 4：AI 问答确认（最多 4 个问题）
+
+```
+❓ 问题 1：领域归属？
+   选项：A. produce（生产）  B. sale（销售）  C. 其他（请说明）
+
+❓ 问题 2：建议的模板命名？
+   AI 建议：TPL-{XXX-XXX}
+   如不满意请提出替代
+
+❓ 问题 3：是否有需要脱敏/抽象的业务特定内容？
+   - 业务字段名（建议保留作为占位符 [字段名]）
+   - 业务接口路径（建议改为 [服务缩写]/[资源名]/{action} 占位）
+   - 硬编码字典码（建议改为占位符或注释说明）
+
+❓ 问题 4：是否合并到已有模板？
+   仅当步骤 3 识别为「相似模板」时才问。
+   选项：A. 增强现有模板（追加章节）  B. 提取为独立新模板
+```
+
+### 步骤 5：生成 TPL 文件
+
+按 `templates/domains/_CONTRIBUTING.md` 格式生成，必须包含：
+
+- 适用场景说明
+- 识别规则（5 条以内）
+- 完整 index.vue / data.ts / index.scss 代码（脱敏后）
+- 注意事项
+
+### 步骤 6：写入并注册
+
+```
+✅ 写入 templates/domains/{domain}/TPL-{NAME}.md
+✅ 更新 templates/_index.md（追加注册条目）
+```
+
+### 步骤 7：输出后续步骤
+
+```
+📦 模板提取完成
+────────────────────────────────────────────────
+✅ 已生成 templates/domains/{domain}/TPL-{NAME}.md
+✅ 已更新 templates/_index.md 注册表
+────────────────────────────────────────────────
+📌 后续步骤：
+   1. 人工 review 模板内容（脱敏完整性 / 占位符正确性）
+   2. 提交：git cz → feat(template): 新增领域模板 TPL-{NAME}
+   3. PR 评审 → CHENY 合入
+────────────────────────────────────────────────
+```
+
+---
+
+## 提取质量校验（AI 自检）
+
+生成 TPL 文件后，AI 必须自检：
+
+- [ ] 业务字段名已替换为 `[字段名]` / `[资源名]` 占位符
+- [ ] API 路径已替换为 `/[服务缩写]/[资源名]/{action}` 格式
+- [ ] 没有遗留具体的字典码 / 状态值（已注释说明用途）
+- [ ] 代码符合 standards/02、13（结构 + 组件合规）
+- [ ] 包含识别规则（让 AI 未来能匹配此模板）
+
+---
+
+## 边界情况
+
+| 情况                             | 处理                                                         |
+| -------------------------------- | ------------------------------------------------------------ |
+| 目标页代码不符合 standards/ 规范 | 拒绝提取，输出审计建议（"目标页本身不合规，建议先整改"）     |
+| 目标页过于业务特化，无法抽象     | 反问开发者："此页面业务耦合较深，提取后通用性差，是否继续？" |
+| 已有 TPL 高度重合                | 优先建议增强现有模板，不建议新建                             |
+| 开发者指定的命名不符合规范       | 给出建议命名，请开发者确认                                   |

package/files/.github/skills/core/template-extract/USAGE.md

@@ -0,0 +1,93 @@
+# 使用指南：template-extract（模板提取）
+
+> **谁读这个文档**：团队成员（主要前端，模板贡献者）
+> **AI 触发文件**：同目录 `SKILL.md`
+
+---
+
+## 这个 Skill 解决什么问题
+
+把项目里**已经写得很好的页面**抽取成可复用模板，沉淀到 `skills/core/page-codegen/templates/domains/` 下。下次 codegen 时同类页面优先复用。
+
+---
+
+## 何时使用
+
+- 写完一个"代表性强、规范度高"的页面，想沉淀给团队复用
+- 同模块内重复结构出现 ≥ 3 次，应抽模板
+- 季度/版本末整理沉淀产出
+
+---
+
+## 触发关键词
+
+`提取模板` / `抽取模板` / `沉淀模板` / `模板贡献`
+
+---
+
+## 标准对话示例
+
+```
+你：把 src/views/produce/aiflow/mmwr-customer-archive/ 这个页面抽取成模板
+AI：[Pre-flight]
+    源：mmwr-customer-archive (LIST 类型，含审批工作流)
+    建议落位：templates/domains/produce/customer/list-with-approval/
+    将抽取：
+    - data.ts.tpl  （EColumn 字段保留 + 字段名占位化）
+    - index.vue.tpl
+    - index.scss.tpl
+    - meta.json    （记录适用场景、字段规则、字典）
+    占位约定：
+    - 资源名 → {{resourceName}}
+    - 服务缩写 → {{serviceShort}}
+    - 字典 logicValue → {{statusDict}}
+    通过 convention-audit 后才落盘。
+```
+
+---
+
+## 输出物
+
+```
+templates/domains/<域>/<场景>/
+├── data.ts.tpl
+├── index.vue.tpl
+├── index.scss.tpl
+├── meta.json    适用条件 / 占位字段说明 / 字典依赖
+└── README.md   场景说明 + 何时复用 + 已知限制
+```
+
+---
+
+## 模板分级
+
+| 层级         | 路径                             | 复用范围                            |
+| ------------ | -------------------------------- | ----------------------------------- |
+| `universal/` | `templates/universal/<类型>/`    | 跨业务通用（LIST/DETAIL/TREE_LIST） |
+| `domains/`   | `templates/domains/<域>/<场景>/` | 同域同场景                          |
+
+抽取的模板**默认进 domains/**。如果发现真的全员通用，可由维护者升级到 universal/。
+
+---
+
+## 常见踩坑
+
+| 现象                               | 原因                 | 解法                                                            |
+| ---------------------------------- | -------------------- | --------------------------------------------------------------- |
+| 抽出来的模板里夹着业务字段         | 占位化不彻底         | meta.json 里**穷举所有占位**，AI 才会替换干净                   |
+| 模板下次 codegen 命中率低          | 命名/scope 太具体    | 起更通用的场景名（list-with-approval 比 mmwr-customer-list 好） |
+| 字典硬编码进模板                   | 没用 logicValue 占位 | 改用 `{{statusDict}}` 占位 + meta 里描述                        |
+| 不同业务字段长度不一时模板生成报错 | 列宽硬编码           | 模板里只给推荐值，meta 标"可调"                                 |
+
+---
+
+## FAQ
+
+**Q：贡献的模板要走 review 吗？**
+A：建议至少同事 review 一下 meta.json + 是否真有复用价值。直接落盘容易污染模板库。
+
+**Q：模板出问题谁负责？**
+A：贡献者维护一段时间，稳定后由 kit 维护者接管。模板里要写 author + lastUpdate。
+
+**Q：能否私有领域只抽到本仓库不发布？**
+A：可以。`templates/domains/` 在 `.github/skills/` 下，跟着业务项目走。kit 包不强制收集。

package/files/.github/skills/domain/README.md

@@ -0,0 +1,51 @@
+# domain/ — 领域专属 Skill 占位目录
+
+> **当前状态**：空目录，等待领域 Skill 沉淀。
+
+---
+
+## 用途
+
+`domain/` 用于存放**强业务域相关的 Skill**——这类 Skill 在其他域几乎无复用价值，但在特定业务域内高频使用。
+
+与 `core/`（全业务通用）和 `sync/`（后端联动通用）不同，`domain/` 的 Skill 允许直接依赖领域特有的术语、流程和数据结构。
+
+---
+
+## 目录结构预期
+
+```
+domain/
+├── README.md          ← 本文件
+├── produce/           生产域（如高炉计划、轧钢批次、工序流转等专属流程）
+│   └── ...
+├── sale/              销售域（如合同审批流、信用额度等专属流程）
+│   └── ...
+└── {其他域}/          按需创建
+```
+
+---
+
+## 何时在此创建新 Skill
+
+满足以下条件时，在对应域子目录下创建新 Skill：
+
+1. 该流程与业务域**强绑定**（换了域就完全不适用）
+2. 在本域内**高频触发**（≥3 个不同功能模块会用到）
+3. `core/` 里已有的 Skill **无法覆盖**（不是简单参数调整能解决的）
+
+---
+
+## 贡献流程
+
+1. 在对应域子目录下创建 `{skill-name}/SKILL.md`
+2. 更新 `skills/_registry.md` 启用路由表
+3. 同步在 `skills/_registry.md` 的目录分级图里添加条目
+4. 可选：创建 `USAGE.md` 供域内团队成员阅读
+5. 参考 `kit-internal/CONTRIBUTING.md` 第三节"添加新 Skill"
+
+---
+
+## 扩展策略
+
+> 当 `domain/` 下某个域的 Skill 数量超过 **5 个**，或产生跨团队复用需求时，考虑将其拆为独立 npm 包（如 `@agile-team/wl-skills-produce`），本包仅保留 `core/sync/ops`。

package/files/.github/skills/ops/code-fix/SKILL.draft.md

@@ -0,0 +1,108 @@
+---
+name: code-fix
+description: "[PLANNED — DRAFT, not yet active] 受控自动修复 Skill 设计草稿。基于 convention-audit 报告，对单条/分组偏差执行 AI 修复，全程必须人工 review 通过 + 单测护栏。"
+status: planned
+---
+
+# Skill: 受控自动修复（code-fix）— 草稿
+
+> ⚠️ **本文件为设计草稿（SKILL.draft.md），未启用，不参与 AI 调度。**
+
+---
+
+## 1. 设计目标
+
+`convention-audit` 已能产出偏差清单。`code-fix` 在此基础上提供**受控的自动修复**：
+
+- **单条修复**：选定 1 条偏差 → AI 修改 → diff 确认 → 写入
+- **分组修复**：选定一类偏差（如"全部缺少 :scoped"）→ 批量修改 → 总体 diff → 分文件确认 → 写入
+- **预置修复模板**：常见偏差直接走规则，不调 AI
+
+---
+
+## 2. 工作流
+
+```
+convention-audit 报告 (reports/AUDIT_AI_*.md)
+        │
+        ▼
+[1] 用户从报告挑选 issueId（或 issueGroup）
+        │
+        ▼
+[2] 解析 issue → 定位文件 + 行号 + 偏差类型
+        │
+        ▼
+[3] 选择修复策略：
+    ├─ rule-based（如缺 :scoped、缺 cid 等）→ 走预置模板
+    └─ ai-based（语义性偏差）→ 调 AI 生成 patch
+        │
+        ▼
+[4] Pre-flight 输出 diff 预览（人读）
+        │
+        ▼
+[5] 用户确认 yes/no
+        │
+        ├─ yes → 跑 lint + typecheck（如配置）
+        │         ├─ 通过 → 写入文件 + 输出 reports/CODE_FIX_<YYYYMMDD>.md
+        │         └─ 失败 → 回滚 + 标记 issue "待人工"
+        │
+        └─ no  → 跳过该 issue，回到挑选界面
+```
+
+---
+
+## 3. 受控原则（关键）
+
+| 原则                | 实现                                                          |
+| ------------------- | ------------------------------------------------------------- |
+| **不破坏功能**      | 修复前后跑 lint + typecheck，失败回滚                         |
+| **不批量盲改**      | 每个文件改完都让用户看 diff，禁止全自动跳过确认               |
+| **可回滚**          | 修改前内存保留原始内容，输出报告含还原 patch                  |
+| **范围明确**        | 只改 issue 报告里点名的行，不顺手"重构"周边                   |
+| **AI 不生成新逻辑** | code-fix 只修偏差，**不**做功能补全（那是 page-codegen 的活） |
+
+---
+
+## 4. 偏差类型 → 修复策略对照
+
+| 偏差类型                            | 来源 standards         | 策略       | 难度 |
+| ----------------------------------- | ---------------------- | ---------- | ---- |
+| EColumn 缺 cid                      | data-ts.md             | rule-based | 易   |
+| scss 文件缺 :scoped 包裹            | scss.md                | rule-based | 易   |
+| import 路径不规范                   | imports.md             | rule-based | 易   |
+| Hook 类未继承 AbstractPageQueryHook | page.md                | rule-based | 中   |
+| API_CONFIG URL 不符合命名约定       | api-contract.md        | ai-based   | 中   |
+| 表格列定义与 api.md 字段不一致      | api-contract + data-ts | ai-based   | 难   |
+| 业务语义偏差（流程不对）            | 多 standards 综合      | **不修复** | -    |
+
+---
+
+## 5. 命令形态（拟定）
+
+```
+"修复 reports/AUDIT_AI_*.md 中的 issue#3"        → 单条
+"修复 reports/AUDIT_AI_*.md 中所有 scss 偏差"    → 分组
+"修复全部 rule-based 偏差，跳过 ai-based"        → 受控批量
+"列出可修复的 issue"                            → 不动手，仅列清单
+```
+
+---
+
+## 6. 与其他 Skill 关系
+
+| Skill            | 关系                                    |
+| ---------------- | --------------------------------------- |
+| convention-audit | **前置**：必须先有审计报告才能 code-fix |
+| page-codegen     | 互斥：生成新页面用 codegen，不要用 fix  |
+| template-extract | 无直接关系                              |
+
+---
+
+## 7. 转正前的开发任务
+
+- [ ] 沉淀至少 10 个 rule-based 修复模板
+- [ ] 设计 patch 内联格式（diff/unified）
+- [ ] 决定 lint/typecheck 失败的处理（默认回滚 + 标记，无须用户决策）
+- [ ] PR review 集成（修复完是否自动建 PR、是否分 commit）
+- [ ] 防御对抗性 prompt：用户能否引导 AI 顺手改业务逻辑？应在 SKILL.md 强制约束
+- [ ] 灰度策略：先支持单文件、再支持单 issue 组、最后批量