[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ACAWMSPCZCQMCJ0WPVTFQ9":3,"skill-same:01M6ACAWMSPCZCQMCJ0WPVTFQ9":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6ACAWMSPCZCQMCJ0WPVTFQ9","airflow-publish-changes",null,"Prepare or carry out authorized publication of Apache Airflow changes, including remote checks, pre-push verification, PR creation, and tracking deferred work. Also use when planning these steps or managing contribution issues.","apache\u002Fairflow","apache","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47359?v=4","01M6AC83E6K4FDKK7HZ8WNMQKE","The Apache Software Foundation","01M6ACADDFF6RHG1DBAJXFG7E5",47442,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fairflow-publish-changes\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,9,34,35,36,37,38],"changes","airflow","airflow publish changes","publish","Publication","prepare","when","remote","contribution","creation","pr creation","use","tracking","work","apache airflow","push","verification","issues","planning","pr","2026-11-10 10:12:30",false,"---\nname: airflow-publish-changes\ndescription: Prepare or carry out authorized publication of Apache Airflow changes, including remote checks, pre-push verification, PR creation, and tracking deferred work. Also use when planning these steps or managing contribution issues.\n---\n\n\u003C!-- SPDX-License-Identifier: Apache-2.0\n     https:\u002F\u002Fwww.apache.org\u002Flicenses\u002FLICENSE-2.0 -->\n\n# Publish Airflow changes\n\nFor a plan, describe the steps without executing publication. For authorized\npublication, preserve existing approval and confirmation boundaries.\nUse the sections below for remote setup, existing PR checks, publication and\nissue tracking. Follow root [`AGENTS.md`](..\u002F..\u002F..\u002FAGENTS.md) for the applicable\ntest conventions and generated check commands; for contribution text, use\n[Draft Airflow contribution text](..\u002Fairflow-pr-draft-summary\u002FSKILL.md).\n\n## Git remote naming conventions\n\nAirflow standardises on two git remote names, and the rest of this file, the\ncontributing docs, and the release docs all assume them:\n\n- **`upstream`** — the canonical `apache\u002Fairflow` repository (fetch from here).\n- **`origin`** — the contributor's fork of `apache\u002Fairflow` (push PR branches here).\n\nAlways push branches to `origin`. Never push directly to `upstream` (and never\npush directly to `main` on either remote).\n\n**Before running any remote-based command, run `git remote -v` and verify the\nnames match this convention.** If they do not — for example, the upstream remote\nis called `apache`, or `origin` points at `apache\u002Fairflow` with the fork under a\ndifferent name like `fork` — **do not silently go along with the existing\nnames**. Surface the mismatch to the user and propose the exact rename commands\nto bring the checkout in line with the convention, then ask the user to confirm\nbefore running them. Examples:\n\n- Upstream is named `apache`, fork is `origin` (common legacy layout):\n\n  ```bash\n  git remote rename apache upstream\n  ```\n\n- `origin` points at `apache\u002Fairflow` and the fork is named `fork` (release-manager\n  \u002F \"cloned upstream directly\" layout):\n\n  ```bash\n  git remote rename origin upstream\n  git remote rename fork origin\n  ```\n\n- Upstream is missing entirely:\n\n  ```bash\n  git remote add upstream https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow.git\n  # or, for SSH:\n  git remote add upstream git@github.com:apache\u002Fairflow.git\n  ```\n\n- Fork is missing entirely:\n\n  ```bash\n  gh repo fork apache\u002Fairflow --remote --remote-name origin\n  ```\n\nAfter any rename\u002Fadd, re-run `git remote -v` to confirm the new state before\ncontinuing with commands that assume `upstream` \u002F `origin`.\n\nIf a doc, script, or command you're about to run uses the old `apache` name (or\nany other variant), **translate it to the `upstream` convention** in what you\npropose to the user, rather than perpetuating the old name. Flag the stale\ndocumentation so it can be fixed in a follow-up.\n\n## Before starting: check for an existing PR\n\nBefore working on an issue, check for open PRs already addressing it\n(`gh pr list --search \"\u003Cissue number or keywords>\"`, and look for `closes:`\n\u002F `fixes:` references). Airflow allows parallel work — \"better PR wins\"\n(see `contributing-docs\u002F04_how_to_contribute.rst`) — but it is not the\ndefault: prefer reviewing and building on an existing PR. Open a separate\none only *if your approach is genuinely different*. Do not blindly open\nanother near-identical PR for an issue that already has one (or several) —\nthat just adds reviewer noise.\n\n## Creating Pull Requests\n\n**Always push to the user's fork (`origin`)**, not to `upstream` (`apache\u002Fairflow`).\nNever push directly to `main`.\n\nBefore pushing, confirm the remote setup matches the conventions above\n(`upstream` → `apache\u002Fairflow`, `origin` → your fork). Run `git remote -v` and,\nif the names don't match, propose renames as described in \"Git remote naming\nconventions\" — ask the user to confirm before running them.\n\nIf the fork remote does not exist at all, create one:\n\n```bash\ngh repo fork apache\u002Fairflow --remote --remote-name origin\n```\n\nBefore pushing, perform a self-review of your changes following the Gen-AI review guidelines\nin [`contributing-docs\u002F05_pull_requests.rst`](..\u002F..\u002F..\u002Fcontributing-docs\u002F05_pull_requests.rst) and the\ncode review checklist in [`.github\u002Finstructions\u002Fcode-review.instructions.md`](..\u002F..\u002F..\u002F.github\u002Finstructions\u002Fcode-review.instructions.md):\n\n1. Review the full diff (`git diff main...HEAD`) and verify every change is intentional and\n   related to the task — remove any unrelated changes.\n2. Read `.github\u002Finstructions\u002Fcode-review.instructions.md` and check your diff against every\n   rule — architecture boundaries, database correctness, code quality, testing requirements,\n   API correctness, and AI-generated code signals. Fix any violations before pushing.\n3. Confirm the code follows the project's coding standards and architecture boundaries\n   described in root [`AGENTS.md`](..\u002F..\u002F..\u002FAGENTS.md).\n4. Run regular (fast) static checks (`prek run --from-ref \u003Ctarget_branch> --stage pre-commit`)\n   and fix any failures. This includes mypy checks for non-provider projects (airflow-core, task-sdk, airflow-ctl, dev, scripts, devel-common).\n5. Run manual (slower) checks\n   (`prek run --from-ref \u003Ctarget_branch> --stage manual --skip compile-ui-assets-dev --skip view-skill-eval --skip run-skill-eval-codex`)\n   and fix any failures. The skipped hooks start long-running local servers or provision the\n   opt-in Codex environment rather than run checks that complete.\n6. Run relevant individual tests and confirm they pass.\n7. If the diff touches a performance-sensitive component (Task SDK comms, supervisor and task runner;\n   Execution API; logging and secret masking; serialization; scheduler and triggerer loops; Dag\n   processing), benchmark the code before and after the change as\n   [`references\u002Fperformance-sensitive-components.md`](references\u002Fperformance-sensitive-components.md)\n   describes, and report the outcome to the user.\n8. Run `breeze verify` and execute every command it lists. The list comes from the same selective-checks logic CI uses. `breeze verify --full` shows everything CI runs for the default matrix cell, including the full suite CI adds when a change touches CI tooling or dependency files. Static checks are not listed: steps 4 and 5 cover them. Confirm the commands pass and check for CI-specific issues.\n9. Check for security issues — no secrets, no injection vulnerabilities, no unsafe patterns.\n\nBefore pushing, always rebase your branch onto the latest target branch (usually `main`)\nto avoid merge conflicts and ensure CI runs against up-to-date code:\n\n```bash\ngit fetch upstream \u003Ctarget_branch>\ngit rebase upstream\u002F\u003Ctarget_branch>\n```\n\nIf there are conflicts, resolve them and continue the rebase. If the rebase is too complex,\nask the user for guidance.\n\nThen push the branch to your fork (`origin`) and open the PR creation page in the browser\nwith the body pre-filled (including the generative AI disclosure already checked):\n\n```bash\ngit push -u origin \u003Cbranch-name>\ngh pr create --web --title \"Short title (under 70 chars)\" --body \"$(cat \u003C\u003C'EOF'\nBrief description of the changes.\n\ncloses: #ISSUE  (if applicable)\n\n---\n\n##### Was generative AI tooling used to co-author this PR?\n\n- [X] Yes — \u003CAgent Name and Version>\n\nGenerated-by: \u003CAgent Name and Version> following [the guidelines](https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002Fcontributing-docs\u002F05_pull_requests.rst#gen-ai-assisted-contributions)\n\nEOF\n)\"\n```\n\nThe `--web` flag opens the browser so the user can review and submit. The `--body` flag\npre-fills the PR template with the generative AI disclosure already completed.\n\nRemind the user to:\n\n1. Review the PR title — keep it short (under 70 chars), in the imperative mood, and focused on user impact. Do not use Conventional Commits prefixes (`fix:`, `feat:`, `chore:`, …).\n2. Add a brief description of the changes at the top of the body.\n3. Reference related issues when applicable (`closes: #ISSUE` or `related: #ISSUE`).\n\n## Golden rule: when a fix is imminent, open the PR, not an issue\n\nIf you already know how to fix the problem and you (or the user) are going to\nopen the PR shortly, **do not file a GitHub issue first**. Go straight to the\nPR.\n\n- Airflow does not use issues as a changelog, as a parallel bug database, or\n  as a duplicate record of in-flight work. The PR itself is the canonical\n  record — title, description, diff, discussion, and merge all live in one\n  place. An issue that gets closed by a PR a day later is double accounting\n  that carries no information the PR does not already carry.\n- Open issues attract drive-by submissions, often from other agents, that\n  haven't seen the in-flight work. That produces duplicate fixes, low-quality\n  PRs that have to be closed, and wasted reviewer time. Not opening the\n  issue avoids creating that bait in the first place.\n- If you catch yourself drafting an issue body that reads like the PR\n  description you are about to write, that is the signal — skip the issue\n  and open the PR.\n\nThe one exception is the case covered by the next section: the PR ships a\n**workaround, mitigation, or partial fix** and the real follow-up work is\ngenuinely deferred to a later PR. There, the issue captures work that will\noutlive the PR, so the issue is load-bearing rather than duplicate.\n\n## Tracking issues for deferred work\n\nWhen a PR applies a **workaround, version cap, mitigation, or partial fix**\nrather than solving the underlying problem (for example: upper-binding a\ndependency to avoid a breaking upstream release, disabling a feature\nbehind a flag, reverting a change that needs a better replacement, or\npapering over a bug so a release can ship), the deferred work must be\ncaptured in a GitHub tracking issue **and** the tracking issue URL must\nappear as a comment at the workaround site in the code.\n\n1. **Open the tracking issue first**, before finalising the PR body.\n2. **Reference it in the PR body by number** — e.g. \"full migration is\n   tracked in #65609\" — so anyone reviewing the PR can see what was\n   deferred and why.\n3. **Add a link to the tracking issue as a comment at the workaround\n   itself**, so the reference survives after the PR merges and anyone\n   reading the source later can click straight through to the follow-up\n   work. Use the **full issue URL**, not bare `#NNNNN` — bare references\n   do not auto-link outside GitHub's web UI (e.g. when grepping in an\n   editor, browsing a checkout, or reading the file in a terminal).\n   For example:\n\n   ```toml\n   # pyproject.toml\n   # Remove the \u003C1.0 cap after migrating to httpx 1.x;\n   # tracked at https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fissues\u002F65609\n   \"httpx>=0.27.0,\u003C1.0\",\n   ```\n\n   ```python\n   # some_module.py\n   # Delete this fallback once the new client is on all workers;\n   # tracked at https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fissues\u002F65609\n   if old_client:\n       ...\n   ```\n\n4. **Do not** write vague forward-looking phrases like \"will open a\n   tracking issue\" or \"to be filed later\" in the PR body or in code\n   comments. Open the issue, link it in both places, then submit the PR.\n5. The tracking issue should describe: what the workaround is, why it\n   was chosen, the concrete follow-up work needed, and any acceptance\n   criteria for removing the workaround.\n\nIf a PR you already opened has such forward-looking language, open the\ntracking issue, add a PR comment referencing the issue URL, and push a\nfollow-up commit that adds the tracking-issue URL as a comment at the\nworkaround site in the code.\n","\u003C!-- SPDX-License-Identifier: Apache-2.0\n     https:\u002F\u002Fwww.apache.org\u002Flicenses\u002FLICENSE-2.0 -->\n\n# Publish Airflow changes\n\nFor a plan, describe the steps without executing publication. For authorized\npublication, preserve existing approval and confirmation boundaries.\nUse the sections below for remote setup, existing PR checks, publication and\nissue tracking. Follow root [`AGENTS.md`](..\u002F..\u002F..\u002FAGENTS.md) for the applicable\ntest conventions and generated check commands; for contribution text, use\n[Draft Airflow contribution text](..\u002Fairflow-pr-draft-summary\u002FSKILL.md).\n\n## Git remote naming conventions\n\nAirflow standardises on two git remote names, and the rest of this file, the\ncontributing docs, and the release docs all assume them:\n\n- **`upstream`** — the canonical `apache\u002Fairflow` repository (fetch from here).\n- **`origin`** — the contributor's fork of `apache\u002Fairflow` (push PR branches here).\n\nAlways push branches to `origin`. Never push directly to `upstream` (and never\npush directly to `main` on either remote).\n\n**Before running any remote-based command, run `git remote -v` and verify the\nnames match this convention.** If they do not — for example, the upstream remote\nis called `apache`, or `origin` points at `apache\u002Fairflow` with the fork under a\ndifferent name like `fork` — **do not silently go along with the existing\nnames**. Surface the mismatch to the user and propose the exact rename commands\nto bring the checkout in line with the convention, then ask the user to confirm\nbefore running them. Examples:\n\n- Upstream is named `apache`, fork is `origin` (common legacy layout):\n\n  ```bash\n  git remote rename apache upstream\n  ```\n\n- `origin` points at `apache\u002Fairflow` and the fork is named `fork` (release-manager\n  \u002F \"cloned upstream directly\" layout):\n\n  ```bash\n  git remote rename origin upstream\n  git remote rename fork origin\n  ```\n\n- Upstream is missing entirely:\n\n  ```bash\n  git remote add upstream https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow.git\n  # or, for SSH:\n  git remote add upstream git@github.com:apache\u002Fairflow.git\n  ```\n\n- Fork is missing entirely:\n\n  ```bash\n  gh repo fork apache\u002Fairflow --remote --remote-name origin\n  ```\n\nAfter any rename\u002Fadd, re-run `git remote -v` to confirm the new state before\ncontinuing with commands that assume `upstream` \u002F `origin`.\n\nIf a doc, script, or command you're about to run uses the old `apache` name (or\nany other variant), **translate it to the `upstream` convention** in what you\npropose to the user, rather than perpetuating the old name. Flag the stale\ndocumentation so it can be fixed in a follow-up.\n\n## Before starting: check for an existing PR\n\nBefore working on an issue, check for open PRs already addressing it\n(`gh pr list --search \"\u003Cissue number or keywords>\"`, and look for `closes:`\n\u002F `fixes:` references). Airflow allows parallel work — \"better PR wins\"\n(see `contributing-docs\u002F04_how_to_contribute.rst`) — but it is not the\ndefault: prefer reviewing and building on an existing PR. Open a separate\none only *if your approach is genuinely different*. Do not blindly open\nanother near-identical PR for an issue that already has one (or several) —\nthat just adds reviewer noise.\n\n## Creating Pull Requests\n\n**Always push to the user's fork (`origin`)**, not to `upstream` (`apache\u002Fairflow`).\nNever push directly to `main`.\n\nBefore pushing, confirm the remote setup matches the conventions above\n(`upstream` → `apache\u002Fairflow`, `origin` → your fork). Run `git remote -v` and,\nif the names don't match, propose renames as described in \"Git remote naming\nconventions\" — ask the user to confirm before running them.\n\nIf the fork remote does not exist at all, create one:\n\n```bash\ngh repo fork apache\u002Fairflow --remote --remote-name origin\n```\n\nBefore pushing, perform a self-review of your changes following the Gen-AI review guidelines\nin [`contributing-docs\u002F05_pull_requests.rst`](..\u002F..\u002F..\u002Fcontributing-docs\u002F05_pull_requests.rst) and the\ncode review checklist in [`.github\u002Finstructions\u002Fcode-review.instructions.md`](..\u002F..\u002F..\u002F.github\u002Finstructions\u002Fcode-review.instructions.md):\n\n1. Review the full diff (`git diff main...HEAD`) and verify every change is intentional and\n   related to the task — remove any unrelated changes.\n2. Read `.github\u002Finstructions\u002Fcode-review.instructions.md` and check your diff against every\n   rule — architecture boundaries, database correctness, code quality, testing requirements,\n   API correctness, and AI-generated code signals. Fix any violations before pushing.\n3. Confirm the code follows the project's coding standards and architecture boundaries\n   described in root [`AGENTS.md`](..\u002F..\u002F..\u002FAGENTS.md).\n4. Run regular (fast) static checks (`prek run --from-ref \u003Ctarget_branch> --stage pre-commit`)\n   and fix any failures. This includes mypy checks for non-provider projects (airflow-core, task-sdk, airflow-ctl, dev, scripts, devel-common).\n5. Run manual (slower) checks\n   (`prek run --from-ref \u003Ctarget_branch> --stage manual --skip compile-ui-assets-dev --skip view-skill-eval --skip run-skill-eval-codex`)\n   and fix any failures. The skipped hooks start long-running local servers or provision the\n   opt-in Codex environment rather than run checks that complete.\n6. Run relevant individual tests and confirm they pass.\n7. If the diff touches a performance-sensitive component (Task SDK comms, supervisor and task runner;\n   Execution API; logging and secret masking; serialization; scheduler and triggerer loops; Dag\n   processing), benchmark the code before and after the change as\n   [`references\u002Fperformance-sensitive-components.md`](references\u002Fperformance-sensitive-components.md)\n   describes, and report the outcome to the user.\n8. Run `breeze verify` and execute every command it lists. The list comes from the same selective-checks logic CI uses. `breeze verify --full` shows everything CI runs for the default matrix cell, including the full suite CI adds when a change touches CI tooling or dependency files. Static checks are not listed: steps 4 and 5 cover them. Confirm the commands pass and check for CI-specific issues.\n9. Check for security issues — no secrets, no injection vulnerabilities, no unsafe patterns.\n\nBefore pushing, always rebase your branch onto the latest target branch (usually `main`)\nto avoid merge conflicts and ensure CI runs against up-to-date code:\n\n```bash\ngit fetch upstream \u003Ctarget_branch>\ngit rebase upstream\u002F\u003Ctarget_branch>\n```\n\nIf there are conflicts, resolve them and continue the rebase. If the rebase is too complex,\nask the user for guidance.\n\nThen push the branch to your fork (`origin`) and open the PR creation page in the browser\nwith the body pre-filled (including the generative AI disclosure already checked):\n\n```bash\ngit push -u origin \u003Cbranch-name>\ngh pr create --web --title \"Short title (under 70 chars)\" --body \"$(cat \u003C\u003C'EOF'\nBrief description of the changes.\n\ncloses: #ISSUE  (if applicable)\n\n---\n\n##### Was generative AI tooling used to co-author this PR?\n\n- [X] Yes — \u003CAgent Name and Version>\n\nGenerated-by: \u003CAgent Name and Version> following [the guidelines](https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002Fcontributing-docs\u002F05_pull_requests.rst#gen-ai-assisted-contributions)\n\nEOF\n)\"\n```\n\nThe `--web` flag opens the browser so the user can review and submit. The `--body` flag\npre-fills the PR template with the generative AI disclosure already completed.\n\nRemind the user to:\n\n1. Review the PR title — keep it short (under 70 chars), in the imperative mood, and focused on user impact. Do not use Conventional Commits prefixes (`fix:`, `feat:`, `chore:`, …).\n2. Add a brief description of the changes at the top of the body.\n3. Reference related issues when applicable (`closes: #ISSUE` or `related: #ISSUE`).\n\n## Golden rule: when a fix is imminent, open the PR, not an issue\n\nIf you already know how to fix the problem and you (or the user) are going to\nopen the PR shortly, **do not file a GitHub issue first**. Go straight to the\nPR.\n\n- Airflow does not use issues as a changelog, as a parallel bug database, or\n  as a duplicate record of in-flight work. The PR itself is the canonical\n  record — title, description, diff, discussion, and merge all live in one\n  place. An issue that gets closed by a PR a day later is double accounting\n  that carries no information the PR does not already carry.\n- Open issues attract drive-by submissions, often from other agents, that\n  haven't seen the in-flight work. That produces duplicate fixes, low-quality\n  PRs that have to be closed, and wasted reviewer time. Not opening the\n  issue avoids creating that bait in the first place.\n- If you catch yourself drafting an issue body that reads like the PR\n  description you are about to write, that is the signal — skip the issue\n  and open the PR.\n\nThe one exception is the case covered by the next section: the PR ships a\n**workaround, mitigation, or partial fix** and the real follow-up work is\ngenuinely deferred to a later PR. There, the issue captures work that will\noutlive the PR, so the issue is load-bearing rather than duplicate.\n\n## Tracking issues for deferred work\n\nWhen a PR applies a **workaround, version cap, mitigation, or partial fix**\nrather than solving the underlying problem (for example: upper-binding a\ndependency to avoid a breaking upstream release, disabling a feature\nbehind a flag, reverting a change that needs a better replacement, or\npapering over a bug so a release can ship), the deferred work must be\ncaptured in a GitHub tracking issue **and** the tracking issue URL must\nappear as a comment at the workaround site in the code.\n\n1. **Open the tracking issue first**, before finalising the PR body.\n2. **Reference it in the PR body by number** — e.g. \"full migration is\n   tracked in #65609\" — so anyone reviewing the PR can see what was\n   deferred and why.\n3. **Add a link to the tracking issue as a comment at the workaround\n   itself**, so the reference survives after the PR merges and anyone\n   reading the source later can click straight through to the follow-up\n   work. Use the **full issue URL**, not bare `#NNNNN` — bare references\n   do not auto-link outside GitHub's web UI (e.g. when grepping in an\n   editor, browsing a checkout, or reading the file in a terminal).\n   For example:\n\n   ```toml\n   # pyproject.toml\n   # Remove the \u003C1.0 cap after migrating to httpx 1.x;\n   # tracked at https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fissues\u002F65609\n   \"httpx>=0.27.0,\u003C1.0\",\n   ```\n\n   ```python\n   # some_module.py\n   # Delete this fallback once the new client is on all workers;\n   # tracked at https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fissues\u002F65609\n   if old_client:\n       ...\n   ```\n\n4. **Do not** write vague forward-looking phrases like \"will open a\n   tracking issue\" or \"to be filed later\" in the PR body or in code\n   comments. Open the issue, link it in both places, then submit the PR.\n5. The tracking issue should describe: what the workaround is, why it\n   was chosen, the concrete follow-up work needed, and any acceptance\n   criteria for removing the workaround.\n\nIf a PR you already opened has such forward-looking language, open the\ntracking issue, add a PR comment referencing the issue URL, and push a\nfollow-up commit that adds the tracking-issue URL as a comment at the\nworkaround site in the code.\n",{"name":5,"description":7},"main","f7e28eec7309f5700ca69ec226df41a5c58d5213",".agents\u002Fskills\u002Fairflow-publish-changes",18343,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow","https:\u002F\u002Fairflow.apache.org\u002F","https:\u002F\u002Fgithub.com\u002Fapache","https:\u002F\u002Fwww.apache.org\u002F","2026-11-11 11:20:17",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add apache\u002Fairflow --skill airflow-publish-changes",{"tool":59,"command":60},"bunx","bunx skills add apache\u002Fairflow --skill airflow-publish-changes",{"tool":62,"command":63},"pnpm","pnpm dlx skills add apache\u002Fairflow --skill airflow-publish-changes","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fairflow-publish-changes\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fperformance-sensitive-components.md","REFERENCE","参考文档",2069,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fairflow-publish-changes\u002Freferences\u002Fperformance-sensitive-components.md",[74,104,125,151,177,199],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":90,"publishedAt":39},"01M6ACBAC3S7GHPX3EB91CA2K5","sql-reporting","Conventions and review steps for writing analytics SQL against the warehouse. Use whenever the task involves querying tables, building a report, or aggregating metrics.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002Fproviders\u002Fcommon\u002Fai\u002Fsrc\u002Fairflow\u002Fproviders\u002Fcommon\u002Fai\u002Fexample_dags\u002Fskills\u002Fsql-reporting\u002FSKILL.md",[80,85],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[91,92,93,94,95,96,97,98,99,100,101,30,102,103],"sql reporting","sql","reporting","writing","review","report","analytics","metrics","tables","warehouse","for","task","conventions",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":39},"01M6ACB7P9C6TV0J1FGWW5HECF","aip-tracker","Track Airflow Improvement Proposal (AIP) implementation progress by comparing Confluence specs against codebase evidence. Use when asked to assess, report on, or compare AIP status.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002Fproviders\u002Fcommon\u002Fai\u002Fsrc\u002Fairflow\u002Fproviders\u002Fcommon\u002Fai\u002Fexample_dags\u002Fskills\u002Faip-tracker\u002FSKILL.md",[],[111,112,113,20,96,114,115,25,116,117,118,119,120,30,121,122,123,124],"aip tracker","aip","tracker","status","proposal","track","progress","evidence","improvement","assess","compare","codebase","implementation","confluence",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":39},"01M6ACB55GGWPTWFKM3BVQS4W5","upgrade-fab-provider","Upgrade the pinned Flask-AppBuilder (FAB) dependency in the Apache Airflow FAB provider (`providers\u002Ffab\u002F`). Bumps the exact `flask-appbuilder==` pin and its mirror constant, regenerates `uv.lock`, drives the `test_fab_alignment.py` drift tripwire, reviews the vendored security-manager `override.py` against the new upstream FAB, and conditionally re-vendors static assets \u002F DB migrations. Use when asked to \"upgrade FAB\", \"bump flask-appbuilder\", or move the FAB provider to a newer Flask-AppBuilder release.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fupgrade-fab-provider\u002FSKILL.md",[],[132,133,134,135,20,9,33,136,137,138,139,140,141,142,143,144,145,146,25,147,148,149,150],"upgrade fab provider","upgrade","provider","test","release","security","alignment","reviews","db","bump","static","re","move","new","uv","drift","tripwire","lock","dependency",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":160,"publishedAt":39},"01M6ACB2TYRC6SB5TQ351K2Q7Q","prepare-providers-documentation","Replace the manual commit-by-commit classification step in `breeze release-management prepare-provider-documentation` with AI-driven classification. For each provider with pending changes, analyze every PR (batched into one sub-agent per provider, not one per PR), pay special attention to potentially breaking changes by inspecting the actual diff, scope multi-provider PRs to the current provider's slice, ask the release manager when uncertain, and apply version bumps + changelog entries. Use during the regular provider release cycle as an alternative to the interactive breeze prompts.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fprepare-providers-documentation\u002FSKILL.md",[157],{"categoryNo":158,"categoryName":159,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000023","Skill与智能体开发",[161,162,24,163,38,164,165,136,166,167,168,25,169,170,171,172,173,174,175,176],"documentation","prepare providers documentation","Providers","commit","changelog","scope","cycle","pay","ask","analyze","sub-agent","multi-provider","manager","as","attention","diff",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":39},"01M6ACAZ1M5SJQH1SHFFY7CXQF","airflow-translations","Add or update translations for the Apache Airflow UI. Guides through setting up locales, scaffolding translation files, translating with locale-specific guidelines, and validating results. Use when working with i18n tasks in airflow-core\u002Fsrc\u002Fairflow\u002Fui\u002Fpublic\u002Fi18n\u002Flocales\u002F.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fairflow-translations\u002FSKILL.md",[],[20,184,185,186,187,9,33,188,189,190,191,192,193,194,195,196,197,25,198,101],"airflow translations","core","guidelines","tasks","update","translation","scaffolding","up","files","guides","i18n","src","ui","add","locale",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":39},"01M6ACAT3JW1XZD3Z9EPP4H68M","airflow-pr-draft-summary","Draft Apache Airflow commit messages, PR titles and descriptions, or GitHub comments and reviews. Also use for release-note decisions when preparing a contribution.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fairflow-pr-draft-summary\u002FSKILL.md",[],[38,206,20,207,208,209,210,164,9,211,33,136,139,212,25,213,101,30,214,215,27],"pr draft summary","airflow pr draft summary","pr draft","draft","summary","github","messages","commit messages","decisions","comments"]