| name | research-build |
| description | 面向实现闭环的工程 workflow。用于把“需求/思路/方案”转成可交付改动，强调验收标准、最小改动、立即验证、明确回滚点。冲突优先级最低：若请求同时包含“接入审计”或“修 bug/继续查”等排障闭环意图，应让位于 skill-safety-audit 或 research-execution-protocol。 |
| version | 1.0.0 |
| author | jinglong92 |
| license | MIT |
| requires | ["file_write"] |
Research Build
把“分析”推进到“实现闭环”的工程 skill。
触发条件
- 用户说“直接帮我实现”
- 用户说“不要只分析，给我落地”
- 用户提供明确目标、代码位置或设计方向，希望生成改动计划或直接修改
- 任务需要从需求走到 patch / script / config / docs / test
冲突让位规则（硬门槛）
出现以下信号时，不触发本 skill：
- 接入审计类信号：
接入风险 / 安全审查 / 外部 skill / 安装脚本 / hook / 遥测
- 排障闭环类信号：
修 bug / 继续查 / 继续修 / 别停在分析 / 验证闭环
- 应让位给：
research-execution-protocol
目标
在不污染全局规则的前提下，生成一条可执行的交付路径：
- 明确目标
- 明确验收标准
- 选择最小改动面
- 逐步实现
- 改动后立即验证
- 说明风险与回滚点
执行流程
1) 定义交付对象
先判断本轮交付属于哪类：
- 代码实现
- 配置修复
- skill 新增/改写
- 文档补充
- 测试补齐
- 脚本自动化
2) 写清验收标准
在动手前明确：
- 什么行为会发生变化
- 什么命令 / 测试 / 例子可证明完成
- 哪些路径本轮不覆盖
3) 设计最小改动方案
优先级：
- 局部 patch
- 增量文件
- 小范围重构
- 大改（只有在前 3 项不可行时才进入）
4) 执行改动
对每类改动都给出：
- 修改文件
- 修改原因
- 与现有规则的兼容性
- 潜在副作用
5) 立即验证
至少执行一项：
- 单元测试
- lint / 静态检查
- 样例输入回放
- 命令执行
- 人工 smoke test
6) 生成交付说明
输出中必须包含：
- 改了什么
- 为什么这样改
- 如何验证
- 风险在哪
- 如何回滚
输出格式
交付结论：<已完成 / 部分完成 / 未完成>
目标：
- ...
验收标准：
- ...
改动方案：
1. 文件：...
原因：...
风险：...
验证：
- 执行：...
- 结果：...
回滚点：
- ...
后续建议：
1. ...
[置信度: X.XX]
[依据: 代码/配置/验证结果]
边界
- 不跳过验收标准直接宣称完成
- 不默认修改全局人格与安全边界文件
- 不用“大重构”掩盖定位不清
- 若需求显著扩大，先按最小闭环交付，再给下一阶段建议
