ship-and-routelisted

End-of-build "take it from here" flow — safely land any outstanding git work behind a proper review gate (only merge if the review is clean), briefly walk through the findings, then route the next move (2–3 ranked options, each with a recommendation + an honest ultracode-benefit call), let Kyle pick (or ask for more), and finally hand him a copy-paste starter prompt for a fresh session plus instructions to run it optimally. Use when Kyle types `/ship-and-route`, says "ship and route" / "land and advise" / "take care of any git stuff then tell me what's next", or finishes a chunk of work and wants Claude to land what's ready, advise on next steps, and equip a fresh session — with explicit per-invocation permission to handle pushes/commits/merges as long as the review finds no issues.
ksdisch/claude-config · ★ 0 · Code & Development · score 70

Install: claude install-skill ksdisch/claude-config

# Ship and Route — land what's ready, then chart what's next This skill is the structured version of: *"if there's any git work to take care of, do it now (you have my permission, as long as the reviews come back clean) — then tell me what to do next, whether ultracode would help, and hand me a prompt to start it fresh."* It runs in **three acts**: **(1) Gated Land**, **(2) Route**, **(3) Handoff**. Do them in order. Acts 1 and the start of 2 are autonomous; the pick at the end of Act 2 and the prompt in Act 3 are collaborative. ## Permission model (read first — this is the load-bearing rule) - **Invoking this skill IS Kyle's explicit, per-action go-ahead** to commit / push / open PRs / merge the work that is **ready right now**. That satisfies the standing rule ("each push needs its own go-ahead; a blanket pre-approval doesn't count") — each run of the command is a fresh go-ahead for the currently-ready work, nothing more. - The go-ahead is **conditional on the review finding no issues.** If the review surfaces a blocker you can't trivially and safely resolve, **stop and report** — do not land it. - **Never direct-push to `main`/`master`.** A global hook hard-blocks `git push … main`, and Kyle's git rules forbid it. Always land via **feature branch → PR → server-side merge** (`gh pr merge`), which the hook permits. This is the proven path. - This authorization covers **only** the work that's ready in this repo this moment. It does **not** authorize unrelated/future pushe