# Subagent Execution

> Delegated step runner over the HOTL execution state machine — delegates eligible steps to fresh subagents while the controller keeps governance, verification, and stop conditions.

- Skill: `thedixitjain/subagent-execution` (Agent Skill)
- Install (CLI): `npx skillmds add thedixitjain/subagent-execution`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thedixitjain/subagent-execution/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thedixitjain (https://skillmd.com/u/thedixitjain)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/thedixitjain/subagent-execution

---



# HOTL Subagent Execution

## Overview

This is a **delegation profile** over the HOTL execution state machine defined in `skills/loop-execution/SKILL.md`. It follows the same resolve → preflight → lint → execute → verify → loop → gate → summarize flow, but eligible steps are delegated to fresh subagents instead of running inline.

When selected by `governed-execution`, the controller uses the chosen driver for all durable transitions and remains responsible for ownership, action gates and effect outcomes, budgets, verification, receipts, and recovery. Native or background-agent success is never sufficient by itself.

**Core principle:** delegation is allowed; governance is not delegated.

## When to Use

- The workflow file already exists (canonical `docs/plans/YYYY-MM-DD-<slug>-workflow.md` preferred; legacy root `hotl-workflow-<slug>.md` still accepted during migration)
- Steps are independent enough to hand to one worker at a time
- You want the controller to stay in this session and keep ownership of gates and verification

## Execution

Follow the **HOTL Execution State Machine** in `skills/loop-execution/SKILL.md` for the full execution flow (workflow resolution, interrupted run detection, branch/worktree preflight, structural lint, execution state persistence, typed verification, loop rules, gate rules, completion).

The controller owns all `hotl-rt` runtime calls. It initializes with `--require-owner`, runs `owner claim`, retains the one-time token only in `HOTL_OWNER_TOKEN`, and runs `owner heartbeat` before dispatch, after a worker returns, and at safe transition boundaries. It calls `hotl-rt step N start/verify/retry/block`, `hotl-rt gate N`, sensitive-action lifecycle commands, budget checks, `hotl-rt finalize`, and `hotl-rt finish` from the resolved `execution_root`, pinning every call to the captured `run_id` (`--run-id <run-id>` or `HOTL_RUN_ID=<run-id>`). Subagents never receive the owner token and never call the runtime directly. The runtime-managed `.hotl/state/<run-id>.json` and `.hotl/reports/<run-id>.md` are the source of truth; delegated workers do implementation only.

Host background subagents, goals, handoffs, hooks, and agent dashboards provide scheduling and liveness only. The controller must persist every transition. Stable host features may be used when available; preview or experimental agent views/teams remain opt-in.

Sensitive effects stay controller-owned: run `action request` with a stable idempotency key and human `action decide`; persist `action begin` before the external operation and `action complete` with evidence afterward. If a worker or controller is interrupted around the effect, inspect the target and run `action reconcile`; never ask another worker to replay an `in_progress` or `uncertain` effect.

The only difference is **how each step body runs:**

1. Announce the step
2. Decide whether to delegate or run inline (see Delegation Rules below)
3. If delegated:
   - Run `owner heartbeat` immediately before dispatch and after the worker returns; if the lease cannot remain renewable, stop at a durable boundary instead of leaving an unowned mutation path
   - Dispatch a fresh subagent with the full step text, the relevant files, and the success condition
   - Do not make the subagent infer the plan from scratch — provide the step directly
   - Require the delegated worker to return one of the statuses defined below
   - Answer clarifying questions before letting the subagent continue
4. If inline: execute the step directly in the controller session
5. Run verification, loop rules, and gate rules as defined in the state machine

## Delegated Worker Prompt Requirements

Every delegated implementation prompt must include:

- Full workflow step text, including `action`, `loop`, `verify`, `gate`, and any relevant frontmatter context
- Exact files or directories the worker may inspect or edit
- The success condition in plain language
- A reminder that the worker is not alone in the codebase and must not revert unrelated changes
- A reminder that the worker must not call `hotl-rt`, mark workflow checkboxes, run gates, or finalize the run
- A reminder that the worker must never receive, request, log, or infer `HOTL_OWNER_TOKEN`
- The required report format:

```
Status: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
Summary:
Files changed:
Tests or checks run:
Concerns or blockers:
```

## Handling Worker Status

Treat the worker's status as an input to controller judgment, not as proof of completion.

**DONE:** Continue with controller-owned verification for the step.

**DONE_WITH_CONCERNS:** Read the concerns before verification. If they raise correctness, scope, safety, or architecture risk, address them before marking the step verified. If they are non-blocking observations, record them in the runtime report and continue to verification.

**NEEDS_CONTEXT:** Provide the missing context and re-dispatch the same step. Do not count this as a failed loop iteration unless the worker had enough context and still could not proceed.

**BLOCKED:** Stop the step and assess the blocker. Options are: provide more context, split the step, run the step inline in the controller, or mark the step blocked through `hotl-rt step ... block`. Do not retry the same prompt unchanged.

Never mark a delegated step complete from the worker report alone. The controller must inspect the changed files as needed, run the configured verification, apply loop rules, and record the result with the pinned `run_id`.

## Critical Invariants

These rules apply regardless of delegation decisions:

1. **Verification always runs in the controller session** — never in the subagent
2. **Gates always stay in the controller session** — `gate: human` pauses the controller, not the subagent
3. **No nested delegation** — subagents cannot spawn other subagents
4. **No parallel write-heavy steps** — do not run multiple implementation subagents in parallel against the same workflow
5. **Controller owns stop conditions** — on repeated verify failure, the controller stops and reports; it does not let the subagent retry silently
6. **Controller owns sensitive effects** — workers may prepare local inputs, but the controller performs the `action begin` / effect / `action complete` sequence and uses `action reconcile` after uncertainty
7. **Completion requires disposition** — successful `hotl-rt finalize` produces `ready_to_finish`; only explicit `finish` produces `completed` and a sufficient receipt

## Delegation Rules

**Delegate by default:**
- Test-writing steps
- Implementation steps
- Localized documentation changes
- Contained refactors

**Keep controller-owned by default:**
- Human-gated steps
- Security-sensitive decisions
- Final verification and summaries
- Any step whose failure would require architectural judgment

## Review Checkpoints

Record `git rev-parse HEAD` as the review base before delegating each reviewable batch.

### After Meaningful Delegated Batches

After a meaningful batch of delegated implementation completes and verification passes:
1. Invoke `requesting-code-review` from the controller (not from a subagent)
   - Review type: checkpoint
   - Review base: the recorded pre-batch HEAD
   - Steps reviewed: all steps completed in this batch
2. When findings return, invoke `receiving-code-review` in the controller
   - Follow Verify → Evaluate → Respond → Implement
3. Resolve all BLOCK findings before delegating the next batch

Review is not required after every single delegated step. The controller decides when a batch is "meaningful" based on:
- 3+ completed implementation steps
- Cross-module changes
- High-risk, user-facing, or shared-infra changes

### Before Final Completion

A final review is required unless the most recent review already covers all current changes and no code changed afterward.

1. Invoke `requesting-code-review` with review type: final
   - Review base: branch point or last review base, whichever is more recent
2. When findings return, invoke `receiving-code-review`
3. Resolve all BLOCK findings before finalizing
4. If fixes after the last review changed scope, constraints, or risk_level, request a scoped follow-up review before completing

Review happens after step verification, before `verification-before-completion`, before `hotl-rt finalize`.

After finalize returns `ready_to_finish`, use `hotl:finishing-a-development-branch` with the same run id and owner token. After explicit finish, release ownership and require a sufficient receipt before claiming completion.

## Reporting

Execution report output must conform to `docs/contracts/execution-report-output.md`. This is the canonical reporting contract from `skills/loop-execution/SKILL.md`. Live step visibility follows the same rules as `skills/loop-execution/SKILL.md` — per-step chat logs on all platforms, deterministic renderer for final summary.

## Related Skills

- `hotl:loop-execution` — the canonical execution state machine (this skill builds on it)
- `hotl:verification-before-completion` — required before claiming done
- `hotl:dispatch-agents` — use for generic parallel independent tasks, not governed workflow execution

---

**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/yimwoo/hotl-plugin/skills/subagent-execution/SKILL.md`