agentleFS
Sathvikar01Sathvikar01/Agent-engineering-skills/human-in-the-loop/SKILL.md

human-in-the-loop

Skill3 starsChanged 38 days agoMITView on GitHub

Place proportional human review and approval gates in an AI system's execution path. Use when designing approval/escalation for agent actions with financial, external, destructive or permission impact, preview-before-commit flows, or uncertainty that warrants human judgment. Do not use for requesting routine coding confirmation, imposing approval on harmless reads, or deterministic authorization logic alone.

8 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use humans where a consequential decision needs their authority or judgment.

    line 12
  2. Distinctive:

    Keep pending, approved, denied, expired and cancelled states explicit.

    line 24

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Human in the Loop

Use humans where a consequential decision needs their authority or judgment. Repeated approvals for harmless actions train users to click through; removing every approval also hides consequential choices.

Decide whether to gate

  1. For each action, record impact, reversibility, affected people/resources, uncertainty, existing user authorization and applicable policy. Do not ask again if a valid scoped authorization already covers the action. A preference remembered by the model is not authorization.
  2. Let deterministic policy decide which actions can proceed, must be denied, or require approval. Favor automatic execution for authorized low-impact reversible work. Gate meaningful financial commitments, external communications, destructive operations and permission changes when the user/policy has not already authorized their specific scope. A sandbox draft or preview can normally be prepared first.
  3. Escalate insufficient evidence, policy exceptions, novel high-impact actions or uncertainty beyond a calibrated threshold. Use objective missing evidence or measured uncertainty, not a model's unsupported confidence score. Hard invariant violations are denied; they are not solved by an approve button.

Prepare a concrete decision

  1. Complete authorized reversible preparation before asking. Present exact proposed action, targets/recipients, amount or scope, useful diff/preview, material risks, evidence and available alternatives. Keep the request understandable and proportional; do not dump a trajectory for the approver to reconstruct.
  2. Identify an approver with the necessary authority. Bind approval to principal, canonical arguments/action digest, resources, relevant state/policy version, expiry and use count. Store application-issued approval and decision evidence outside model prose. Reject self-approval by the acting model.
  3. Keep pending, approved, denied, expired and cancelled states explicit. A timeout or silence is not approval. While pending, continue independent authorized work without executing the gated action. Offer cancellation and safe draft retention.
  4. Recheck policy and binding before commit. Changed recipients, amounts, material diff, state or expired approval require a fresh decision. Prevent time-of-check/time-of-use substitution. Apply idempotency so retries do not duplicate approved effects.

Control friction and verify

  1. Batch related decisions only when users can understand and authorize the bounded group; allow item-level rejection. Define explicit standing grants with limits/expiry if appropriate, rather than assuming previous approvals authorize future actions. Measure approval frequency, abandonment, review time, erroneous approvals and escalation outcomes.

Deliver an action-to-gate table, one exact preview, approval state/binding contract, timeout/changed-action behavior and tests. Verify denied/expired grants prevent effects, changed payload invalidates approval, and harmless authorized reads proceed without repeated prompts.

deterministic-authority owns enforcement; this skill owns when and how a human decision enters that path. Ordinary development review and confirmation are out of scope; do not add a ritual approval step to every coding task.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.