setup-override-upstreamlisted

<!-- SPDX-License-Identifier: Apache-2.0 https://www.apache.org/legal/release-policy.html --> <!-- Placeholder convention (see ../../AGENTS.md#placeholder-convention-used-in-skill-files): <adopter-repo> → repo this skill is being run in (an adopter) <override-file> → .apache-steward-overrides/<skill>.md being upstreamed <framework-skill> → framework skill the override modifies <framework-clone> → user's local clone of apache/airflow-steward (separate from .apache-steward/, which is a gitignored snapshot) <framework-fork> → user's GitHub fork of apache/airflow-steward (where the PR branch gets pushed) --> # setup-override-upstream This skill is the path from *local override* to *framework feature*. It takes a single `.apache-steward-overrides/<skill>.md` file in an adopter repo, walks the user through deciding whether the change is worth upstreaming, designs the framework-level abstraction, implements it in `apache/airflow-steward`, and opens a PR. The override mechanism (per [`docs/setup/agentic-overrides.md`](../../../docs/setup/agentic-overrides.md)) is deliberately *agentic* and *adopter-local*: there's no schema, no anchors, no patch tool. That makes overrides quick to write but hard to share — every adopter who wants the same behaviour writes their own. **Upstreaming** is the escape hatch: when an override stops being project-specific