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:
- Intent contract: objective, constraints, success criteria
- Verification contract: how to confirm each step worked
- Governance contract: approval gates, risk level, rollback strategy
Source: hashgraph-online/awesome-codex-plugins → plugins/yimwoo/hotl-plugin/skills/using-hotl/SKILL.md
1---2name: using-hotl3description: Use when the user explicitly asks for HOTL routing or needs guidance choosing the right HOTL workflow skill.4---567## When to Use HOTL Skills89HOTL skills are for **code-changing tasks that require planning** — new features, refactors, and significant changes. Not every task needs a skill.1011**Answer directly without invoking a skill:**12- Code understanding questions — "how does this work?", "where is this defined?", "explain this error"13- Quick fixes — typos, config values, import paths, obvious one-line corrections14- Error tracing — "what does this error mean?", "which file throws this?"1516**Use `hotl:systematic-debugging` (no brainstorm/plan needed):**17- Bug investigations, test failures, unexpected behavior1819**Use the full HOTL workflow (brainstorm → plan → execute):**20- New features, significant refactors, architectural changes2122## Available HOTL Skills2324Invoke any of these when appropriate:2526| Skill | When to Use |27|---|---|28| `hotl:brainstorming` | Before any feature work — design with HOTL contracts |29| `hotl:writing-plans` | After design approval — produces `docs/plans/YYYY-MM-DD-<slug>-workflow.md` |30| `hotl:governed-execution` | Preferred execution entry point — selects host driver/profile while preserving renewable ownership, bounded loops, effect evidence, and receipts |31| `hotl:executing-plans` | Linear execution with human checkpoints |32| `hotl:loop-execution` | Execute a workflow file with loops + auto-approve |33| `hotl:subagent-execution` | Delegated step runner over the loop execution engine — delegates eligible steps to fresh subagents |34| `hotl:dispatch-agents` | 2+ independent tasks that can run in parallel |35| `hotl:finishing-a-development-branch` | After execution — merge back, publish/PR, keep, or discard the execution branch/worktree |36| `hotl:tdd` | Before writing any implementation code |37| `hotl:systematic-debugging` | When encountering any bug or unexpected behavior |38| `hotl:skill-authoring` | When creating, editing, or reviewing HOTL skills, agents, commands, or behavior-shaping instructions |39| `hotl:document-review` | Optional — review existing docs, external specs, or hand-authored plans |40| `hotl:requesting-code-review` | Dispatched by executors at review checkpoints — standardizes what context the reviewer receives |41| `hotl:receiving-code-review` | Invoked when review findings arrive — verify, evaluate against contracts, then implement |42| `hotl:code-review` | After completing implementation, before merging |43| `hotl:pr-reviewing` | Review a PR across multiple dimensions — description, code, scan, tests |44| `hotl:resuming` | Resume an interrupted workflow run with verify-first effect recovery and explicit ownership takeover/handoff |45| `hotl:verification-before-completion` | Before claiming work is done |46| `hotl:setup-project` | To generate adapter files for Codex, Cline, Cursor, Copilot |4748## Red Flags (You Are Over-Routing)4950- Routing a code question through brainstorming → just answer it51- Creating a plan for a typo fix → just fix it and verify52- Brainstorming before debugging → use systematic-debugging directly53- Skipping brainstorming for a real feature → invoke the skill5455## HOTL Operating Principles5657**Human-on-the-Loop:** Set intent + constraints upfront. AI executes autonomously within guardrails. Human reviews final output.5859**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.6061**Three contracts every implementation workflow should define:**621. **Intent contract:** objective, constraints, success criteria632. **Verification contract:** how to confirm each step worked643. **Governance contract:** approval gates, risk level, rollback strategy6566---6768**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/yimwoo/hotl-plugin/skills/using-hotl/SKILL.md`
hashgraph-online