skills/human-gate-designer/SKILL.md
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.
npx skillsauth add curiositech/windags-skills human-gate-designerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
✅ Use for:
❌ NOT for:
dag-runtime + Temporal signals)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]
| 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 |
┌──────────────────────────────────────────────────────┐
│ 🔍 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] ││
│ └──────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────┘
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]
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.
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.
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.
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.
This skill produces:
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.