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

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