| 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]
[依据: 代码/配置/验证结果]
边界
- 不跳过验收标准直接宣称完成
- 不默认修改全局人格与安全边界文件
- 不用“大重构”掩盖定位不清
- 若需求显著扩大,先按最小闭环交付,再给下一阶段建议