setup-working-genius

Setup Working Genius

The workflow runs on defaults (.genius/ for work files, verify commands discovered per run, no issue mirror), so this skill is about the pointer as much as the settings: a fresh session in a fresh context knows none of it until an instruction file tells it. Run it once per repo — after that, every session starts already knowing.

Run it as a conversation, not a script: look first (existing CLAUDE.md/AGENTS.md, any .genius/ in flight, the project's task runner, a CONTEXT.md or DESIGN.md already alive), propose what you found, let the user correct each choice.

A — Work-file directory. Default .genius/ at the repo root. Commit or gitignore? Recommend committing — done files are decision history every session can read. Create the directory now (a .gitkeep when it would otherwise be empty): pinned and present beats pinned and promised.

B — Verify commands. Propose the discovered typecheck / test / lint commands; the user corrects them. These are what Enablement runs each cycle and Tenacity runs fresh at close-out.

C — Issue tracking. Default off — the work file already carries the state. Pin Issue tracking: github when people watch progress through the tracker: Galvanizing then publishes each approved breakdown as one parent issue with a slice issue under it per slice, all wearing one shared working-genius label (one-click filter; the parent does the per-work grouping, so labels don't sprawl). Enablement closes slice issues as slices close, Tenacity sweeps orphans and closes the parent last — its open state is the work's live status. The work file stays the source of truth — issues are its published mirror, never a second place to plan. Only on needs writing.

D — Seed the project docs. Work files are per-work memory; three homes are project memory, compounding across all future work — and setup is the one conversation guaranteed to happen before any of it, so the ground is prepared here rather than left to whichever session happens to notice. .genius/DECIDED.md needs no seeding — its lines are earned, written by the first decision a future stranger would re-fight (decision-record skill); the pointer alone prepares it. The other two:

• CONTEXT.md — the vocabulary. Exploration already read the README and the code's load-bearing names; propose the handful of terms a stranger would need decoded — domain words, never general programming ones — and let the user confirm or sharpen each definition. Write the confirmed set in the domain-glossary skill's format. Where the project's records will be written in a language other than English, add the flow's own names — the domain-glossary skill lists which — each with one rendering the user confirms, so that every later record says them the same way. Confirmed terms only: an empty skeleton is premature documentation, and a CONTEXT.md that already exists gets its ## Language section appended, everything else left alone (the glossary skill's don't-hijack rule). A user with no patience for this right now declines in a word — the pointer below still tells every session to grow the file as terms resolve.
• DESIGN.md — the visual language. Never scaffolded here: it is the output of the /designer taste conversation, and a template written without that conversation is exactly the model-default aesthetic it exists to prevent. Ask one question — does this project have an interface someone will see? The answer decides whether the pointer carries the DESIGN.md line: read the file before building screens when it exists, route to /designer before pixels when it doesn't.
• ARCHITECTURE.md — the committed architecture. The same rule: it is the output of /architect, never scaffolded. Where one exists, the pointer says to read it before designing anything that touches its boundaries; where the project is greenfield or a subsystem is about to be shaped, the pointer routes to /architect first.

Three settings, and it stays three: configuration is for what a session must know and cannot infer from the repo. D adds no switch — it turns the files the pointer names into files that exist. Preferences — how deep to interview, which style you like, what tone to use — are things you say in plain words when they matter, not switches to accumulate here.