contribution-tooling
Contribute safely to the Apache Airflow monorepo with repo-specific tooling, validation, documentation, and PR conventions.
- License 许可
- Apache-2.0
- 最近更新
- 2026-09-03
- Stars
- ★ 351
- Forks
- 27
01 前言 Front Matter
- name
- contribution-tooling
- license
- Apache 2.0
- metadata
- { "disco-role": "operating" }
- description
- Contribute safely to the Apache Airflow monorepo with repo-specific tooling, validation, documentation, and PR conventions.
- disable-model-invocation
- true
02 资源文件 5
- 参考文档references/change-patterns.md10.1 KB
- 参考文档references/development-workflows.md7.1 KB
- 参考文档references/repo-map.md6.5 KB
- 参考文档references/troubleshooting.md7.0 KB
- 脚本scripts/select_test_command.py10.8 KB
03 SKILL.md 正文
<!-- SPDX-License-Identifier: Apache-2.0 -->
Contribution Tooling
Use this sub-skill when changing the Airflow repository itself: Python code, Task SDK, airflowctl, providers, docs, UI, Helm chart, CI/dev tooling, database migrations, generated files, or PR preparation.
Start Here
- Read
references/repo-map.mdto identify the owning distribution, nested rules, and likely tests. - Read
references/development-workflows.mdbefore running commands; it contains the Airflow-specific Breeze,uv, andprekrules. - Read
references/change-patterns.mdfor docs, newsfragment, changelog, generated-file, API, migration, provider, chart, and PR conventions. - Use
references/troubleshooting.mdwhen setup, Docker, Breeze, docs, generated files, or mypy caches fail. - Optionally run
scripts/select_test_command.pywith changed paths to get a quick first-pass command list, then refine with the real Airflow selective checks before final PR readiness.
Non-Negotiable Rules
- Write Dag in prose. Keep literal tokens unchanged, such as
DAG,dag_id,dag,airflow dags list,get_dag, and path/config names. - Do not run host
pytest,python, orairflowcommands directly. Preferuv run --project <project>for targeted local commands and use Breeze when system services, providers, or CI parity are needed. - After editing Python files, format and fix with
uv run ruff format <file>anduv run ruff check --fix <file>before moving on. - Respect every applicable
AGENTS.md. Nested instructions under providers, UI, dev scripts, registry, shared code, and prek scripts override broader guidance for files in their scope. - Do not hand-edit generated files when a generation hook or workflow owns them; regenerate and commit the result.
- Keep security boundaries intact: scheduler code must not run user code, task execution must use the Execution API rather than direct metadata DB access, and providers must use public SDK/API surfaces rather than core internals.
Quick Validation Flow
# First-pass recommendations from changed paths.
uv run skills/apache-airflow/sub-skills/contribution-tooling/scripts/select_test_command.py <changed-file> [...]
# Authoritative CI-oriented selector once a commit/ref exists.
breeze selective-checks --commit-ref <commit_with_squashed_changes>
# Fast static checks before PR handoff.
prek run --from-ref <target_branch> --stage pre-commit
When To Route Elsewhere
- Deployment, admin operation, and runtime configuration questions belong in the deployment/operations coverage of the root skill.
- Deep API authoring, Dag authoring, scheduler behavior, provider implementation, UI, Helm, or Task SDK changes may need their specialized sub-skills after this one sets contribution guardrails.
- Java SDK and Go SDK work is intentionally out of scope here except for routing and CI cautions; use specialized SDK guidance when available.
- Provider release-manager bulk classification is specialized, path-dependent work; use the repo-local release-management skill if the user explicitly asks for that workflow.
04 同仓库更多 Skills
passnet-triton-opt
Make a single PassNet Triton kernel fast AND numerically faithful: performance model (when a replacement can win at all), block/grid/warp tuning, autotune policy, launch overhead, and per-op numeric recipes to pass the dtype baseline tolerances. Use when a pass matches and is correct but speedup below expected, or when correctness fails by small numeric margins.
passnet-solve
END-TO-END playbook for solving one PassNet sample: analyze the computation graphs, decide the optimization strategy (what to fuse, what to replace, what to leave alone), drive the iteration loop, and maximize the sample score. This is the ENTRY skill — invoke it first for any PassNet optimization task; it tells you when to use passnet-pattern-fusion, passnet-triton-opt and passnet-feedback.
passnet-skill
PassNet GPU kernel optimization via compiler passes. Design and implement Triton-based optimization passes, create pass files under ./pass_dir/, self-evaluate with pass_evaluator, and iterate to maximize GPU speedup.
passnet-pattern-fusion
Author PassNet pass files: write patterns that actually MATCH the FX graph, pick fusion regions (which ops to absorb into one Triton kernel), and structure multi-pass submissions with the mandatory shared-dispatch architecture. Use when creating or fixing pattern()/replacement_args()/replacement_func() files, when a pass "failed to match", or when deciding how to fuse multiple kernels/ops.
passnet-orchestrate
Round/batch planning and decision support for PassNet graph optimization. Use for multi-sample triage, worker allocation, eval-budget policy, and post-eval keep/revert decisions. For solving one concrete sample end to end, use passnet-solve as the entry skill; consult this skill only when you need broader planning or a specific decision gate.
passnet-feedback
Fast, deterministic feedback for PassNet work: pre-flight pattern/match verification WITHOUT burning a GPU evaluation, per-node bottleneck analysis of a sample's graphs, and eval-log parsing into per-variant status + estimated score + failure classification. Use BEFORE every GPU evaluation (check_pattern), at the START of a sample (analyze_graph), and AFTER every evaluation (parse_eval_log).