Agent skill
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.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/human-gate-designer
Metadata
Additional technical details for this skill
- tags
-
human gate designer human-review approval-gate
- category
- Design & Creative
- pairs with
-
[ { "skill": "task-decomposer", "reason": "Task decomposition identifies which DAG nodes require human approval gates" }, { "skill": "output-contract-enforcer", "reason": "Human gate inputs and outputs need schema validation before routing decisions" }, { "skill": "reactflow-expert", "reason": "Human gates are visualized as interactive approval nodes in DAG dashboards" } ]
SKILL.md
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 (<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.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?