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 knows none of it until an instruction file tells it. Run it once per repo, as a conversation: look first (existing CLAUDE.md/AGENTS.md, any .genius/ in flight, the task runner, a CONTEXT.md or DESIGN.md already alive), propose what you found, let the user correct each choice.

The concept: a setting no instruction file carries does not exist for the next session, so the pointer counts as much as the settings. Done when the work-file directory exists, any confirmed CONTEXT.md terms are written, and a fresh session reading only CLAUDE.md finds the ## Working Genius section through @AGENTS.md, with every setting and doc line in it confirmed by the user.

A — Work-file directory. Default .genius/ at the repo root. Recommend committing — done files are decision history every session can read. Create the directory now (a .gitkeep where it would be empty).

B — Verify commands. Propose the discovered typecheck / test / lint commands; the user corrects them. Pin each in its quiet form — pytest -q --tb=short, never -v — because a coordinator re-runs every criterion of every slice and carries each run's output in its context to the end of the work.

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 per slice, all wearing one shared working-genius label; Enablement closes slice issues as slices close, Tenacity closes the parent last. Issues are the work file's published mirror, never a second place to plan.

D — Seed the project docs. Work files are per-work memory; three homes are project memory, and setup is the one conversation guaranteed to happen before any of it. .genius/DECIDED.md needs no seeding — its lines are earned by the first decision a future stranger would re-fight (decision-record skill). The other two:

• CONTEXT.md — the vocabulary. Propose the handful of terms a stranger would need decoded — domain words, never general programming ones — and let the user confirm or sharpen each; 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 glossary skill lists which — each with one rendering the user confirms. Confirmed terms only: an empty skeleton is premature documentation, and an existing CONTEXT.md gets its ## Language section appended, everything else left alone. A user with no patience for this declines in a word; the pointer 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 conversation, and a template written without it is the model-default aesthetic it exists to prevent. Ask one question — does this project have an interface someone will see? — and the answer decides whether the pointer carries the DESIGN.md line.
• ARCHITECTURE.md — the committed architecture. The same rule: the output of /architect, never scaffolded. Where one exists, the pointer says to read it before designing across its boundaries; where the project is greenfield, 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. Preferences are said in plain words when they matter, not switches.