potiuk opened a new pull request, #184: URL: https://github.com/apache/airflow-steward/pull/184
## Summary Adds five new behaviours to `/setup-steward` (all sub-actions, documented across SKILL.md / adopt.md / upgrade.md / verify.md / worktree-init.md): - **Always-on families.** Every `setup-*` skill (except `setup-steward` itself) and every `list-steward-*` skill is wired up unconditionally on every adopt / upgrade / worktree-init run. Not exposed in the `skill-families:` prompt, not stored in the lock files, cannot be opted out — captured as new Golden rule 8. - **In-flight skill reload after self-update.** When a sub-action overwrites the committed `setup-steward` (adopt's new Step 3b, upgrade's hoisted Step 4b), the agent re-reads SKILL.md + the active sub-action file before continuing the run — so the rest of the upgrade/adopt executes against the new bootstrap content. Captured as new Golden rule 9. - **Hook + local-config sync from the snapshot.** Every adopt/upgrade run compares adopter-installed hooks (today: `post-checkout`) against the snapshot's expected content and re-syncs when drifted. `verify.md` check 8 gained the matching content-drift sub-check. - **Family-wide symlink refresh.** `upgrade.md` Step 6 now uses an "effective family set" (opt-in from the lock + always-on, computed fresh from the snapshot) instead of just the lock's families. `verify.md` check 5 treats missing always-on symlinks as ✗ rather than ⚠. - **Automatic `worktree-init` on every linked worktree.** `adopt.md` Step 12 and `upgrade.md` Step 6c now enumerate `git worktree list --porcelain`, skip the main, and invoke `/setup-steward worktree-init` on every linked worktree as the final pass. Unconditional, idempotent, never aborts the parent run on a single worktree failure. `worktree-init.md` gained Step 1b to wire the worktree's `<adopter-skills-dir>` symlinks for the full effective family set so the chained invocation has something to do beyond the snapshot symlink. These are documentation/specification changes only — no executable code paths in this repo. The skill files are the spec the agent follows when an adopter (or contributor) runs `/setup-steward`. ## Test plan - [ ] On a fresh adopter clone, run `/setup-steward` and confirm the symlink list includes all `setup-*` (except `setup-steward`) + `list-steward-*` skills regardless of the family pick. - [ ] On an already-adopted repo, bump `.apache-steward.lock`, run `/setup-steward upgrade`, and confirm: (a) the committed `setup-steward` is overwritten before the symlink refresh runs; (b) Step 6c invokes `/setup-steward worktree-init` on each linked worktree. - [ ] Add a `git worktree add` of a feature branch off an adopted repo, then run `/setup-steward upgrade` and confirm the worktree's `<adopter-skills-dir>` symlinks reflect the new family set without manual `cd` + worktree-init. - [ ] Hand-edit `.git/hooks/post-checkout` to an older content, run `/setup-steward verify` and confirm check 8's content-drift sub-check surfaces it; then run `/setup-steward` and confirm Step 12 pass 1 re-syncs it from the snapshot. - [ ] On a repo with `.apache-steward.lock` recording only `pr-management`, run `/setup-steward verify` and confirm missing `setup-isolated-setup-*` or `list-steward-*` symlinks are reported as ✗ (not ⚠). 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
