Menu
Optional per-repo configuration — pin the work-file directory and verify commands so every stage runs them the same way.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Question the work before doing it — the interview that turns a raw idea into a confirmed problem statement. Use when a tracked piece of work is at its wonder stage, or when starting the Working Genius flow on a new idea.
Read and update Working Genius work files. Use when a stage skill needs the work-file discipline, when the user asks what work is in flight or where a piece of work left off, or before resuming any work tracked under .genius/.
The map of the Working Genius workflow — where each piece of work stands, what to run next, and where genius gaps are hiding.
Drive the work to actually-done — fresh verification of every claim, two-axis diff review, cleanup, commit, post-mortem. Use when a tracked piece of work has all slices built and is at its tenacity stage.
Build one slice at a time with red-before-green tests at the agreed seams and tight feedback loops. Use when a tracked piece of work is at its enablement stage and a slice needs building.
Find the unknowns before they find the work — a read-only territory pass that surfaces the questions nobody knew to ask, judgment taught before a choice is extracted, and a quiz that catches the user's map up with what actually changed. Use when work enters territory the user calls unfamiliar, when the user is confirming a choice they can't evaluate, or when the user asks what they're missing or wants to be quizzed before accepting built work.
| name | setup-working-genius |
| description | Optional per-repo configuration — pin the work-file directory and verify commands so every stage runs them the same way. |
| disable-model-invocation | true |
The workflow runs fine on defaults (.genius/ for work files, verify commands discovered per run). This skill pins those choices per repo so no session has to rediscover them. Run it once, or never.
Run it as a conversation, not a script: look first, propose what you found, and let the user correct each choice before anything gets written.
CLAUDE.md / AGENTS.md at the repo root — which exists? Is there already a ## Working Genius section?.genius/ — any work files already in flight?package.json scripts, Makefile, justfile, pyproject.toml, …) — find the likely typecheck, test, and lint commands.A — Work-file directory. Default .genius/ at the repo root. Also ask: commit work files or gitignore them? Recommend committing — done files are decision history, and gates only bind what's visible to every session.
B — Verify commands. Propose the discovered typecheck / test / lint commands; let the user correct them. These are what Enablement runs each cycle and Tenacity runs fresh at close-out.
C — Gate enforcement. How hard should the Stop hook hold the gate rule when a stage ran past an unchecked, unskipped gate? warn (default): blocks ending the session once per distinct bypass state — the repair message lands, then the user can still stop. block: every stop attempt re-blocks until the bypass is repaired or recorded as skipped. Recommend warn for solo exploratory repos and block where the work files are shared history other sessions build on. Only block needs writing — warn is what no line means.
Pick the file: CLAUDE.md if it exists, else AGENTS.md if it exists; if neither, ask which to create — never create one when the other already exists. If a ## Working Genius section already exists, update it in place — don't append a duplicate, and preserve any Lessons: list Tenacity has grown there (it's project memory, not setup output).
## Working Genius
Work files: `.genius/` (committed). Flow: /wonder → /invent → /discern → /galvanize → /enable → /tenacity; type /genius for status.
Gate enforcement: block
Verify commands:
- typecheck: `<command>`
- test: `<command>`
- lint: `<command>`
Don't seed a Lessons: list — Tenacity creates it lazily, the first time a lesson recurs across work and earns promotion.
If the user chose gitignore, add the directory to .gitignore.
Tell the user setup is complete, and that editing the ## Working Genius section directly is the normal way to change these later — re-running this skill is only for starting over.