working-overnightlisted

<!-- working-overnight-version: 8 --> # Working overnight Governed unattended work while the user is away. The engine is `/loop`: the user launches `/loop working-overnight` and each cycle does one unit of work and returns with fresh context. This skill holds the policy: what to pull, how to stay safe, when to defer, and when to wind down. The `overnight-continue` hook keeps a single cycle from halting on a question; it is not the engine. Read `references/safety.md` (the tier model and the never-list) and `references/pipeline.md` (the per-task governance pipeline) before the first cycle. They are binding. ## Two modes, told apart by the manifest - **Pre-flight** (interactive, once, when the user sets up the night): arm the run. - **Cycle** (each `/loop` iteration, unattended): do one unit of work. If `.claude/overnight/active.md` is absent, this is pre-flight. If it is present, this is a cycle. ## Pre-flight (arming) Do this with the user present. Never start autonomous work until they confirm. 1. Agree the work source and scope: which tickets, which investigations, and any no-go areas (paths, systems, ticket labels to avoid). 2. Agree the budget (token or cost ceiling) and the investigation-depth cap (how many new tickets an investigation may create before implementation must catch up). 3. Confirm the safety config in `references/safety.md`: the allowed tools and the Tier-3 never-list. Do not proceed if the requested work would need anything on the never