AGENT SKILL

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

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

  1. Read references/repo-map.md to identify the owning distribution, nested rules, and likely tests.
  2. Read references/development-workflows.md before running commands; it contains the Airflow-specific Breeze, uv, and prek rules.
  3. Read references/change-patterns.md for docs, newsfragment, changelog, generated-file, API, migration, provider, chart, and PR conventions.
  4. Use references/troubleshooting.md when setup, Docker, Breeze, docs, generated files, or mypy caches fail.
  5. Optionally run scripts/select_test_command.py with 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, or airflow commands directly. Prefer uv 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> and uv 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

VectorSpaceLab
VectorSpaceLab/AREX-Skill

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.

★ 351
VectorSpaceLab
VectorSpaceLab/AREX-Skill

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.

★ 351
VectorSpaceLab
VectorSpaceLab/AREX-Skill

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.

★ 351
VectorSpaceLab
VectorSpaceLab/AREX-Skill

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.

★ 351
VectorSpaceLab
VectorSpaceLab/AREX-Skill

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.

★ 351
VectorSpaceLab
VectorSpaceLab/AREX-Skill

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).

★ 351