airflow-hitl
Skill459 starsChanged 37 days agoApache-2.0View on GitHub
Builds human-in-the-loop (HITL) Airflow workflows - approval gates, form input, and human-driven branching. Use when a DAG needs a human in the loop - an approval or reject step, sign-off before a task runs, a decision or approval UI, branching on a human choice, or collecting form input mid-run; also on mentions of ApprovalOperator, HITLOperator, HITLBranchOperator, HITLEntryOperator, or HITLTrigger. Requires Airflow 3.1+. Not for AI/LLM task calls (see migrating-ai-sdk-to-common-ai).
1 other project uses a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- miptah21/skillsedited, first seen May 26, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- miptah21/skills★ 215% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository35 other files it gives its agents.
- AGENTS.mdAGENTS.md
- astro-airflow-mcp/AGENTS.mdAGENTS.md
- airflow-pluginsSkill
- airflowSkill
- airflow-state-storeSkill
- analyzing-dataSkill
- annotating-task-lineageSkill
- authoring-dagsSkill
- authoring-go-sdk-tasksSkill
- authoring-java-sdk-tasksSkill
- authoring-language-sdk-tasksSkill
- blueprintSkill
- checking-freshnessSkill
- configuring-airflow-language-sdksSkill
- cosmos-dbt-coreSkill
- cosmos-dbt-fusionSkill
- creating-openlineage-extractorsSkill
- dag-factorySkill
- debugging-dagsSkill
- delegating-to-ottoSkill
- deploying-airflowSkill
- deploying-go-sdk-bundlesSkill
- deploying-java-sdk-bundlesSkill
- managing-astro-deploymentsSkill
- managing-astro-local-envSkill
- migrating-airflow-2-to-3Skill
- migrating-ai-sdk-to-common-aiSkill
- migrating-dagster-to-airflowSkill
- profiling-tablesSkill
- setting-up-astro-projectSkill
- testing-dagsSkill
- tracing-downstream-lineageSkill
- tracing-upstream-lineageSkill
- troubleshooting-astro-deploymentsSkill
- warehouse-initSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 34
Before writing HITL code, run these to see the live roster and constructor params (see the airflow skill for the full af registry …
- Distinctive: line 51
If the registry shows a param that this skill does not mention, prefer the registry.
- Very specific: line 111
All HITL operators accept the standard Airflow callback kwargs (on_success_callback, on_failure_callback, etc.).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Airflow Human-in-the-Loop Operators
Pause a DAG until a human responds via the Airflow UI or REST API. HITL operators are deferrable — they release their worker slot while waiting.
Requires Airflow 3.1+ (
af config version).UI location: Browse → Required Actions. Respond from the task instance page's Required Actions tab.
Cross-references:
migrating-ai-sdk-to-common-aifor AI/LLM task decorators;airflowfor registry and API discovery commands used below.
Step 1 — Pick the capability you need
| Capability | Class (verify in Step 2) |
| Approve or reject; downstream skips on reject | ApprovalOperator |
| Present N options and return which were chosen | HITLOperator |
| Branch to one or more downstream tasks based on a choice | HITLBranchOperator |
| Collect a form (no approve/select step) | HITLEntryOperator |
| Use the HITL trigger directly (advanced / custom operators) | HITLTrigger |
This is the only place class names are hardcoded. The provider adds, renames, and removes params across releases — do not copy parameter lists from memory. Fetch the current signature before writing code.
Step 2 — Discover the current signatures from the Airflow Registry
Before writing HITL code, run these to see the live roster and constructor params (see the airflow skill for the full af registry reference):
# Every HITL-related module in the standard provider
af registry modules standard \
| jq '.modules[] | select(.import_path | test("\\.hitl\\.")) | {name, type, import_path, short_description, docs_url}'
# Constructor signatures: name, type, default, required, description
af registry parameters standard \
| jq '.classes | to_entries[] | select(.key | test("\\.hitl\\.")) | {fqn: .key, parameters: .value.parameters}'
# Pin to the exact installed provider version
af config providers \
| jq '.providers[] | select(.package_name == "apache-airflow-providers-standard") | .version'
# then: af registry parameters standard --version <VERSION>If the registry shows a param that this skill does not mention, prefer the registry. If the registry shows a class that is not in Step 1, treat it as additive — the decision table above may be stale.
Step 3 — Canonical example (approval gate)
Starting point for any HITL task. Adapt by swapping the class name and params per Step 2.
from airflow.providers.standard.operators.hitl import ApprovalOperator
from airflow.sdk import dag, task, chain, Param
from pendulum import datetime
@dag(start_date=datetime(2025, 1, 1), schedule="@daily")
def approval_example():
@task
def prepare():
return "Review quarterly report"
approval = ApprovalOperator(
task_id="approve_report",
subject="Report Approval",
body="{{ ti.xcom_pull(task_ids='prepare') }}",
defaults="Approve", # Auto-selected on timeout
params={"comments": Param("", type="string")},
)
@task
def after_approval(result):
print(f"Decision: {result['chosen_options']}")
chain(prepare(), approval)
after_approval(approval.output)
approval_example()For the other classes in Step 1, the shape is the same (task_id, subject, plus class-specific params). Verify each constructor through Step 2 — for example, HITLBranchOperator requires every option either to match a downstream task id directly or to be resolved via a mapping param surfaced in the registry.
Step 4 — Behavior contracts (stable across versions)
Timeout
- With
defaultsset: task succeeds on timeout, default option(s) selected. - Without
defaults: task fails on timeout.
Markdown + Jinja in body
body supports Markdown and is Jinja-templatable. Render XCom context directly:
body = """**Total Budget:** {{ ti.xcom_pull(task_ids='get_budget') }}
| Category | Amount |
|----------|--------|
| Marketing | $1M |
"""Callbacks
All HITL operators accept the standard Airflow callback kwargs (on_success_callback, on_failure_callback, etc.).
Notifiers
HITL operators accept a notifiers list. Inside a notifier's notify(context) method, build a link to the pending task with HITLOperator.generate_link_to_ui_from_context(context, base_url=...).
Restricting who can respond
The parameter name and accepted identifier format depend on the active auth manager. Do not hardcode — check which one is active and which kwarg the current provider exposes:
af config show | jq '.auth_manager // .core.auth_manager'Then look up the current kwarg in Step 2 (at the time of writing it is assigned_users, accepting identifiers in whatever format the active auth manager uses — Astro uses the Astro user ID, FabAuthManager uses email, SimpleAuthManager uses username).
Step 5 — Responding from external integrations
For Slack bots, custom apps, or scripts. Discover the live endpoint rather than hardcoding a path:
af api ls --filter hitl # live endpoint list
af api spec \
| jq '.paths | to_entries[] | select(.key | test("hitl"))' # request/response schemasThe PATCH-to-respond pattern is stable; the exact path is discovered. Typical shape:
import os, requests
HOST = os.environ["AIRFLOW_HOST"]
TOKEN = os.environ["AIRFLOW_API_TOKEN"]
HEADERS = {"Authorization": f"Bearer {TOKEN}"}
# List pending — use the path from `af api ls --filter hitl`
requests.get(f"{HOST}/<path>", headers=HEADERS, params={"state": "pending"})
# Respond — same discovered path family, PATCH
requests.patch(
f"{HOST}/<path>/{dag_id}/{run_id}/{task_id}",
headers=HEADERS,
json={"chosen_options": ["Approve"], "params_input": {"comments": "ok"}},
)Step 6 — Safety checks
- Airflow version ≥ 3.1 (
af config version). - Constructor kwargs match the current registry output from Step 2 — no
respondents-vs-assigned_usersstyle drift. - For branching: every option resolves to a downstream task id (directly or via the mapping kwarg from Step 2).
- Every value in
defaultsis also inoptions. execution_timeoutset;defaultsconfigured if timeout should succeed rather than fail.- API token configured if external responders are part of the flow.
References
The upstream docs URL is surfaced per-module by the registry — do not hardcode:
af registry modules standard \
| jq '.modules[] | select(.import_path | test("\\.hitl\\.")) | {name, docs_url}'Related skills
- airflow —
af registry,af api,af configcommand reference. - migrating-ai-sdk-to-common-ai — AI/LLM task decorators and GenAI patterns (common-ai provider).
- authoring-dags — general DAG writing best practices.
- testing-dags — iterative test → debug → fix cycles.
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
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.

