菜单
研究型工程执行协议。用于复杂实现、排障、代码修改、配置修复与实验验证。强调先证据后判断、先验证后宣称完成、失败后系统性换路，不改变全局人格。冲突优先级次高：当请求包含“修 bug/继续查/验证闭环”与“交付落地”混合意图时，优先于 research-build。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Coding Agent 完整工作流——自主理解 codebase、制定修改计划、执行修改、运行验证、失败换路，交付可验证的代码改动。ENGINEER 路由且任务涉及代码修改时触发。
longClaw 运行时体检与诊断。用于检查 skill 不触发、hook 不生效、DEV LOG 异常、state.db 记账异常、memory 检索退化、配置迁移不完整等问题。Use when the user says 体检、自检、诊断、doctor、status、排查 longClaw、skill 不触发、hook 有问题、sidecar 异常、DEV LOG 乱了.
Generate publication-quality academic diagrams, methodology figures, architecture illustrations, and statistical plots from text descriptions using the PaperBanana multi-agent AI pipeline. Also evaluate diagram quality against reference images. Use when: (1) user asks to generate, create, or make a research diagram, methodology figure, system architecture illustration, pipeline diagram, or framework figure, (2) user asks to create a statistical plot, bar chart, or data visualization from CSV/JSON data, (3) user asks to evaluate or score a generated diagram against a reference, (4) user asks to refine or improve a previously generated diagram. NOT for: analyzing existing images, general image generation (non-academic), or chart/graph discussions without explicit generation intent.
记忆增强陪伴——BRO/SIS 回复前自动 spawn MemoryAgent 检索近期记忆，让陪伴有"记得你"的感觉。无需用户触发，CTRL 路由到 BRO/SIS 时自动激活。
面向实现闭环的工程 workflow。用于把“需求/思路/方案”转成可交付改动，强调验收标准、最小改动、立即验证、明确回滚点。冲突优先级最低：若请求同时包含“接入审计”或“修 bug/继续查”等排障闭环意图，应让位于 skill-safety-audit 或 research-execution-protocol。
分析岗位 JD，给出匹配度评级、核心要求拆解、简历叙事建议和投递优先级。
| name | research-execution-protocol |
| description | 研究型工程执行协议。用于复杂实现、排障、代码修改、配置修复与实验验证。强调先证据后判断、先验证后宣称完成、失败后系统性换路，不改变全局人格。冲突优先级次高：当请求包含“修 bug/继续查/验证闭环”与“交付落地”混合意图时，优先于 research-build。 |
| version | 1.0.0 |
| author | jinglong92 |
| license | MIT |
| requires | ["file_write"] |
用于高不确定性、易反复失败、需要多轮验证的工程任务。
满足任一条件时启用：
本 skill 优先于 research-build。 当请求同时包含"修 bug/继续查/验证闭环"与"交付落地"混合意图时，先执行本 skill。 research-build 仅在意图明确为"从零实现新功能"且无排障信号时才触发。
先收集最小必要证据，再下结论。 不要在没有日志、代码位置、配置状态、返回结果的情况下断言根因。
除非已有可见证据，否则不要说“已经修好”“完成了”。 只有在满足至少一项时，才可宣称完成：
一次失败后，必须显式切换策略之一：
优先做最小、可验证、可回滚的改动。 避免在根因未明时大面积重构。
输出中区分：
能自己做的检查先自己做。 只有在缺失关键输入、权限不足、或所有合理备用路径都失败后，才向用户索取额外信息。
复杂任务默认按以下结构输出：
结论：<已验证完成 / 已部分完成 / 未完成>
目标：<本轮目标>
已确认事实：
- [FACT] ...
当前假设：
- [HYP] ...
已执行验证：
- [TEST] ...
- [RESULT] ...
改动：
- ...
风险与边界：
- ...
下一步：
1. ...
完成判定：
- <哪项证据表明任务真的完成>
短任务可压缩为：
结论：
事实：
验证：
改动：
下一步：
AGENTS.md / SOUL.md / USER.md / MULTI_AGENTS.md更少臆测，更快验证，更小改动，更清楚地结束。