@gong-ym/ai-spec-auto 0.2.3

package/.agents/skills/common/create-proposal/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "create-proposal",
+  "evals": [
+    {
+      "id": "proposal-output-1",
+      "prompt": "用户要发起一个带设计稿和未就绪接口的新页面需求，请给出提案前置分析、上下文注入重点和后置检查项。",
+      "files": [],
+      "expected_output": "输出应覆盖设计稿、接口状态、交付形态、复杂交互、后置检查和下一步 apply/execute-task 提示。",
+      "assertions": [
+        "说明何时触发 design-analysis",
+        "明确 mock 与真实接口边界",
+        "包含后置检查与下一步建议"
+      ]
+    }
+  ]
+}

package/.agents/skills/common/create-proposal/evals/train_queries.json

@@ -0,0 +1,18 @@
+[
+  {
+    "query": "帮我给这个新页面需求起一个 OpenSpec 提案",
+    "should_trigger": true
+  },
+  {
+    "query": "我要发起一个包含 UI 和接口的需求 proposal",
+    "should_trigger": true
+  },
+  {
+    "query": "开始按 tasks.md 写代码",
+    "should_trigger": false
+  },
+  {
+    "query": "把这个变更归档",
+    "should_trigger": false
+  }
+]

package/.agents/skills/common/create-proposal/evals/validation_queries.json

@@ -0,0 +1,18 @@
+[
+  {
+    "query": "在 /opsx:propose 之前先帮我梳理需求和设计稿输入",
+    "should_trigger": true
+  },
+  {
+    "query": "我要新增一个带 mock 数据的页面提案",
+    "should_trigger": true
+  },
+  {
+    "query": "执行下一个开发任务",
+    "should_trigger": false
+  },
+  {
+    "query": "检查页面和设计稿差异",
+    "should_trigger": false
+  }
+]

package/.agents/skills/common/create-proposal/references/interaction-spec-template.md

@@ -0,0 +1,42 @@
+# 交互说明模板
+
+当需求包含搜索、表单、弹窗、批量操作、复杂状态切换等交互时，可先按这份模板收口，再写入 `proposal / design / tasks`。
+
+```md
+## 交互说明
+
+### 页面概述
+- 目标：
+- 入口：
+- 关键用户路径：
+
+### 布局与区域
+- 主区域：
+- 次区域：
+- 响应式注意点：
+
+### 关键交互
+#### 搜索 / 筛选
+- 字段：
+- 查询时机：
+- 重置行为：
+
+#### 表单 / 弹窗
+- 打开条件：
+- 校验规则：
+- 提交成功 / 失败反馈：
+
+#### 列表 / 批量操作
+- 批量选择：
+- 空态 / 加载态 / 错误态：
+- 分页与筛选联动：
+
+### 数据与状态
+- 数据来源：
+- mock / 真实接口边界：
+- 本地状态与全局状态分工：
+
+### 验收关注点
+- 用户是否能完成关键路径：
+- 是否存在易错或易漏状态：
+```

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

@@ -0,0 +1,292 @@
+---
+name: create-test
+description: 当需要为功能模块编写单元测试或集成测试时使用本技能。指导按团队规范创建 Vitest 测试文件，涵盖命名约定、断言模式、Mock 策略与覆盖率要求。
+compatibility: Assumes a local TypeScript/JavaScript repository with Vitest-compatible tooling and .agents/rules/common testing conventions.
+---
+
+# 创建测试
+
+## 使用时机
+
+当出现以下场景时使用本技能：
+
+- 为新增的工具函数、Store 逻辑、数据转换编写**单元测试**
+- 为关键用户交互流程编写**组件测试**或**集成测试**
+- 重构现有模块后需补充或更新测试用例
+- `execute-task` 技能中 TDD 落地编码阶段需要创建测试文件
+
+## 环境依赖
+
+- 默认面向本仓库的 `.agents/rules/common/11-测试规范.md`
+- 示例以 Vitest 为主，若项目测试栈不同，需要按项目实际工具调整
+
+## 注意事项
+
+- 不要为了“补覆盖率”去 mock 被测模块内部逻辑
+- 测试文件应跟随真实代码落点，不要新造一套平行目录
+- 组件测试只在项目已具备对应测试运行条件时再补
+
+---
+
+## 步骤
+
+### 步骤 1：确认测试目标与类型
+
+1. 明确被测模块：工具函数、Store、组件、业务逻辑。
+2. 确定测试级别：
+
+| 级别 | 适用对象 | 说明 |
+|------|----------|------|
+| 单元测试 | 工具函数、纯逻辑、数据转换 | 隔离测试单个函数/模块的输入输出 |
+| 组件测试 | UI 组件交互 | 使用 `@testing-library/react` 或 `@vue/test-utils` |
+| 集成测试 | 多模块协作流程 | 验证模块间协作的正确性 |
+
+### 步骤 2：创建测试文件
+
+1. 在被测源文件**同目录**下创建测试文件。
+2. 文件命名：`<源文件名>.test.ts`（逻辑）或 `<源文件名>.test.tsx`（React 组件）。
+3. 导入 Vitest API 与被测模块。
+
+```text
+src/utils/
+├── formatDate.ts
+└── formatDate.test.ts       # 与源文件同目录
+```
+
+### 步骤 3：编写测试用例
+
+按 **Arrange-Act-Assert** 模式编写每个测试：
+
+1. **Arrange**：准备测试数据和前置条件。
+2. **Act**：调用被测函数或触发被测行为。
+3. **Assert**：断言结果符合预期。
+
+```ts
+import { describe, it, expect } from 'vitest';
+import { formatDate } from './formatDate';
+
+describe('formatDate', () => {
+  it('应将时间戳转换为 YYYY-MM-DD 格式', () => {
+    const timestamp = 1700000000000;
+    const result = formatDate(timestamp);
+    expect(result).toBe('2023-11-15');
+  });
+
+  it('传入 null 时应返回空字符串', () => {
+    expect(formatDate(null)).toBe('');
+  });
+
+  it('传入 undefined 时应返回空字符串', () => {
+    expect(formatDate(undefined)).toBe('');
+  });
+});
+```
+
+### 步骤 4：补充边界与异常用例
+
+每个被测函数至少覆盖：
+
+- **正常路径**：典型输入的预期输出
+- **边界值**：空值、零值、极大/极小值、空数组/空对象
+- **异常输入**：类型错误、格式异常、非法参数
+- **特殊场景**：并发、超时等（视业务而定）
+
+### 步骤 5：运行测试并确认通过
+
+```bash
+npx vitest run <测试文件路径>
+```
+
+确认所有用例通过后，再提交代码。
+
+---
+
+## 命名约定
+
+### 文件命名
+
+| 类型 | 命名规则 | 示例 |
+|------|----------|------|
+| 逻辑/工具测试 | `<name>.test.ts` | `formatDate.test.ts` |
+| React 组件测试 | `<name>.test.tsx` | `UserCard.test.tsx` |
+| Vue 组件测试 | `<name>.test.ts` | `UserCard.test.ts` |
+| 公共 Mock / 辅助 | 放置于 `tests/` 或 `src/__tests__/helpers/` | `tests/mocks/mockUser.ts` |
+
+### 描述命名
+
+- `describe` 块：使用被测模块名称（函数名、组件名、Store 名）
+- `it` / `test` 块：使用**中文**描述预期行为，格式为「应……」或「当……时应……」
+- 描述表达**预期行为**，而非实现步骤
+
+```ts
+describe('useAuthStore', () => {
+  it('登录成功后应保存用户信息到 state', () => { /* ... */ });
+  it('token 过期时应自动清除登录状态', () => { /* ... */ });
+  it('当网络异常时应抛出错误并保持原状态', () => { /* ... */ });
+});
+```
+
+---
+
+## 测试模式
+
+### 单元测试模式
+
+隔离测试纯函数，不依赖外部环境：
+
+```ts
+describe('calculateTotal', () => {
+  it('应正确计算商品总价', () => {
+    const items = [
+      { price: 10, quantity: 2 },
+      { price: 20, quantity: 1 },
+    ];
+    expect(calculateTotal(items)).toBe(40);
+  });
+
+  it('空数组应返回 0', () => {
+    expect(calculateTotal([])).toBe(0);
+  });
+});
+```
+
+### Mock 策略
+
+遵循原则：**Mock 外部依赖，不 Mock 被测模块内部。**
+
+#### API 请求 Mock
+
+```ts
+import { vi } from 'vitest';
+import { fetchUser } from './api';
+
+vi.mock('./api', () => ({
+  fetchUser: vi.fn(),
+}));
+
+describe('UserService', () => {
+  it('应正确处理用户数据', async () => {
+    vi.mocked(fetchUser).mockResolvedValue({ id: 1, name: '张三' });
+    const result = await getUserInfo(1);
+    expect(result.name).toBe('张三');
+  });
+
+  it('接口异常时应抛出错误', async () => {
+    vi.mocked(fetchUser).mockRejectedValue(new Error('网络错误'));
+    await expect(getUserInfo(1)).rejects.toThrow('网络错误');
+  });
+});
+```
+
+#### 定时器 Mock
+
+```ts
+import { vi, beforeEach, afterEach } from 'vitest';
+
+beforeEach(() => {
+  vi.useFakeTimers();
+});
+
+afterEach(() => {
+  vi.useRealTimers();
+});
+
+it('防抖函数应在延迟后执行', () => {
+  const fn = vi.fn();
+  const debounced = debounce(fn, 300);
+
+  debounced();
+  expect(fn).not.toHaveBeenCalled();
+
+  vi.advanceTimersByTime(300);
+  expect(fn).toHaveBeenCalledOnce();
+});
+```
+
+#### 模块 Mock
+
+```ts
+vi.mock('@/utils/storage', () => ({
+  getItem: vi.fn(),
+  setItem: vi.fn(),
+}));
+```
+
+### 组件测试模式（React）
+
+```tsx
+import { render, screen, fireEvent } from '@testing-library/react';
+
+describe('SearchInput', () => {
+  it('输入关键词后应触发搜索回调', async () => {
+    const onSearch = vi.fn();
+    render(<SearchInput onSearch={onSearch} />);
+
+    const input = screen.getByTestId('search-input');
+    await fireEvent.change(input, { target: { value: '测试' } });
+    await fireEvent.click(screen.getByTestId('search-btn'));
+
+    expect(onSearch).toHaveBeenCalledWith('测试');
+  });
+});
+```
+
+### 组件测试模式（Vue）
+
+```ts
+import { mount } from '@vue/test-utils';
+
+describe('SearchInput', () => {
+  it('输入关键词后应触发搜索事件', async () => {
+    const wrapper = mount(SearchInput);
+
+    await wrapper.find('[data-testid="search-input"]').setValue('测试');
+    await wrapper.find('[data-testid="search-btn"]').trigger('click');
+
+    expect(wrapper.emitted('search')?.[0]).toEqual(['测试']);
+  });
+});
+```
+
+---
+
+## 禁止模式
+
+| 禁止项 | 原因 |
+|--------|------|
+| 测试依赖执行顺序 | 测试应互相独立，可单独运行 |
+| 快照测试滥用 | 仅用于关键 UI 结构，禁止对大段 HTML 做快照 |
+| 硬编码延时（`setTimeout`） | 使用 `vi.useFakeTimers()` 或 `waitFor` |
+| Mock 被测模块内部方法 | 只 Mock 外部依赖 |
+| 断言内部状态或私有变量 | 测试行为而非实现 |
+| `data-testid` 以外的元素定位 | 禁止依赖 CSS class 或 DOM 结构 |
+
+---
+
+## 检查清单
+
+完成测试编写后，逐条确认以下事项：
+
+- [ ] **文件位置**：测试文件与源文件在同一目录下
+- [ ] **文件命名**：遵循 `<name>.test.ts` / `<name>.test.tsx` 命名规则
+- [ ] **describe 命名**：使用被测模块名称作为 describe 描述
+- [ ] **it 描述**：使用中文描述预期行为（「应……」「当……时应……」）
+- [ ] **AAA 模式**：每个测试用例遵循 Arrange-Act-Assert 结构
+- [ ] **每个 it 单一职责**：每个 `it` 只验证一个行为点
+- [ ] **正常路径覆盖**：典型输入场景已测试
+- [ ] **边界值覆盖**：空值、零值、极值等已测试
+- [ ] **异常输入覆盖**：非法参数、类型错误等已测试
+- [ ] **Mock 合理性**：仅 Mock 外部依赖，未 Mock 被测模块内部
+- [ ] **元素定位**：组件测试使用 `data-testid` 定位元素
+- [ ] **测试独立性**：每个测试可单独运行，不依赖执行顺序
+- [ ] **测试通过**：所有用例通过 `vitest run`
+- [ ] **类型检查**：`tsc --noEmit` 无报错
+
+---
+
+## 相关规范
+
+- `.agents/rules/common/11-测试规范.md` — 测试框架选型、文件约定、编写规范与质量门禁
+- `.agents/rules/common/02-编码规范.md` — 通用编码规范
+- `.agents/rules/common/08-通用约束.md` — 中文描述等通用约束
+- `.agents/skills/common/execute-task/SKILL.md` — TDD 落地编码阶段引用本技能

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

@@ -0,0 +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`
+
+### 消费者提醒
+- 内部消费者：
+- 外部发布面（若存在）：
+```
+
+## 注意事项
+
+- 单包仓库下要明确写“当前为单包分析”
+- 尽量区分运行时依赖与仅类型依赖
+- 若项目已有测试命令约定，可附命令示例，但不写死某个工具

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

@@ -0,0 +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 三阶段工作流说明

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

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