setup-stewardlisted

<!-- 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-skills-dir> → the dir holding the adopter's skills (`.claude/skills/` or `.github/skills/`, per the project's convention) <snapshot-dir> → the gitignored framework snapshot. Pre-Magpie it is `.apache-steward/`; the migration moves it to `.apache-magpie/`. --> # setup-steward — pre-Magpie migration shim > **This skill is a one-shot transition artefact.** The framework was > renamed from **apache-steward** to **Apache Magpie**, which moved the > skill source (`​.claude/skills/` → `skills/`), renamed the dotfiles > (`​.apache-steward*` → `.apache-magpie*`), renamed the bootstrap skill > (`setup-steward` → committed as `magpie-setup`), and namespaced every > framework skill under a `magpie-` prefix. A repo that adopted the > framework **before** that rename has a committed `setup-steward` skill > frozen on the old layout, and cannot self-upgrade across the change. > This shim is the bridge. ## How a pre-Magpie adopter reaches this shim The pre-Magpie `setup-steward/upgrade.md` an adopter committed does, on every `/setup-steward upgrade`: 1. delete `.apache-steward/` and re-fetch the framework per the committed lock (which lands the **new*