[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ACAGQTAG0QCJWCFXR69RTZ":3,"skill-same:01M6ACAGQTAG0QCJWCFXR69RTZ":77},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6ACAGQTAG0QCJWCFXR69RTZ","aip-user-stories",null,"Generate verified recipe playbooks from AIPs with PR implementations (post mode), or speculative user stories from AIPs without implementations (pre mode). Use when the user provides an AIP URL or AIP content, optionally with PR URLs and file paths.","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\u002Faip-user-stories\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,9,38,39],"stories","aip","aip user stories","user stories","user","recipes","when","verified","mode","URL","org","paths","recipe","github","read","gh pr","Bash","how","playbook","generate","pr","2026-11-10 10:12:30",false,"---\nname: aip-user-stories\ndescription: Generate verified recipe playbooks from AIPs with PR implementations (post mode), or speculative user stories from AIPs without implementations (pre mode). Use when the user provides an AIP URL or AIP content, optionally with PR URLs and file paths.\nwhen_to_use: Trigger when the user mentions aip user stories, aip playbook, aip recipes, generate recipes from AIP, user stories for AIP, AIP guide, AIP how-to.\nallowed-tools: Bash(gh pr view *) Bash(gh pr diff *) Read WebFetch(domain:cwiki.apache.org) WebFetch(domain:github.com)\nargument-hint: \u003CAIP-URL-or-pasted-content> [\u003CPR-URL>...] [\u003Cfile>...]\nlicense: Apache-2.0\n---\n\n\u003C!-- SPDX-License-Identifier: Apache-2.0\n     https:\u002F\u002Fwww.apache.org\u002Flicenses\u002FLICENSE-2.0 -->\n\n# AIP-to-User-Stories Playbook\n\n## Invocation\n\n```\n\u002Faip-user-stories \u003CAIP-URL-or-pasted-content> [\u003CPR-URL>...] [\u003Cfile>...]\n```\n\nIf no arguments: print this usage synopsis and stop.\n\n## Mode Detection\n\nAn argument starting with `https:\u002F\u002Fcwiki.apache.org\u002Fconfluence\u002F` is the AIP URL. Arguments starting with `https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fpull\u002F` are PR URLs. Other arguments are local file paths.\n\n- **PR URLs present → post-implementation mode**: generates verified recipe playbooks from actual code.\n- **No PR URLs → pre-implementation mode**: generates speculative user stories to help AIP authors validate design.\n\nPR URLs signal post mode and serve as **discovery hints** — starting points for finding the implementation in the codebase. They are not an exhaustive list of all PRs for the feature, and the skill must explore beyond the supplied PRs to find the full implementation.\n\n## AIP Number\n\nExtract the AIP number from the URL path (e.g., `AIP-76` from a URL containing `\u002Faip-76` or `\u002FAIP-76`). If the number cannot be determined from the URL or pasted content, ask the user.\n\n## Output Path\n\nWrite the final playbook to `.claude\u002Faip-{number}.md` where `{number}` is the extracted AIP number. If the file already exists, ask the user before overwriting.\n\n---\n\n## Post-Implementation Mode\n\nSource of truth: the **actual implementation** in the codebase and PRs — not the AIP specification. When the AIP proposes APIs that differ from what was implemented, the playbook follows the implementation.\n\n### Phase 1 — Parse\n\nSeparate arguments into:\n\n- **AIP source**: a URL to fetch, or pasted content already in the conversation.\n- **PR URLs**: GitHub pull request URLs (one or more).\n- **File paths**: local files (example Dags, source files, tests).\n\nAIP content can come from a URL (fetched via WebFetch) or pasted directly by the user — both are equally valid input paths. If a URL fetch returns empty or garbled content, tell the user and ask them to paste the AIP content instead.\n\nAt least one PR URL is required in post mode. If none are provided but the mode was forced, ask for PR URLs.\n\n### Phase 2 — Fetch & Discover\n\nRetrieve initial sources:\n\n- AIP content (from URL or already pasted).\n- PR diffs and metadata via `gh pr view \u003Cnumber> --json title,body,files` and `gh pr diff \u003Cnumber>`.\n- Local files specified as arguments.\n\nThen use the PRs as **discovery seeds**: identify which modules, packages, and files the PRs touch, and explore outward from there:\n\n- Read the touched files in their current state (not just the diff) to understand the full implementation.\n- Follow imports, base classes, and related modules to find connected implementation code.\n- Search for related example Dags, test files, and documentation that may not appear in the PR diffs.\n- Grep for key class names, function names, and configuration keys from the AIP to find implementation spread across files the PRs didn't touch.\n\nThe PRs are a starting point, not a boundary. Code may have been implemented in other PRs, refactored since the PR merged, or spread across modules the PR didn't directly modify.\n\n### Phase 3 — Analyze\n\nCross-reference AIP features against the **codebase** (not the PRs):\n\n- Which AIP features are implemented (found in the current codebase)?\n- Which AIP features are NOT implemented (proposed in AIP but absent from the codebase)?\n- What patterns exist in tests and example Dags that demonstrate usage?\n\n### Version Detection\n\nSearch PR diffs for `versionadded::` or `.. versionadded::` directives. If found, use that version. If not found, ask the user for the target Airflow version.\n\n### Phase 4 — Propose\n\nPresent a numbered list of recipe candidates, grouped by concept:\n\n```\n**[Concept Group Name]**\n1. Recipe Title — one-sentence description of what the user accomplishes\n2. Recipe Title — one-sentence description\n...\n```\n\nEach recipe maps to one distinct use case — a specific problem the user solves with this feature. If two API classes serve the same use case, combine them. If one class serves multiple use cases, split them.\n\nFor AIP features not found in the implementation, list them separately under **Not Yet Implemented** and ask the user: include with placeholder code, or skip?\n\nWait for user approval before generating.\n\n### Phase 5 — Generate\n\nFor each approved recipe, produce content following the template in `references\u002Fplaybook-template.md`.\n\n**Code block tiers:**\n\n1. **Verified** — the pattern exists in the codebase (source, example Dags, or tests). Use the code directly. No markers.\n2. **Adapted** — combines verified components in a new way (e.g., using a verified mapper with a different asset). Clean code, with a brief note below the block: *\"Adapted from [source file path]\"*.\n3. **Unverified** — no codebase evidence for this pattern. Use placeholders:\n\n   ```python\n   # TODO: Implement [description]\n   # See: [reference or AIP section]\n   ...\n   ```\n\nVerification sources: source code under `airflow-core\u002Fsrc\u002F`, example Dags, and test files.\n\n### Phase 6 — Assemble\n\nCombine the overview and recipes into a playbook following the template structure. Write to `.claude\u002Faip-{number}.md`.\n\nIf the user chose to skip unimplemented AIP features during the Propose phase, add a brief \"Not Yet Implemented\" section at the end listing them with one-line descriptions. Omit this section if all features were covered.\n\n---\n\n## Pre-Implementation Mode\n\nSource of truth: the **AIP specification** itself. No implementation exists to verify against.\n\nIf file paths are provided, warn that they will be ignored (no implementation to reference).\n\n### Phase 1 — Parse\n\nExtract the AIP source: a URL to fetch, or pasted content. File path arguments are ignored with a warning.\n\nAIP content can come from a URL or pasted directly — both are equally valid.\n\n```\nURL-based:  \u002Faip-user-stories https:\u002F\u002Fcwiki.apache.org\u002Fconfluence\u002Fdisplay\u002FAIRFLOW\u002FAIP-76\nPaste-based: \u002Faip-user-stories (then paste AIP content when prompted)\n```\n\n### Phase 2 — Fetch\n\nRetrieve AIP content from URL or accept pasted content. If a URL fetch returns empty or garbled content, ask the user to paste the AIP content.\n\nAsk the user for the target Airflow version (no PR to extract `versionadded` from).\n\n### Phase 3 — Analyze\n\nExtract from the AIP:\n\n- Proposed features, APIs, and configuration options.\n- Use cases described or implied.\n- Code examples provided in the AIP itself.\n\nNo code verification — nothing is implemented yet.\n\n### Phase 4 — Propose\n\nPresent a numbered list of user story candidates, grouped by concept:\n\n```\n**[Concept Group Name]**\n1. Story Title — one-sentence description of the user goal\n2. Story Title — one-sentence description\n...\n```\n\nWait for user approval before generating.\n\n### Phase 5 — Generate\n\nFor each approved story, produce content following the template in `references\u002Fplaybook-template.md` (pre-mode section).\n\nALL code blocks must be marked as speculative:\n\n```python\n# PROPOSED API — not yet implemented\n```\n\nBase speculative code on the AIP's own code examples and proposed API as closely as possible.\n\nEach story must include **open design questions** that probe:\n\n- **API ergonomics** — Is this easy to use correctly and hard to misuse?\n- **Edge cases** — What happens with unusual inputs, empty partitions, or unexpected configurations?\n- **Compatibility** — How does this interact with existing Airflow patterns (catchup, backfill, dynamic task mapping, sensors, XCom)?\n- **Implementation feasibility** — What constraints or complexities has the AIP not addressed?\n\nQuestions must be specific to the story's use case. Generic questions (\"what about error handling?\") do not count.\n\n### Phase 6 — Assemble\n\nCombine the overview and user stories into a document following the template structure. Write to `.claude\u002Faip-{number}.md`.\n\n---\n\n## Gotchas\n\n- **Confluence pages often return partial or JavaScript-rendered content via WebFetch.** If the fetched AIP content looks incomplete (missing sections, garbled HTML), ask the user to paste the content. Don't generate from partial input.\n- **PR diffs can show intermediate code that was later revised.** When multiple commits exist in a PR, prefer the final state of files (use `gh pr view` with `--json files` and read the current branch\u002Fmerged code) over the raw diff, which may include since-reverted changes. More broadly, always prefer the current codebase state over PR diffs — PRs are discovery aids, not the source of truth.\n- **AIP terminology drifts from implementation.** AIPs are written before (or during) implementation. Class names, parameter names, and module paths in the AIP frequently differ from what was actually merged. Always verify names against the codebase, not the AIP text.\n- **Test files reveal use cases that examples miss.** Example Dags tend to show the happy path. Test files (especially parametrized tests) expose edge cases, error conditions, and alternative configurations that make better recipes.\n- **An AIP feature listed as \"implemented\" in the AIP may not be in the PR.** AIPs track overall status, not per-PR scope. Cross-reference each feature against actual PR code, not the AIP's status section.\n","\u003C!-- SPDX-License-Identifier: Apache-2.0\n     https:\u002F\u002Fwww.apache.org\u002Flicenses\u002FLICENSE-2.0 -->\n\n# AIP-to-User-Stories Playbook\n\n## Invocation\n\n```\n\u002Faip-user-stories \u003CAIP-URL-or-pasted-content> [\u003CPR-URL>...] [\u003Cfile>...]\n```\n\nIf no arguments: print this usage synopsis and stop.\n\n## Mode Detection\n\nAn argument starting with `https:\u002F\u002Fcwiki.apache.org\u002Fconfluence\u002F` is the AIP URL. Arguments starting with `https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fpull\u002F` are PR URLs. Other arguments are local file paths.\n\n- **PR URLs present → post-implementation mode**: generates verified recipe playbooks from actual code.\n- **No PR URLs → pre-implementation mode**: generates speculative user stories to help AIP authors validate design.\n\nPR URLs signal post mode and serve as **discovery hints** — starting points for finding the implementation in the codebase. They are not an exhaustive list of all PRs for the feature, and the skill must explore beyond the supplied PRs to find the full implementation.\n\n## AIP Number\n\nExtract the AIP number from the URL path (e.g., `AIP-76` from a URL containing `\u002Faip-76` or `\u002FAIP-76`). If the number cannot be determined from the URL or pasted content, ask the user.\n\n## Output Path\n\nWrite the final playbook to `.claude\u002Faip-{number}.md` where `{number}` is the extracted AIP number. If the file already exists, ask the user before overwriting.\n\n---\n\n## Post-Implementation Mode\n\nSource of truth: the **actual implementation** in the codebase and PRs — not the AIP specification. When the AIP proposes APIs that differ from what was implemented, the playbook follows the implementation.\n\n### Phase 1 — Parse\n\nSeparate arguments into:\n\n- **AIP source**: a URL to fetch, or pasted content already in the conversation.\n- **PR URLs**: GitHub pull request URLs (one or more).\n- **File paths**: local files (example Dags, source files, tests).\n\nAIP content can come from a URL (fetched via WebFetch) or pasted directly by the user — both are equally valid input paths. If a URL fetch returns empty or garbled content, tell the user and ask them to paste the AIP content instead.\n\nAt least one PR URL is required in post mode. If none are provided but the mode was forced, ask for PR URLs.\n\n### Phase 2 — Fetch & Discover\n\nRetrieve initial sources:\n\n- AIP content (from URL or already pasted).\n- PR diffs and metadata via `gh pr view \u003Cnumber> --json title,body,files` and `gh pr diff \u003Cnumber>`.\n- Local files specified as arguments.\n\nThen use the PRs as **discovery seeds**: identify which modules, packages, and files the PRs touch, and explore outward from there:\n\n- Read the touched files in their current state (not just the diff) to understand the full implementation.\n- Follow imports, base classes, and related modules to find connected implementation code.\n- Search for related example Dags, test files, and documentation that may not appear in the PR diffs.\n- Grep for key class names, function names, and configuration keys from the AIP to find implementation spread across files the PRs didn't touch.\n\nThe PRs are a starting point, not a boundary. Code may have been implemented in other PRs, refactored since the PR merged, or spread across modules the PR didn't directly modify.\n\n### Phase 3 — Analyze\n\nCross-reference AIP features against the **codebase** (not the PRs):\n\n- Which AIP features are implemented (found in the current codebase)?\n- Which AIP features are NOT implemented (proposed in AIP but absent from the codebase)?\n- What patterns exist in tests and example Dags that demonstrate usage?\n\n### Version Detection\n\nSearch PR diffs for `versionadded::` or `.. versionadded::` directives. If found, use that version. If not found, ask the user for the target Airflow version.\n\n### Phase 4 — Propose\n\nPresent a numbered list of recipe candidates, grouped by concept:\n\n```\n**[Concept Group Name]**\n1. Recipe Title — one-sentence description of what the user accomplishes\n2. Recipe Title — one-sentence description\n...\n```\n\nEach recipe maps to one distinct use case — a specific problem the user solves with this feature. If two API classes serve the same use case, combine them. If one class serves multiple use cases, split them.\n\nFor AIP features not found in the implementation, list them separately under **Not Yet Implemented** and ask the user: include with placeholder code, or skip?\n\nWait for user approval before generating.\n\n### Phase 5 — Generate\n\nFor each approved recipe, produce content following the template in `references\u002Fplaybook-template.md`.\n\n**Code block tiers:**\n\n1. **Verified** — the pattern exists in the codebase (source, example Dags, or tests). Use the code directly. No markers.\n2. **Adapted** — combines verified components in a new way (e.g., using a verified mapper with a different asset). Clean code, with a brief note below the block: *\"Adapted from [source file path]\"*.\n3. **Unverified** — no codebase evidence for this pattern. Use placeholders:\n\n   ```python\n   # TODO: Implement [description]\n   # See: [reference or AIP section]\n   ...\n   ```\n\nVerification sources: source code under `airflow-core\u002Fsrc\u002F`, example Dags, and test files.\n\n### Phase 6 — Assemble\n\nCombine the overview and recipes into a playbook following the template structure. Write to `.claude\u002Faip-{number}.md`.\n\nIf the user chose to skip unimplemented AIP features during the Propose phase, add a brief \"Not Yet Implemented\" section at the end listing them with one-line descriptions. Omit this section if all features were covered.\n\n---\n\n## Pre-Implementation Mode\n\nSource of truth: the **AIP specification** itself. No implementation exists to verify against.\n\nIf file paths are provided, warn that they will be ignored (no implementation to reference).\n\n### Phase 1 — Parse\n\nExtract the AIP source: a URL to fetch, or pasted content. File path arguments are ignored with a warning.\n\nAIP content can come from a URL or pasted directly — both are equally valid.\n\n```\nURL-based:  \u002Faip-user-stories https:\u002F\u002Fcwiki.apache.org\u002Fconfluence\u002Fdisplay\u002FAIRFLOW\u002FAIP-76\nPaste-based: \u002Faip-user-stories (then paste AIP content when prompted)\n```\n\n### Phase 2 — Fetch\n\nRetrieve AIP content from URL or accept pasted content. If a URL fetch returns empty or garbled content, ask the user to paste the AIP content.\n\nAsk the user for the target Airflow version (no PR to extract `versionadded` from).\n\n### Phase 3 — Analyze\n\nExtract from the AIP:\n\n- Proposed features, APIs, and configuration options.\n- Use cases described or implied.\n- Code examples provided in the AIP itself.\n\nNo code verification — nothing is implemented yet.\n\n### Phase 4 — Propose\n\nPresent a numbered list of user story candidates, grouped by concept:\n\n```\n**[Concept Group Name]**\n1. Story Title — one-sentence description of the user goal\n2. Story Title — one-sentence description\n...\n```\n\nWait for user approval before generating.\n\n### Phase 5 — Generate\n\nFor each approved story, produce content following the template in `references\u002Fplaybook-template.md` (pre-mode section).\n\nALL code blocks must be marked as speculative:\n\n```python\n# PROPOSED API — not yet implemented\n```\n\nBase speculative code on the AIP's own code examples and proposed API as closely as possible.\n\nEach story must include **open design questions** that probe:\n\n- **API ergonomics** — Is this easy to use correctly and hard to misuse?\n- **Edge cases** — What happens with unusual inputs, empty partitions, or unexpected configurations?\n- **Compatibility** — How does this interact with existing Airflow patterns (catchup, backfill, dynamic task mapping, sensors, XCom)?\n- **Implementation feasibility** — What constraints or complexities has the AIP not addressed?\n\nQuestions must be specific to the story's use case. Generic questions (\"what about error handling?\") do not count.\n\n### Phase 6 — Assemble\n\nCombine the overview and user stories into a document following the template structure. Write to `.claude\u002Faip-{number}.md`.\n\n---\n\n## Gotchas\n\n- **Confluence pages often return partial or JavaScript-rendered content via WebFetch.** If the fetched AIP content looks incomplete (missing sections, garbled HTML), ask the user to paste the content. Don't generate from partial input.\n- **PR diffs can show intermediate code that was later revised.** When multiple commits exist in a PR, prefer the final state of files (use `gh pr view` with `--json files` and read the current branch\u002Fmerged code) over the raw diff, which may include since-reverted changes. More broadly, always prefer the current codebase state over PR diffs — PRs are discovery aids, not the source of truth.\n- **AIP terminology drifts from implementation.** AIPs are written before (or during) implementation. Class names, parameter names, and module paths in the AIP frequently differ from what was actually merged. Always verify names against the codebase, not the AIP text.\n- **Test files reveal use cases that examples miss.** Example Dags tend to show the happy path. Test files (especially parametrized tests) expose edge cases, error conditions, and alternative configurations that make better recipes.\n- **An AIP feature listed as \"implemented\" in the AIP may not be in the PR.** AIPs track overall status, not per-PR scope. Cross-reference each feature against actual PR code, not the AIP's status section.\n",{"name":5,"license":15,"description":7,"when_to_use":45,"allowed-tools":46,"argument-hint":47},"Trigger when the user mentions aip user stories, aip playbook, aip recipes, generate recipes from AIP, user stories for AIP, AIP guide, AIP how-to.","Bash(gh pr view *) Bash(gh pr diff *) Read WebFetch(domain:cwiki.apache.org) WebFetch(domain:github.com)","\u003CAIP-URL-or-pasted-content> [\u003CPR-URL>...] [\u003Cfile>...]","main","f7e28eec7309f5700ca69ec226df41a5c58d5213",".agents\u002Fskills\u002Faip-user-stories",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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add apache\u002Fairflow --skill aip-user-stories",{"tool":63,"command":64},"bunx","bunx skills add apache\u002Fairflow --skill aip-user-stories",{"tool":66,"command":67},"pnpm","pnpm dlx skills add apache\u002Fairflow --skill aip-user-stories","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Faip-user-stories\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fplaybook-template.md","REFERENCE","参考文档",2114,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fairflow\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Faip-user-stories\u002Freferences\u002Fplaybook-template.md",[78,109,130,157,184,206],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":94,"publishedAt":40},"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",[84,89],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[95,96,97,98,99,100,101,102,103,104,105,106,107,108],"sql reporting","sql","reporting","writing","review","report","analytics","metrics","tables","warehouse","for","use","task","conventions",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":40},"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",[],[116,20,117,118,100,119,120,25,121,122,123,124,125,106,126,127,128,129],"aip tracker","tracker","airflow","status","proposal","track","progress","evidence","improvement","assess","compare","codebase","implementation","confluence",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":40},"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",[],[137,138,139,140,118,9,141,142,143,144,145,146,147,148,149,150,151,152,25,153,154,155,156],"upgrade fab provider","upgrade","provider","test","apache airflow","release","security","alignment","reviews","db","bump","static","re","move","new","uv","drift","tripwire","lock","dependency",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":166,"publishedAt":40},"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",[163],{"categoryNo":164,"categoryName":165,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000023","Skill与智能体开发",[167,168,169,170,39,171,172,142,173,174,175,25,176,177,178,179,180,181,182,183],"documentation","prepare providers documentation","prepare","Providers","commit","changelog","scope","cycle","pay","ask","analyze","sub-agent","multi-provider","manager","as","attention","diff",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":40},"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",[],[118,191,192,193,194,9,141,195,196,197,198,199,200,201,202,203,204,25,205,105],"airflow translations","core","guidelines","tasks","update","translation","scaffolding","up","files","guides","i18n","src","ui","add","locale",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":212,"publishedAt":40},"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",[],[118,213,214,215,216,39,217,218,219,9,141,169,220,221,25,222,223,224,106,225,226],"airflow publish changes","publish","changes","push","planning","issues","verification","creation","remote","work","pr creation","Publication","contribution","tracking"]