Menu

Individual skill

governed-execution

0upvotes

Use when executing an accepted HOTL workflow through the best available host or fallback driver.

plugins/yimwoo/hotl-plugin/skills/governed-execution/SKILL.md

Read pinned source

Source commit d780783eba4ecc7c8b9429f95c9362df95f07c61

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
No
Observed behavior
Not checked yet
Last checked
Nov 4, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
1,538
Repository last updated
Nov 7, 2026
License
Apache-2.0

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# HOTL Governed Execution

This is the preferred execution entry point for new HOTL runs. It selects a host driver and an execution profile while preserving the canonical state machine in `loop-execution`.

## Required behavior

1. Resolve and lint the workflow using `loop-execution` rules.
2. Select the profile from user intent: `loop` for autonomous sequential work, `manual` for explicit checkpoints, or `delegated` for eligible independent steps. Never select delegated execution when the user prohibited subagents.
3. Locate the router in the active HOTL installation, then run `runtime/drivers/route.sh preflight <workflow>` before initialization. Supported roots include the current repository, `~/.codex/hotl`, `~/.codex/plugins/hotl-source`, the active Codex plugin cache, the Claude plugin root, and `~/.cline/hotl`. Use `--host` only when the user or trusted host context identifies one.
4. If preflight resolves fallback, follow the chosen existing execution skill with the generic driver. If it resolves native, obtain `envelope` and use only supported native features; the host sandbox and approvals remain authoritative. Native goals, automations, background sessions, handoffs, and hooks provide scheduling and liveness only. They never replace HOTL ownership, verification, state, or receipts. Preview and experimental continuation features remain explicit opt-ins.
5. Launch new driver-managed runs with `--require-owner`. Immediately run `owner claim --owner <stable-controller-id> --lease-seconds <bounded-lease> --run-id <run-id>`, retain the returned token only in the controller, export it as `HOTL_OWNER_TOKEN`, and run `owner heartbeat` before and after long actions and at safe transition boundaries. Every later mutation must carry that token. Use explicit `owner handoff`, `owner release`, or reviewed `owner takeover`; never infer ownership from age alone.
6. Persist every step, verification, gate, action decision, effect outcome, budget observation, finalize, and finish transition through the selected driver. Host UI or chat text is never state.
7. Before claiming success, require `receipt <run-id>` to return `sufficiency.sufficient: true`. A successful `finalize` only moves the run to `ready_to_finish`; `finish` records the explicit disposition and moves it to `completed`. If interrupted, run `reconcile <run-id>` and follow `resuming` verify-first behavior.