---
description: Cold-start a session — read the last HANDOFF snapshot, the newest shipping log, the git summary, any in-flight orbits/worktrees, and (if LS is connected) your open work items, reconcile them, then categorize all pending work (resume in-flight · review/PR feedback · bugs · high-priority · low-hanging fruit · stale/dead · tech-debt/deferred, plus a non-pickable blocked list) and let you choose a list to work from before drilling into a specific item. Read-only; the complement to /kit:handoff. Does NOT branch, commit, or write files unless you confirm a next step.
---

# /kit:kickoff

Start a session the way `/kit:handoff` ends one. Handoff **writes** the current-state snapshot and a single kickoff prompt at the end of a session; kickoff **reads** that snapshot back at the start of the next one, cross-checks it against git and your work items, and turns "what was I doing / what's next" into a concrete pick.

The loop is: `/kit:handoff` → (new session) → `/kit:kickoff` → choose a slice → work → `/kit:handoff` → `/kit:ship`. One session per feature; kickoff is the first thing you run in the fresh session.

This skill is **read-only by default**. It does not branch, commit, push, or write files. Its output is: a lay-of-the-land board, the pending work **sorted into categorized lists** (resume in-flight · low-hanging fruit · high-priority · stale/dead · tech-debt/deferred), a two-stage choice (pick a *list*, then a *specific item*), and — once you've chosen — a ready-to-use kickoff prompt for that item plus an offer to set up the branch/orbit as a *separate, confirmed* next step.

Parse `$ARGUMENTS`:

- (empty) — full orient: gather all sources, show the board + categorized lists, ask which list to work from, then drill into a specific item.
- **--brief** — show the lay-of-the-land board + the category headline counts only (e.g. "🍒 Low-hanging: 4 · 🔥 High-priority: 3 · 🪦 Stale: 6"). Skip the interactive choice. For "just remind me where I was."
- **--list=&lt;name&gt;** — skip the first-stage menu; go straight to the named list (`resume` / `review` / `bugs` / `priority` / `fruit` / `stale` / `debt`) and present its filtered items to pick from.
- **--pick=&lt;text&gt;** — skip both menus; treat `<text>` as the chosen item and go straight to producing its kickoff prompt + setup offer.
- **--all** — when assembling work-item candidates, include items not assigned to you (whole-board backlog), not just your own. Default is assigned-to-me.

## Preflight

1. `git rev-parse --is-inside-work-tree` — abort if not a git repo.
2. Resolve the **base branch** (same logic as `/kit:handoff` and `/kit:ship`):
   - `git symbolic-ref refs/remotes/origin/HEAD --short` (strip `origin/`). Fall back to `origin/main` / `origin/master` if unset.
3. Record current branch (`git rev-parse --abbrev-ref HEAD`) and git email (`git config user.email`) — the email is the work-item handle.
4. Detect LS connectivity: check for `.launch-secure.cred.config` at the repo root. If absent, kickoff still runs — it just **skips the work-items source** and notes "LS not connected; candidates from HANDOFF + git only." Do NOT abort (unlike `/kit:standup`, kickoff is useful offline).

## Step 1 — Gather the sources (don't show yet)

Pull from five layers in parallel. Each is independently optional; a missing one is noted, not fatal.

**1a. The HANDOFF snapshot** — read `doc/handoff/HANDOFF.md` if it exists. Extract its four live sections: **Where we are**, **What's next** (the priority-ordered 1–3), **Open threads**, and the embedded **Kickoff prompt**. This is the human-curated "what's next," highest signal. If the file doesn't exist, note "no HANDOFF yet — first kickoff" and lean on git + work items.

**1b. The last ship** — read the newest file under `doc/shipping-logs/` (date-prefixed `YYYY-MM-DD-…`, so the lexically-last name is newest). This is the authoritative "what was *actually* last updated/shipped" — HANDOFF is current-state only and does not carry per-ship detail. Capture its title + the slice it shipped. If the dir is empty, skip.

**1c. Git summary** — the real on-disk state, to reconcile against what HANDOFF claims:
- `git log <base>..HEAD --oneline` — commits on this branch not yet in base.
- `git log -n 8 --oneline <base>` — recent baseline history (what landed lately).
- `git status --porcelain` — uncommitted work. Filter out generated noise (`.launchsecure/graphs/*.json`, `node_modules`, `dist`, `.next`). What remains is genuine in-flight work — a **"resume this"** candidate.
- Current branch + whether it's ahead/behind base.

> ⚠️ Everything in 1c is scoped to the **current** worktree only. In-flight work in other worktrees/orbits is invisible here — 1e covers it. Do not present a "resume in-flight" list without running 1e first.

**1d. Work items (only if LS connected)** — build the backlog candidates:
- `mcp__launch-secure__work_items_list({ assignee_email: "<git email>", status: "IN_PROGRESS" })` — things you already started; strongest "resume" candidates.
- `mcp__launch-secure__work_items_list({ assignee_email: "<git email>", status: "TODO" })` — your queued backlog.
- With `--all`, also fetch the same statuses without `assignee_email` to include unassigned/team items.
- Capture id + title + status for each. Cap at ~8 total; if more, keep the top 8 and note "(N more in LS)".

> Use the hosted `launch-secure` MCP by default. Only use `local-launch-secure` if the active course points there (see `/kit:course`). Don't ask for org/project slugs — the `.mcp.json` headers default to the current project.

**1e. Orbits / other worktrees** — the in-flight work that 1c structurally can't see. A feature usually lives in its own orbit (isolated worktree + forked DB), so the current tree being clean does NOT mean nothing is in flight. Enumerate + classify them:
- **Primary: `mcp__launch-orbit__orbit_check({ all: true })`** (if launch-orbit is wired) — sweeps every orbit registered for THIS repo and returns, per orbit, a `recommendation` + two verdicts. This replaces the hand-rolled dirty/ahead/merged math — orbit_check already runs `git status`, the merged-vs-base check, AND the DB/data drop-safety checks, then tells you which orbits still hold work vs. are safe to drop:
  - **not `dropSafe`** (uncommitted changes or commits ahead of base) → a **🔧 Resume in-flight** candidate. Pull the "N dirty, M ahead" label from its `git.clean` / `git.merged` check summaries, and use the report's `actions[]` for what's needed to land it.
  - **`dropSafe`** (merged + clean, nothing to lose) → a **🪦 Stale / dead** candidate ("orbit ‹slug› merged + clean — safe to drop"). Note: `healthy:false` here is usually just the DB being down, not real work — don't promote it to resume on that alone.
- `mcp__launch-orbit__orbit_list` — use for the stable slug + `age` metadata to label candidates and sort 🔧 Resume in-flight (freshest first).
- `git worktree list` — also surfaces **bare** worktrees created outside launch-orbit (these won't appear in orbit_check/orbit_list). For each such non-orbit worktree other than the current one, fall back to raw git: `git -C <path> status --porcelain` (uncommitted, filter the generated noise from 1c) + `git -C <path> rev-list --count <base>..HEAD` (commits ahead). Same rule: dirty/ahead → resume; clean + 0-ahead → stale/dead.
- `orbit_check` / `orbit_list` span **all** projects on the machine — keep only orbits whose `path` is under this repo's root.
- **Fallback (launch-orbit not wired):** classify every worktree from `git worktree list` with the raw-git pair above — still works, just without the DB/data drop-safety signal.

## Step 2 — Reconcile + flag drift

Before showing anything, cross-check the sources against each other. This is the honesty pass — the inverse of what `/kit:standup` does for shipped work.

- **Stale "What's next":** if a HANDOFF "What's next" item appears already done in git (matching commits in `<base>..HEAD`, or named in the newest shipping log), flag it: _"HANDOFF lists ‹X› as next, but it appears shipped (commit ‹sha›) — likely stale."_ Don't silently drop it; surface the contradiction.
- **Dedup across sources:** a HANDOFF "What's next" item and an LS work item often refer to the same slice (match on id like `LS-…`/`#…`, or on title similarity). Collapse them into one candidate that carries both handles.
- **Resolved open threads:** if an "Open thread" looks addressed by a recent commit, note it as "possibly resolved — confirm."
- **Branch sanity:** if the current branch already has commits ahead of base AND there's an in-progress work item, the most likely intent is "continue the current branch," not "start something new" — rank accordingly.

## Step 3 — Categorize the pending work into lists

Pool every candidate from the reconciled sources (HANDOFF "What's next" + "Open threads", LS work items, uncommitted git work, follow-up flags grepped from recent commit bodies — same patterns `/kit:standup` uses: `TODO`, `follow-up`, `deferred`, `not patched`, `revert`, `next pass`, plus `broken`/`bug`/`failing`/`blocked`/`waiting on`). Dedup (Step 2).

**First, pull out the blocked items** — anything tagged `blocked`/`waiting`, marked depending on an unfinished item, or whose commit/thread says "waiting on ‹X›". These go to the non-pickable **🚧 Blocked** list (Step 4) so you see *why* they aren't moving; they are removed from all buckets below.

Then sort each remaining item into **one** bucket — most-specific bucket wins, in this precedence:

1. **🔧 Resume in-flight** — uncommitted local work in the current tree (1c) + **dirty/ahead orbits & other worktrees (1e)** + `IN_PROGRESS` work items. The strongest "continue what you started" signal; always wins if present. Sort orbit/worktree candidates by recency (`age` / most-recently-touched first) — the freshest dirty orbit is usually what you were last on, even if it isn't the current tree.
2. **👀 Review / PR feedback** — work waiting on *your* action on something already in motion: open PRs you authored or are assigned to review, unresolved review comments, `needs-review`/`changes-requested` tags. Time-sensitive (someone's blocked on you), so it outranks fresh work.
3. **🐛 Bugs / broken** — defects: work items of type `bug` or tagged `bug`/`defect`/`regression`, and `broken`/`failing`/`revert`/`not patched` follow-up flags from commit bodies. Distinct from feature backlog regardless of priority.
4. **🔥 High-priority** — items the project marks urgent: a work-item priority/severity field at its top value, tags like `p0`/`p1`/`urgent`, **and** everything in HANDOFF "What's next" (human-curated = high priority by definition), minus anything Step 2 flagged stale.
5. **🍒 Low-hanging fruit** — quick wins: work items with a small estimate/size field or `quick`/`chore`/`good-first`/`small` tags, single-file follow-up flags from commit bodies, and one-line open threads. When no size signal exists, infer from scope words in the title ("rename", "typo", "bump", "add flag", "copy") — but say it's inferred.
6. **🪦 Stale / dead** — pending too long: `TODO`/`IN_PROGRESS` work items whose `updatedAt` is older than ~30 days (tune to the project's pace), and open threads that have survived multiple handoffs. These are the "why is this still here" items.
7. **🧹 Tech-debt / deferred** — items tagged `tech-debt`/`debt`/`deferred`/`backlog`, explicit deferrals recorded in HANDOFF, and `deferred`/`rolled back` follow-up flags from commit bodies.

Each item lands in exactly one bucket. Within a bucket, sort by the most relevant key (priority desc, then age; for stale, oldest first; for fruit, smallest first). An empty bucket is simply omitted everywhere downstream.

## Step 4 — Show the lay of the land

One compact block: orientation header, then each **non-empty** bucket with up to **5** items and a `+N more` tail. No preamble.

```
📍 Where we are
<HANDOFF "Where we are", trimmed to 2–4 lines. If no HANDOFF: a 1-line synthesis from git.>
🚢 Last shipped: <newest shipping-log title + date> — <one line>
⚠️ Drift: <Step 2 flags, one line each. Omit if none.>

🔧 Resume in-flight (N)
- <item — handle/branch/file · short why>
- <orbit ‹slug› [branch] · N dirty, M ahead · touched <age>>
  …up to 5… (+N more)

👀 Review / PR feedback (N)
- <item — PR#/LS-id · what's waiting on you>
  …up to 5… (+N more)

🐛 Bugs / broken (N)
- <item — LS-id · short why>
  …up to 5… (+N more)

🔥 High-priority (N)
- <item — LS-id · short why>
  …up to 5… (+N more)

🍒 Low-hanging fruit (N)
- <item — handle · est/size or "inferred quick">
  …up to 5… (+N more)

🪦 Stale / dead (N)
- <item — LS-id · "untouched 47d">
  …up to 5… (+N more)

🧹 Tech-debt / deferred (N)
- <item — handle · source>
  …up to 5… (+N more)

🚧 Blocked (N) — not pickable, shown for awareness
- <item — handle · waiting on ‹what›>
  …up to 5… (+N more)
```

Readable in under a minute. The 🚧 Blocked list is informational only — never offered as a pick. If `--brief`, stop after the headline counts line (don't expand the bucket items).

## Step 5 — Two-stage choice: pick a list, then an item

**Stage A — which list.** Call **AskUserQuestion** ("Which list do you want to work from?"). Options are the **non-empty pickable buckets** (🚧 Blocked is never an option), capped at 4 (the tool's max) — there are up to 7 pickable buckets, so choose the 4 most useful for this session by precedence + item count + freshness, and surface the rest in option descriptions ("…also N stale, N tech-debt — say the word to see them"). Thin slow-moving buckets may be folded into one option ("Stale & deferred"). Each option's description carries the bucket's count + a one-line flavor of what's inside. "Other" (auto-added) lets the user name any list (including a folded/overflow one) or item directly. Skip Stage A if `--list=` was passed.

**Stage B — which item.** Once a list is chosen, show that bucket's **full** filtered list (not just the top 5 — now we're focused on one category, so depth is fine), numbered, each with its handle + the one-line why. Ask the user to pick one (a second `AskUserQuestion` with up to 4 of the top items, or just let them reply with a number/name if the list is long). Skip Stage B if `--pick=` was passed.

## Step 6 — Set up the chosen item

Once a specific item is chosen:

1. **Produce its kickoff prompt.** If the chosen slice matches the one HANDOFF already wrote a "Kickoff prompt for the next session" for, **reuse that verbatim** in a fenced block. Otherwise synthesize one in the **same shape** handoff uses (Starting **‹item — Title›** · read CLAUDE.md + HANDOFF + relevant Briefs · then the 1–6 design-shape questions: Surface, Fields/inputs, Eligibility, Data path, feature-specific, Out-of-scope). Make it specific to the chosen slice, not generic.
2. **Offer the setup as a confirmed next step — do not do it unprompted.** Tailor the offer to what was picked:
   - **Picked an existing orbit/worktree (1e candidate):** it already exists — offer to switch into it (`mcp__launch-orbit__orbit_switch` to activate, then work in its `path`), NOT to create a branch. Never re-create an orbit that's already live.
   - **Picked a fresh slice:** offer to branch off the base (`git checkout <base> && git pull && git checkout -b <slice-branch>`) **or** create an isolated orbit (`/kit:orbit`) if the slice wants a forked DB.
   Wait for an explicit "yes" / branch name before running any git or orbit command — this is a state mutation and falls under the per-action confirmation rule.
3. If the chosen slice is a `TODO` work item and the user confirms starting it, offer (don't auto-run) to move it to `IN_PROGRESS` via `mcp__launch-secure__work_item_move` / `work_item_update`.

## Edge cases

- **No HANDOFF.md yet** (first kickoff in a repo) — don't fabricate a "Where we are." Synthesize the board from git + last shipping log + work items, and tell the user "no HANDOFF snapshot yet — run `/kit:handoff` at the end of this session to create one." Kickoff degrades to a git+LS orientation.
- **LS not connected** — skip Step 1d entirely; candidates come from HANDOFF + git. Note it once on the board.
- **Clean tree, nothing in flight, empty backlog** — say so plainly ("nothing in flight; HANDOFF's next is ‹X›") and just present HANDOFF's "What's next" as the candidates. Don't invent work.
- **HANDOFF wildly out of sync with git** (many stale "next" items already shipped) — lead with the drift block and suggest the previous session likely forgot `/kit:handoff`; offer to reconstruct current-state from git, but don't write HANDOFF here (that's `/kit:handoff`'s job).
- **Mid-branch resume** (current branch already ahead of base) — surface "continue this branch" at the top of the 🔧 Resume in-flight list, and skip the branch-creation offer in Step 6 unless the user picks a different item.
- **In-flight work lives in an orbit, not the current tree** (the common case — current tree clean but a dirty/ahead orbit exists per 1e) — do NOT report "nothing in flight." Lead 🔧 Resume in-flight with the freshest dirty/ahead orbit, and in Step 6 offer `orbit_switch` into it rather than a new branch.
- **Everything lands in one bucket** (e.g. all candidates are stale) — that's fine; show the single list and skip Stage A (no choice to make), going straight to picking an item.

## Notes for the assistant

- Kickoff is **read + orient + choose**. It is the mirror of `/kit:handoff` (write) — keep the boundary clean: kickoff does not write `HANDOFF.md`, does not commit, does not push. The only mutations it ever performs are the explicitly-confirmed branch/orbit/work-item-move in Step 6.
- The single most useful thing kickoff adds over just re-reading HANDOFF is **reconciliation** (Step 2): HANDOFF is hand-maintained and goes stale. Always cross-check it against git before presenting its "What's next" as gospel.
- Prefer commit scopes, work-item ids, and shipping-log titles as candidate handles — they're stable and clickable. Don't pull the full chart/graph for this; kickoff is a fast orientation, not an analysis (`/kit:analyse` is for structure).
- Respect the course: read/write LS through whichever server the active course points at, never cross prod/local.
