@gong-ym/ai-spec-auto 0.2.13 → 0.2.15

package/.agents/skills/common/dependency-impact-graph/SKILL.md

@@ -1,80 +1,80 @@
----
-name: dependency-impact-graph
-description: 分析 monorepo、多包仓库或单仓模块间的依赖关系，判断“改一个包、目录或文件会影响谁”，并给出回归测试范围与潜在消费者提醒。当用户说“改了这个包会影响谁”“依赖影响分析”“回归测试范围”时使用。
-compatibility: Requires a local repository workspace with dependency manifests, package/module boundaries, and source files available for static inspection.
----
-
-# 依赖影响分析
-
-## 使用时机
-
-当你需要：
-
-- 判断某个包、目录、文件改动的下游影响
-- 评估回归测试范围
-- 梳理 monorepo / workspace 的依赖关系
-
-## 核心原则
-
-- 先识别仓库结构，再建依赖图
-- 优先用依赖声明，其次用代码引用补边
-- 输出以“直接影响 / 间接影响 / 建议测试范围”为主
-- 不自动安装依赖、不自动改代码
-
-## 步骤 1：识别结构
-
-优先检查：
-
-- Node：`package.json`、`pnpm-workspace.yaml`、`lerna.json`
-- Rust：`Cargo.toml`
-- Go：`go.mod`
-
-若不是多包仓库，也可以退化为“单包内模块/目录影响分析”。
-
-## 步骤 2：建立依赖图
-
-依赖来源按优先级：
-
-1. 声明依赖
-2. 代码 import / require / 相对路径引用
-
-图的语义：
-
-- `A -> B` 表示 A 依赖 B
-- 当 B 被修改时，需要沿“谁依赖它”的方向做反向传播
-
-## 步骤 3：输出影响范围
-
-至少输出：
-
-- 变更目标
-- 直接依赖方
-- 间接依赖方
-- 建议回归测试范围
-- 潜在 API / SDK / 服务消费者
-
-## 输出模板
-
-```md
-## 依赖影响分析
-
-**变更目标**：`packages/shared-utils`
-
-### 受影响下游
-- 直接：`packages/web-app`、`packages/admin-app`
-- 间接：`packages/e2e-suite`
-
-### 建议回归测试范围
-- 必测：`packages/shared-utils`
-- 建议：`packages/web-app`、`packages/admin-app`
-
-### 消费者提醒
-- 内部消费者：
-- 外部发布面（若存在）：
-```
-
-## 注意事项
-
-- 单包仓库下要明确写“当前为单包分析”
-- 尽量区分运行时依赖与仅类型依赖
-- 若项目已有测试命令约定，可附命令示例，但不写死某个工具
+---
+name: dependency-impact-graph
+description: 分析 monorepo、多包仓库或单仓模块间的依赖关系，判断“改一个包、目录或文件会影响谁”，并给出回归测试范围与潜在消费者提醒。当用户说“改了这个包会影响谁”“依赖影响分析”“回归测试范围”时使用。
+compatibility: Requires a local repository workspace with dependency manifests, package/module boundaries, and source files available for static inspection.
+---
+
+# 依赖影响分析
+
+## 使用时机
+
+当你需要：
+
+- 判断某个包、目录、文件改动的下游影响
+- 评估回归测试范围
+- 梳理 monorepo / workspace 的依赖关系
+
+## 核心原则
+
+- 先识别仓库结构，再建依赖图
+- 优先用依赖声明，其次用代码引用补边
+- 输出以“直接影响 / 间接影响 / 建议测试范围”为主
+- 不自动安装依赖、不自动改代码
+
+## 步骤 1：识别结构
+
+优先检查：
+
+- Node：`package.json`、`pnpm-workspace.yaml`、`lerna.json`
+- Rust：`Cargo.toml`
+- Go：`go.mod`
+
+若不是多包仓库，也可以退化为“单包内模块/目录影响分析”。
+
+## 步骤 2：建立依赖图
+
+依赖来源按优先级：
+
+1. 声明依赖
+2. 代码 import / require / 相对路径引用
+
+图的语义：
+
+- `A -> B` 表示 A 依赖 B
+- 当 B 被修改时，需要沿“谁依赖它”的方向做反向传播
+
+## 步骤 3：输出影响范围
+
+至少输出：
+
+- 变更目标
+- 直接依赖方
+- 间接依赖方
+- 建议回归测试范围
+- 潜在 API / SDK / 服务消费者
+
+## 输出模板
+
+```md
+## 依赖影响分析
+
+**变更目标**：`packages/shared-utils`
+
+### 受影响下游
+- 直接：`packages/web-app`、`packages/admin-app`
+- 间接：`packages/e2e-suite`
+
+### 建议回归测试范围
+- 必测：`packages/shared-utils`
+- 建议：`packages/web-app`、`packages/admin-app`
+
+### 消费者提醒
+- 内部消费者：
+- 外部发布面（若存在）：
+```
+
+## 注意事项
+
+- 单包仓库下要明确写“当前为单包分析”
+- 尽量区分运行时依赖与仅类型依赖
+- 若项目已有测试命令约定，可附命令示例，但不写死某个工具

package/.agents/skills/common/execute-task/SKILL.md

@@ -1,206 +1,206 @@
----
-name: execute-task
-description: 当用户要求按 `tasks.md`、`/opsx:apply` 或同类任务清单开始实施时，严格按 Superpowers 四步执行具体开发任务并输出审计结果。
-compatibility: Requires tasks.md, local .agents/rules execution policies, and an ai-spec-auto/OpenSpec workspace with write access to task state.
-metadata:
-  version: "2.0.0"
-  openclaw-user-invocable: "true"
-  type: rigid
----
-
-# Superpowers 任务执行技能 (Task Execution Skill)
-
-> 本技能为**刚性技能**：严格遵循，不可简化步骤。每一步都必须产出可见的结构化输出。
-
-## 强制约束（NON-NEGOTIABLE）
-
-1. **四步必须完整执行**：每条任务必须依次经过四个步骤，禁止合并、跳过或简化任何一步。
-2. **每步必须有可见输出**：每个步骤必须以指定的 Markdown 标题开头输出（`### 第一步：头脑风暴`、`### 第二步：TDD 编码`、`### 第三步：双重审查`、`### 第四步：状态更新`），缺失标题即视为未执行该步骤。
-3. **步骤 1 的用户确认门禁不可跳过**：除非用户事先明确指示"批量执行"或"跳过确认"。
-4. **禁止直出代码**：绝对禁止未经步骤 1 思考就直接输出业务代码。
-
-## 触发条件
-
-当用户输入以下类似指令时，**必须**强制调用此技能：
-
-- "开始执行任务"
-- "按 tasks 开始写代码"
-- "应用变更 (Apply)"
-- "执行下一个 task"
-
-本技能也会被 `/opsx:apply` / `/opsx-apply` 命令自动触发。
-
-## 环境依赖
-
-- 依赖 `tasks.md`、`.agents/rules/12-Superpowers执行规范.md` 和 `.agents/rules/14-审计汇报规范.md`
-- 默认在 ai-spec-auto / OpenSpec 协议驱动仓库中运行
-
-## 注意事项
-
-- 未经过第一步确认，不得直接进入编码
-- 没有测试环境时也要明确记录 RED/GREEN/REFACTOR 的替代验证方式
-- 审计报告是强制产物，不能因为任务很小而省略
-
-## 前置要求
-
-1. 当前工作区必须存在 `tasks.md` 文件，且包含未完成的任务 (`- [ ]`)。
-2. 必须已完整读取对应变更目录下的 `proposal.md` 或 `design.md` 获取上下文。
-3. 必须已读取 `.agents/rules/12-Superpowers执行规范.md` 确认执行原则。
-4. 必须已读取 `.agents/rules/14-审计汇报规范.md` 确认审计报告格式。
-
----
-
-## 四步循环（每条任务必须完整执行）
-
-### 第一步：头脑风暴 (Brainstorm)
-
-**强制输出标题**：`### 第一步：头脑风暴`
-
-1. 读取 `tasks.md` 找到第一个未完成的 `- [ ]` 任务。
-2. 根据任务类型，按需读取对应的项目规范（见「规范按需引用表」）。
-3. **必须输出**以下内容（限 100 字以内）：
-   - **思路**：实现该任务的核心方案。
-   - **边界**：考虑到的边界情况和潜在风险。
-4. **用户确认门禁**：输出完成后，必须主动提问："我的思路是否正确？是否可以开始编写测试和代码？"。**等待用户明确同意后才能进入下一步。**
-
-**输出示例**：
-
-```text
-### 第一步：头脑风暴
-
-**任务**：创建 AppButton 全局组件
-**思路**：在 src/components/AppButton/ 下创建组件，使用 NutUI Button 封装，暴露 type/size/disabled 属性。
-**边界**：需处理 loading 状态防重复点击；需兼容 Taro 小程序端。
-
-→ 我的思路是否正确？是否可以开始编写测试和代码？
-```
-
-### 第二步：TDD 编码 (Red-Green-Refactor)
-
-**强制输出标题**：`### 第二步：TDD 编码`
-
-获得用户同意后，**必须输出** RED / GREEN / REFACTOR 三阶段的操作说明：
-
-1. **RED**：先创建或修改测试文件 / 类型定义，编写验证条件。
-2. **GREEN**：编写刚好能通过验证的最小必要业务逻辑代码。
-3. **REFACTOR**：清理冗余代码，确保符合 `.agents/rules/` 下的项目规范。
-
-**测试环境分级策略**：
-
-| 项目环境 | RED 阶段做什么 | 参考 |
-|----------|---------------|------|
-| 已配置 Vitest/Jest | 创建测试文件，编写失败测试用例 | `.agents/skills/create-test/SKILL.md` |
-| 有 TypeScript 但无测试框架 | 编写严格类型定义（interface/type），确保 tsc 通过 | — |
-| 纯 JavaScript 项目 | 编写 JSDoc 类型注释 + `console.assert` 运行时校验 | — |
-
-**输出示例**：
-
-```text
-### 第二步：TDD 编码
-
-**RED**：创建 src/components/AppButton/types.ts，定义 AppButtonProps 接口（type、size、disabled、loading、onClick）。
-**GREEN**：创建 src/components/AppButton/index.tsx，实现组件满足类型约束。
-**REFACTOR**：提取 barrel export 到 src/components/index.ts，对齐 04-组件规范.md。
-```
-
-### 第三步：双重审查 (Double Review)
-
-**强制输出标题**：`### 第三步：双重审查`
-
-代码编写完成后，**必须输出以下审查结论表格**（不可静默跳过、不可省略）：
-
-| 维度 | 检查项 | 结论 |
-|------|--------|------|
-| 架构对齐 | 实现是否符合 `design.md` / `specs/` | 通过 / 偏差说明 |
-| 代码健壮性 | 异常捕获、类型严谨、边界处理 | 通过 / 待补充项 |
-| 规范合规 | 是否符合步骤 1 加载的规范 | 通过 / 偏差说明 |
-
-如发现偏差，必须在进入步骤 4 前修正代码或说明原因。
-
-**输出示例**：
-
-```text
-### 第三步：双重审查
-
-| 维度 | 检查项 | 结论 |
-|------|--------|------|
-| 架构对齐 | 符合 design.md 组件拆分方案 | 通过 |
-| 代码健壮性 | Props 均有默认值，loading 防重复点击 | 通过 |
-| 规范合规 | 目录 PascalCase、barrel export（04-组件规范） | 通过 |
-```
-
-### 第四步：状态更新与审计汇报 (Update Status & Audit)
-
-**强制输出标题**：`### 第四步：状态更新`
-
-1. 修改 `tasks.md`，将完成的任务状态更新为 `- [x]`。
-2. 按 `.agents/rules/14-审计汇报规范.md` 的模板输出审计报告（五个区块）。
-3. 主动询问："是否继续执行下一个任务？"
-
----
-
-## 批量执行模式
-
-当用户明确指示"批量执行"、"不用逐步确认"或"全部执行"时：
-
-- 步骤 1 的用户确认门禁可跳过（但**仍须输出**头脑风暴标题和内容）
-- 步骤 2、3、4 **不可简化**，每步仍须有可见输出
-- 必须在审计报告区块 5 中注明："用户指示批量执行，跳过逐步确认"
-
----
-
-## 自我检查：危险信号
-
-当你产生以下想法时，**立即停下** — 你正在合理化跳过步骤：
-
-| 你的想法 | 事实 |
-|---------|------|
-| "这个任务很简单，不需要头脑风暴" | 再简单也要输出思路，30 字足够 |
-| "用户着急，我先写代码再补流程" | 流程是质量保证，不是额外负担 |
-| "测试框架没配置，跳过 TDD" | 用类型定义或 assert 兜底，不可跳过 RED 阶段 |
-| "审查没问题，不用写出来" | 必须输出审查表格，不可静默通过 |
-| "这几个任务类似，合并执行更高效" | 除非用户指示批量执行，否则逐条执行 |
-| "输出四个标题太啰嗦了" | 标题是合规证据，缺失即违规 |
-| "我可以把四步内容缩成一段" | 每步必须有独立标题，不可合并 |
-
----
-
-## 规范按需引用表
-
-在第一步头脑风暴阶段，根据当前 Task 涉及的内容，按需读取对应规范和技能：
-
-| 任务类型 | 应读取的规范 | 应读取的技能 |
-|----------|-------------|-------------|
-| 创建/修改组件 | `04-组件规范.md`、`09-样式规范.md` | `create-component`、`theme-variables` |
-| 新增/调整接口 | `05-API规范.md` | `create-api` |
-| 新增页面路由 | `06-路由规范.md`、`03-项目结构.md` | `create-route` / `create-view` |
-| 新增/重构状态 | `07-状态管理.md` | `create-store` |
-| 样式还原 | `09-样式规范.md` | `theme-variables`、`design-analysis` |
-| 编写测试 | `11-测试规范.md` | `create-test` |
-| 通用编码 | `02-编码规范.md`、`08-通用约束.md` | — |
-
-无需一次性全部加载。只读取与当前 Task 直接相关的规范，保持上下文精简。
-
----
-
-## 合规自检清单
-
-每条任务完成后（步骤 4 输出前），对照以下清单确认合规：
-
-- [ ] 输出了 `### 第一步：头脑风暴` 标题和内容
-- [ ] 输出了 `### 第二步：TDD 编码` 标题和 RED/GREEN/REFACTOR 说明
-- [ ] 输出了 `### 第三步：双重审查` 标题和审查结论表格
-- [ ] 输出了 `### 第四步：状态更新` 标题和审计报告
-- [ ] `tasks.md` 中对应任务已标记为 `- [x]`
-
-如有任何一项缺失，必须补充后再进入下一条任务。
-
----
-
-## 相关规范与技能
-
-- `.agents/rules/12-Superpowers执行规范.md` — 执行原则与约束（何时必须启用、何时可跳过）
-- `.agents/rules/14-审计汇报规范.md` — 审计报告格式与约束（第四步必须输出）
-- `.agents/skills/create-test/SKILL.md` — TDD RED 阶段创建测试文件的详细指导
-- `.agents/skills/create-proposal/SKILL.md` — 提案前置分析（OpenSpec 增强层，委托 `/opsx:propose` 产出 tasks.md）
-- `openspec/AGENTS.md` — OpenSpec 三阶段工作流说明
+---
+name: execute-task
+description: 当用户要求按 `tasks.md`、`/opsx:apply` 或同类任务清单开始实施时，严格按 Superpowers 四步执行具体开发任务并输出审计结果。
+compatibility: Requires tasks.md, local .agents/rules execution policies, and an ai-spec-auto/OpenSpec workspace with write access to task state.
+metadata:
+  version: "2.0.0"
+  openclaw-user-invocable: "true"
+  type: rigid
+---
+
+# Superpowers 任务执行技能 (Task Execution Skill)
+
+> 本技能为**刚性技能**：严格遵循，不可简化步骤。每一步都必须产出可见的结构化输出。
+
+## 强制约束（NON-NEGOTIABLE）
+
+1. **四步必须完整执行**：每条任务必须依次经过四个步骤，禁止合并、跳过或简化任何一步。
+2. **每步必须有可见输出**：每个步骤必须以指定的 Markdown 标题开头输出（`### 第一步：头脑风暴`、`### 第二步：TDD 编码`、`### 第三步：双重审查`、`### 第四步：状态更新`），缺失标题即视为未执行该步骤。
+3. **步骤 1 的用户确认门禁不可跳过**：除非用户事先明确指示"批量执行"或"跳过确认"。
+4. **禁止直出代码**：绝对禁止未经步骤 1 思考就直接输出业务代码。
+
+## 触发条件
+
+当用户输入以下类似指令时，**必须**强制调用此技能：
+
+- "开始执行任务"
+- "按 tasks 开始写代码"
+- "应用变更 (Apply)"
+- "执行下一个 task"
+
+本技能也会被 `/opsx:apply` / `/opsx-apply` 命令自动触发。
+
+## 环境依赖
+
+- 依赖 `tasks.md`、`.agents/rules/12-Superpowers执行规范.md` 和 `.agents/rules/14-审计汇报规范.md`
+- 默认在 ai-spec-auto / OpenSpec 协议驱动仓库中运行
+
+## 注意事项
+
+- 未经过第一步确认，不得直接进入编码
+- 没有测试环境时也要明确记录 RED/GREEN/REFACTOR 的替代验证方式
+- 审计报告是强制产物，不能因为任务很小而省略
+
+## 前置要求
+
+1. 当前工作区必须存在 `tasks.md` 文件，且包含未完成的任务 (`- [ ]`)。
+2. 必须已完整读取对应变更目录下的 `proposal.md` 或 `design.md` 获取上下文。
+3. 必须已读取 `.agents/rules/12-Superpowers执行规范.md` 确认执行原则。
+4. 必须已读取 `.agents/rules/14-审计汇报规范.md` 确认审计报告格式。
+
+---
+
+## 四步循环（每条任务必须完整执行）
+
+### 第一步：头脑风暴 (Brainstorm)
+
+**强制输出标题**：`### 第一步：头脑风暴`
+
+1. 读取 `tasks.md` 找到第一个未完成的 `- [ ]` 任务。
+2. 根据任务类型，按需读取对应的项目规范（见「规范按需引用表」）。
+3. **必须输出**以下内容（限 100 字以内）：
+   - **思路**：实现该任务的核心方案。
+   - **边界**：考虑到的边界情况和潜在风险。
+4. **用户确认门禁**：输出完成后，必须主动提问："我的思路是否正确？是否可以开始编写测试和代码？"。**等待用户明确同意后才能进入下一步。**
+
+**输出示例**：
+
+```text
+### 第一步：头脑风暴
+
+**任务**：创建 AppButton 全局组件
+**思路**：在 src/components/AppButton/ 下创建组件，使用 NutUI Button 封装，暴露 type/size/disabled 属性。
+**边界**：需处理 loading 状态防重复点击；需兼容 Taro 小程序端。
+
+→ 我的思路是否正确？是否可以开始编写测试和代码？
+```
+
+### 第二步：TDD 编码 (Red-Green-Refactor)
+
+**强制输出标题**：`### 第二步：TDD 编码`
+
+获得用户同意后，**必须输出** RED / GREEN / REFACTOR 三阶段的操作说明：
+
+1. **RED**：先创建或修改测试文件 / 类型定义，编写验证条件。
+2. **GREEN**：编写刚好能通过验证的最小必要业务逻辑代码。
+3. **REFACTOR**：清理冗余代码，确保符合 `.agents/rules/` 下的项目规范。
+
+**测试环境分级策略**：
+
+| 项目环境 | RED 阶段做什么 | 参考 |
+|----------|---------------|------|
+| 已配置 Vitest/Jest | 创建测试文件，编写失败测试用例 | `.agents/skills/create-test/SKILL.md` |
+| 有 TypeScript 但无测试框架 | 编写严格类型定义（interface/type），确保 tsc 通过 | — |
+| 纯 JavaScript 项目 | 编写 JSDoc 类型注释 + `console.assert` 运行时校验 | — |
+
+**输出示例**：
+
+```text
+### 第二步：TDD 编码
+
+**RED**：创建 src/components/AppButton/types.ts，定义 AppButtonProps 接口（type、size、disabled、loading、onClick）。
+**GREEN**：创建 src/components/AppButton/index.tsx，实现组件满足类型约束。
+**REFACTOR**：提取 barrel export 到 src/components/index.ts，对齐 04-组件规范.md。
+```
+
+### 第三步：双重审查 (Double Review)
+
+**强制输出标题**：`### 第三步：双重审查`
+
+代码编写完成后，**必须输出以下审查结论表格**（不可静默跳过、不可省略）：
+
+| 维度 | 检查项 | 结论 |
+|------|--------|------|
+| 架构对齐 | 实现是否符合 `design.md` / `specs/` | 通过 / 偏差说明 |
+| 代码健壮性 | 异常捕获、类型严谨、边界处理 | 通过 / 待补充项 |
+| 规范合规 | 是否符合步骤 1 加载的规范 | 通过 / 偏差说明 |
+
+如发现偏差，必须在进入步骤 4 前修正代码或说明原因。
+
+**输出示例**：
+
+```text
+### 第三步：双重审查
+
+| 维度 | 检查项 | 结论 |
+|------|--------|------|
+| 架构对齐 | 符合 design.md 组件拆分方案 | 通过 |
+| 代码健壮性 | Props 均有默认值，loading 防重复点击 | 通过 |
+| 规范合规 | 目录 PascalCase、barrel export（04-组件规范） | 通过 |
+```
+
+### 第四步：状态更新与审计汇报 (Update Status & Audit)
+
+**强制输出标题**：`### 第四步：状态更新`
+
+1. 修改 `tasks.md`，将完成的任务状态更新为 `- [x]`。
+2. 按 `.agents/rules/14-审计汇报规范.md` 的模板输出审计报告（五个区块）。
+3. 主动询问："是否继续执行下一个任务？"
+
+---
+
+## 批量执行模式
+
+当用户明确指示"批量执行"、"不用逐步确认"或"全部执行"时：
+
+- 步骤 1 的用户确认门禁可跳过（但**仍须输出**头脑风暴标题和内容）
+- 步骤 2、3、4 **不可简化**，每步仍须有可见输出
+- 必须在审计报告区块 5 中注明："用户指示批量执行，跳过逐步确认"
+
+---
+
+## 自我检查：危险信号
+
+当你产生以下想法时，**立即停下** — 你正在合理化跳过步骤：
+
+| 你的想法 | 事实 |
+|---------|------|
+| "这个任务很简单，不需要头脑风暴" | 再简单也要输出思路，30 字足够 |
+| "用户着急，我先写代码再补流程" | 流程是质量保证，不是额外负担 |
+| "测试框架没配置，跳过 TDD" | 用类型定义或 assert 兜底，不可跳过 RED 阶段 |
+| "审查没问题，不用写出来" | 必须输出审查表格，不可静默通过 |
+| "这几个任务类似，合并执行更高效" | 除非用户指示批量执行，否则逐条执行 |
+| "输出四个标题太啰嗦了" | 标题是合规证据，缺失即违规 |
+| "我可以把四步内容缩成一段" | 每步必须有独立标题，不可合并 |
+
+---
+
+## 规范按需引用表
+
+在第一步头脑风暴阶段，根据当前 Task 涉及的内容，按需读取对应规范和技能：
+
+| 任务类型 | 应读取的规范 | 应读取的技能 |
+|----------|-------------|-------------|
+| 创建/修改组件 | `04-组件规范.md`、`09-样式规范.md` | `create-component`、`theme-variables` |
+| 新增/调整接口 | `05-API规范.md` | `create-api` |
+| 新增页面路由 | `06-路由规范.md`、`03-项目结构.md` | `create-route` / `create-view` |
+| 新增/重构状态 | `07-状态管理.md` | `create-store` |
+| 样式还原 | `09-样式规范.md` | `theme-variables`、`design-analysis` |
+| 编写测试 | `11-测试规范.md` | `create-test` |
+| 通用编码 | `02-编码规范.md`、`08-通用约束.md` | — |
+
+无需一次性全部加载。只读取与当前 Task 直接相关的规范，保持上下文精简。
+
+---
+
+## 合规自检清单
+
+每条任务完成后（步骤 4 输出前），对照以下清单确认合规：
+
+- [ ] 输出了 `### 第一步：头脑风暴` 标题和内容
+- [ ] 输出了 `### 第二步：TDD 编码` 标题和 RED/GREEN/REFACTOR 说明
+- [ ] 输出了 `### 第三步：双重审查` 标题和审查结论表格
+- [ ] 输出了 `### 第四步：状态更新` 标题和审计报告
+- [ ] `tasks.md` 中对应任务已标记为 `- [x]`
+
+如有任何一项缺失，必须补充后再进入下一条任务。
+
+---
+
+## 相关规范与技能
+
+- `.agents/rules/12-Superpowers执行规范.md` — 执行原则与约束（何时必须启用、何时可跳过）
+- `.agents/rules/14-审计汇报规范.md` — 审计报告格式与约束（第四步必须输出）
+- `.agents/skills/create-test/SKILL.md` — TDD RED 阶段创建测试文件的详细指导
+- `.agents/skills/create-proposal/SKILL.md` — 提案前置分析（OpenSpec 增强层，委托 `/opsx:propose` 产出 tasks.md）
+- `openspec/AGENTS.md` — OpenSpec 三阶段工作流说明

package/.agents/skills/common/execute-task/evals/evals.json

@@ -1,16 +1,16 @@
-{
-  "skill_name": "execute-task",
-  "evals": [
-    {
-      "id": "execute-output-1",
-      "prompt": "根据 tasks.md 的第一条未完成任务进入执行，要求输出四步结构并在最后给出审计结论。",
-      "files": [],
-      "expected_output": "输出必须包含头脑风暴、TDD 编码、双重审查、状态更新四个步骤，并保留确认门槛。",
-      "assertions": [
-        "四步标题完整出现",
-        "第一步包含确认门禁",
-        "第四步包含审计/状态更新信息"
-      ]
-    }
-  ]
-}
+{
+  "skill_name": "execute-task",
+  "evals": [
+    {
+      "id": "execute-output-1",
+      "prompt": "根据 tasks.md 的第一条未完成任务进入执行，要求输出四步结构并在最后给出审计结论。",
+      "files": [],
+      "expected_output": "输出必须包含头脑风暴、TDD 编码、双重审查、状态更新四个步骤，并保留确认门槛。",
+      "assertions": [
+        "四步标题完整出现",
+        "第一步包含确认门禁",
+        "第四步包含审计/状态更新信息"
+      ]
+    }
+  ]
+}

package/.agents/skills/common/execute-task/evals/train_queries.json

@@ -1,18 +1,18 @@
-[
-  {
-    "query": "按 tasks.md 开始执行第一个任务",
-    "should_trigger": true
-  },
-  {
-    "query": "帮我应用这个 OpenSpec 变更",
-    "should_trigger": true
-  },
-  {
-    "query": "先生成一个提案",
-    "should_trigger": false
-  },
-  {
-    "query": "归档这个 change",
-    "should_trigger": false
-  }
-]
+[
+  {
+    "query": "按 tasks.md 开始执行第一个任务",
+    "should_trigger": true
+  },
+  {
+    "query": "帮我应用这个 OpenSpec 变更",
+    "should_trigger": true
+  },
+  {
+    "query": "先生成一个提案",
+    "should_trigger": false
+  },
+  {
+    "query": "归档这个 change",
+    "should_trigger": false
+  }
+]