governed-execution
Use when executing an accepted HOTL workflow through the best available host or fallback driver.
Skill by yimwoo
Install
Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.
npx agentmarket install skill/yimwoo-governed-execution
Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.
Get the weekly diff
The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.
About
Use cases: productivity
Reviews
Write a reviewNo reviews yet. Installed it? Reviews come from verified installers only. How reviews work
Permissions
What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.
- Tools
- No tools found
- Secrets
- None asked for
- Install scripts
- None found
Network hosts it talks to 1
codeload.github.com· found in install command
Files it touches
~/.claude/skills/governed-execution
What's inside
- Skill name
governed-execution- Description
- Use when executing an accepted HOTL workflow through the best available host or fallback driver.
- License
- MIT
- Instructions
- 39 lines in SKILL.md · view on GitHub
Agent Skills spec issues
- files: referenced but missing: scripts/hotl-memory-proposal.sh
Files (1)
- SKILL.md
SKILL.md (first lines)
# 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. ## Long-running controller contract - The controller, not the host session UI or a delegated worker, owns `HOTL_OWNER_TOKEN`, gates, verification, budgets, and stop conditions. - Before a sensitive external effect, run `action request` with a stable idempotency key, obtain the required human `action decide`, and then persist `action begin` before performing the effect. Persist the observed result with `action complete`; after an interrupted or uncertain result, inspect the target and use `action reconcile` instead of replaying it. - Treat `in_progress` or `uncertain` effect state as a reconciliation stop. Approval authorizes one bounded attempt; it is not evidence that the effect succeeded. - Keep the lease renewable during long work. If the controller cannot heartbeat safely, stop at a durable boundary and hand off or release ownership. ## Compatibility profiles - `loop-execution`: canonical autonomous state machine and reporting contract. - `executing-plans`: explicit human checkpoints. - `subagent-execution`: delegated workers; controller retains gates and verification. - `resuming`: interrupted-run recovery. - `finishing-a-development-branch`: explicit finish disposition. These names remain supported. Do not rewrite an accepted workflow merely to use this router. ## Safety invariants - Native mode is opt-in; executable presence alone does not prove capability. - `external_write`, `production_change`, and `secret_access` require the `action request` → human `action decide` → `action begin` → effect → `action complete` lifecycle. Interrupted effects use `action reconcile`, never blind replay. - Unknown budget telemetry stays unknown. - Never auto-write project memory. `scripts/hotl-memory-proposal.sh` only creates a proposal for human review.
From yimwoo/hotl-plugin, MIT.
More from yimwoo/hotl-plugin
- 0.559score
receiving-code-review
yimwoo
Use when review findings arrive — verify each claim against the codebase and HOTL contracts before making changes.
SkillCFreshness: C★ 27Claude Code +9 - 0.559score
skill-authoring
yimwoo
Use when creating, editing, or reviewing HOTL skills, agents, command prompts, or other behavior-shaping instruction files.
SkillCFreshness: C★ 27Claude Code +9 - 0.558score
dispatch-agents
yimwoo
Use when you have 2+ independent tasks with no shared state — dispatches parallel subagents for each task.
SkillCFreshness: C★ 27Claude Code +9 - 0.556score
subagent-execution
yimwoo
Delegated step runner over the HOTL execution state machine — delegates eligible steps to fresh subagents while the controller keeps governance, verification…
SkillCFreshness: C★ 27Claude Code +9 - 0.556score
pr-reviewing
yimwoo
Review a PR across multiple dimensions — description, code changes, code scan, unit tests — using parallel subagents.
SkillCFreshness: C★ 27Claude Code +9 - 0.556score
verification-before-completion
yimwoo
Use before claiming any work is complete, fixed, or passing — runs verification commands and confirms output before making success claims.
SkillCFreshness: C★ 27Claude Code +9 - 0.556score
finishing-a-development-branch
yimwoo
Use after execution is complete or intentionally stopped — decide whether to merge back, publish a PR branch, keep the execution checkout, or discard it, and…
SkillCFreshness: C★ 27Claude Code +9 - 0.556score
requesting-code-review
yimwoo
Use at executor review checkpoints to dispatch the code-reviewer agent with structured context — git range, workflow contracts, and verification evidence.
SkillCFreshness: C★ 27Claude Code +9 - 0.555score
loop-execution
yimwoo
Use when executing an existing HOTL workflow file — reads steps, loops until success criteria met, auto-approves low-risk gates, pauses at high-risk gates.
SkillCFreshness: C★ 27Claude Code +9 - 0.554score
executing-plans
yimwoo
Use when executing an implementation plan linearly with explicit human checkpoints between batches of tasks.
SkillCFreshness: C★ 27Claude Code +9 - 0.553score
tdd
yimwoo
Use before writing any implementation code — enforces RED-GREEN-REFACTOR cycle.
SkillCFreshness: C★ 27Claude Code +9 - 0.553score
code-review
yimwoo
Use after completing implementation steps and before merging — reviews against plan and HOTL contracts.
SkillCFreshness: C★ 27Claude Code +9
Signals
- Stars
- 27
- Forks
- 3
- Open issues
- 1
- Last commit (this folder)
- Jul 6, 2026 (3 months ago)
- Last release
- Jul 2, 2026 (3 months ago)
From GitHub (fetched Oct 24, 2026).
Details
- License
- MIT
- Repository
- github.com/yimwoo/hotl-plugin
- First seen
- Oct 24, 2026
- Last checked
- Oct 24, 2026
- Source
- GitHubgithub-graphql
More from yimwoo
- 0.559score
skill-authoring
yimwoo
Use when creating, editing, or reviewing HOTL skills, agents, command prompts, or other behavior-shaping instruction files.
SkillCFreshness: C★ 27Claude Code +9 - 0.559score
receiving-code-review
yimwoo
Use when review findings arrive — verify each claim against the codebase and HOTL contracts before making changes.
SkillCFreshness: C★ 27Claude Code +9 - 0.558score
dispatch-agents
yimwoo
Use when you have 2+ independent tasks with no shared state — dispatches parallel subagents for each task.
SkillCFreshness: C★ 27Claude Code +9 - 0.556score
requesting-code-review
yimwoo
Use at executor review checkpoints to dispatch the code-reviewer agent with structured context — git range, workflow contracts, and verification evidence.
SkillCFreshness: C★ 27Claude Code +9 - 0.556score
pr-reviewing
yimwoo
Review a PR across multiple dimensions — description, code changes, code scan, unit tests — using parallel subagents.
SkillCFreshness: C★ 27Claude Code +9 - 0.556score
finishing-a-development-branch
yimwoo
Use after execution is complete or intentionally stopped — decide whether to merge back, publish a PR branch, keep the execution checkout, or discard it, and…
SkillCFreshness: C★ 27Claude Code +9
Cite this page
governed-execution skill. Agent Mart. https://agentmart.dev/skills/yimwoo-governed-execution (last updated 2026-10-24)