/setup

name: setup
description: Scaffold .nightshift/ and propose quality gates for this stack in at most four questions, with every default on one screen; asks, never imposes.
license: MIT
metadata:
  internal: true

Set up Nightshift in this project in at most four questions. Scaffold first, then ask the questions in section 3, apply every answer in the same turn, then print a summary that ends with the one sentence that starts a shift.

The four state files and what each holds are in `$NIGHTSHIFT_PLUGIN_ROOT/skills/nightshift/references/shift/state-map.md`. Ordinary plans belong in the drafting table, never in Hunt or the parking lot.

Resolve `$NIGHTSHIFT_PLUGIN_ROOT` to the copy this host installed, as an absolute path. On Claude Code that is `${CLAUDE_PLUGIN_ROOT}`, on Cursor `${CURSOR_PLUGIN_ROOT}`, and on Codex `$PLUGIN_ROOT` when set. A skill loaded from a copy another host installed is the wrong runtime — use the copy under this host's plugins directory. When none of those is set, use the absolute path this skill was attached from (`skills/setup/SKILL.md`). Run every command below through `"$NIGHTSHIFT_PLUGIN_ROOT/runtime/ns"` — native Windows: `& "$NIGHTSHIFT_PLUGIN_ROOT\runtime\windows\ns.ps1"` in the PowerShell tool, same verbs — which resolves the host and the workspace; `ns help` lists the verbs, and `ns bind` prints the six resolved facts (`TASK_ROOT`, `NIGHTSHIFT_WORKSPACE`, `NS`, `NIGHTSHIFT_PLUGIN_ROOT`, `HOST`, `SOURCE`); `$NS` below is that `NS`. Never a bare relative path: the working directory persists between calls. Each `$NS/...` path below is where the current layout keeps that file; `ns path <key>` prints where this workspace keeps it, and `ns path --list` names every key.

Once the workspace and work target are resolved, the bundled mechanical scaffold is `ns setup --work-target "$WORK_TARGET" --mode "$WORK_MODE"`, which exists on native Windows only; on every other host this skill writes the same templates itself, as below. It copies only absent files, writes state version 2 for a new site, persists the work target and work mode (`-Mode repository` or `-Mode artifact`), and keeps `$NS/` private. It refuses a notes folder under default repository mode: `use -Mode artifact for a notes folder that is not a Git repository`. On an existing site at an older state-version its `migration` field describes the move into the current layout, exactly as the preview below would. Read its output back rather than restating it. The skill still owns every owner choice below; the script asks nothing and never invents gates, permissions, profiles, migration approval, a receipts choice, or a tooling policy.

If the user explicitly identifies a different existing workspace containing `.nightshift/`, show both absolute paths and ask for confirmation. On yes, run `"$NIGHTSHIFT_PLUGIN_ROOT/runtime/ns" link-workspace --host-root "$TASK_ROOT" --workspace "$PROPOSED_WORKSPACE"`. The pointer is local-only and state remains in the authoritative workspace; never copy it.

0. Reject disposable ChatGPT scratch workspaces

Before creating or changing any file, resolve the project root to an absolute path. If it is under `/workspace/scratch/`, this is a disposable ChatGPT scratch workspace that cannot affect the user's repository. **Stop immediately: create no `$NS/` directory, rules, settings, receipts repo, or other files.** Tell the user directly:

> Nightshift needs a persistent software project workspace. This ChatGPT conversation is using a > temporary workspace, so files created here will not affect your repository. > > Open your project in Codex (a Git repository or a persistent local folder), or start Codex connected to its GitHub repository. Then mention > Nightshift and say: “Set up Nightshift in this project.”

Do not mention Claude Code in this ChatGPT-specific redirect: the user is already in an OpenAI product, so give them the shortest OpenAI-native route. Do not infer “temporary” merely because the project is not a git repository — local non-git projects and the recommended parent-workspace layout remain valid. The explicit disposable scratch path is the stop signal.

Detect the work mode and the work target. When the choice is ambiguous (several child repositories, or a folder that could be either mode), explain it and ask before persisting it; that is section 3's first question. An obvious single repository is not asked: it is stated in the summary. Use `ns_propose_work_mode` (POSIX) or `Get-NSProposedWorkMode` after importing `Nightshift.psm1` (native Windows):

• `repository` — the workspace is a Git repository, or exactly one immediate non-hidden child is. Skip a symlink or reparse child; it is not a nested checkout.

several child repositories still mean repository mode; show the choices and require an explicit target, never guess.

• `artifact` — there is no Git repository here. The persistent folder itself is the work target

(research, docs, audits, planning). Say so plainly: gates, commits, and stack detection that require Git do not apply; complete each item with a receipt under `$NS/receipts/`. Completion in that folder is `$NS/receipts/`, not a git log. When `$NS/receipts` exists but is not a usable directory, say so and do not treat artifact setup as complete.

• scratch (`ns_propose_work_mode` status 2, or `Get-NSProposedWorkMode` throwing) — stop; create

nothing.

Never persist an ambiguous mode until the owner confirms. Never `git init` a notes folder to change an artifact proposal into repository mode. Then write `$NS/run/work-mode` as `repository` or `artifact` (one word, one newline) and `$NS/run/work-target` as the absolute canonical path of the chosen folder. On POSIX: `ns_record_work_target "$NIGHTSHIFT_WORKSPACE" "$WORK_TARGET" "$WORK_MODE"`. On later setup runs, validate and retain that mode and target unless the owner explicitly changes them. Repository mode: stack detection, Git checks, gates, commits, and verification operate in the wor