Review a proposed Human-in-the-Loop workflow for propose-then-commit shape and flag missing metadata, idempotency, verification, or challenge-and-response layers. Use when building UI with hitl design language and visual style.
Installs into .claude/skills of the current project.
Are you the author of Hitl Design?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/anubhavg-icpl-hitl-design)
---
name: hitl-design
description: Review a proposed Human-in-the-Loop workflow for propose-then-commit shape and flag missing metadata, idempotency, verification, or challenge-and-response layers. Use when building UI with hitl design language and visual style.
license: CC-BY-NC-SA-4.0
phase: 15
lesson: 15
metadata:
version: 1.0.0
tags: [hitl, propose-then-commit, idempotency, langgraph, cloudflare, agent-framework, eu-ai-act]
---
Given a proposed HITL workflow, audit it against the propose-then-commit reference and flag what is missing, under-specified, or regulator-incompatible.
Produce:
1. **Proposal metadata.** Confirm every proposal surfaces: intent (why), data lineage (source content), permissions touched, blast radius (worst case), rollback plan. Missing fields are blockers; "the agent wants to X" is not a proposal.
2. **Idempotency.** Name the idempotency key composition. It must be derivable from the proposal content so retries return the same record. Keys that include wall-clock time are not idempotency keys; they are logging timestamps.
3. **Durability.** Name the store (PostgreSQL, Redis, Durable Object, object storage with integrity check). Confirm approvals survive agent restart, host restart, and deploy. In-memory queues do not qualify.
4. **Approval surface.** Rubber-stamp approval (single Approve button) fails this audit. Required: challenge-and-response checklist with positive acknowledgement on intent understanding, blast-radius verification, and rollback readiness. Confirm the checklist is tailored to the specific action class, not generic.
5. **Post-commit verify.** Confirm the workflow re-reads the target resource after execution and alerts on verify failure. "The tool returned 200" is not verify.
Hard rejects:
- HITL surfaces that do not persist proposals durably.
- Approval flows where the reviewer is the agent itself.
- Any irreversible production action without challenge-and-response.
- Idempotency keys with wall-clock components.
- Workflows where post-commit verify is absent on consequential actions.
Refusal rules:
- If the user names the approval UI but cannot name the durable store behind it, refuse and require a store first.
- If the user treats "max_budget_usd and a confirmation dialog" as sufficient HITL, refuse. Budgets cap cost, not correctness.
- If the deployment touches high-risk EU scope and rubber-stamp patterns remain, refuse on Article 14 grounds.
Output format:
Return a propose-then-commit audit with:
- **Proposal field table** (intent / lineage / blast / rollback / permissions — all five required)
- **Idempotency note** (key composition, retry test result)
- **Durability line** (store, survives-restart y/n)
- **Approval surface** (rubber-stamp / checklist; if checklist, list the questions)
- **Post-commit verify** (present y/n, what it re-reads)
- **Readiness** (production / staging / research-only)
