用途：该技能用于为编码智能体建立仓库级 harness（工程护栏），把重复出现的 AI 编码错误转化为可长期保留的仓库资产。公式为 Harness = 指令 + 约束 + 反馈 + 记忆 + 评估 + 治理。适用场景包括：让仓库对 GitHub Copilot 等编码智能体更可靠；添加长期有效的智能体指令、仓库规则或护栏；防止重复的 AI 编码错误；记录已知失败路径及防止复发的检查；为项目规则添加轻量漂移检查；审查、刷新或更新已有 harness。普通功能实现不适用，除非用户要求改善仓库的智能体运行环境。
核心原则：以目标仓库为唯一事实来源；编辑前先检查，保留现有技术栈、包管理器、CI、文档、命名与架构；只添加最小可用的 harness，优先更新已有文件而非新增重复指引；重要规则尽量通过测试、linter、类型检查、CI、pre-commit 钩子或漂移脚本强制执行；仅在自动化脆弱或误导时使用人工审查点；记录不应复发的高风险失败，并指明捕获复发的检查或审查点；不要盲目复制通用模板，每个产物都要适配仓库中的真实证据。
发现阶段：在提出或实施 harness 变更前，检查仓库中已有的规则与证据，包括 README.md、AGENTS.md、.github/copilot-instructions.md、.github/instructions/、.github/workflows/、CONTRIBUTING.md、package.json、pyproject.toml、go.mod、Cargo.toml、pom.xml、build.gradle、docs/、scripts/、现有测试与 CI 检查。随后总结技术栈、包管理器与入口点，现有开发与验证命令，当前智能体指令或仓库约定，已知失败、事故、不稳定路径或重复审查意见，以及项目规则未被强制执行的缺口。
采用流程：1）选择适配目标仓库的 harness 载体（常驻行为用 AGENTS.md 或 .github/copilot-instructions.md；文件级指引用 .github/instructions/.instructions.md；周期性检查用 scripts/check_.py、shell 脚本或包脚本；CI 强制用现有工作流或小型新工作流；已知失败用 docs/failures/.md；架构或流程决策用 docs/decisions/.md；采用证据用 docs/harness/adoption-report.md 等）。若仓库已有等价位置，应更新而非另建并行体系。2）编写具体可操作的智能体指令，包含项目目的与所有权边界、安装/测试/lint/构建/验证命令、包管理器与依赖规则、安全编辑规则、生成文件规则与禁止路径、变更代码的测试期望、PR 与提交约定、如何记录新失败或决策；避免宽泛的人格指引与无法检查的通用最佳实践。3）把高价值规则转为可执行检查，要求窄到避免误报、快到可本地与 CI 运行、命名清晰、并记录其保护的规则。4）记录失败记忆：当失败对用户可见、高风险或可能复发时，在 docs/failures/ 下新建文件，结构含 Summary、Root Cause、Prevention、Evidence；若无可行自动化检查，记录人工审查点及原因。5）添加漂移检查，针对可能静默过期的指引，如文档提到已不存在的命令、profile 片段与生成示例分叉、失败笔记缺少回归检查、结构性变更缺少决策记录、CI 引用过期脚本或包命令；优先用仓库现有语言写小脚本，无约定时可用仅标准库的 Python。6）完成采用报告，包含变更文件、新增或更新的规则、新增或复用的检查、运行的命令与结果、假设与人工跟进、创建或有意跳过的失败记忆、效果衡量方式。
审查流程：被要求审查 harness 变更时，采取对立视角，查找无证据的通用规则、重复或冲突的指令文件、易在有效变更上失败的宽泛检查、未强制执行的高风险规则、重复错误或运行时失败缺少失败记忆、源变更后未刷新生成文档、未运行相关检查的 CI 门禁、被 harness 默认值覆盖的仓库约定。先按严重程度报告发现，附文件与行号；除非用户明确要求修复，审查期间不要修改文件。
输出契约：完成前确认已先检查目标仓库、新指引针对目标仓库、变更的检查可本地运行或有文档化人工替代、必要时已记录失败记忆或说明跳过原因、生成文档或索引已刷新、最终报告列出每条运行的命令及结果。
可选参考：https://github.com/baskduf/harness-starter-kit 中的 prompt-first 工作流是这些思路的参考实现，仅在用户要求或仓库已包含时作为参考材料使用；目标仓库始终是事实来源。