Harness 是一个面向编码智能体的技能，目标是构建让智能体工作值得信任的验证基础设施。
用途
Harness 用于为代码仓库搭建和改善验证基础设施。它的典型适用场景是：仓库没有可启动的开发环境、没有真实界面、缺少能让智能体证明自己工作成果的机制。当需要让编码智能体在真实环境中被验证，而不是仅靠提示词或口头约定时，可使用该技能。
核心理念
- 环境 > 指令：harness 比提示词更重要。
- 机械执行 > 文字说明：钩子、CI、健康检查和脚本胜过愿望式描述。
- 构建者与评判者分离：harness 搭建验证台，verify 使用它。
- 最小可用 harness 优先：按顺序添加层级，当仓库变得可靠可验证时即停止。
- 渐进式披露：核心工作流保留在此，按需加载模式。
7 层堆栈
- Boot——用单条命令启动应用。
- Smoke——快速证明应用存活。
- Interact——智能体可以操作真实界面。
- E2e——关键用户流程端到端可用。
- Enforce——钩子、CI 门禁、lint 规则或机械检查。
- Observe——日志、健康端点、追踪、机器可读信号。
- Isolate——worktree 或容器互不冲突。
使用方式（工作流程）
1. 审计
按以下维度给仓库评分：bootable、testable、observable、verifiable。每个维度报告：
- status：pass / partial / fail
- evidence：文件或命令
- gap：缺失内容 使用 references/grading.md。最低的维度决定整体等级。
2. 设置
按以下顺序构建缺失的层：Boot → Smoke → Interact → E2e → Enforce → Observe → Isolate。每一步都应独立有用。一旦仓库可靠可验证即停止；不要因兴奋而建造大教堂式的过度工程。
3. 改进
收紧薄弱或不稳定的层：
- 移除仅靠 mock 的「信心表演」
- 用可复用脚本或钩子替换一次性检查
- 添加智能体可查询的日志和健康信号
- 当智能体碰撞真实存在时，让并行工作安全
4. 移交
当仓库达到 C+ 并能被诚实评判时，移交给 verify。如果 harness 变更造成文档漂移，移交给 docs。
分派规则
- 需要在真实界面评审 diff、分支或 PR → 使用 verify
- 需要更新 AGENTS.md、README.md、specs 或仓库文档 → 使用 docs
反模式
- 仅靠 mock 的测试——按构造通过，实际什么都没验证
- 自我评估——构建者为自己的工作打分
- 把文档修复伪装成 harness 工作
- 在此做常规 PR 评审——那是 verify 的职责
- 一开始就追求完美 harness——应从真实失败模式迭代
输出
完成 harness 工作后，报告：
- 工作前后的等级
- 各维度及证据
- 变更的文件
- 按影响排序的剩余缺口
- verify 就绪状态
- 建议的下一步移交：verify、docs 或人工评审
参考资料
- references/grading.md——harness 质量评级量表，含机械性标准
- references/setup-patterns.md——boot、smoke、e2e、可观测性与隔离模式
- references/industry-examples.md——外部模式及对 harness 投入的论证
限制
关于该技能的收费、价格、平台支持情况，资料中暂未提供。