initlisted

# init: configure ship-it for this project Produce a `ship-it.config` that adapts the generic engine to this project. Detect first, ask only for the gaps, generate doc-job skills for anything without a built-in. This is the one place all the interactive questions live; everything downstream runs from the config non-interactively. The full config schema is in the plugin's `CONTRACTS.md`; the keys are summarized in step 5. ## 0. Welcome and explain the plan Before touching anything, open with a short welcome that orients a first-time user. Cover four things, briefly and skimmably: a **welcome**, **what ship-it does**, **the stages it covers**, and **what is about to happen** in this setup. Something like: > **Welcome to ship-it.** It takes your work from a tracker issue (or just your current changes) all the way to a merged pull request, and keeps your living docs in step as it goes. It is configurable per project, and every stage is also a standalone skill you can run on its own. > > **The stages** (the named skills below also run on their own, and `init` configures or swaps each): > > - **plan** (`plan-one-issue`): draft a right-sized plan per work-unit (validating any plan already in the ticket), checkpointed before any code. > - **implement** (`fix-one-issue`): make the change in a branch, verify, commit. > - **comment cleanup** (`comment-cleanup`): a pass that verifies and corrects comment overuse and verbosity in the change, keeping the non-obvious why and dropping n