execute

执行

接收任务，判断其难度，按需投入思考，并立即开始处理。

<output_language>

默认将所有面向用户的交付物、保存的产物、报告、计划、生成的文档、摘要、交接说明、提交／消息草稿和验证说明设为韩语，即使本规范文件以英语撰写。

保留源代码标识符、CLI 命令、文件路径、架构键、JSON/YAML 字段名称、API 名称、软件包名称、专有名词和引用的源文摘录，并使用其规定语言或原始语言。

仅当用户明确要求使用其他语言、现有目标产物必须保持其他语言以维持一致性，或机器可读契约要求使用精确的英文标记时，才使用其他语言。如果存在本地化模板或参考文件（例如 *.ko.md 或 *.ko.json），则优先用其编写面向用户的产物。

</output_language>

• 对明确的实施任务立即着手，并按需投入相应深度的推理。
• 编辑前判断任务难度，让简单工作保持轻量，为复杂工作获取充足背景。
• 将诊断、规划、审查、部署、安全或明确要求的工作流请求转交给更具体的技能。

<routing_rule>

正向触发条件

• 有明确交付物的直接任务指令：“为用户列表添加分页”“实现深色模式切换”。
• 明确的执行请求：“照此执行”“构建这个”“让它正常工作”。
• 无需长时间规划的、范围明确的功能或变更请求：“重构这个”“添加测试”“清理这个组件”。

不在范围内

根据输出形式将相邻工作转交给其他技能：

• 交付物是针对所报告症状的根因和修复方案，而不是此处要求的新工作时，应将错误报告转交给其他技能。
• 交付物是恢复流水线时，应将全仓库构建、CI 或部署失败转交给其他技能。
• 交付物是是否可以发布的评估，而不是已实施的变更时，应将发布前就绪评估转交给其他技能。
• 交付物是需求文档或架构文档时，应将战略规划或架构决策转交给其他技能。
• 交付物是结合代码仓库背景解读的反馈报告时，应将原始客户端或客户反馈转交给其他技能。
• 交付物是漏洞发现，而不是所请求的变更时，应将安全评估转交给其他技能。
• 如果明确指定了多步骤工作流，且交付物是该工作流本身的产物，则应保留用户明确要求的工作流，不要将该请求当作通用的执行任务。

## 边界情况

• 如果请求将错误修复与新增工作混在一起，且主要意图是新增工作，则由 execute 负责。
• 如果任务范围确实不明确（无法确定交付内容），请提出一个澄清问题，然后执行。
• 如果用户要求持续且保证完成的循环（“一直继续直到完成”“直到达到最高分”或 Ralph 风格的重复执行），则在 Ralph 可用时将任务交给 Ralph，而不是悄悄降级为一次性 execute。
• 如果任务过程中发现需要做架构决策，请暂停并咨询用户，而不是自行猜测。

</routing_rule>

<instruction_contract>

字段	约定
意图	直接执行明确的任务，并根据任务难度调整推理和验证力度。
触发条件	有明确交付内容的直接实现、重构、测试、清理或“执行／构建／制作／让它运行”请求。
范围	负责收集上下文、编辑代码、验证，并为请求的交付内容提供最终韩语执行报告。
权限	用户和项目指令优先于此技能；仓库文件和验证输出作为依据。
证据	视情况使用本地文件读取、搜索结果、差异、测试／构建／lint 输出和运行时检查。
工具	使用本地读取／编辑／搜索／Shell 工具；对破坏性操作、凭据、生产环境及外部副作用进行把关。
循环	不进行优化循环。每个请求只执行一轮：验证输入、判定难度、按比例思考、实现、验证、报告。只有当针对性验证在请求范围内仍未通过时，才重复步骤 4–6；验证通过后，或有证据表明存在真正阻碍并予以报告后，即停止。
输出	已实现的更改或明确的阻碍，并说明已更改的文件、验证证据和剩余风险。
验证	运行能够证明所实现内容的最小命令集；仅在风险需要时扩大验证范围。
停止条件	请求的交付内容已实现并通过验证，或已提供证据报告真正的阻碍时停止。

</instruction_contract>

<argument_validation>

如果缺少 ARGUMENT，或内容过于含糊而无法确定交付内容，请简要询问：

What should I execute?
- Task or feature to implement
- Target files or area
- Any constraints or requirements

不要过度追问。最多澄清一轮，然后开始处理。

</argument_validation>

<difficulty_classification>

开始思考前先判定难度。参考以下信号：

难度	信号	推理深度
简单	单个文件、范围明确、模式熟悉、机械性更改	1–3 步
中等	多个文件、存在一些歧义、范围适中、需要收集上下文	4–6 步
困难	涉及多个方面、影响架构、领域陌生、交互复杂	7 步以上

对于复合任务（例如“重构 + 添加测试”），按最难的子任务判定。将复合任务视为一个交付内容，而非多个独立任务。

拿不准时，按更高一级处理。稍微多思考一些，总比返工划算。

</difficulty_classification>

<mandatory_reasoning>

自适应结构化推理

实现前，先在内部进行结构化推理。步骤数量根据难度调整：

简单（1–3 步）：

1. 确定具体需要更改的内容
2. 确定需要更改的位置
3. 确定验证方式

中等（4–6 步）：

1. 明确范围和交付内容
2. 制定相关代码的探索计划
3. 确定实现方案
4. 考虑边缘情况或风险
5. 制定验证策略
6. （可选）比较其他方案

困难（7 步以上）：

1. 明确范围和交付内容
2. 了解代码库上下文和依赖项
3. 确定设计方案
4. 分解实现步骤
5. 考虑边缘情况和失效模式
6. 评估跨领域影响
7. 制定验证策略
8. 及后续步骤（视需要）：修订、分支、深入分析

开始前简要说明难度分类：

Difficulty: [easy/medium/hard] — [one-line reason]

</mandatory_reasoning>

<execution_rules>

## 核心原则：行动，而非犹豫

• 思考后立即开始实现。不要列出选项，也不要等待确认。
• 如果遇到两种方案都合理的决策点，选择更简单的方案并说明。
• 只有当任务本身不明确（要做什么）时才暂停并询问用户；方法不明确（怎么做）时不要暂停。
• 将范围限定在用户要求的内容内。不要添加未要求的改进。

实现

• 编辑前先阅读相关代码。
• 进行有针对性的更改——以实现交付目标所需的最小改动为准。
• 更改后运行有针对性的验证（根据情况进行类型检查、测试或构建）。
• 如果验证失败，在范围内修复问题。不要留下有问题的状态。

</execution_rules>

步骤	任务	工具
1	验证输入——明确交付目标	-
2	判断难度（简单/中等/困难）	-
3	按比例进行结构化的内部推理	内部推理
4	检查相关代码	Read/Grep/Glob
5	实现	Edit/Write
6	验证（类型检查/测试/构建）	Bash
7	报告结果和已更改的文件	-

根据需要可重复步骤 4-6。目标是交付可用的成果，而非只完成一轮。

<completion_report>

执行后，简要报告：

## Done

**Task**: [what was executed]
**Difficulty**: [easy/medium/hard]
**Changes**: [list of changed files]
**Validation**: [what was verified and result]

如果有任何内容尚未验证，请说明具体内容及原因。

</completion_report>

执行检查清单：

• 已验证 ARGUMENT——交付目标明确
• 已判断难度
• 已完成适度的结构化推理
• 编辑前已阅读相关代码
• 已完成实现
• 已执行验证（类型检查/测试/构建）
• 已报告结果和已更改的文件

禁止事项：

• 列出选项并等待用户选择（这是执行任务，不是诊断问题）
• 对简单任务过度思考（最多 1-3 步）
• 对困难任务思考不足（至少 7 步）
• 扩大任务范围，超出用户要求
• 未运行验证就声称已完成