@gong-ym/ai-spec-auto 0.2.3

package/.agents/skills/common/branch-code-reviewer/references/business-risk-guide.md

@@ -0,0 +1,293 @@
+# 业务风险评估指南
+
+## 概述
+
+本指南帮助 AI 评审专家系统性地识别业务类风险,确保代码实现与需求文档一致。
+
+## 评估维度
+
+### 1. 需求覆盖度检查
+
+#### 检查清单
+
+- [ ] **功能完整性**: 需求文档中的所有功能点是否都已实现
+- [ ] **验收标准**: 是否满足需求文档中的验收标准
+- [ ] **业务规则**: 代码实现是否符合业务规则
+- [ ] **边界场景**: 需求文档中提到的边界场景是否都处理了
+- [ ] **异常流程**: 异常场景是否有对应处理逻辑
+
+#### 示例
+
+**需求文档**:
+> 用户下单时必须校验库存,库存不足时显示"暂时缺货"并禁止提交订单。
+
+**代码检查**:
+```javascript
+// ✅ 正确实现
+if (stock <= 0) {
+  showError('暂时缺货');
+  disableSubmit();
+}
+
+// ❌ 风险实现 - 缺少库存校验
+submitOrder(); // 直接提交,未检查库存
+```
+
+### 2. 业务流程完整性
+
+#### 常见业务流程
+
+**电商订单流程**:
+```
+浏览商品 → 加入购物车 → 确认订单 → 支付 → 发货 → 完成
+                ↓
+              取消订单 → 退款
+```
+
+**检查要点**:
+- 流程是否完整,有无缺失环节
+- 流程跳转是否正确
+- 异常流程是否处理(如支付失败、库存不足)
+
+#### 示例
+
+**风险场景**:
+```
+✅ 正常流程: 创建订单 → 支付 → 更新库存
+❌ 缺失流程: 支付失败 → 无处理逻辑
+```
+
+### 3. 状态流转一致性
+
+#### 常见状态机
+
+**订单状态流转**:
+```
+待支付 → 已支付 → 待发货 → 已发货 → 已完成
+  ↓                        ↓
+取消                     退款中 → 已退款
+```
+
+**检查要点**:
+- 状态流转是否符合需求文档
+- 是否存在非法状态跳转
+- 状态变更是否有对应业务逻辑
+
+#### 示例
+
+**风险场景**:
+```javascript
+// ❌ 风险: 状态从"待支付"直接跳到"已完成"
+order.status = 'completed'; // 缺少"已支付"状态
+
+// ✅ 正确: 按流程流转
+if (order.status === 'pending_payment' && payment.success) {
+  order.status = 'paid';
+  // 后续流程...
+}
+```
+
+### 4. 数据一致性
+
+#### 检查要点
+
+- **事务性**: 多个数据操作是否在同一事务中
+- **并发控制**: 是否存在并发安全问题
+- **数据校验**: 输入数据是否符合业务约束
+- **数据关联**: 关联数据是否同步更新
+
+#### 示例
+
+**风险场景**:
+```javascript
+// ❌ 风险: 库存扣减与订单创建不在同一事务
+await createOrder(orderData);
+await deductStock(productId, quantity);
+// 如果 createOrder 成功但 deductStock 失败,数据不一致
+
+// ✅ 正确: 使用事务
+await db.transaction(async (tx) => {
+  await createOrder(tx, orderData);
+  await deductStock(tx, productId, quantity);
+});
+```
+
+### 5. 权限与合规
+
+#### 检查要点
+
+- **身份认证**: 操作前是否校验用户身份
+- **权限控制**: 用户是否有权限执行该操作
+- **数据权限**: 用户只能访问自己的数据
+- **合规要求**: 是否符合法律法规(如隐私保护)
+
+#### 示例
+
+**风险场景**:
+```javascript
+// ❌ 风险: 未校验权限即可删除订单
+async function deleteOrder(orderId) {
+  await api.delete(`/orders/${orderId}`);
+}
+
+// ✅ 正确: 校验权限
+async function deleteOrder(orderId) {
+  const order = await getOrder(orderId);
+  if (order.userId !== currentUser.id) {
+    throw new Error('无权限操作');
+  }
+  await api.delete(`/orders/${orderId}`);
+}
+```
+
+### 6. 异常场景处理
+
+#### 常见异常场景
+
+- **网络异常**: 请求失败、超时、重试
+- **业务异常**: 库存不足、余额不足、状态不符
+- **系统异常**: 服务不可用、数据库连接失败
+- **用户异常**: 用户取消、用户退出
+
+#### 检查要点
+
+- 是否有错误提示
+- 是否有降级方案
+- 是否有重试机制
+- 是否有回滚逻辑
+
+#### 示例
+
+**风险场景**:
+```javascript
+// ❌ 风险: 支付失败无处理
+async function handlePayment() {
+  const result = await pay();
+  // 如果支付失败,无任何提示
+}
+
+// ✅ 正确: 完整的异常处理
+async function handlePayment() {
+  try {
+    const result = await pay();
+    if (result.success) {
+      showSuccess('支付成功');
+      navigateToOrderDetail();
+    } else {
+      showError(result.message);
+      enableRetry();
+    }
+  } catch (error) {
+    showError('支付失败,请重试');
+    enableRetry();
+    logError(error);
+  }
+}
+```
+
+## 风险等级判定标准
+
+### 🔴 严重(Critical)
+
+**判定标准**:
+- 缺失核心功能点
+- 业务流程错误
+- 数据一致性问题
+- 安全合规问题
+
+**处理建议**: 必须修复后才能上线
+
+### 🟡 警告(Warning)
+
+**判定标准**:
+- 缺少异常场景处理
+- 边界条件遗漏
+- 状态流转不完整
+- 用户体验问题
+
+**处理建议**: 建议修复后上线
+
+### 🔵 建议(Suggestion)
+
+**判定标准**:
+- 体验优化
+- 流程改进
+- 性能优化
+- 代码重构
+
+**处理建议**: 可在后续迭代中处理
+
+## 需求文档解析要点
+
+### 提取关键信息
+
+1. **业务目标**: 为什么要做这个功能
+2. **功能清单**: 需要实现哪些功能
+3. **业务规则**: 有什么约束条件
+4. **验收标准**: 怎样算完成
+5. **边界场景**: 有哪些特殊情况
+6. **异常流程**: 出错时怎么处理
+
+### 映射到代码
+
+| 需求文档内容 | 代码检查点 |
+|-------------|-----------|
+| "必须校验库存" | 库存校验逻辑 |
+| "支付失败显示错误提示" | 支付异常处理 |
+| "仅管理员可删除" | 权限校验 |
+| "3秒无响应显示loading" | loading 状态管理 |
+| "支持批量操作" | 批量处理逻辑 |
+
+## 输出格式要求
+
+每个业务风险必须包含:
+
+```markdown
+### [风险标题]
+
+**风险等级**: 🔴 严重 / 🟡 警告 / 🔵 建议
+**需求来源**: 需求文档章节引用
+**影响范围**: 影响的业务场景
+**问题描述**: 详细说明风险
+**修复建议**: 具体的修复方案
+**示例代码**: 修复后的代码示例(可选)
+```
+
+## 常见业务风险模式
+
+### 1. 缺失功能
+
+- 需求文档要求的功能未实现
+- 只实现了正常流程,缺少异常流程
+- 只实现了主流程,缺少分支流程
+
+### 2. 流程错误
+
+- 流程顺序错误
+- 缺少必要的流程环节
+- 流程跳转逻辑错误
+
+### 3. 状态管理混乱
+
+- 状态定义不完整
+- 状态流转不合法
+- 状态变更无业务逻辑支撑
+
+### 4. 数据不一致
+
+- 关联数据未同步
+- 操作非原子性
+- 缺少数据校验
+
+### 5. 权限漏洞
+
+- 未校验用户身份
+- 权限控制缺失
+- 数据权限泄露
+
+### 6. 异常处理不足
+
+- 无错误提示
+- 无降级方案
+- 无重试机制
+- 无回滚逻辑

package/.agents/skills/common/branch-code-reviewer/references/html-template-guide.md

@@ -0,0 +1,121 @@
+# 评审报告 HTML 模板参考
+
+## 报告结构示例
+
+本文件提供 HTML 报告的结构参考,实际生成时应动态填充数据。
+
+## 核心功能模块
+
+### 1. 概览面板
+
+应包含的统计指标:
+- 变更文件总数
+- 新增行数 / 删除行数
+- 提交次数
+- 技术风险总数(按等级分布)
+- 业务风险总数(按等级分布)
+- 需求覆盖度(如果有需求文档)
+- 整体通过率
+
+### 2. 文件树导航
+
+展示结构:
+```
+src/
+├── components/
+│   ├── OrderForm.vue (+120/-15) 🟡 2个风险
+│   └── PaymentButton.vue (+80/-0) 🔴 1个风险
+├── api/
+│   └── order.js (+200/-30) 🔵 3个建议
+└── utils/
+    └── validator.js (+50/-0) ⚪ 1个提示
+```
+
+### 3. 代码差异展示
+
+支持两种模式:
+- **Side-by-Side**: 左右对比
+- **Unified**: 统一显示
+
+颜色标记:
+- 绿色背景: 新增行
+- 红色背景: 删除行
+- 黄色背景: 修改行
+
+### 4. 技术风险列表
+
+每个风险项包含:
+```json
+{
+  "file": "src/components/OrderForm.vue",
+  "line": 45,
+  "severity": "critical",
+  "category": "security",
+  "title": "XSS 攻击风险",
+  "description": "用户输入未转义直接渲染到页面",
+  "suggestion": "使用 v-html 时应对内容进行转义处理",
+  "code": "<div v-html=\"userInput\"></div>",
+  "fixed_code": "<div>{{ userInput }}</div>"
+}
+```
+
+### 5. 业务风险列表
+
+每个业务风险项包含:
+```json
+{
+  "severity": "critical",
+  "category": "missing_feature",
+  "title": "缺少支付失败处理逻辑",
+  "description": "需求文档要求支付失败时显示错误提示并提供重试选项",
+  "requirement_ref": "docs/prd-order-module.md §4.2 支付流程",
+  "related_files": ["src/components/PaymentButton.vue"],
+  "suggestion": "添加支付失败的 catch 处理,显示错误提示",
+  "impact": "用户支付失败后无法继续操作,影响转化率"
+}
+```
+
+## 交互功能实现要点
+
+### 模式切换
+- 使用 JavaScript 切换 CSS class 实现
+- Side-by-Side: `display: grid; grid-template-columns: 1fr 1fr;`
+- Unified: `display: block;`
+
+### 主题切换
+- 使用 CSS 变量定义颜色
+- 通过切换 `data-theme="dark"` 属性实现
+- 使用 localStorage 保存用户偏好
+
+### 评论功能
+- 点击行号触发评论输入
+- 评论数据存储在 localStorage
+- 格式: `comments:{fileName}:{line}: [{user, content, timestamp}]`
+
+### 搜索功能
+- 使用正则表达式匹配文件名和代码内容
+- 高亮匹配结果
+- 支持上一个/下一个跳转
+
+### 过滤功能
+- 按文件类型过滤: `.vue`, `.js`, `.ts` 等
+- 按风险等级过滤: critical, warning, suggestion, info
+- 按风险类型过滤: technical, business
+
+## 性能优化建议
+
+1. **虚拟滚动**: 大量代码差异时使用虚拟滚动
+2. **懒加载**: 文件树展开时才加载子节点
+3. **代码折叠**: 默认折叠未变更区域
+4. **防抖搜索**: 搜索输入防抖 300ms
+5. **Web Worker**: 复杂计算(如代码分析)放到 Web Worker
+
+## 打印优化
+
+```css
+@media print {
+  .no-print { display: none; }
+  .diff-viewer { page-break-inside: avoid; }
+  .risk-item { page-break-inside: avoid; }
+}
+```

package/.agents/skills/common/config-and-secret-scan/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: config-and-secret-scan
+description: 统一配置项命名、分层与校验方式，并扫描代码与配置文件中的硬编码密钥、敏感信息或不安全配置。当用户说“检查配置”“新增配置项”“扫描敏感信息”“密钥泄露”“secret scan”“环境变量规范”时使用。
+compatibility: Requires access to a local repository workspace and project config files; designed for source scanning rather than remote-only review.
+---
+
+# 配置与敏感信息扫描
+
+## 使用时机
+
+当你需要：
+
+- 新增或调整环境变量、配置项、配置文档
+- 检查仓库里是否有硬编码 token、密码、API Key、证书片段
+- 对齐 `.env`、配置模块、启动校验的写法
+
+优先同时参考：
+
+- `.agents/rules/common/08-通用约束.md`
+- 当前项目已有的 `.env.example`、配置模块、启动入口
+
+## 核心原则
+
+- 配置名保持全大写、下划线分隔，避免写死业务前缀假设
+- 示例只写占位符，不写真实密钥
+- 先看项目已有配置约定，再补统一规范
+- 输出以位置、风险和修复建议为主，不做空泛安全口号
+- 若当前在协议流程中，优先把结果沉淀到当前 `checklist.md`、`risk-findings` 或用户指定文档，不写死固定输出目录
+
+## 配置规范
+
+### 命名与分层
+
+- 环境变量：如 `API_BASE_URL`、`LOG_LEVEL`、`ACCESS_TOKEN_TTL`
+- 按环境区分：`.env.development`、`.env.test`、`.env.production` 或配置中心 namespace
+- 新增配置项至少说明：
+  - 用途
+  - 类型
+  - 默认值
+  - 是否必填
+  - 缺失时的处理方式
+
+### 启动校验
+
+- 启动时校验关键配置，避免运行时才暴露缺失项
+- 端口、URL、布尔、枚举值应做最小格式校验
+- `.env.example` 只保留字段名、示例值或占位符
+
+## 扫描目标
+
+默认检查下列内容：
+
+- 硬编码密码：`password = "..."`、`pwd = "..."` 等
+- API Key / Token：`apiKey`、`token`、`secret`、`bearer`、`authorization`
+- 私钥或证书片段：`-----BEGIN`
+- 配置文件中的敏感字段：`.env`、`config.*`、`*.yaml`、`*.yml`
+- 明显不安全配置：关闭鉴权、跳过证书校验、生产环境默认弱口令
+
+## 排除项
+
+- `node_modules`、`dist`、`coverage`、缓存目录
+- `.env.example`、模板文档中的明确占位符
+- 测试假值：`dummy`、`test`、`example`、`your_xxx`
+
+## 输出格式
+
+按表格或清单输出：
+
+| 文件 | 行号 | 风险类型 | 片段 | 建议 |
+|------|------|----------|------|------|
+| `src/config/auth.ts` | `12` | `hardcoded-token` | `Bearer sk-***` | 改为从环境变量或密钥服务读取 |
+
+若没有发现问题，明确写：
+
+- 未发现疑似硬编码密钥或明显不安全配置
+
+## 执行步骤
+
+### 1. 识别当前任务
+
+- 若是“新增配置项”，先找现有配置模块、启动入口、`.env.example`
+- 若是“扫描敏感信息”，先确定扫描范围；未指定时默认扫描仓库源码与配置目录
+
+### 2. 读取项目事实
+
+- 查看 `package.json`、启动入口、配置模块
+- 判断项目是直接读 `process.env`、配置对象，还是走统一配置层
+
+### 3. 输出结果
+
+- 配置类需求：给出字段定义、示例、读取方式、校验建议
+- 扫描类需求：给出命中位置、风险说明、修复建议
+- 若在协议流程内，优先将结果归入当前审查/风险产物
+
+## 禁止事项
+
+- 不写入真实密钥
+- 不把占位符误判为真实泄露
+- 不忽略项目已有配置约定，自行发明另一套命名体系

package/.agents/skills/common/create-proposal/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: create-proposal
+description: 当用户需要为新需求、改版需求或补充方案发起 OpenSpec 提案时，在 `/opsx:propose` 前完成需求分析、上下文注入和提案后置检查。
+compatibility: Requires an OpenSpec workspace, local .agents/rules constraints, and repository paths such as openspec/changes/ and docs/样式还原/.
+---
+
+# 创建提案（OpenSpec 增强层）
+
+## 定位
+
+本技能是 OpenSpec `/opsx:propose` 的**增强层**，不替代、不干预 OpenSpec 的产物生成。
+
+职责划分：
+
+| 层 | 职责 | 产物位置 |
+|----|------|----------|
+| **本技能** | 需求前置分析 + 上下文注入 + 后置检查 | 无独立产物（分析结论注入 OpenSpec 上下文） |
+| **OpenSpec** | 生成 proposal.md / specs/ / design.md / tasks.md | `openspec/changes/<name>/` |
+| **config.yaml** | 桥接 ai-spec-auto  规范到 OpenSpec rules | `openspec/config.yaml` |
+
+## 使用时机
+
+当需要为一个**需求**创建提案时使用。需求可能是：
+
+- 新增/改版一个**页面**（有或没有设计稿）
+- 开发一系列**功能组件**（有或没有 UI 描述）
+- **有接口**或**无接口**（后端未就绪时用 mock）
+- 纯逻辑、纯接口、或 UI + 接口 等组合
+
+## 环境依赖
+
+- 依赖本仓库的 `openspec/` 目录、`.agents/rules/` 规范和相关命令约定
+- 设计稿分析与 UI 产物默认落到 `docs/样式还原/`
+- 会引用兄弟 skill 与 OpenSpec 命令，不适合作为脱离仓库的通用提案模板
+
+## 注意事项
+
+- 本技能只做提案增强，不替代 OpenSpec 原生产物生成
+- 复杂交互必须先整理交互摘要，不能把实现口径留到编码阶段临时补
+- 只要进入后置检查，就必须按审计汇报规范输出结论
+
+---
+
+## 步骤 1：需求前置分析
+
+在委托 OpenSpec 生成提案之前，先确认下列条件，作为传递给 OpenSpec 的上下文。
+
+| 条件 | 选项 | 影响 |
+|------|------|------|
+| **是否有设计稿或 UI 要求描述** | 有 / 无 | 有 → 步骤 2 触发 design-analysis；OpenSpec 的 tasks 中应包含 UI 验收任务 |
+| **是否有接口（已提供或约定）** | 有 / 无 / 未就绪 | 有 → 正常对接；无 → 可不做数据层；未就绪 → mock，见项目 Mock 数据策略 |
+| **交付形态** | 新页面 / 功能组件 / 能力模块 / 其它 | 决定目录结构（routes vs components）与 OpenSpec design.md 中的技术方案 |
+| **是否仅样式/还原类** | 是 / 否 | 是 → 重点在 design-analysis + 验收 |
+| **是否存在复杂交互** | 有 / 无 | 有 → 先按 `references/interaction-spec-template.md` 收口搜索、表单、弹窗、批量操作等交互说明，再写 proposal/design/tasks |
+
+---
+
+## 步骤 2：设计稿分析（可选但推荐）
+
+当需求**包含界面**且**有设计稿**（.pen、figma 链接、设计图、标注）或**有明确 UI 描述**时：
+
+- **使用技能**：`.agents/skills/design-analysis/SKILL.md`
+- **产出**：`docs/样式还原/<名称>-UI分析清单.md`
+
+分析清单应在 OpenSpec 生成提案前或同步完成，以便 OpenSpec 的 specs/、design.md、tasks.md 能引用分析结果。
+
+若页面包含搜索、表单、弹窗、批量操作、复杂状态切换等交互，先参考 `references/interaction-spec-template.md` 把交互说明整理成摘要，再写入 `proposal.md / design.md / tasks.md`，避免实现阶段自己补口径。
+
+---
+
+## 步骤 3：委托 OpenSpec 生成提案
+
+将步骤 1-2 的分析结论整合为变更描述，调用 `/opsx:propose <change-name>`。
+
+OpenSpec 会在 `openspec/changes/<change-name>/` 下生成原生产物：
+
+```
+openspec/changes/<change-name>/
+├── .openspec.yaml      # 变更元数据
+├── proposal.md         # 变更概述（why + what + impact）
+├── specs/              # Delta specs（新增/修改/删除的需求）
+│   └── <domain>/
+│       └── spec.md
+├── design.md           # 技术设计（方案选型、组件拆分、数据结构）
+└── tasks.md            # 实施任务清单
+```
+
+**上下文注入**：OpenSpec 通过 `openspec/config.yaml` 中的 `context` 和 `rules` 字段自动读取 ai-spec-auto  的规范约束（路由、组件、API、样式等），无需本技能额外干预。
+
+**传递给 OpenSpec 的信息**（作为 propose 描述的一部分）：
+- 步骤 1 确认的条件（交付形态、接口情况、设计稿情况）
+- 步骤 2 产出的 UI 分析清单路径（如有）
+- 涉及 UI 时：组件放置位置建议（依据 `.agents/rules/04-组件规范.md`）
+- 涉及接口时：接口结构建议（依据 `.agents/rules/05-API规范.md`）
+- 接口未就绪时：标注 mock 策略
+
+---
+
+## 步骤 4：后置检查与增强
+
+OpenSpec 生成提案后，检查以下项目并按需补充：
+
+### 4.1 design.md 检查
+- 技术方案是否遵循 `.agents/rules/` 中的架构约束
+- 涉及页面时，是否参考了 `.agents/rules/06-路由规范.md`
+- 涉及组件时，是否参考了 `.agents/rules/04-组件规范.md`
+- 样式方案是否使用主题变量（`.agents/rules/09-样式规范.md`）
+
+### 4.2 tasks.md 检查
+- 涉及 UI 且有设计稿时，末尾是否包含 UI 还原验收任务（引用 `.agents/skills/ui-verification/SKILL.md`）
+- 涉及接口时，是否包含接口封装任务（引用 `.agents/rules/05-API规范.md`）
+- 图标/图片未定时，是否标注占位元素（`.agents/rules/08-通用约束.md`）
+- 有 UI 分析清单时，开发任务是否引用 `docs/样式还原/<名称>-UI分析清单.md`
+- 存在复杂交互时，是否把搜索、表单、弹窗、批量操作和异常状态写成明确任务项，而不是只留一句“完善交互”
+
+### 4.3 specs/ 检查
+- 每个 capability 的验收场景是否可测试
+- 有设计稿时，是否引用 UI 分析清单作为验收参考
+
+### 4.4 执行交接与审计（提案阶段）
+
+- 提案确认后进入执行阶段时，遵循 `.agents/rules/12-Superpowers执行规范.md`，按 `.agents/skills/execute-task/SKILL.md` 的四步循环逐条执行 `openspec/changes/<change-name>/tasks.md`，或通过 IDE/OpenSpec 的 apply 命令进入同一执行链路。
+- **本步骤 4 后置检查完成、向用户交付分析摘要与检查结果时**，须遵守 `.agents/rules/14-审计汇报规范.md`（适用范围含「完成 create-proposal 后置检查」）。执行阶段的审计要求见 **4.5** 中与方案一、方案二的衔接说明。
+
+### 4.5 输出模板：下一步（必选）
+
+OpenSpec 生成提案且本步骤 4 检查完毕后，**必须**以独立小节 **「下一步」** 输出以下内容（将 `<change-name>` 替换为实际变更目录名，如 `add-simple-input`）。
+
+#### 4.5.1 如何写对 apply 命令（IDE 启发式）
+
+无法从仓库自动检测 IDE；按本轮对话线索选用主推命令，**无法判断时并列整张对照表**：
+
+| 情况 | 主推命令 |
+|------|----------|
+| 用户已使用 `/opsx-propose`、`/opsx-apply` 等**连字符**命令 | `/opsx-apply <change-name>`（Cursor / Windsurf / Copilot IDE 等） |
+| 用户使用 `/opsx:propose`、`/opsx:apply` 等**冒号**命令 | `/opsx:apply <change-name>`（Claude Code） |
+| **无法判断** | 并列给出：Claude Code → `/opsx:apply <change-name>`；Cursor / Windsurf / Copilot IDE → `/opsx-apply <change-name>`；Trae → `/openspec-apply <change-name>`（与 `docs/openspec-guide.md` §7.4 一致） |
+
+另附一句：若使用 **OpenSpec CLI** 本地 `openspec apply`，与上述 apply 流程语义一致，不替代各 IDE 中的斜杠命令。
+
+#### 4.5.2 方案一：Superpowers + execute-task（推荐）
+
+向用户提供**可复制**的提示语（可整段粘贴到新会话）：
+
+> 请使用 execute-task 技能，以 `openspec/changes/<change-name>/tasks.md` 为准，从第一条未勾选 `- [ ]` 开始，按 Superpowers 四步（头脑风暴 → TDD → 双重审查 → 状态更新）逐条执行；必要时先执行 `/opsx-apply <change-name>`（Cursor 等）或 `/opsx:apply <change-name>`（Claude Code）。执行须遵守 `.agents/rules/12-Superpowers执行规范.md` 与 `.agents/rules/14-审计汇报规范.md`（第四步状态更新含审计报告）。
+
+技能路径：`.cursor/skills/common/execute-task/SKILL.md` 或 `.agents/skills/common/execute-task/SKILL.md`。
+
+#### 4.5.3 方案二：仅按 tasks.md 清单
+
+适合小改动或用户明确要求「快扫清单」、不强制每步输出四步标题时，提供**可复制**提示语：
+
+> 请直接按 `openspec/changes/<change-name>/tasks.md` 顺序逐项实现，每完成一项将对应 `- [ ]` 改为 `- [x]`，并保证与 `design.md`、`specs/` 一致。**凡产生代码变更**，仍须按 `.agents/rules/14-审计汇报规范.md` 输出审计报告，不得因未走 execute-task 四步而省略。
+
+#### 4.5.4 可选说明
+
+若用户只需子集（例如仅改导出、仅改单文件），可提示其用一句话收窄范围，并仍指向同一 `tasks.md` 或具体条目。
+
+#### 4.5.5 审计汇报（跨阶段小结）
+
+在「下一步」小节末尾用一两句汇总：**提案阶段**后置检查交付已适用 `14-审计汇报规范.md`；**执行阶段**每条任务或批量实现后的审计要求不变，与方案一、方案二中的引用一致。
+
+---
+
+## 样式还原验证检查清单（供 create-route / create-component 引用）
+
+当开发涉及 **UI 还原**（有设计稿或分析清单）时，可对照以下检查项自检；更完整项见 `docs/样式还原/<名称>-UI分析清单.md` 中的「验证检查清单」。
+
+**布局**：区域位置、尺寸、间距是否与分析清单/设计稿一致；对齐方式（如 flex-start vs center）是否正确。  
+**样式**：颜色、字体、字号、字重、圆角、边框、阴影、效果（如 backdrop-filter）是否一致。  
+**元素**：是否缺少区块、图标、占位图；占位尺寸与比例是否正确。  
+**交互**：默认/hover/active 等状态是否还原（若有设计）。
+
+create-route、create-component 等技能中「涉及 UI 还原时」可引用：`.agents/skills/create-proposal/SKILL.md` 中的「样式还原验证检查清单」及对应页面的 `docs/样式还原/<名称>-UI分析清单.md`。
+
+---
+
+## 相关规范与技能
+
+- `.agents/rules/03-项目结构.md` - 目录结构、Mock 数据策略
+- `.agents/rules/04-组件规范.md` - 组件放置决策
+- `.agents/rules/05-API规范.md` - 接口封装
+- `.agents/rules/06-路由规范.md` - 路由结构
+- `.agents/rules/08-通用约束.md` - 占位元素等
+- `.agents/rules/09-样式规范.md` - 设计稿颜色提取、主题变量
+- `.agents/rules/12-Superpowers执行规范.md` - 执行原则
+- `.agents/rules/14-审计汇报规范.md` - 后置检查交付与执行任务后的审计报告
+- `.agents/skills/execute-task/SKILL.md` - Superpowers 四步循环执行
+- `.agents/skills/design-analysis/SKILL.md` - 设计稿分析（有设计稿时使用，产出 UI 分析清单）
+- `.agents/skills/ui-verification/SKILL.md` - UI 验收（实现后需验收时使用）
+- `references/interaction-spec-template.md` - 搜索、表单、弹窗、批量操作等复杂交互的摘要模板
+- `openspec/config.yaml` - OpenSpec 配置（含 ai-spec-auto  上下文注入）