/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.

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

The Execute Process

Step 1: Pre-flight Check

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]."

Step 2: Build

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:

Make the change
Verify it works (tests, manual check, whatever's appropriate)
Stage changes
Run review if available (
```
sg review
```
or equivalent)
Handle review findings (fix trivial, create tasks for non-trivial)
Commit with clear message

Step 3: Detect Drift

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.

Step 4: Salvage if Needed

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.

Output Format

When execution completes successfully:

## 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

**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]

Examples

Example 1: Clean Execution

/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:

## 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

### Verification
- Added unit tests for each handler (empty, whitespace-only, valid)
- Manual test: confirmed error message appears in UI

### Notes
- Downstream processors still accept empty strings (out of scope)
- Consider adding validation to API gateway layer in future

Example 2: Drift Detection Mid-Execution

/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:

## 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.

### 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.

Example 3: Triggering Salvage

/execute

Building the new auth flow

After multiple iterations:

## 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.

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

## Execute
**Updated:** <timestamp>
**Status:** [pre-flight | in-progress | drift-detected | complete]

[execution notes, drift observations, etc.]

Adaptive Enhancement

Base Skill (prompt only)

Works anywhere. Manual pre-flight checklist, drift detection by reasoning. No persistence.

With .oh/ session file

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

With 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)

Creates subtasks for non-trivial findings
Updates task status as work progresses
Links commits to tasks

With code review (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

/problem-space

via

/salvage

when the approach isn't working.

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.

execute

NPX Install

Tags

SKILL.md Content