القائمة
Use when the user explicitly asks for HOTL routing or needs guidance choosing the right HOTL workflow skill.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
Resume an interrupted workflow run with verify-first strategy — loads sidecar state, verifies the last step, and continues execution.
Use when executing an implementation plan linearly with explicit human checkpoints between batches of tasks.
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 record that disposition in HOTL state.
Use when executing an accepted HOTL workflow through the best available host or fallback driver.
Delegated step runner over the HOTL execution state machine — delegates eligible steps to fresh subagents while the controller keeps governance, verification, and stop conditions.
| name | using-hotl |
| description | Use when the user explicitly asks for HOTL routing or needs guidance choosing the right HOTL workflow skill. |
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:
Use hotl:systematic-debugging (no brainstorm/plan needed):
Use the full HOTL workflow (brainstorm → plan → execute):
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 |
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:
