[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MP8F7VWRPHTSQF2NF76RTB":3,"skill-same:01M6MP8F7VWRPHTSQF2NF76RTB":60},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":41,"ownerHtmlUrl":42,"ownerBlogUrl":43,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M6MP8F7VWRPHTSQF2NF76RTB","executing-plans",null,"Use when executing an implementation plan linearly with explicit human checkpoints between batches of tasks.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1554,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fyimwoo\u002Fhotl-plugin\u002Fskills\u002Fexecuting-plans\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30],"executing plans","plans","tasks","plan","use","implementation","human","with","batches","checkpoints","implementation plan","when","2026-11-10 10:12:30",false,"---\nname: executing-plans\ndescription: Use when executing an implementation plan linearly with explicit human checkpoints between batches of tasks.\n---\n\n# Executing Plans (Linear with Checkpoints)\n\nExecute the plan task by task. Pause after every 3 tasks for human review.\n\nThis remains the explicit manual-checkpoint profile. New host-native or fallback runs may enter through `governed-execution`; when they do, use its selected driver for lifecycle calls, sensitive-action decisions, budgets, receipts, and reconciliation while preserving every checkpoint in this skill.\n\n## Workflow File Resolution\n\nResolve which workflow file to execute:\n\n1. If the user specified a filename → use that file\n2. Else, glob for canonical workflows in `docs\u002Fplans\u002F*-workflow.md`:\n   - **One match** → use it automatically\n   - **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\n3. If no canonical matches, glob for legacy `hotl-workflow*.md` in project root:\n   - **One match** → use it automatically\n   - **Multiple matches** → list them and ask the user to pick\n4. **No matches** → stop and ask the user to create or name a workflow file\n\n## Branch\u002FWorktree Preflight\n\nAfter resolving the workflow file, run this preflight **before executing any steps**:\n\n```\n1. Is this a git repo with at least one commit?\n   - No  → log \"Skipping branch setup (no git history)\" → proceed to step execution\n   - Yes → continue\n\n2. Check for uncommitted changes\n   - First, exclude HOTL-owned transient artifacts from the dirty check:\n     • docs\u002Fplans\u002F*-workflow.md (canonical workflow files)\n     • hotl-workflow-*.md (legacy workflow files)\n     • docs\u002Fdesigns\u002F*.md (canonical design docs from brainstorming)\n     • docs\u002Fplans\u002F*-design.md, docs\u002Fplans\u002F*-plan.md (legacy design docs from brainstorming)\n     • .hotl\u002F (runtime state, reports, cache)\n   - If only HOTL artifacts are dirty → treat as clean, continue\n   - If non-HOTL dirty files exist:\n     • If dirty_worktree: allow in workflow frontmatter → proceed without prompting\n     • Otherwise → HARD-FAIL. Tell the user which non-HOTL files are dirty. Offer choices:\n       a. Clean up manually, then re-run\n       b. Stash manually, then re-run\n       c. Explicitly approve HOTL to stash and continue\n   - Clean → continue\n\n3. Determine branch name\n   - If branch: field exists in workflow frontmatter → use it\n   - Otherwise → derive `hotl\u002F\u003Cslug>` from the workflow filename\n     • Canonical: strip `YYYY-MM-DD-` prefix and `-workflow.md` suffix from `docs\u002Fplans\u002FYYYY-MM-DD-\u003Cslug>-workflow.md`\n     • Legacy: strip `hotl-workflow-` prefix and `.md` suffix from `hotl-workflow-\u003Cslug>.md`\n\n4. Capture authoring origin\n   - Record the current branch name (if any) and current `HEAD` commit as the workflow's authoring origin\n   - If the current branch is neither `main` nor `master`, and the workflow frontmatter does not already set `branch:` or `worktree:`, PAUSE and ask:\n     a. Continue on the current branch in this checkout\n        → set `branch: \u003Ccurrent-branch>` and `worktree: false`\n     b. Use HOTL's isolated execution branch\u002Fworktree (recommended)\n        → leave `worktree: true` and let HOTL derive `hotl\u002F\u003Cslug>` unless the user wants a custom branch name\n     c. Use a custom execution branch\n        → set `branch: \u003Cuser-branch>` and keep worktree isolation unless the user explicitly opts out\n   - Explain clearly: the authoring checkout and the execution checkout can differ. HOTL can execute in a separate worktree while leaving the current checkout untouched\n\n5. Determine isolation mode\n   - If `worktree: host` in frontmatter → stay on the current checkout's current feature branch exactly as provided by the host tool; reject `main` and `master`\n   - If `worktree: false` in frontmatter → stay in the current checkout and use a dedicated branch there\n   - If the current checkout is already a named linked git worktree, and the workflow frontmatter does not set `branch:` or `worktree:`, use host mode automatically to avoid stacking another worktree\n   - Otherwise → use an isolated git worktree by default\n\n6. Check if the target branch\u002Fworktree already exists locally\n   - Current helper behavior: existing branch\u002Fworktree collisions are a hard stop, not an interactive reuse\u002Frecreate flow\n   - If the helper reports an existing branch\u002Fworktree conflict, stop and ask the user whether to reuse manually, delete+recreate manually, or abort\n   - Does not exist → create (no prompt)\n\n7. Resolve the execution root with `scripts\u002Fhotl-prepare-execution-root.sh \u003Cworkflow-file> --executor-mode \u003Cmode>`\n   - The helper returns JSON with: `branch`, `repo_root`, `execution_root`, `workflow_path`, `source_workflow_path`, `source_branch`, `source_head`, `worktree_path`\n   - By default it creates a linked git worktree for the branch, copies the current workflow into that worktree, and returns that worktree as `execution_root`\n   - If `worktree: false` in frontmatter → create\u002Fswitch to the dedicated branch in the current checkout and return the repo root as `execution_root`\n   - If `worktree: host` in frontmatter → keep the current branch and return the current checkout as `execution_root`; if `branch:` is set, it must match the current branch\n   - If `branch:` matches the currently checked-out branch while worktree isolation is still enabled, the helper must STOP with a clear message telling the user to set `worktree: false` or `worktree: host` for same-branch continuity\n8. Change into `execution_root`\n   - Every later git command, runtime call, Codex helper call, and review command for this run MUST execute from that directory\n```\n\n**Rules:**\n- No auto-stash. Hidden state mutation weakens governance.\n- Existing branch\u002Fworktree collisions do not currently auto-prompt; treat them as a stop-and-ask condition until interactive reuse\u002Frecreate is implemented.\n- Non-git repos skip entirely — HOTL works without git ceremony.\n- Run HOTL structural lint (`scripts\u002Fdocument-lint.sh`) automatically on the workflow file before any git mutation or step execution. If lint fails, STOP and show all errors. If lint passes, continue silently.\n\n## Typed Verification\n\nThe `verify` field supports 4 types. A scalar string is shorthand for `type: shell`. If `verify` is a list, ALL checks must pass.\n\n- **type: shell** — run command, check exit code, capture stdout\u002Fstderr\n- **type: browser** — use browser tooling with url+check; if unavailable, downgrade to type: human-review with check text as prompt\n- **type: human-review** — `hotl-rt step N verify` returns a `human review required: ...` block reason and pauses the run; show the prompt, wait for approval, then persist it with `hotl-rt gate N approved|rejected --mode human` (never auto-approve)\n- **type: artifact** — check path exists, evaluate assert (kind: exists | contains | matches-glob)\n  For `matches-glob`, `path` must be the directory and `value` must be a filename glob only; values like `src\u002F*` are invalid and should be authored as `path: src`\n\n## Execution State Persistence\n\nAll state persistence is handled by the `hotl-rt` shared runtime (`runtime\u002Fhotl-rt`). This executor calls `hotl-rt` for all state transitions and keeps the claimed controller token in `HOTL_OWNER_TOKEN`:\n\n- `hotl-rt init \u003Cworkflow-file> --require-owner --executor-mode executing-plans ...` — at run start\n- `hotl-rt owner claim ...` and renewable `hotl-rt owner heartbeat ...` — controller coordination\n- `hotl-rt step N start --run-id \u003Crun-id>` — before each step\n- `hotl-rt step N verify --run-id \u003Crun-id>` — after each step's action\n- `hotl-rt step N retry --run-id \u003Crun-id>` \u002F `hotl-rt step N block --reason \"...\" --run-id \u003Crun-id>` — on failure\n- `hotl-rt gate N approved|rejected --run-id \u003Crun-id>` — at gate steps\n- `hotl-rt action request|decide|begin|complete|reconcile ...` — sensitive authorization and effect evidence\n- `hotl-rt budget check --run-id \u003Crun-id>` — before another costly or long action when telemetry is relevant\n- `hotl-rt finalize --json --run-id \u003Crun-id>` — after all execution evidence is complete; successful runs become `ready_to_finish`\n- `hotl-rt finish \u003Cdisposition> --run-id \u003Crun-id>` — after the user selects the explicit disposition; successful runs then become `completed`\n\nThe runtime owns `.hotl\u002Fstate\u002F\u003Crun-id>.json` and `.hotl\u002Freports\u002F\u003Crun-id>.md`. Agents do not manage these files directly. Runtime calls happen before the corresponding chat or progress UI update.\n\nUse the same HOTL runtime and script path resolution order defined in `skills\u002Floop-execution\u002FSKILL.md`. Do not assume `runtime\u002F` or `scripts\u002F` exist in the user's project checkout.\n\nTo resume an interrupted executing-plans run, use the host tool's native resume entry point.\n- **Codex:** ask me to use `$hotl:resuming` on the workflow file\n- **Claude Code:** `\u002Fhotl:resume \u003Cworkflow-file>`\n\n### Long-running controller and effect rules\n\n- Immediately after init, run `hotl-rt owner claim --owner \u003Cstable-controller-id> --lease-seconds \u003Cbounded-lease> --run-id \u003Crun-id>`, parse its one-time token without displaying it, export it as `HOTL_OWNER_TOKEN`, and heartbeat before and after long actions and at batch boundaries. Every later mutation inherits the token.\n- If control must move, use explicit `owner handoff`, `owner release`, or reviewed `owner takeover`. Age alone is never takeover authority.\n- Host goals, automations, background sessions, handoffs, and hooks provide scheduling and liveness only. HOTL state, verification, ownership, and receipts remain authoritative.\n- For each sensitive effect, use `action request` with a stable idempotency key, human `action decide`, then `action begin` before the external operation and `action complete` with evidence afterward. If the outcome is interrupted or uncertain, inspect the target and use `action reconcile`; do not replay it blindly.\n\n## Process\n\n1. Resolve and read the workflow (see above)\n2. Run Branch\u002FWorktree Preflight (see above), capture its JSON result, and change into `execution_root`\n3. Run `hotl-rt init \u003Cworkflow-file> --require-owner --executor-mode executing-plans --repo-root \u003Crepo-root> --execution-root \u003Cexecution-root> --source-workflow-path \u003Csource-workflow-path> --source-branch \u003Csource-branch|null> --source-head \u003Csource-head|null> --worktree-path \u003Cworktree-path|null> --branch \u003Cbranch>` to initialize state and report\n4. Capture the run id, claim ownership, retain the raw token only as `HOTL_OWNER_TOKEN`, and pass `--run-id \u003Crun-id>` (or set `HOTL_RUN_ID=\u003Crun-id>`) on every later runtime\u002Fhelper call for this run\n5. Execute tasks in order, 3 at a time:\n   - `hotl-rt step N start --run-id \u003Crun-id>` before each step\n   - Execute the action\n   - `hotl-rt step N verify --run-id \u003Crun-id>` to run typed verification\n   - If verify reports `human review required: ...`, pause and do not continue until `hotl-rt gate N approved|rejected --mode human --run-id \u003Crun-id>` succeeds\n   - On failure: `hotl-rt step N retry --run-id \u003Crun-id>` or `hotl-rt step N block --reason \"...\" --run-id \u003Crun-id>`\n   - On gate: `hotl-rt gate N approved|rejected --run-id \u003Crun-id>`\n6. After each batch: run review checkpoint (see below), then show what was done, ask \"Continue to next batch?\"\n7. On failure: stop and report — never silently skip a failed step\n8. When execution evidence is complete: run final review checkpoint (see below), invoke `hotl:verification-before-completion`, then `hotl-rt finalize --json --run-id \u003Crun-id>`. Treat `ready_to_finish` as awaiting disposition, render the verified-step summary, and invoke `hotl:finishing-a-development-branch` with the same `run_id` and owner token.\n9. After explicit finish moves a successful run to `completed`, release ownership, require a sufficient receipt, and only then claim completion.\n\n## Review Checkpoints\n\nRecord `git rev-parse HEAD` as the review base before starting each batch.\n\n### After Each Batch\n\nAfter all steps in the batch have passed verification:\n1. Invoke `requesting-code-review` to dispatch the `code-reviewer` agent\n   - Review type: checkpoint\n   - Review base: the recorded pre-batch HEAD\n   - Steps reviewed: the batch step numbers\n2. When findings return, invoke `receiving-code-review`\n   - Follow Verify → Evaluate → Respond → Implement\n3. Resolve all BLOCK findings before proceeding to the next batch\n\n### Before Final Completion\n\nA final review is required unless the most recent review already covers all current changes and no code changed afterward.\n\n1. Invoke `requesting-code-review` with review type: final\n   - Review base: branch point or last review base, whichever is more recent\n2. When findings return, invoke `receiving-code-review`\n3. Resolve all BLOCK findings before finalizing\n4. If fixes after the last review changed scope, constraints, or risk_level, request a scoped follow-up review before completing\n\nReview happens after step verification, before `verification-before-completion`, before `hotl-rt finalize`.\n\nUse this over `loop-execution` when you want explicit human checkpoints at every stage rather than auto-approve.\n\n## Reporting\n\nExecution report output must conform to `docs\u002Fcontracts\u002Fexecution-report-output.md`. This is the canonical reporting contract from `skills\u002Floop-execution\u002FSKILL.md`. Live step visibility follows the same rules as `skills\u002Floop-execution\u002FSKILL.md` — per-step chat logs on all platforms, deterministic renderer for final summary.\n","# Executing Plans (Linear with Checkpoints)\n\nExecute the plan task by task. Pause after every 3 tasks for human review.\n\nThis remains the explicit manual-checkpoint profile. New host-native or fallback runs may enter through `governed-execution`; when they do, use its selected driver for lifecycle calls, sensitive-action decisions, budgets, receipts, and reconciliation while preserving every checkpoint in this skill.\n\n## Workflow File Resolution\n\nResolve which workflow file to execute:\n\n1. If the user specified a filename → use that file\n2. Else, glob for canonical workflows in `docs\u002Fplans\u002F*-workflow.md`:\n   - **One match** → use it automatically\n   - **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\n3. If no canonical matches, glob for legacy `hotl-workflow*.md` in project root:\n   - **One match** → use it automatically\n   - **Multiple matches** → list them and ask the user to pick\n4. **No matches** → stop and ask the user to create or name a workflow file\n\n## Branch\u002FWorktree Preflight\n\nAfter resolving the workflow file, run this preflight **before executing any steps**:\n\n```\n1. Is this a git repo with at least one commit?\n   - No  → log \"Skipping branch setup (no git history)\" → proceed to step execution\n   - Yes → continue\n\n2. Check for uncommitted changes\n   - First, exclude HOTL-owned transient artifacts from the dirty check:\n     • docs\u002Fplans\u002F*-workflow.md (canonical workflow files)\n     • hotl-workflow-*.md (legacy workflow files)\n     • docs\u002Fdesigns\u002F*.md (canonical design docs from brainstorming)\n     • docs\u002Fplans\u002F*-design.md, docs\u002Fplans\u002F*-plan.md (legacy design docs from brainstorming)\n     • .hotl\u002F (runtime state, reports, cache)\n   - If only HOTL artifacts are dirty → treat as clean, continue\n   - If non-HOTL dirty files exist:\n     • If dirty_worktree: allow in workflow frontmatter → proceed without prompting\n     • Otherwise → HARD-FAIL. Tell the user which non-HOTL files are dirty. Offer choices:\n       a. Clean up manually, then re-run\n       b. Stash manually, then re-run\n       c. Explicitly approve HOTL to stash and continue\n   - Clean → continue\n\n3. Determine branch name\n   - If branch: field exists in workflow frontmatter → use it\n   - Otherwise → derive `hotl\u002F\u003Cslug>` from the workflow filename\n     • Canonical: strip `YYYY-MM-DD-` prefix and `-workflow.md` suffix from `docs\u002Fplans\u002FYYYY-MM-DD-\u003Cslug>-workflow.md`\n     • Legacy: strip `hotl-workflow-` prefix and `.md` suffix from `hotl-workflow-\u003Cslug>.md`\n\n4. Capture authoring origin\n   - Record the current branch name (if any) and current `HEAD` commit as the workflow's authoring origin\n   - If the current branch is neither `main` nor `master`, and the workflow frontmatter does not already set `branch:` or `worktree:`, PAUSE and ask:\n     a. Continue on the current branch in this checkout\n        → set `branch: \u003Ccurrent-branch>` and `worktree: false`\n     b. Use HOTL's isolated execution branch\u002Fworktree (recommended)\n        → leave `worktree: true` and let HOTL derive `hotl\u002F\u003Cslug>` unless the user wants a custom branch name\n     c. Use a custom execution branch\n        → set `branch: \u003Cuser-branch>` and keep worktree isolation unless the user explicitly opts out\n   - Explain clearly: the authoring checkout and the execution checkout can differ. HOTL can execute in a separate worktree while leaving the current checkout untouched\n\n5. Determine isolation mode\n   - If `worktree: host` in frontmatter → stay on the current checkout's current feature branch exactly as provided by the host tool; reject `main` and `master`\n   - If `worktree: false` in frontmatter → stay in the current checkout and use a dedicated branch there\n   - If the current checkout is already a named linked git worktree, and the workflow frontmatter does not set `branch:` or `worktree:`, use host mode automatically to avoid stacking another worktree\n   - Otherwise → use an isolated git worktree by default\n\n6. Check if the target branch\u002Fworktree already exists locally\n   - Current helper behavior: existing branch\u002Fworktree collisions are a hard stop, not an interactive reuse\u002Frecreate flow\n   - If the helper reports an existing branch\u002Fworktree conflict, stop and ask the user whether to reuse manually, delete+recreate manually, or abort\n   - Does not exist → create (no prompt)\n\n7. Resolve the execution root with `scripts\u002Fhotl-prepare-execution-root.sh \u003Cworkflow-file> --executor-mode \u003Cmode>`\n   - The helper returns JSON with: `branch`, `repo_root`, `execution_root`, `workflow_path`, `source_workflow_path`, `source_branch`, `source_head`, `worktree_path`\n   - By default it creates a linked git worktree for the branch, copies the current workflow into that worktree, and returns that worktree as `execution_root`\n   - If `worktree: false` in frontmatter → create\u002Fswitch to the dedicated branch in the current checkout and return the repo root as `execution_root`\n   - If `worktree: host` in frontmatter → keep the current branch and return the current checkout as `execution_root`; if `branch:` is set, it must match the current branch\n   - If `branch:` matches the currently checked-out branch while worktree isolation is still enabled, the helper must STOP with a clear message telling the user to set `worktree: false` or `worktree: host` for same-branch continuity\n8. Change into `execution_root`\n   - Every later git command, runtime call, Codex helper call, and review command for this run MUST execute from that directory\n```\n\n**Rules:**\n- No auto-stash. Hidden state mutation weakens governance.\n- Existing branch\u002Fworktree collisions do not currently auto-prompt; treat them as a stop-and-ask condition until interactive reuse\u002Frecreate is implemented.\n- Non-git repos skip entirely — HOTL works without git ceremony.\n- Run HOTL structural lint (`scripts\u002Fdocument-lint.sh`) automatically on the workflow file before any git mutation or step execution. If lint fails, STOP and show all errors. If lint passes, continue silently.\n\n## Typed Verification\n\nThe `verify` field supports 4 types. A scalar string is shorthand for `type: shell`. If `verify` is a list, ALL checks must pass.\n\n- **type: shell** — run command, check exit code, capture stdout\u002Fstderr\n- **type: browser** — use browser tooling with url+check; if unavailable, downgrade to type: human-review with check text as prompt\n- **type: human-review** — `hotl-rt step N verify` returns a `human review required: ...` block reason and pauses the run; show the prompt, wait for approval, then persist it with `hotl-rt gate N approved|rejected --mode human` (never auto-approve)\n- **type: artifact** — check path exists, evaluate assert (kind: exists | contains | matches-glob)\n  For `matches-glob`, `path` must be the directory and `value` must be a filename glob only; values like `src\u002F*` are invalid and should be authored as `path: src`\n\n## Execution State Persistence\n\nAll state persistence is handled by the `hotl-rt` shared runtime (`runtime\u002Fhotl-rt`). This executor calls `hotl-rt` for all state transitions and keeps the claimed controller token in `HOTL_OWNER_TOKEN`:\n\n- `hotl-rt init \u003Cworkflow-file> --require-owner --executor-mode executing-plans ...` — at run start\n- `hotl-rt owner claim ...` and renewable `hotl-rt owner heartbeat ...` — controller coordination\n- `hotl-rt step N start --run-id \u003Crun-id>` — before each step\n- `hotl-rt step N verify --run-id \u003Crun-id>` — after each step's action\n- `hotl-rt step N retry --run-id \u003Crun-id>` \u002F `hotl-rt step N block --reason \"...\" --run-id \u003Crun-id>` — on failure\n- `hotl-rt gate N approved|rejected --run-id \u003Crun-id>` — at gate steps\n- `hotl-rt action request|decide|begin|complete|reconcile ...` — sensitive authorization and effect evidence\n- `hotl-rt budget check --run-id \u003Crun-id>` — before another costly or long action when telemetry is relevant\n- `hotl-rt finalize --json --run-id \u003Crun-id>` — after all execution evidence is complete; successful runs become `ready_to_finish`\n- `hotl-rt finish \u003Cdisposition> --run-id \u003Crun-id>` — after the user selects the explicit disposition; successful runs then become `completed`\n\nThe runtime owns `.hotl\u002Fstate\u002F\u003Crun-id>.json` and `.hotl\u002Freports\u002F\u003Crun-id>.md`. Agents do not manage these files directly. Runtime calls happen before the corresponding chat or progress UI update.\n\nUse the same HOTL runtime and script path resolution order defined in `skills\u002Floop-execution\u002FSKILL.md`. Do not assume `runtime\u002F` or `scripts\u002F` exist in the user's project checkout.\n\nTo resume an interrupted executing-plans run, use the host tool's native resume entry point.\n- **Codex:** ask me to use `$hotl:resuming` on the workflow file\n- **Claude Code:** `\u002Fhotl:resume \u003Cworkflow-file>`\n\n### Long-running controller and effect rules\n\n- Immediately after init, run `hotl-rt owner claim --owner \u003Cstable-controller-id> --lease-seconds \u003Cbounded-lease> --run-id \u003Crun-id>`, parse its one-time token without displaying it, export it as `HOTL_OWNER_TOKEN`, and heartbeat before and after long actions and at batch boundaries. Every later mutation inherits the token.\n- If control must move, use explicit `owner handoff`, `owner release`, or reviewed `owner takeover`. Age alone is never takeover authority.\n- Host goals, automations, background sessions, handoffs, and hooks provide scheduling and liveness only. HOTL state, verification, ownership, and receipts remain authoritative.\n- For each sensitive effect, use `action request` with a stable idempotency key, human `action decide`, then `action begin` before the external operation and `action complete` with evidence afterward. If the outcome is interrupted or uncertain, inspect the target and use `action reconcile`; do not replay it blindly.\n\n## Process\n\n1. Resolve and read the workflow (see above)\n2. Run Branch\u002FWorktree Preflight (see above), capture its JSON result, and change into `execution_root`\n3. Run `hotl-rt init \u003Cworkflow-file> --require-owner --executor-mode executing-plans --repo-root \u003Crepo-root> --execution-root \u003Cexecution-root> --source-workflow-path \u003Csource-workflow-path> --source-branch \u003Csource-branch|null> --source-head \u003Csource-head|null> --worktree-path \u003Cworktree-path|null> --branch \u003Cbranch>` to initialize state and report\n4. Capture the run id, claim ownership, retain the raw token only as `HOTL_OWNER_TOKEN`, and pass `--run-id \u003Crun-id>` (or set `HOTL_RUN_ID=\u003Crun-id>`) on every later runtime\u002Fhelper call for this run\n5. Execute tasks in order, 3 at a time:\n   - `hotl-rt step N start --run-id \u003Crun-id>` before each step\n   - Execute the action\n   - `hotl-rt step N verify --run-id \u003Crun-id>` to run typed verification\n   - If verify reports `human review required: ...`, pause and do not continue until `hotl-rt gate N approved|rejected --mode human --run-id \u003Crun-id>` succeeds\n   - On failure: `hotl-rt step N retry --run-id \u003Crun-id>` or `hotl-rt step N block --reason \"...\" --run-id \u003Crun-id>`\n   - On gate: `hotl-rt gate N approved|rejected --run-id \u003Crun-id>`\n6. After each batch: run review checkpoint (see below), then show what was done, ask \"Continue to next batch?\"\n7. On failure: stop and report — never silently skip a failed step\n8. When execution evidence is complete: run final review checkpoint (see below), invoke `hotl:verification-before-completion`, then `hotl-rt finalize --json --run-id \u003Crun-id>`. Treat `ready_to_finish` as awaiting disposition, render the verified-step summary, and invoke `hotl:finishing-a-development-branch` with the same `run_id` and owner token.\n9. After explicit finish moves a successful run to `completed`, release ownership, require a sufficient receipt, and only then claim completion.\n\n## Review Checkpoints\n\nRecord `git rev-parse HEAD` as the review base before starting each batch.\n\n### After Each Batch\n\nAfter all steps in the batch have passed verification:\n1. Invoke `requesting-code-review` to dispatch the `code-reviewer` agent\n   - Review type: checkpoint\n   - Review base: the recorded pre-batch HEAD\n   - Steps reviewed: the batch step numbers\n2. When findings return, invoke `receiving-code-review`\n   - Follow Verify → Evaluate → Respond → Implement\n3. Resolve all BLOCK findings before proceeding to the next batch\n\n### Before Final Completion\n\nA final review is required unless the most recent review already covers all current changes and no code changed afterward.\n\n1. Invoke `requesting-code-review` with review type: final\n   - Review base: branch point or last review base, whichever is more recent\n2. When findings return, invoke `receiving-code-review`\n3. Resolve all BLOCK findings before finalizing\n4. If fixes after the last review changed scope, constraints, or risk_level, request a scoped follow-up review before completing\n\nReview happens after step verification, before `verification-before-completion`, before `hotl-rt finalize`.\n\nUse this over `loop-execution` when you want explicit human checkpoints at every stage rather than auto-approve.\n\n## Reporting\n\nExecution report output must conform to `docs\u002Fcontracts\u002Fexecution-report-output.md`. This is the canonical reporting contract from `skills\u002Floop-execution\u002FSKILL.md`. Live step visibility follows the same rules as `skills\u002Floop-execution\u002FSKILL.md` — per-step chat logs on all platforms, deterministic renderer for final summary.\n",{"name":5,"description":7},"main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002Fyimwoo\u002Fhotl-plugin\u002Fskills\u002Fexecuting-plans",468,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-11 02:22:54",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill executing-plans",{"tool":52,"command":53},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill executing-plans",{"tool":55,"command":56},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill executing-plans","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fyimwoo\u002Fhotl-plugin\u002Fskills\u002Fexecuting-plans\u002FSKILL.md",true,[],[61,87,111,145,165,179],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":31},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[68,69,70,71,72,73,74,75,76,77,78,30,79,80,81,82,83,84,85,86],"search","deja search","error","ready","never","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":31},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[94,95,96,97,73,98,99,100,101,102,103,104,105,82,26,106,107,108,109,110],"reflect","deja reflect","brew","remember","project rules","project","session","end","reflection","Rules","decisions","review","record","github","next","https","node",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":128,"publishedAt":31},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[117,122,125],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":123,"categoryName":124,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":126,"categoryName":127,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000023","Skill与智能体开发",[113,129,130,131,132,133,99,134,74,135,136,137,138,30,139,140,141,142,143,144],"Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","URL","image","mcp server","schedule","api","publish",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":31},"01M71569ZM2X3H5RBFK8PVKMK2","review-study","Review a QuestionPunk survey before launch for wording, answer choices, branching, and missing settings. Use for check my survey or review this draft before publishing.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Freview-study\u002FSKILL.md",[],[152,153,105,154,155,156,157,158,23,159,160,161,162,163,164],"study","review study","for","answer","missing","survey","publishing","check","draft","settings","launch","my","branching",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":31},"01M71567GV0C35YQBY0DPGR86B","manage-study","Find QuestionPunk studies, check status, publish an explicitly requested draft, or retrieve its participant link. Use for find my survey, publish this study, or how many people responded.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Fmanage-study\u002FSKILL.md",[],[172,152,173,154,157,23,174,159,160,144,175,176,177,178,163],"manage study","manage","people","how","find","link","status",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":31},"01M71565A8TCA01AZQZRGRYMFZ","create-study","Create a saved QuestionPunk survey draft from a research brief or edit specified questions. Use for requests such as make a customer feedback survey or shorten my onboarding study.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Fcreate-study\u002FSKILL.md",[],[186,152,187,188,189,190,154,191,157,192,23,193,194,160,195,196,197,198,199,163],"create study","create","brief","as","feedback","customer feedback","research brief","shorten","saved","research","requests","customer","questions","edit"]