{"slug":"timharris707-setup","name":"setup","description":"For a new TeamWorkflow installation, binding refresh, or drift audit after a pack release, inspect and bind the project workflow. Reuse explicit recorded decisions with their sources; ask about missing, conflicting, or changed authority and bindings.","long_description":"---\nname: setup\ndescription: \"For a new TeamWorkflow installation, binding refresh, or drift audit after a pack release, inspect and bind the project workflow. Reuse explicit recorded decisions with their sources; ask about missing, conflicting, or changed authority and bindings.\"\n---\n\n# Setup\n\nRead the [Codex desktop binding](../../../CODEX.md) when this workflow needs harness mechanics, model routing, or recovery.\n\nThis skill binds the team-workflow pack to a specific repo, once, through an interview, and refreshes that binding on re-run. Everything the other pack skills call \"the binding doc\" is what this skill seeds. Nothing here rewrites the repo's CI or processes; it records how the pack composes with what is already there.\n\n**Posture: inspect first, reuse decisions.** Scan the tracker, verification commands, instruction files, templates, installed skill paths, and configuration ownership. Reuse explicit recorded bindings and prior answers under the safeguards below. Ask only about a new binding, material drift, or an unresolved choice. A read-only installation audit needs no setup interview or tracker write.\n\n## The five mandatory bindings\n\n1. **Tracker.** The repo + tracker in use, and the mapping onto the pack's tracker discipline: how claims are posted, how blocking is expressed, what the frontier query is. The pack is GitHub-Issues-first (the recipes in [references/tracker-discipline.md](references/tracker-discipline.md) use `gh`), but the tracker is a **named binding**, not an assumption baked into the skills: a repo on a different tracker writes a different tracker section in its binding doc, mapping the same discipline (machine-readable claims, dependency edges, a frontier query) onto its own tool. The skills stay unchanged.\n\n **Implicit-repo check (GitHub trackers):** at binding time, compare gh's implicit repo resolution in the working directory (`gh repo view`) against the bound repo. A fork or multi-remote clone commonly resolves to the *upstream* repo, and every recipe run unqualified would then read and write tracker state there, not on the bound tracker. On mismatch, warn and record it in the tracker binding. The recipes scope `gh issue` and `gh label` with `--repo /` and write the bound repo literally into every `gh api` path (see tracker-discipline), precisely so this mismatch stays harmless; do not lean on `gh repo set-default`, which is per-clone state the next worktree or machine doesn't have.\n\n **A repo with no tracker yet** is a normal starting state, not a setup failure. Offer two honest paths and record whichever the human picks: (a) **bind one now**: on a GitHub remote that usually means the repo's own GitHub Issues, ready immediately; (b) **record `none yet`** as the tracker binding, with the consequence stated in the doc: the claim, frontier, and blocking recipes stay dormant until a tracker is bound. Never invent a tracker the team doesn't use, and never leave the field blank.\n\n **Label vocabulary on a fresh tracker:** the pack's recipes assume the labels they query already exist: a frontier query against labels nobody created returns empty forever, and nothing downstream ever creates them. When binding a tracker that lacks them, setup enumerates the pack's reference vocabulary (state: `needs-triage`, `ready-for-agent`, `ready-for-human`, `blocked`; type: `slice`, `bug`, `gate-decision`, `process`) and, on confirmation, creates the missing ones (on GitHub: `gh label create \"