cascading-fleet

The fleet runs on chore(wheelhouse): cascade template@<sha> commits. Every wheelhouse template change has to land in every fleet repo to take effect. This skill packages the operation so it isn't recreated ad-hoc per session.

🚨 This is mechanical work, not a thinking task. Run the canonical operation, commit, push. Don't analyze each modified file in the cascade, don't design alternatives, don't write multi-paragraph rationale — the wheelhouse template is the source of truth and the sync runner decides what changes. If a repo's cascade refuses to apply (lockfile policy reject, soak window, broken hook from a stale install), bump the immediate blocker (soak-exclude entry, lockfile rebuild) or defer the repo and report it — don't reason through a multi-step manual reproduction of what the sync runner already does. Cheap/fast model settings are the right default; reserve heavier reasoning for genuine design work.

When to use

• A wheelhouse template/ SHA needs to propagate to every fleet repo.
• A socket-registry pin chain (the multi-layer setup-and-install → setup → checkout pin graph) needs propagation.
• Batching multiple template SHAs into one wave.

Never use this skill while another cascade is in flight (each cascade creates a chore/wheelhouse-<sha> branch per repo; concurrent runs collide).

Two modes

Mode 1: template (outer cascade, default)

Propagates a socket-wheelhouse/template/ SHA to every fleet repo. The flow: