hotl-plugin

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.

Use when the user explicitly asks for HOTL routing or needs guidance choosing the right HOTL workflow skill.

Use after design approval to create a dated executable workflow file with bite-sized tasks, exact file paths, and loop/gate definitions.

Use to generate HOTL adapter files for the current project — creates AGENTS.md, .clinerules, cursor rules, or copilot instructions depending on tools the team uses.

Use before any feature work — explores intent, requirements, and design. Produces HOTL contracts (intent, verification, governance) before implementation.

Optional utility for reviewing existing docs, external specs, hand-authored notes, or non-HOTL documents. HOTL design docs and workflows get structural lint + AI review; other documents get AI-only review with a generic rubric.

Use when creating, editing, or reviewing HOTL skills, agents, command prompts, or other behavior-shaping instruction files.

Use after completing implementation steps and before merging — reviews against plan and HOTL contracts.

Review a PR across multiple dimensions — description, code changes, code scan, unit tests — using parallel subagents. Supports GitHub, GitLab, and enterprise platforms.

Use at executor review checkpoints to dispatch the code-reviewer agent with structured context — git range, workflow contracts, and verification evidence.

Use when you have 2+ independent tasks with no shared state — dispatches parallel subagents for each task.

Use when review findings arrive — verify each claim against the codebase and HOTL contracts before making changes. Governs how agents respond to review feedback.

Use when encountering any bug, test failure, or unexpected behavior — before proposing fixes.

Use before writing any implementation code — enforces RED-GREEN-REFACTOR cycle.

Use before claiming any work is complete, fixed, or passing — runs verification commands and confirms output before making success claims.