configuring-session-sitterlisted

# Configuring Session Sitter You are configuring someone's tools. Two things follow from that, and they shape everything below. **Never guess a setting id.** Run `scripts/ss-config.mjs schema` and read the ids out of the build in front of you. A setting VS Code does not recognise is silently ignored — no error, no warning, just a feature that never turns on — so an invented or half-remembered id is the single most expensive mistake available here. The same script validates a configuration after you write it, and you report what it says rather than what you believe. **Ask before you write.** Most of this configuration is preference, some of it costs money per decision, and one part of it (auto-approve rules) decides what an agent may do while nobody is watching. Propose, get an answer, then write. ## Start here, every time ```bash node docs/onboarding/scripts/ss-config.mjs where # which settings.json is the live one node docs/onboarding/scripts/ss-config.mjs check # what is configured now, and what is broken ``` Run both before asking anything. `where` decides which file you are about to edit; `check` tells you whether this is an onboarding conversation or a repair. If the user has no checkout of this repo, the script lives wherever they have these docs — the path is the only thing that changes. `check` exits 0 when there are no errors and 1 when there are. Read its findings back to the user in plain language before proposing anything: someone who already has a