Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/yimwoo/hotl-plugin/loop-executionnpx skills add yimwoo/hotl-plugin --skill loop-executiongit clone --depth 1 https://github.com/yimwoo/hotl-pluginWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00037 | $0.06327 |
| Opus 5 | $0.00018 | $0.03164 |
| Sonnet 5 | $0.00007 | $0.01265 |
| Haiku 4.5 | $0.00004 | $0.00633 |
Grade A, and why
loop-execution scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 406 lines — stays where its author put it; the contents beside it link to each section on GitHub.
HOTL Loop Execution
Overview
Execute an existing HOTL workflow file autonomously. Canonical workflows live at docs/plans/YYYY-MM-DD-<slug>-workflow.md, with legacy root hotl-workflow-<slug>.md still accepted during migration. Loop on steps with success criteria. Auto-approve low-risk gates. Always pause for high-risk gates.
governed-execution is the preferred new router for host-native or fallback runs. This skill remains the canonical autonomous state machine and a supported explicit compatibility profile. When invoked through the router, use the selected driver for lifecycle calls and require a sufficient evidence receipt before completion.
Announce: "Starting HOTL loop execution. Looking for workflow file..."
Workflow File Resolution
Resolve which workflow file to execute:
- If the user specified a filename → use that file
- Else, glob for canonical workflows in
docs/plans/*-workflow.md:- One match → use it automatically
- Multiple matches → if one is clearly the newest revision for the same semantic slug, prefer it; otherwise list them and ask the user to pick
- If no canonical matches, glob for legacy
hotl-workflow*.mdin project root:- One match → use it automatically
- Multiple matches → list them and ask the user to pick
- No matches → see "What to Do If No Workflow Found" below
Interrupted Run Detection
After resolving the workflow file, locate interrupted runs before Branch/Worktree Preflight. Use scripts/hotl-locate-run.sh --workflow <workflow-file> when available. This helper scans the current checkout, linked git worktrees, and HOTL's default .hotl-worktrees/<repo>/ directory, so it can find state created inside an isolated execution worktree even when the new session starts from the authoring checkout.
If the helper is unavailable, manually scan these locations for .hotl/state/*.json and match workflow_path or source_workflow_path against the resolved workflow:
- Current checkout
git worktree list --porcelainroots for the repo$(dirname <repo-root>)/.hotl-worktrees/$(basename <repo-root>)/*
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 406 lines · 37 tokens per session scan A 762d8633d78c
loop-execution is a skill published in the GitHub repository yimwoo/hotl-plugin (26 stars, last pushed 1mo ago), licensed MIT. It adds 37 tokens to every session and 6,327 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
first-plan-co-change-analysis
Skill que constrói o Co-change Graph - "quando arquivo X muda, qual outro arquivo geralmente muda junto?". Use durante Discovery e em /fp:cochange. Baseado em git history. Detecta arquivos co-dependentes que devem ser editados juntos para evitar PRs incompletos. v0.3.0+ usa engine nativo Rust quando disponível…
first-plan-provenance-tracker
Skill que define o schema de proveniência e o sistema de freshness tracking para findings em .first-plan/. Use durante Discovery e refresh para registrar source (file:line@SHA), TTL, confidence inicial e cadeia de supersedeção. Aplica decay de confidence baseado em idade.
first-plan-protocol
Esta skill DEVE ser carregada em qualquer comando do plugin first-plan. Define o protocolo PLAN-FIRST (Discovery -> Plan -> Approval -> Execution -> Report), as 7 regras invioláveis e o comportamento esperado em cada fase. Ative quando o usuário invocar /fp: ou mencionar "first-plan", "context compilation", "discovery…
first-plan-reconciliation
Skill que define Spec-Code Reconciliation - matching contínuo entre artefatos de intenção (docs, specs, JIRA, GitHub issues) e implementação (código, testes, PRs). Use durante Discovery e em /fp:check para identificar feature ja implementada, em flight, drifted ou abandonada.
first-plan-git-intelligence
Skill que extrai inteligência do git history - heatmap de atividade, ownership, branches/PRs in-flight. Use durante Discovery e em /fp:hot, /fp:owner, /fp:in-flight. Tudo via comandos git read-only.
first-plan-lens-engine
Skill que define o motor de detecção e roteamento de stack lenses do first-plan. Mapeia manifestos (go.mod, package.json, etc) -> stack -> papel -> lens skill correspondente. Use quando precisar decidir qual lens aplicar a uma pasta durante Discovery, ou quando estender suporte a uma nova stack.