---
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**：
1. 接入审计类信号：`接入风险` / `安全审查` / `外部 skill` / `安装脚本` / `hook` / `遥测`
   - 应让位给：`skill-safety-audit`
2. 排障闭环类信号：`修 bug` / `继续查` / `继续修` / `别停在分析` / `验证闭环`
   - 应让位给：`research-execution-protocol`

## 目标
在不污染全局规则的前提下，生成一条可执行的交付路径：
- 明确目标
- 明确验收标准
- 选择最小改动面
- 逐步实现
- 改动后立即验证
- 说明风险与回滚点

## 执行流程

### 1) 定义交付对象
先判断本轮交付属于哪类：
- 代码实现
- 配置修复
- skill 新增/改写
- 文档补充
- 测试补齐
- 脚本自动化

### 2) 写清验收标准
在动手前明确：
- 什么行为会发生变化
- 什么命令 / 测试 / 例子可证明完成
- 哪些路径本轮不覆盖

### 3) 设计最小改动方案
优先级：
1. 局部 patch
2. 增量文件
3. 小范围重构
4. 大改（只有在前 3 项不可行时才进入）

### 4) 执行改动
对每类改动都给出：
- 修改文件
- 修改原因
- 与现有规则的兼容性
- 潜在副作用

### 5) 立即验证
至少执行一项：
- 单元测试
- lint / 静态检查
- 样例输入回放
- 命令执行
- 人工 smoke test

### 6) 生成交付说明
输出中必须包含：
- 改了什么
- 为什么这样改
- 如何验证
- 风险在哪
- 如何回滚

## 输出格式
```text
交付结论：<已完成 / 部分完成 / 未完成>

目标：
- ...

验收标准：
- ...

改动方案：
1. 文件：...
   原因：...
   风险：...

验证：
- 执行：...
- 结果：...

回滚点：
- ...

后续建议：
1. ...

[置信度: X.XX]
[依据: 代码/配置/验证结果]
```

## 边界
- 不跳过验收标准直接宣称完成
- 不默认修改全局人格与安全边界文件
- 不用“大重构”掩盖定位不清
- 若需求显著扩大，先按最小闭环交付，再给下一阶段建议