How to designate certain steps in a skill as "human in the loop"

OSS Product Help Deep Agents
1

When using tools, we can specify things with interrupt_on, but how do we add human intervention for high-risk steps within a skill? Is there a better way? Take OpenClaw, which is getting a lot of buzz right now—most of what users are really doing is just installing skills. It makes having human-in-the-loop control over method calls inside skills pretty important too.

2

Skills are essentially declarative: SkillsMiddleware loads SKILL.md files and injects their contents into the system prompt. A skill itself does not define an execution pipeline, it only provides instructions that the agent follows when it later decides to invoke tools.

Because of that, “interrupting within a skill” really means interrupting before the specific tool calls that the skill leads the agent to make.

Suggestions

1. Tool-level interrupt_on is the primary control point

Since skills ultimately execute through the agent’s normal tool-calling path, tool-level gating is the most reliable way to control risky skill behavior.

If a skill performs high-risk actions such as execute, edit_file, or similar tools, those are already covered when the CLI runs with HITL enabled.

The experimental allowed_tools field in skill frontmatter can also help here, because it explicitly signals which tools a skill is expected to use:

---
name: my-skill
description: Does something
allowed-tools: execute write_file
---

SkillsMiddleware surfaces this in the system prompt, and it is also available at runtime through SkillMetadata.allowed_tools.

However, there is currently no automatic wiring from allowed_tools into interrupt_on.

So if you want this behavior, you would need to:

  • read skills_metadata from state

  • collect allowed_tools across loaded skills

  • union those tools into your interrupt_on configuration yourself

That gives you a practical way to automatically apply stricter HITL policies for third-party skills.

2. Explicit confirmation instructions inside SKILL.md

The better option is to place confirmation rules directly inside the skill instructions.

Example:

## High-Risk Steps

Before running `execute` with any install command, present the full command to the user with:

"I'm about to run: <command>. Shall I proceed? (yes/no)"

Wait for explicit approval before continuing.  
Do not proceed if the user's response is ambiguous.

This creates prompt-level HITL behavior.

2 Likes