القائمة
为缺少测试的已有项目渐进式补充多层自动化测试覆盖。Use when project has low or no test coverage and needs automated test generation.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
为当前项目初始化完整的 Harness Engineering 配置（Rules、Hooks、Constraints、QA 标准）。Use when bootstrapping a new project or adding harness to an existing project.
执行 5 层 QA 金字塔检查，生成量化验证报告。Use when completing a feature, before committing, or before creating a PR.
执行交付前 5 项复盘检查，确保流程合规和质量达标。Use when about to deliver work to users, before final handoff, or when completing a development cycle.
启动 Harness 任务（交互式收集需求，自动带上全部流程约束）。Use when starting a new feature, task, or any development work in a Harness-enabled project.
在 AI 工具内执行受控自动修复 loop。Use when tests, E2E, quality gate, or verification fails and the user expects the agent to fix and rerun instead of only reporting failure.
执行 Santa Method 双独立对抗验证。Use when reviewing high-risk changes, production deployments, or complex logic before shipping.
| name | auto-harness-test-bootstrap |
| description | 为缺少测试的已有项目渐进式补充多层自动化测试覆盖。Use when project has low or no test coverage and needs automated test generation. |
为缺少测试的已有项目建立多层自动化测试覆盖。AI 分析代码、生成测试、运行验证、迭代补充——用户只做验收。
这不是单纯“补几个测试文件”。SHK 在目标工程里的职责是完整链路：
AI 扫描项目，输出分析报告：
如果是新应用工程或 UI/API 相关任务，先跑后端识别器：
node scripts/shk.js spec status --risk medium --format json
node scripts/shk.js e2e inspect --format json
node scripts/shk.js e2e bootstrap --risk medium --format json
这两个命令是给 AI 读的，不是让用户背命令。AI 要根据输出判断：
.harness/iteration-spec.json，AI 要先补一份短 spec：需求、方案、风险、测试计划、流量路径、验收标准。测试分析报告
============
技术栈: [自动识别]
现有测试: [框架/覆盖率/数量，如果有]
建议测试框架: [根据技术栈推荐]
模块风险评估:
高风险: src/auth/（认证逻辑，无测试）
高风险: src/api/（对外接口，无测试）
中风险: src/utils/（工具函数，部分测试）
低风险: src/components/（展示组件）
建议优先级:
1. src/auth/ — 先补单元测试
2. src/api/ — 补集成测试
3. 关键页面 — 补 E2E 测试
→ 暂停，等用户确认优先级。
如果项目没有测试框架，AI 自动搭建：
→ 运行 smoke test 确认环境 OK。
如果项目没有 E2E，AI 必须进入 E2E bootstrap：
.harness/task-quality-contract.json；对每个模块，按 3 步循环：
Step 1: AI 读代码，理解现有行为
Step 2: 生成测试（覆盖正常路径 + 边界 + 错误处理）
Step 3: 运行测试
→ 全部通过 → 记录覆盖率，进入下一个模块
→ 有失败 → 分析原因：
- 测试写错了 → AI 修测试
- 发现真实 bug → 记录到 constraints.md（不自动修，等用户决定）
根据项目类型，逐层补充：
Layer 1 — 单元测试（最先补）
目标: 所有公开函数/方法
方法: AI 读函数签名和实现 → 生成测试 → 运行
覆盖: 正常输入、边界值、空值、异常输入
Layer 2 — 集成测试（API/数据库项目）
目标: API 端点、数据库操作、服务间调用
方法: AI 分析路由/ORM → 生成请求级测试
覆盖: 正常请求、参数校验、权限、错误码
Layer 3 — E2E 测试（有前端的项目）
目标: 关键用户流程
方法: AI 分析页面路由和交互 → 生成 Playwright 测试
覆盖: 核心路径（登录→操作→结果）、错误路径、响应式
E2E 生成后必须运行：
node scripts/shk.js e2e assess --risk medium --format json
node scripts/shk.js test effectiveness --risk medium --format json
如果结果是 NOT_READY 或 NOT_SUFFICIENT，不能交付。AI 最多进入 3 轮修复 loop，每轮只补一个失败点并重跑最小测试。
有效性证明必须包含 mutation 思路：故意破坏一个关键行为后，E2E 应该失败。坏代码下 E2E 也 PASS，说明这套 E2E 是摆设。
Layer 4 — a11y / 安全（按需）
目标: 无障碍合规、安全扫描
方法: axe-core 扫描、依赖审计、秘钥扫描
测试 Bootstrap 完成
===================
新增测试: [N] 个
单元测试: [n1]
集成测试: [n2]
E2E 测试: [n3]
a11y 测试: [n4]
覆盖率: [之前]% → [之后]%
发现的问题（未修复，等用户决定）:
1. [描述] — 记录在 C-XXX-01
2. [描述] — 记录在 C-XXX-02
下一步建议:
- 开启 CI 中的覆盖率检查（不低于当前值）
- 后续开发用 TDD 自然维持覆盖率
E2E 报告必须说人话：
这套 E2E 可以用于本轮准出。
它已经跑过核心正向流程，也跑过错误输入的拦截路径。我还把关键成功输出改坏试了一次，E2E 会失败。
机器状态：READY
如果不充分，必须直说：
现在还不能交付。
这套 E2E 只证明页面能打开，还没测到本次改动的业务路径，也没证明错误输入或阻断场景能被拦住。
我会先补一条业务正向路径和一条失败路径，再重跑最小 E2E。
机器状态：NOT_SUFFICIENT
AI 生成测试时可能发现现有代码的 bug。处理原则：