mcpbeat

Human Gate Designer

curiositech/human-gate-designer

Designs human-in-the-loop review points for DAG workflows. Determines what to present to the human, how to collect feedback, and how to route approve/reject/modify decisions back into the DAG. Use when adding approval gates, designing review UX, or handling human feedback in agent workflows. Activate on "human review", "approval gate", "human-in-the-loop", "human gate", "approval workflow", "user review step". NOT for executing human gates at runtime (use dag-runtime with Temporal signals), general UX design, or chatbot conversation design.

2k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
177
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/curiositech/some_claude_skills --skill human-gate-designer

The instruction itself

13 sections, as written by the author

Human Gate Designer

Designs human-in-the-loop review points in DAG workflows: what to present, how to collect feedback, how to route decisions back into the DAG.


When to Use

Use for:

  • Deciding WHERE in a DAG to place human gates
  • Designing WHAT the human sees at each gate
  • Defining HOW feedback routes back (approve/reject/modify)
  • Balancing automation speed with human oversight

NOT for:

  • Runtime execution of human gates (use dag-runtime + Temporal signals)
  • General UI/UX design (use design skills)
  • Chatbot conversation flow (different pattern)

Gate Placement Decision Tree

flowchart TD
  A{Is the action irreversible?} -->|Yes| G1[Gate BEFORE the action]
  A -->|No| B{Is output user-facing?}
  B -->|Yes| G2[Gate AFTER generation, BEFORE delivery]
  B -->|No| C{Cost > $0.50 for remaining nodes?}
  C -->|Yes| G3[Gate at the cost threshold]
  C -->|No| D{Confidence score < 0.7?}
  D -->|Yes| G4[Gate on low-confidence outputs]
  D -->|No| N[No gate needed]

Where to Place Gates

| Situation | Gate Position | Why |

|-----------|-------------|-----|

| Irreversible action (deploy, send email, submit) | Before the action | Can't undo |

| User-facing deliverable (report, website, PR) | After generation, before delivery | Quality check |

| High cost remaining (>$0.50) | Before expensive phase | Budget confirmation |

| Low confidence output (&lt;0.7) | After the uncertain node | Expert judgment needed |

| Ambiguous task decomposition | After planning, before execution | Validate the plan |

| First run of a new template DAG | After each phase | Build trust gradually |


Gate Presentation Design

What the Human Sees

┌──────────────────────────────────────────────────────┐
│  🔍 Human Review: [Node Name]                        │
│                                                      │
│  Context: [1-2 sentences: what happened so far]      │
│                                                      │
│  Output to Review:                                   │
│  ┌──────────────────────────────────────────────────┐│
│  │ [The node's output, formatted for readability]   ││
│  │ [Key decisions highlighted]                      ││
│  │ [Confidence: 0.82]                               ││
│  └──────────────────────────────────────────────────┘│
│                                                      │
│  Cost so far: $0.08 / $0.50 budget                  │
│  Remaining nodes: 4 (est. $0.12)                    │
│                                                      │
│  [✅ Approve]  [✏️ Modify]  [❌ Reject]              │
│                                                      │
│  If modifying, what should change?                   │
│  ┌──────────────────────────────────────────────────┐│
│  │ [text input for human feedback]                  ││
│  └──────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────┘

Presentation Principles

  • Show context, not just output: The human needs to understand what the DAG has done so far, not just the current node's result.
  • Highlight decisions: Bold or annotate the choices the agent made. These are what the human is actually reviewing.
  • Show confidence: If the agent was uncertain, say so. Low-confidence outputs need more scrutiny.
  • Show cost: The human should know what they've spent and what's remaining.
  • Make "Modify" easy: A text input for feedback that gets injected into the retry prompt.

Feedback Routing

flowchart TD
  H[Human decision] --> A{Decision?}
  A -->|Approve| C[Continue to next wave]
  A -->|Modify| M[Re-execute node with human feedback injected]
  M --> V[Validate modified output]
  V --> H
  A -->|Reject| R{Reject scope?}
  R -->|This node only| RN[Re-plan this node with different approach]
  RN --> H
  R -->|Entire phase| RP[Re-plan from last successful phase]
  RP --> H
  R -->|Abort DAG| AB[Stop execution, return partial results]

Feedback Injection

When the human selects "Modify," their text becomes part of the re-execution prompt:

Original task: [same as before]
Previous output: [the output the human rejected]
Human feedback: "[the human's modification text]"

Revise your output to address the human's feedback.
Preserve the parts they didn't comment on.

Anti-Patterns

Gate After Every Node

Wrong: Requiring human approval after every single node.

Right: Gate only at irreversible actions, user-facing outputs, and low-confidence decisions. Most internal nodes need no gate.

Binary Approve/Reject Only

Wrong: The human can only approve or reject, with no way to provide specific feedback.

Right: Always include a "Modify" option with a text input for targeted feedback.

No Context in the Gate

Wrong: Showing the human a raw JSON output with no explanation.

Right: Show: what the DAG is doing, what happened so far, what this output means, what happens next if approved.

How to use it

Copy the folder

Take curiositech/human-gate-designer from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.