setup

name	setup
description	Use when the user runs /setup, or asks to set up, initialize, personalize, or re-run setup for this workspace after cloning it. Interviews the user one question at a time, writes their ME.md, scaffolds their project and admin folders, and turns the optional blocks in CLAUDE.md on or off.

Setup: turn a fresh clone into the user's workspace

The whole adoption path. It runs once on a fresh clone and is safe to re-run. You do every step with your own file tools: there is no script.

Four rules hold across every phase.

• One question at a time. Never batch. Offer a recommended answer where one is genuinely better, with one line on why.
• Never ask for a credential. No API key, token, password, or secret, in any phase, for any reason. If a step appears to need one, it is the wrong step.
• Never invent a fact about the user. Every value comes from an answer. An unanswered field keeps its placeholder and gets reported. A plausible guess is the failure this skill exists to prevent.
• Touch nothing outside this workspace.

Phase 0: preflight

0.1 and 0.2 run on every entry, including a re-run of a single phase or domain.

0.1 Confirm the workspace

Check that CLAUDE.md, ME.md, docs/CONCEPTS.md, and templates/CONTEXT.md exist at the session's root. If any is missing, stop: say the session is not rooted in a gucci clone, and do nothing else.

0.2 The remote check

Everything the later phases write is the user's personal context, and it lands in a git-tracked tree whose contents are exactly as public as its remote. Establish what the remote is before writing a single personal value, and look rather than assume:

git remote -v

Name the case that applies out loud:

What it shows	What it means
The gucci upstream, or any remote the user does not confirm is theirs	Unsafe. Their clone points at someone else's repo, and a fork of a public repo on GitHub is public by default. Offer both remedies.
No remote	Safe but sync-less. Nothing can be pushed anywhere. The workspace lives in a repo so it can sync across their machines and agents, so offer remedy A.
Exactly one remote the user confirms is a private repo of theirs	Safe. Say so in one line and move on.

Recommend remedy A: it is the one that keeps the point of the product.

A. Their own private remote. Order matters: never destroy the existing remote until the replacement is known to be possible. Check the tool before touching anything.

gh auth status

If that succeeds, confirm with the user, then run both steps, substituting their repo name:

git remote remove origin
gh repo create <their-repo-name> --private --source=. --remote=origin --push

If gh is missing or unauthenticated, or they prefer the web UI, change nothing. Leave origin as it is, tell them to create a private repo and wire it up themselves, and to re-run /setup once it is done. The remote stays unsafe until then, which is the honest outcome: a user who picks the recommended remedy must never end up worse off than one who picks neither.

B. No remote at all. Confirm, then run git remote remove origin. Say the cost: no sync between machines and no backup until they add a private remote later.

If the user declines both, continue. The remote stays unsafe, which constrains the toggles and the closing summary. Carry it as an open item and re-raise it on every re-run until it resolves.

Two boundaries. Do not gitignore ME.md or any other personal file. The context lives in the repo so it syncs across machines and agents; ignoring it defeats the point of the workspace. The remedy is a private remote, not a hidden file. And git advice stays advice: beyond the read-only check and the one confirmed command above, this skill does not manage the user's remotes.

0.3 Detect a previous run

Read ME.md. If the PLACEHOLDER FILE banner is gone, setup has already run. Do not clobber it. Report what exists, re-raise any open remote item, and offer a targeted re-run: one phase (interview, write, integrations) or one domain (identity, projects, admin, roles, priorities, toggles). Act only on what the user names, rewrite only what it owns, leave the rest alone.

Phase 1: interview

Six domains, in the order below. The list is fixed and finite. Cap yourself at two follow-ups inside a domain, then move on. When the last domain is answered the interview is over: do not free-roam, do not add a seventh domain, do not keep grilling.

Do not invoke the grill-me skill. It has no termination condition by design, which is right for its use case and wrong here. Borrow the manner; keep the termination in this file.

Every domain is skippable. A skipped domain leaves its placeholders untouched and is reported at the end as still hollow. Ask only what changes a file.

Domain	Fills	Ask for
identity	ME.md Identity	Name; city and IANA timezone; one line on what they do and are working toward; spoken languages they work in (programming languages are not this: they belong in a project brief's stack line); how they want agents to talk to them
projects	PROJECTS.md, engineering/projects/<slug>/CONTEXT.md	Per project: name and folder slug; repo, and whether it is public or private; local clone path; default branch; stack an agent must not guess; which tracker owns its issues; the gates that bite (what an agent may never do unattended)
admin	admin/README.md, admin/<area>/CONTEXT.md	Per area: name and folder slug; what it covers in one line; the named file or system that is its source of truth
roles	ME.md Roles	One row per hat the user wears: the role, one line on what they own in it, and which of the folders just scaffolded carries its detail. Plus the one-line list of personal and admin workflows they run
priorities	ME.md Operating priorities	Their standing priority now; what they want protected
toggles	CLAUDE.md optional blocks, ME.md Normal workflow	The three toggles below, one question each; plus any standing workflow of their own worth one line

Projects and admin come before roles on purpose: a role's context link can only name a folder that already exists.

When the user has nothing yet

The case that breaks if you assume otherwise: no tracker, no deploy, no gates, maybe no projects at all. Every question presuming infrastructure gets a "none yet" branch, and "none yet" is a durable fact worth writing, not a gap to fill with a guess.

• No projects, or no admin areas. Skip the domain; the index keeps its commented example row and stays empty. Say the workspace is honest about having nothing there yet, and that adding one later is a CONTEXT.md plus a row.
• No tracker. Write none yet in the PROJECTS.md tracker column, and record in the brief that until one exists, unfinished work on this project routes to tasks/ through the persistence gate. That is the contract's own answer: tasks/ catches what no other system owns.
• No deploy, no worktrees, no clone yet. "Not deployed" and "one branch, no worktrees" are true durable facts. Write them. Delete a template line only when the concept does not apply.
• No gates, or they do not know. Do not invent one. Delete both gate-ish bullets from the template's "How work runs" list: the one about what agents may do unattended, and the one about hard gates. Say gates get written the first time one bites, which is how that section honestly fills up.

Phase 2: write

ME.md. Rewrite in place. Resolve the placeholders in Identity, Roles, Operating priorities, and the Normal workflow line. Keep the structure, section order, and Updated when: trigger. Leave the static sections (Detailed personal context, Factual precedence and promotion, Personal-assistant stance) exactly as written: they are contract, not interview output. Delete the PLACEHOLDER FILE banner once real values are in. A Roles context cell may only name a folder that now exists; if projects or admin was skipped, write not scaffolded yet rather than a link to nothing. Keep it a router: every session reads it at boot, so a long answer belongs in a reference/ topic or a CONTEXT.md, with ME.md pointing at it.

Projects. Per project: copy templates/CONTEXT.md to engineering/projects/<slug>/CONTEXT.md, fill what was answered, and delete the template's own "copy this file" guidance lines. Add one row per project to PROJECTS.md; the commented example row shows the shape and stays commented. The template's "how to run it locally" line has no interview question by design, since it is worth writing only once a project runs: leave the placeholder and name it in the summary as fill-later, so it reads as deliberate rather than missed.

Admin areas. Per area: create admin/<area>/CONTEXT.md. There is no admin template, and the engineering brief is the wrong shape (admin/README.md says so): write a short entry point with an Updated when: trigger, what the area covers, its named source of truth, and its durable workflow rules. Add one row per area to admin/README.md.

CLAUDE.md. Apply the toggle mechanic below.

reference/. Leave reference/*.md untouched: fill-as-you-go, not this skill's job. In the summary, say they exist, that ME.md links them, and that they hold detail loaded on demand rather than at boot.

Verify, then report

No agent certifies its own work, and that includes you. Re-read every file written and confirm:

• every value the user gave is in the file, and every field they did not answer still carries its placeholder (an invented value is a defect; a surviving placeholder is not);
• every table row links to a file that exists, and every role's context cell names a real folder or says not scaffolded yet;
• ME.md no longer carries its banner.

Fix what fails. Do not report around it. Then print: what was written, file by file; every surviving placeholder with the domain name that fills it; the remote's state and any open item; and what to do next (reference/ topics and phase 3).

Close the loop on committing. Their context is written and uncommitted, and nothing commits it on its own. Say so. If the remote is safe, offer to commit and push. If it is unsafe or unresolved, offer to commit only, and say plainly that pushing waits until the remote is theirs and private.

The toggle mechanic

CLAUDE.md marks each optional block:

<!-- gucci:optional <name> · state: default -->
...
<!-- /gucci:optional -->

state is default (never configured), enabled, or disabled. Read it before acting: a re-run that finds enabled or disabled has already applied that toggle and must not apply it twice. Ask once per block and set the state from the answer.

The remote interlock. auto-push and multi-machine both make an agent push this workspace with no human in the loop, so both are conditional on the remote. If 0.2 did not end with a remote the user confirmed is private and theirs, do not enable either, whatever the user answers. Say why: an unattended push to an upstream or unknown remote publishes their personal context, and the GitHub fork default is public. Leave state: default rather than disabled (they were blocked, they did not choose), carry it as an open item, and tell them to re-run the toggles domain once their remote is sorted. Opting out is always available.

Block	Opt-in (only if the remote is confirmed safe)	Opt-out
auto-push	state: enabled, and replace the block's prose with A below	state: disabled, prose as-is
multi-machine	state: enabled, and replace the block's prose with B below	state: disabled, prose as-is
memory	state: enabled, prose as-is	Delete the block outright, per the blast radius below. There is no state to set: a missing block and a missing memory/ folder together are the record that the user opted out, so a re-run reads that as configured and does not re-ask or recreate it.

Disambiguate memory before recommending anything. The folder's name collides with the reason most people clone this workspace, so say both halves plainly and in this order: memory/ is an episodic archive of what happened on a given day, and it is not what makes their context persist between sessions. ME.md and the project briefs are what survive, and those are already being written. Then recommend opting out, because memory/README.md says most people should skip it and an unused archive is a folder that rots. Take the user's answer either way. A user must never delete this folder thinking they just deleted their agent's memory, nor keep it because the name matched what they came for.

A. auto-push enabled, verbatim:

- **Auto-commit-and-push this workspace.** Committing and pushing this repo is standing behavior:
  agents do it at safe checkpoints and at the end of a task, and do not ask. The hygiene steps
  above still run; only the permission prompt is gone. This applies to this coordination repo
  only, never to the user's engineering repos.

B. multi-machine enabled, verbatim:

- **Never leave committed work local-only.** The Git remote is the only transport between the
  user's machines, so unpushed commits are a sync bug, not a pending decision: every branch has an
  upstream, every commit is pushed, and nothing committed sits local-only at the end of a session.
  Audit worktrees, not just repo roots; that is where unpushed work hides. Dirty working-tree
  files and stashes stay the user's call and are never auto-committed.

The house rule above them ("Ask the user before committing or pushing unless the user has opted out below") is never edited, either way. It refers forward to the auto-push block and stays true whichever way that block goes: opting in is the opt-out it names.

The memory opt-out is the one deletion setup performs, and it owns its blast radius. Delete memory/, the marked block and the folder-map line in CLAUDE.md, the daily-record row in README.md's "Where things live" table, the memory/ link in reference/README.md, and the memory/ line in admin/README.md. Then run grep -ri memory and check what is left rather than trusting that list.

Two things survive that grep and must not be touched.

• Runtime memory. Every mention of runtime or agent memory (CLAUDE.md's factual precedence rule and context preflight, ME.md's promotion section), and the [[memory]] slot in the subproject header. Those mean the agent's own memory store, which docs/CONCEPTS.md section 10 defines as a different thing from this folder. Deleting them breaks the contract.
• Everything under docs/. Those files document gucci itself, the product the user cloned, not the user's own workspace. One user declining one folder is not a reason to rewrite the project's design record, so leave docs/ alone even though the grep will surface it.

Phase 3: integrations

Guided wiring for the personal-assistant tools a chief-of-staff needs. The reference set is mail, calendar, and the user's todo app, and it is the whole set. Each connection ends in a real read-only call, so "connected" means proven rather than claimed.

Read integrations.md when this phase runs, and not before. It holds the preconditions, the per-integration flows, the verification bar, and the report shape. Do not work this phase from memory: the vendor paths changed recently enough that recall is likely to be wrong, and that file is written from current documentation with its sources named inline.

Two things bind you before you open it. The user authenticates to each vendor through that vendor's own flow: you never see, handle, echo, or store a secret. And every integration is optional, independent, and skippable; the workspace is fully usable with none of them, so ask, and take no for an answer.

This phase is written from current documentation but not yet walked end to end against a real account, because authenticating real mail is the user's decision rather than a rehearsal. Say so once when the phase opens. If the user declines the phase or stops partway, that is a complete outcome: report what connected, what did not, and that returning later means re-running this phase alone. The interview and write phases never need to run again for it.