Back to Details

execute

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/execute

/execute

Do the actual work. Execute is the bridge from Solution Space to shipped code. Pre-flight checks, build, detect drift, salvage if needed.
Execute sits within the larger Intent -> Execution -> Review loop. This skill handles the Execution phase, which itself contains an inner loop: build, check alignment, course-correct or salvage.
开展实际工作。/execute 是连接解决方案空间与已交付代码的桥梁，涵盖预检查、构建、漂移检测，必要时进行补救。
/execute 属于更大的意图 -> 执行 -> 评审循环。该技能负责执行阶段，而执行阶段本身包含一个内部循环：构建、检查一致性、修正方向或进行补救。

When to Use

适用场景

Invoke 
/execute
when:
  • Aim is clear - you know the outcome you're trying to achieve
  • Solution is chosen - you've explored options and picked an approach
  • Context is loaded - you understand the constraints and guardrails
  • Ready to build - not still exploring or discovering
Do not use when:
  • Aim is unclear - use 
    /aim
    first
  • Still exploring options - use 
    /solution-space
    first
  • Problem is ambiguous - use 
    /problem-space
    or 
    /problem-statement
    first
在以下情况调用 
/execute
：
  • 目标明确 - 清楚自己要达成的成果
  • 方案已选定 - 已探索多种选项并选定了一种方法
  • 上下文已加载 - 了解约束条件和规则边界
  • 准备好构建 - 不再处于探索或发现阶段
请勿在以下情况使用：
  • 目标不明确 - 先使用 
    /aim
  • 仍在探索选项 - 先使用 
    /solution-space
  • 问题模糊不清 - 先使用 
    /problem-space
    或 
    /problem-statement

The Execute Process

执行流程

Step 1: Pre-flight Check

步骤1：预检查

Before writing code, verify alignment:
Pre-flight Checklist:
[ ] Aim is clear - what outcome am I producing?
[ ] Constraints known - what must I NOT break?
[ ] Context loaded - do I have the codebase understanding I need?
[ ] Scope bounded - what am I specifically doing (and NOT doing)?
[ ] Success criteria - how will I know when I'm done?
If any box can't be checked, stop and address it before proceeding. Ask clarifying questions if requirements are ambiguous.
"The task is [task]. The aim is [aim]. I'm specifically doing [scope]. I will NOT be touching [out of scope]. Success looks like [criteria]."
在编写代码前，验证一致性：
Pre-flight Checklist:
[ ] 目标明确 - 我要产出什么成果？
[ ] 已知约束条件 - 哪些内容绝对不能破坏？
[ ] 上下文已加载 - 我是否了解代码库的相关内容？
[ ] 范围已界定 - 我具体要做什么（以及不做什么）？
[ ] 成功标准 - 如何判断任务已完成？
如果有任何一项未勾选，请先解决问题再继续。如果需求模糊，请提出澄清问题。
"任务是[任务内容]。目标是[目标]。我具体要做[范围]。我不会触碰[超出范围的内容]。成功的标志是[判定标准]。"

Step 2: Build

步骤2：构建

Do the work. Keep it focused.
Build principles:
  • Work in small, testable increments
  • Commit logical units of change
  • Stay within the declared scope
  • If scope expands, pause and reassess (see Drift Detection)
During build:
  1. Make the change
  2. Verify it works (tests, manual check, whatever's appropriate)
  3. Stage changes
  4. Run review if available (
    sg review
    or equivalent)
  5. Handle review findings (fix trivial, create tasks for non-trivial)
  6. Commit with clear message
开展实际工作，保持专注。
构建原则：
  • 以小的、可测试的增量推进工作
  • 提交逻辑独立的变更单元
  • 严格遵循已声明的范围
  • 如果范围扩大，暂停并重新评估（参见漂移检测）
构建过程中：
  1. 进行变更
  2. 验证变更有效（测试、手动检查等合适的方式）
  3. 暂存变更
  4. 如有可用工具，运行评审（
    sg review
    或同类工具）
  5. 处理评审结果（修复小问题，为重大问题创建任务）
  6. 提交并附上清晰的提交信息

Step 3: Detect Drift

步骤3：漂移检测

Periodically check alignment during execution:
Drift signals:
  • Scope is expanding beyond original task
  • You're touching files not mentioned in the plan
  • "While I'm here" thoughts keep appearing
  • Original estimate is significantly exceeded
  • Approach has changed direction multiple times
  • You're protecting code you've invested in
When you notice drift:
Drift Check:
- Original aim: [aim]
- What I'm actually doing now: [current work]
- Gap: [describe the divergence]
- Verdict: [aligned | minor drift | significant drift | lost]
Aligned: Continue building.
Minor drift: Note it, continue if still valuable, or refocus.
Significant drift: Pause. Either:
  • Refocus on original aim and defer the tangent
  • Acknowledge scope change and get confirmation
  • Salvage and restart
Lost: Invoke 
/salvage
immediately.
在执行过程中定期检查一致性：
漂移信号：
  • 范围超出了原始任务
  • 正在修改计划中未提及的文件
  • 频繁出现“顺便做一下”的想法
  • 原始预估时间已大幅超出
  • 方法多次变更方向
  • 试图维护自己投入过精力的代码
发现漂移时：
Drift Check:
- 原始目标: [目标]
- 当前实际工作: [当前工作内容]
- 偏差: [描述偏离情况]
- 结论: [一致 | 轻微漂移 | 严重漂移 | 失控]
一致： 继续构建。
轻微漂移： 记录情况，若仍有价值则继续，否则重新聚焦。
严重漂移： 暂停。可选择：
  • 重新聚焦原始目标，将次要任务延后
  • 承认范围变更并获取确认
  • 进行补救并重新开始
失控： 立即调用 
/salvage
。

Step 4: Salvage if Needed

步骤4：必要时进行补救

When to stop and salvage:
  • Approach has reversed 3+ times
  • Scope keeps expanding while "done" keeps fuzzing
  • You're oscillating, not converging
  • The finish line keeps moving
  • Starting over feels right
Don't fight lost work. Extract the learning and restart clean.
"Code is cheap now. Learning is the asset."
Invoke 
/salvage
to extract what you learned before restarting.
在以下情况停止并进行补救：
  • 方法已反转3次以上
  • 范围持续扩大，而“完成”的标准却越来越模糊
  • 一直在反复调整，没有进展
  • 终点不断移动
  • 重新开始感觉是正确的选择
不要纠结于失败的工作，提取经验教训后重新开始。
"代码的成本很低，经验才是宝贵的资产。"
调用 
/salvage
提取经验教训后再重新开始。

Output Format

输出格式

When execution completes successfully:
undefined
当执行成功完成时：
undefined

Execution Complete

Execution Complete

Task: [what was done] Aim achieved: [how it maps to the original aim]
任务: [已完成的工作] 达成的目标: [如何匹配原始目标]

Changes

变更内容

  • [file/component]: [what changed and why]
  • [file/component]: [what changed and why]

Verification

验证方式

  • [how it was tested/verified]
  • [测试/验证的方式]

Notes

备注

  • [anything relevant for future work]

When drift triggers a pause:
  • [对未来工作有参考价值的内容]

当漂移触发暂停时：

Execution Paused - Drift Detected

Execution Paused - Drift Detected

Original aim: [aim] Current state: [where things stand] Drift: [what diverged and why]
原始目标: [目标] 当前状态: [当前进展] 漂移情况: [偏离的内容及原因]

Options

可选方案

  1. [option 1]
  2. [option 2]
  3. Salvage and restart
Recommendation: [your assessment]
undefined
  1. [方案1]
  2. [方案2]
  3. 补救并重新开始
建议: [你的评估]
undefined

Examples

示例

Example 1: Clean Execution

示例1：顺利执行

/execute

Task: Add validation for empty strings in user input
Pre-flight:
Pre-flight Checklist:
[x] Aim is clear - prevent empty strings from causing silent failures
[x] Constraints known - don't break existing validation, maintain API compatibility
[x] Context loaded - reviewed input processing flow, found 3 entry points
[x] Scope bounded - only the 3 input handlers, not the downstream processors
[x] Success criteria - empty strings rejected with clear error message
Output:
undefined
/execute

Task: Add validation for empty strings in user input
预检查:
Pre-flight Checklist:
[x] 目标明确 - 防止空字符串导致静默失败
[x] 已知约束条件 - 不破坏现有验证逻辑，保持API兼容性
[x] 上下文已加载 - 评审了输入处理流程，发现3个入口点
[x] 范围已界定 - 仅处理3个输入处理器，不涉及下游处理器
[x] 成功标准 - 空字符串被拒绝并返回清晰的错误信息
输出:
undefined

Execution Complete

Execution Complete

Task: Add empty string validation to user input Aim achieved: Empty strings now rejected at entry points with clear error message
任务: 为用户输入添加空字符串验证 达成的目标: 现在空字符串在入口点会被拒绝，并返回清晰的错误信息

Changes

变更内容

  • handlers/user.go: Added empty string check before processing
  • handlers/profile.go: Added empty string check before processing
  • handlers/settings.go: Added empty string check before processing
  • lib/validation.go: New isEmpty() helper for consistency
  • handlers/user.go: 在处理前添加了空字符串检查
  • handlers/profile.go: 在处理前添加了空字符串检查
  • handlers/settings.go: 在处理前添加了空字符串检查
  • lib/validation.go: 新增了isEmpty()辅助函数以保持一致性

Verification

验证方式

  • Added unit tests for each handler (empty, whitespace-only, valid)
  • Manual test: confirmed error message appears in UI
  • 为每个处理器添加了单元测试（空值、仅空格、有效值）
  • 手动测试：确认UI中会显示错误信息

Notes

备注

  • Downstream processors still accept empty strings (out of scope)
  • Consider adding validation to API gateway layer in future
undefined
  • 下游处理器仍接受空字符串（超出范围）
  • 未来可考虑在API网关层添加验证
undefined

Example 2: Drift Detection Mid-Execution

示例2：执行中检测到漂移

/execute

Task: Fix the timezone bug in calendar display
Mid-execution drift check:
Drift Check:
- Original aim: Fix timezone display bug
- What I'm actually doing now: Refactoring the entire date handling library
- Gap: Went from fixing display to rewriting infrastructure
- Verdict: Significant drift
Output:
undefined
/execute

Task: Fix the timezone bug in calendar display
执行中漂移检查:
Drift Check:
- 原始目标: 修复日历显示中的时区bug
- 当前实际工作: 重构整个日期处理库
- 偏差: 从修复显示问题变成了重写基础架构
- 结论: 严重漂移
输出:
undefined

Execution Paused - Drift Detected

Execution Paused - Drift Detected

Original aim: Fix timezone bug in calendar display Current state: Found the bug, but discovered date handling is inconsistent across 12 files
Drift: Started fixing the display bug, realized the root cause is a design issue. Fixing it properly requires touching the date library, which affects everything.
原始目标: 修复日历显示中的时区bug 当前状态: 找到了bug，但发现12个文件中的日期处理逻辑不一致
漂移情况: 开始修复显示bug时，意识到根本原因是设计问题。要彻底修复需要修改日期库，这会影响所有相关功能。

Options

可选方案

  1. Band-aid fix in display layer only (solves symptom, not cause)
  2. Refactor date handling (right fix, but 10x scope)
  3. Salvage learning, create proper task for date system redesign
Recommendation: Option 3 - the date system needs intentional redesign, not accidental refactoring during a bug fix. Salvage what we learned, create a proper design task, apply band-aid for now.
undefined
  1. 仅在显示层进行临时修复（解决表象，而非根源）
  2. 重构日期处理逻辑（正确的修复，但范围扩大10倍）
  3. 提取经验教训，为日期系统重新设计创建正式任务
建议: 方案3 - 日期系统需要有计划地重新设计，而不是在修复bug时意外进行重构。提取已有的经验教训，创建正式的设计任务，先应用临时修复。
undefined

Example 3: Triggering Salvage

示例3：触发补救

/execute

Building the new auth flow
After multiple iterations:
undefined
/execute

Building the new auth flow
多次迭代后:
undefined

Execution Paused - Salvaging

Execution Paused - Salvaging

Original aim: Simplify authentication flow Current state: 4th approach attempted, complexity has increased
The approach has reversed multiple times:
  1. Started with unified flow -> broke provider-specific handling
  2. Switched to provider adapters -> too much duplication
  3. Tried abstract base class -> inheritance nightmare
  4. Back to unified flow with exceptions -> where we started, but worse
Invoking /salvage to extract learning before restart.
undefined
原始目标: 简化认证流程 当前状态: 已尝试第4种方案，复杂度反而增加了
方案已多次反转:
  1. 从统一流程开始 -> 破坏了特定提供商的处理逻辑
  2. 切换为提供商适配器 -> 重复代码过多
  3. 尝试抽象基类 -> 继承结构混乱
  4. 回到带例外的统一流程 -> 回到原点，但情况更糟
调用 /salvage 提取经验教训后重新开始。
undefined

Session Persistence

会话持久化

This skill can persist context to 
.oh/<session>.md
for use by subsequent skills.
If session name provided (
/execute auth-refactor
):
  • Reads/writes 
    .oh/auth-refactor.md
    directly
If no session name provided (
/execute
):
  • After pre-flight, offer to save execution context:
    "Save to session? [suggested-name] [custom] [skip]"
  • Suggest a name based on git branch or the task description
Reading: Check for existing session file. Read Aim, Problem Statement, Solution Space to understand what we're building and why. This is essential for drift detection.
Writing: After pre-flight and during execution, write status to the session file:
markdown
undefined
该技能可将上下文持久化到 
.oh/<session>.md
，供后续技能使用。
如果提供了会话名称（
/execute auth-refactor
）:
  • 直接读写 
    .oh/auth-refactor.md
如果未提供会话名称（
/execute
）:
  • 预检查完成后，会询问是否保存执行上下文:
    "保存到会话？[建议名称] [自定义] [跳过]"
  • 根据git分支或任务描述生成建议名称
读取: 检查是否存在会话文件。读取目标、问题陈述、解决方案空间以了解要构建的内容及原因。这对漂移检测至关重要。
写入: 预检查完成后及执行过程中，将会话状态写入会话文件:
markdown
undefined

Execute

Execute

Updated: <timestamp> Status: [pre-flight | in-progress | drift-detected | complete]
[execution notes, drift observations, etc.]
undefined
更新时间: <时间戳> 状态: [预检查中 | 执行中 | 检测到漂移 | 已完成]
[执行备注、漂移观察结果等]
undefined

Adaptive Enhancement

自适应增强

Base Skill (prompt only)

基础技能（仅提示）

Works anywhere. Manual pre-flight checklist, drift detection by reasoning. No persistence.
可在任何场景使用。手动完成预检查清单，通过推理进行漂移检测。无持久化功能。

With .oh/ session file

配合 .oh/ 会话文件使用

  • Reads 
    .oh/<session>.md
    for aim, constraints, selected solution
  • Writes execution status and notes to the session file
  • Drift detection compares current work against session aim
  • 读取 
    .oh/<session>.md
    获取目标、约束条件、选定的解决方案
  • 将会话状态和备注写入会话文件
  • 漂移检测将当前工作与会话中的目标进行对比

With Open Horizons MCP

配合 Open Horizons MCP 使用

  • Queries related past decisions and learnings
  • Logs execution decisions to graph database
  • Session file serves as local cache
  • 查询相关的过往决策和经验教训
  • 将执行决策记录到图形数据库
  • 会话文件作为本地缓存

With task management (ba, GitHub issues)

配合任务管理工具（ba, GitHub issues）使用

  • Creates subtasks for non-trivial findings
  • Updates task status as work progresses
  • Links commits to tasks
  • 为重大问题创建子任务
  • 随着工作推进更新任务状态
  • 将提交记录与任务关联

With code review (sg, CodeRabbit)

配合代码评审工具（sg, CodeRabbit）使用

  • Runs automated review on staged changes
  • Triages findings by severity
  • Iterates until review passes
  • 对暂存的变更运行自动化评审
  • 根据严重程度分类处理评审结果
  • 迭代直到评审通过

Position in Framework

在框架中的位置

Comes after: 
/solution-space
(you need a chosen approach to execute). Leads to: 
/ship
to deliver, 
/review
to verify, 
/salvage
if drifting. Can loop back to: 
/aim
or 
/problem-space
via 
/salvage
when the approach isn't working.
前置技能: 
/solution-space
（需要先选定方案才能执行）。 后续技能: 
/ship
用于交付，
/review
用于验证，若发生漂移则使用 
/salvage
。 可回退到: 当方案不可行时，可通过 
/salvage
回到 
/aim
或 
/problem-space
。

Leads To

后续流程

After execute, typically:
  • /review
    - Verify the work before committing
  • /ship
    - Deploy the change to users
  • /salvage
    - If drift was detected and restart needed
Remember: Execute is the inner loop. Stay focused on the aim. Code is cheap; thrashing is expensive. Detect drift early. Salvage without shame.
执行完成后，通常会进行：
  • /review
    - 提交前验证工作成果
  • /ship
    - 将变更部署给用户
  • /salvage
    - 如果检测到漂移且需要重新开始
注意: /execute 是内部循环。保持专注于目标。代码成本低廉；反复试错代价高昂。尽早检测漂移，无需羞愧地进行补救。