[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ACAQ4V2WBZA2D38X2X47VR":3,"skill-same:01M6ACAQ4V2WBZA2D38X2X47VR":70},{"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":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6ACAQ4V2WBZA2D38X2X47VR","airflow-new-sdk",null,"Guide for implementing a brand-new language SDK for Airflow (AIP-108). Use this skill when a contributor wants to add support for a new programming language — designing the Python coordinator, implementing the wire protocol in the target language, writing the bundle format, and structuring the PR. Trigger on phrases like \"new language SDK\", \"new SDK\", \"add support for [language]\", \"implement coordinator for\", \"SubprocessCoordinator\", \"BaseCoordinator\", \"new runtime\", \"AFBNDL01\", \"supervisor schema\", or anything about bringing a new language into the Airflow executor ecosystem.","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-new-sdk\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"new","sdk","airflow","airflow new sdk","guide","when","contributor","aip","for","implementing","ecosystem","coordinator","add","executor","runtime","writing","brand","programming language","protocol","pr","support","implement","python","2026-11-10 10:12:30",false,"---\nname: airflow-new-sdk\ndescription: >\n  Guide for implementing a brand-new language SDK for Airflow (AIP-108). Use\n  this skill when a contributor wants to add support for a new programming\n  language — designing the Python coordinator, implementing the wire protocol in\n  the target language, writing the bundle format, and structuring the PR. Trigger\n  on phrases like \"new language SDK\", \"new SDK\", \"add support for [language]\",\n  \"implement coordinator for\", \"SubprocessCoordinator\", \"BaseCoordinator\",\n  \"new runtime\", \"AFBNDL01\", \"supervisor schema\", or anything about bringing a\n  new language into the Airflow executor ecosystem.\n---\n\n\u003C!-- SPDX-License-Identifier: Apache-2.0\n     https:\u002F\u002Fwww.apache.org\u002Flicenses\u002FLICENSE-2.0 -->\n\n# Implementing a new language SDK for Airflow\n\n## Start here\n\n**Read `contributing-docs\u002F30_new_language_sdk.rst` first.** It is the\nauthoritative contributor guide for this topic — coordinator base class choices,\nwire protocol spec, bundle footer format, and testing requirements. Everything\nin this skill builds on top of it, not alongside it.\n\n---\n\n## Repository layout\n\nEvery new SDK needs two things. The coordinator (Python) goes here:\n\n```\ntask-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fcoordinators\u002F\u003Clanguage>\u002F\n    __init__.py        # re-export + module docstring\n    coordinator.py     # subclass of SubprocessCoordinator or BaseCoordinator\ntask-sdk\u002Ftests\u002Fcoordinators\u002F\u003Clanguage>\u002F\n    test_coordinator.py\ntask-sdk\u002Ftests\u002Fintegration\u002Fcoordinators\u002F\u003Clanguage>\u002F\n    test_integration.py   # requires Breeze\n```\n\nThe language SDK itself lives in a top-level `\u003Clanguage>-sdk\u002F` directory (like\n`java-sdk\u002F` and `go-sdk\u002F`). For native-executable languages using\n`ExecutableCoordinator`, no coordinator code is needed at all.\n\n---\n\n## Choosing the right base class — quick guide\n\n```\nDoes the runtime compile to a self-contained native executable?\n  YES → Use ExecutableCoordinator (zero Python to write).\n        Append an AFBNDL01 footer with a packer tool (see go-sdk reference).\n  NO  →\n    Does it start via a single shell command (node, ruby, dotnet, …)?\n      YES → Subclass SubprocessCoordinator.\n            Implement _build_execute_task_command only (see 30_new_language_sdk.rst).\n      NO  →\n        Subclass BaseCoordinator and implement execute_task from scratch.\n        (Rare: gRPC daemons, shared memory, persistent processes.)\n```\n\nThe full rationale, method signature, and socket lifecycle for each path are in\n`30_new_language_sdk.rst`. Read that section before writing any code.\n\n---\n\n## Reference implementations to study\n\n| What to study | Where |\n|---|---|\n| SubprocessCoordinator base class | `task-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fcoordinators\u002F_subprocess.py` |\n| Java coordinator (SubprocessCoordinator subclass) | `task-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fcoordinators\u002Fjava\u002Fcoordinator.py` |\n| ExecutableCoordinator (native bundles) | `task-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fcoordinators\u002Fexecutable\u002Fcoordinator.py` |\n| Wire protocol in Kotlin | `java-sdk\u002Fsdk\u002Fsrc\u002Fmain\u002Fkotlin\u002Forg\u002Fapache\u002Fairflow\u002Fsdk\u002Fexecution\u002F` |\n| Wire protocol in Go | `go-sdk\u002Fpkg\u002Fexecution\u002F` |\n| AFBNDL01 footer (Go reference) | `go-sdk\u002Finternal\u002Fbundlefooter\u002F`, `task-sdk\u002Fdocs\u002Fexecutable-bundle-spec.rst` |\n| All message types and field specs | `task-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fexecution_time\u002Fschema\u002Fschema.json` |\n\nThe Java and Go implementations are the two production reference points. When\nimplementing a new SDK, read whichever matches the target language's runtime\nmodel (JVM\u002Finterpreted → Java; native\u002Fcompiled → Go).\n\n---\n\n## Logging\n\nThe **Logging** section of `30_new_language_sdk.rst` is the spec: the `--logs`\nJSON record format, the level names, and the `AIRFLOW__LOGGING__*` environment\nvariables. Read it first. A few language-neutral details it leaves out:\n\n- **Level values.** Levels follow Python's `logging` scale, so thresholds line\n  up with the rest of Airflow: `CRITICAL=50`, `ERROR=40`, `WARNING=30`,\n  `INFO=20`, `DEBUG=10`, `NOTSET=0`.\n- **Parsing `NAMESPACE_LEVELS`.** Split the value on `[\\s,]+`, then split each\n  item on `=` into `(logger_name, level_name)`. Emit a record only when its\n  level is `>=` the matching `logger_name` threshold, or the global threshold\n  when no per-logger entry matches.\n- **Don't drop late logs.** Connect the `--logs` socket early and keep it open\n  until the `--comm` channel has finished; otherwise records emitted during\n  teardown can be lost.\n- **Extra config keys.** The runtime can't read Airflow's config, so if your SDK\n  needs `[logging]` settings beyond the two above, propagate them as environment\n  variables from your coordinator's `start`, the same way.\n\nFor how a given language wires its native logging frameworks into this channel,\nread that SDK's source (e.g. `java-sdk\u002F`) rather than reproducing it here.\n\n### E2E test suite\n\nCreate two files mirroring `java_sdk_tests\u002F` or `go_sdk_tests\u002F`:\n\n```\nairflow-e2e-tests\u002Ftests\u002Fairflow_e2e_tests\u002F\u003Clanguage>_sdk_tests\u002F\n    __init__.py\n    test_\u003Clanguage>_sdk_dag.py\n```\n\nThe test file should:\n\n- Trigger the SDK's example Dag (the one added to `\u003Clanguage>-sdk\u002Fdags\u002F` or\n  equivalent) via `AirflowClient.trigger_dag`.\n- Wait for the run to finish with `AirflowClient.wait_for_dag_run`.\n- Assert that each SDK task instance reached `\"success\"`.\n- Assert at least one XCom value — confirms the full round-trip from task\n  return value through the supervisor to the XCom store.\n- Assert structured logs where the SDK emits them (see the Go suite for an\n  example of log-content assertions).\n\nRun locally with:\n\n```bash\nE2E_TEST_MODE=\u003Clanguage>_sdk uv run --project airflow-e2e-tests pytest \\\n    tests\u002Fairflow_e2e_tests\u002F\u003Clanguage>_sdk_tests\u002F -xvs\n```\n\nThe Java (`java_sdk_tests\u002Ftest_java_sdk_dag.py`) and Go\n(`go_sdk_tests\u002Ftest_go_sdk_dag.py`) suites are the reference implementations.\n\n\n---\n\n## PR checklist (items not covered by 30_new_language_sdk.rst)\n\nThe `30_new_language_sdk.rst` guide covers coordinator placement, wire protocol\nimplementation, and testing. These additional items belong in the same PR:\n\n1. `task-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fcoordinators\u002F\u003Clanguage>\u002F__init__.py` — short\n   module docstring and `__all__` re-export of the coordinator class.\n2. `airflow-core\u002Fdocs\u002Fauthoring-and-scheduling\u002Flanguage-sdks\u002F\u003Clanguage>.rst` —\n   user-facing doc following the structure of `java.rst` or `go.rst`.\n3. `airflow-core\u002Fdocs\u002Fauthoring-and-scheduling\u002Flanguage-sdks\u002Findex.rst` — add\n   the new doc to the toctree.\n4. `airflow-core\u002Fnewsfragments\u002F\u003CPR>.feature.rst` — a new language is always\n   user-visible; add a newsfragment.\n5. CI wiring — check `dev\u002Fbreeze\u002Fsrc\u002Fairflow_breeze\u002Futils\u002Fselective_checks.py`\n   to confirm `\u003Clanguage>-sdk\u002F` changes trigger the right test group. Add if\n   missing.\n6. E2E tests — add a `\u003Clanguage>_sdk_tests\u002F` suite under\n   `airflow-e2e-tests\u002Ftests\u002Fairflow_e2e_tests\u002F`. See below.\n","\u003C!-- SPDX-License-Identifier: Apache-2.0\n     https:\u002F\u002Fwww.apache.org\u002Flicenses\u002FLICENSE-2.0 -->\n\n# Implementing a new language SDK for Airflow\n\n## Start here\n\n**Read `contributing-docs\u002F30_new_language_sdk.rst` first.** It is the\nauthoritative contributor guide for this topic — coordinator base class choices,\nwire protocol spec, bundle footer format, and testing requirements. Everything\nin this skill builds on top of it, not alongside it.\n\n---\n\n## Repository layout\n\nEvery new SDK needs two things. The coordinator (Python) goes here:\n\n```\ntask-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fcoordinators\u002F\u003Clanguage>\u002F\n    __init__.py        # re-export + module docstring\n    coordinator.py     # subclass of SubprocessCoordinator or BaseCoordinator\ntask-sdk\u002Ftests\u002Fcoordinators\u002F\u003Clanguage>\u002F\n    test_coordinator.py\ntask-sdk\u002Ftests\u002Fintegration\u002Fcoordinators\u002F\u003Clanguage>\u002F\n    test_integration.py   # requires Breeze\n```\n\nThe language SDK itself lives in a top-level `\u003Clanguage>-sdk\u002F` directory (like\n`java-sdk\u002F` and `go-sdk\u002F`). For native-executable languages using\n`ExecutableCoordinator`, no coordinator code is needed at all.\n\n---\n\n## Choosing the right base class — quick guide\n\n```\nDoes the runtime compile to a self-contained native executable?\n  YES → Use ExecutableCoordinator (zero Python to write).\n        Append an AFBNDL01 footer with a packer tool (see go-sdk reference).\n  NO  →\n    Does it start via a single shell command (node, ruby, dotnet, …)?\n      YES → Subclass SubprocessCoordinator.\n            Implement _build_execute_task_command only (see 30_new_language_sdk.rst).\n      NO  →\n        Subclass BaseCoordinator and implement execute_task from scratch.\n        (Rare: gRPC daemons, shared memory, persistent processes.)\n```\n\nThe full rationale, method signature, and socket lifecycle for each path are in\n`30_new_language_sdk.rst`. Read that section before writing any code.\n\n---\n\n## Reference implementations to study\n\n| What to study | Where |\n|---|---|\n| SubprocessCoordinator base class | `task-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fcoordinators\u002F_subprocess.py` |\n| Java coordinator (SubprocessCoordinator subclass) | `task-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fcoordinators\u002Fjava\u002Fcoordinator.py` |\n| ExecutableCoordinator (native bundles) | `task-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fcoordinators\u002Fexecutable\u002Fcoordinator.py` |\n| Wire protocol in Kotlin | `java-sdk\u002Fsdk\u002Fsrc\u002Fmain\u002Fkotlin\u002Forg\u002Fapache\u002Fairflow\u002Fsdk\u002Fexecution\u002F` |\n| Wire protocol in Go | `go-sdk\u002Fpkg\u002Fexecution\u002F` |\n| AFBNDL01 footer (Go reference) | `go-sdk\u002Finternal\u002Fbundlefooter\u002F`, `task-sdk\u002Fdocs\u002Fexecutable-bundle-spec.rst` |\n| All message types and field specs | `task-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fexecution_time\u002Fschema\u002Fschema.json` |\n\nThe Java and Go implementations are the two production reference points. When\nimplementing a new SDK, read whichever matches the target language's runtime\nmodel (JVM\u002Finterpreted → Java; native\u002Fcompiled → Go).\n\n---\n\n## Logging\n\nThe **Logging** section of `30_new_language_sdk.rst` is the spec: the `--logs`\nJSON record format, the level names, and the `AIRFLOW__LOGGING__*` environment\nvariables. Read it first. A few language-neutral details it leaves out:\n\n- **Level values.** Levels follow Python's `logging` scale, so thresholds line\n  up with the rest of Airflow: `CRITICAL=50`, `ERROR=40`, `WARNING=30`,\n  `INFO=20`, `DEBUG=10`, `NOTSET=0`.\n- **Parsing `NAMESPACE_LEVELS`.** Split the value on `[\\s,]+`, then split each\n  item on `=` into `(logger_name, level_name)`. Emit a record only when its\n  level is `>=` the matching `logger_name` threshold, or the global threshold\n  when no per-logger entry matches.\n- **Don't drop late logs.** Connect the `--logs` socket early and keep it open\n  until the `--comm` channel has finished; otherwise records emitted during\n  teardown can be lost.\n- **Extra config keys.** The runtime can't read Airflow's config, so if your SDK\n  needs `[logging]` settings beyond the two above, propagate them as environment\n  variables from your coordinator's `start`, the same way.\n\nFor how a given language wires its native logging frameworks into this channel,\nread that SDK's source (e.g. `java-sdk\u002F`) rather than reproducing it here.\n\n### E2E test suite\n\nCreate two files mirroring `java_sdk_tests\u002F` or `go_sdk_tests\u002F`:\n\n```\nairflow-e2e-tests\u002Ftests\u002Fairflow_e2e_tests\u002F\u003Clanguage>_sdk_tests\u002F\n    __init__.py\n    test_\u003Clanguage>_sdk_dag.py\n```\n\nThe test file should:\n\n- Trigger the SDK's example Dag (the one added to `\u003Clanguage>-sdk\u002Fdags\u002F` or\n  equivalent) via `AirflowClient.trigger_dag`.\n- Wait for the run to finish with `AirflowClient.wait_for_dag_run`.\n- Assert that each SDK task instance reached `\"success\"`.\n- Assert at least one XCom value — confirms the full round-trip from task\n  return value through the supervisor to the XCom store.\n- Assert structured logs where the SDK emits them (see the Go suite for an\n  example of log-content assertions).\n\nRun locally with:\n\n```bash\nE2E_TEST_MODE=\u003Clanguage>_sdk uv run --project airflow-e2e-tests pytest \\\n    tests\u002Fairflow_e2e_tests\u002F\u003Clanguage>_sdk_tests\u002F -xvs\n```\n\nThe Java (`java_sdk_tests\u002Ftest_java_sdk_dag.py`) and Go\n(`go_sdk_tests\u002Ftest_go_sdk_dag.py`) suites are the reference implementations.\n\n\n---\n\n## PR checklist (items not covered by 30_new_language_sdk.rst)\n\nThe `30_new_language_sdk.rst` guide covers coordinator placement, wire protocol\nimplementation, and testing. These additional items belong in the same PR:\n\n1. `task-sdk\u002Fsrc\u002Fairflow\u002Fsdk\u002Fcoordinators\u002F\u003Clanguage>\u002F__init__.py` — short\n   module docstring and `__all__` re-export of the coordinator class.\n2. `airflow-core\u002Fdocs\u002Fauthoring-and-scheduling\u002Flanguage-sdks\u002F\u003Clanguage>.rst` —\n   user-facing doc following the structure of `java.rst` or `go.rst`.\n3. `airflow-core\u002Fdocs\u002Fauthoring-and-scheduling\u002Flanguage-sdks\u002Findex.rst` — add\n   the new doc to the toctree.\n4. `airflow-core\u002Fnewsfragments\u002F\u003CPR>.feature.rst` — a new language is always\n   user-visible; add a newsfragment.\n5. CI wiring — check `dev\u002Fbreeze\u002Fsrc\u002Fairflow_breeze\u002Futils\u002Fselective_checks.py`\n   to confirm `\u003Clanguage>-sdk\u002F` changes trigger the right test group. Add if\n   missing.\n6. E2E tests — add a `\u003Clanguage>_sdk_tests\u002F` suite under\n   `airflow-e2e-tests\u002Ftests\u002Fairflow_e2e_tests\u002F`. See below.\n",{"name":5,"description":7},"main","f7e28eec7309f5700ca69ec226df41a5c58d5213",".agents\u002Fskills\u002Fairflow-new-sdk",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":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add apache\u002Fairflow --skill airflow-new-sdk",{"tool":62,"command":63},"bunx","bunx skills add apache\u002Fairflow --skill airflow-new-sdk",{"tool":65,"command":66},"pnpm","pnpm dlx skills add apache\u002Fairflow --skill airflow-new-sdk","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fairflow-new-sdk\u002FSKILL.md",true,[],[71,100,120,146,173,194],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":87,"publishedAt":42},"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",[77,82],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[88,89,90,34,91,92,93,94,95,96,27,97,98,99],"sql reporting","sql","reporting","review","report","analytics","metrics","tables","warehouse","use","task","conventions",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":42},"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",[],[107,26,108,21,92,109,110,24,111,112,113,114,115,97,116,117,118,119],"aip tracker","tracker","status","proposal","track","progress","evidence","improvement","assess","compare","codebase","implementation","confluence",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":42},"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",[],[127,128,129,130,21,9,131,132,133,134,135,136,137,138,139,140,19,141,24,142,143,144,145],"upgrade fab provider","upgrade","provider","test","apache airflow","release","security","alignment","reviews","db","bump","static","re","move","uv","drift","tripwire","lock","dependency",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":155,"publishedAt":42},"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",[152],{"categoryNo":153,"categoryName":154,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000023","Skill与智能体开发",[156,157,158,159,38,160,161,132,162,163,164,24,165,166,167,168,169,170,171,172],"documentation","prepare providers documentation","prepare","Providers","commit","changelog","scope","cycle","pay","ask","analyze","sub-agent","multi-provider","manager","as","attention","diff",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":42},"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",[],[21,180,181,182,183,9,131,184,185,186,187,188,189,190,191,192,31,24,193,27],"airflow translations","core","guidelines","tasks","update","translation","scaffolding","up","files","guides","i18n","src","ui","locale",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":42},"01M6ACAWMSPCZCQMCJ0WPVTFQ9","airflow-publish-changes","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.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fairflow-publish-changes\u002FSKILL.md",[],[21,201,202,203,204,38,205,206,207,9,131,158,208,209,24,210,211,212,97,213,214],"airflow publish changes","publish","changes","push","planning","issues","verification","creation","remote","work","pr creation","Publication","contribution","tracking"]