Use when the user explicitly asks for HOTL routing or needs guidance choosing the right HOTL workflow skill.
Scanned 9/12/2026
Install to Claude Code
npx -y skills add thedixitjain/the-mega-skill-library --skill using-hotl --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Using Hotl?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/thedixitjain-using-hotl)More formats (shields.io, HTML) on the badges page.
---
name: using-hotl
description: "Use when the user explicitly asks for HOTL routing or needs guidance choosing the right HOTL workflow skill."
category: general-purpose
source_repo: hashgraph-online/awesome-codex-plugins
source_path: "plugins/yimwoo/hotl-plugin/skills/using-hotl/SKILL.md"
source_url: https://github.com/hashgraph-online/awesome-codex-plugins/blob/HEAD/plugins/yimwoo/hotl-plugin/skills/using-hotl/SKILL.md
---
## When to Use HOTL Skills
HOTL skills are for **code-changing tasks that require planning** — new features, refactors, and significant changes. Not every task needs a skill.
**Answer directly without invoking a skill:**
- Code understanding questions — "how does this work?", "where is this defined?", "explain this error"
- Quick fixes — typos, config values, import paths, obvious one-line corrections
- Error tracing — "what does this error mean?", "which file throws this?"
**Use `hotl:systematic-debugging` (no brainstorm/plan needed):**
- Bug investigations, test failures, unexpected behavior
**Use the full HOTL workflow (brainstorm → plan → execute):**
- New features, significant refactors, architectural changes
## Available HOTL Skills
Invoke any of these when appropriate:
| Skill | When to Use |
|---|---|
| `hotl:brainstorming` | Before any feature work — design with HOTL contracts |
| `hotl:writing-plans` | After design approval — produces `docs/plans/YYYY-MM-DD-<slug>-workflow.md` |
| `hotl:governed-execution` | Preferred execution entry point — selects host driver/profile while preserving renewable ownership, bounded loops, effect evidence, and receipts |
| `hotl:executing-plans` | Linear execution with human checkpoints |
| `hotl:loop-execution` | Execute a workflow file with loops + auto-approve |
| `hotl:subagent-execution` | Delegated step runner over the loop execution engine — delegates eligible steps to fresh subagents |
| `hotl:dispatch-agents` | 2+ independent tasks that can run in parallel |
| `hotl:finishing-a-development-branch` | After execution — merge back, publish/PR, keep, or discard the execution branch/worktree |
| `hotl:tdd` | Before writing any implementation code |
| `hotl:systematic-debugging` | When encountering any bug or unexpected behavior |
| `hotl:skill-authoring` | When creating, editing, or reviewing HOTL skills, agents, commands, or behavior-shaping instructions |
| `hotl:document-review` | Optional — review existing docs, external specs, or hand-authored plans |
| `hotl:requesting-code-review` | Dispatched by executors at review checkpoints — standardizes what context the reviewer receives |
| `hotl:receiving-code-review` | Invoked when review findings arrive — verify, evaluate against contracts, then implement |
| `hotl:code-review` | After completing implementation, before merging |
| `hotl:pr-reviewing` | Review a PR across multiple dimensions — description, code, scan, tests |
| `hotl:resuming` | Resume an interrupted workflow run with verify-first effect recovery and explicit ownership takeover/handoff |
| `hotl:verification-before-completion` | Before claiming work is done |
| `hotl:setup-project` | To generate adapter files for Codex, Cline, Cursor, Copilot |
## Red Flags (You Are Over-Routing)
- Routing a code question through brainstorming → just answer it
- Creating a plan for a typo fix → just fix it and verify
- Brainstorming before debugging → use systematic-debugging directly
- Skipping brainstorming for a real feature → invoke the skill
## HOTL Operating Principles
**Human-on-the-Loop:** Set intent + constraints upfront. AI executes autonomously within guardrails. Human reviews final output.
**Long-running harness contract:** Host goals, automations, background agents, hooks, and handoffs provide scheduling and liveness only. HOTL's renewable controller, serialized state, runtime loop/budget stops, effect reconciliation, explicit finish disposition, and sufficient receipt remain authoritative.
**Three contracts every implementation workflow should define:**
1. **Intent contract:** objective, constraints, success criteria
2. **Verification contract:** how to confirm each step worked
3. **Governance contract:** approval gates, risk level, rollback strategy
---
**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/yimwoo/hotl-plugin/skills/using-hotl/SKILL.md`
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!