harness-engineering

校验业务代码与 IDL 契约同步、字段冻结状态是否被破坏。作为 8 维度 code review 的"契约一致"维度，可被 design-checker / code-review-preparer 调用，也可独立运行。

聚合 8 维度 review Agent 的产出，生成统一的 review 报告并写入 reviews/{ts}.md。

当 context/ 下新增/删除文件时，自动更新对应层级的 INDEX.md，避免"孤儿文件"。

按 templates/detail-design.md 模板撰写详细设计文档，包括数据模型、IDL 变更、接口设计、决策、错误处理、监控、灰度等。

运维操作中心（Operations Center）通用适配器——为团队的运营/运维操作（开关、灰度、限流、降级）提供统一调用约定。具体实现按团队接入。

DevOps CLI 通用适配器——把团队的部署/构建/发布命令包装成一致的高层接口。具体实现按团队接入。

当 requirements/{p}/{r}/ 下新增文档（design / review / experience 等）时，自动更新该需求的 INDEX 与摘要。

查询团队工程规范（错误码段位、日志字段、安全基线、Git 规范、编码风格）的事实型问答。

按 topic / keyword / 模块组合搜索已沉淀的 experience，支持相似度排序与"触发提示"匹配。

管理单个 feature（FT-*）的生命周期：pending → in_progress → done。维护 features.json，触发对应 Agent。

根据本次 diff + 关联 feature 生成符合团队 git-conventions 的 commit message。

内部 CI/Code Review 平台适配器（原 QQ 音乐"工蜂"）——通用化为"代码托管平台" PR/MR/CI 操作适配器。

深度分析 IDL diff——字段增删改、frozen 状态、向后兼容性、下游受影响调用方。

"运行时影响面"分析（区别于 service-dependency-analyzer 的"拓扑影响面"）。基于实际 diff + 流量数据估计真实受影响的请求规模。

加载一个业务域（module）下所有服务的上下文，生成跨服务技术总结与共享教训。

一站式加载某个服务的全部相关上下文：dependencies.yaml 节点、architecture.md、experience/、IDL 文件清单、最近 N 个相关 commit。

知识管理总入口。负责 INDEX.md 维护、知识层级判断、知识检索路径优化。

中央调度——驱动需求在五阶段四门禁之间流转，维护 state.json，调用门禁 Agent，更新追溯链。任何需求相关操作的总入口。

协助解决三仓 merge / rebase 冲突——给出冲突上下文、关联 FT、建议解决策略。不自动 commit。

命名规范校验——函数 / 变量 / 文件 / 接口 / 错误码 / 表名 / 分支等命名是否符合团队规范。

按 templates/outline-design.md 模板撰写概要设计文档。

评估本次改动引入回归 bug 的风险，给出"高/中/低"分级与推荐测试范围。

阶段 5 上线时撰写 release note。面向用户/运营/客服三种受众分别输出。

阶段 5.1 测试验收前的"上线就绪自检"——聚合 8 维 review、回归风险、债务、配置就位等多个信号。

阶段 5.3 收尾归档——把 done 的需求标记归档，关闭 TAPD 单（如果有 MCP），归档目录的 INDEX 更新。

跟踪 state.json pending_debts 的全生命周期——创建、超期提醒、清理、归档。

把零散的输入（聊天记录 / TAPD 摘要 / 用户描述）写成符合模板的 requirement.md。是 requirement-input-normalizer Agent 的核心子能力。

跨会话恢复需求上下文。LLM 没有跨会话记忆，本 Skill 把仓内状态文件还原为可继续工作的 context bundle。

把用户的"纠正"转化为团队资产。当 AI 识别到模式性教训时，主动提议沉淀到对应知识层级。

基于 .service-matrix/dependencies.yaml 做影响面分析。给定一个服务/模块，返回上下游影响范围、是否涉及 IDL、是否跨团队。

跟踪 context/team / context/harness-framework 下规范文件的演化，回答"这条规范什么时候开始的""为什么这么定"。

写 tech-research.md。把候选方案、benchmark、风险、POC 建议组织成机读结构。

阶段 3.2 / 4.1 撰写 test-plan.md——覆盖单测、集成、契约、压测、灰度验证。

校验 REQ→DEC→FT→commit→review 的双向追溯链，是 3.3 和 4.2 门禁的核心组件。