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

**URL:** <https://forum.langchain.com/t/how-to-designate-certain-steps-in-a-skill-as-human-in-the-loop/3240>\
**Category:** Deep Agents\
**Created:** [March 24, 2026, 7:03am UTC](https://forum.langchain.com/t/how-to-designate-certain-steps-in-a-skill-as-human-in-the-loop/3240 "2026-03-24T07:03:20Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ShenghuZhang](https://yyz1.discourse-cdn.com/flex007/user_avatar/forum.langchain.com/shenghuzhang/32/2602_2.png) [@ShenghuZhang](https://forum.langchain.com/u/ShenghuZhang)\
**Post date:** [March 24, 2026, 7:03am UTC](https://forum.langchain.com/t/how-to-designate-certain-steps-in-a-skill-as-human-in-the-loop/3240/1 "2026-03-24T07:03:20Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![keenborder786](https://yyz1.discourse-cdn.com/flex007/user_avatar/forum.langchain.com/keenborder786/32/1757_2.png) [@keenborder786](https://forum.langchain.com/u/keenborder786)\
**Post date:** [March 24, 2026, 2:46pm UTC](https://forum.langchain.com/t/how-to-designate-certain-steps-in-a-skill-as-human-in-the-loop/3240/2 "2026-03-24T14:46:17Z")

</div>

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:

```auto
---
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:

```auto
## 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**.