Menu
The map of the Working Genius workflow — where each piece of work stands, what to run next, and where genius gaps are hiding.
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/.
Optional per-repo configuration — pin the work-file directory and verify commands so every stage runs them the same way.
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 | genius |
| description | The map of the Working Genius workflow — where each piece of work stands, what to run next, and where genius gaps are hiding. |
| disable-model-invocation | true |
| argument-hint | optional: a work slug, or a new idea to start tracking |
The map answers three questions: where every piece of work stands, what runs next, and which genius went missing when something feels wrong. It routes; it never builds.
Every piece of work travels through six geniuses, in three pairs:
| Stage | Genius | Command | Skipping it looks like |
|---|---|---|---|
| Ideation | Wonder — question the work | /wonder | building exactly the wrong thing |
| Invention — generate options | /invent | anchoring on the first idea | |
| Activation | Discernment — judge and choose | /discern | plausible-but-wrong ships |
| Galvanizing — mobilize into slices | /galvanize | a plan nobody can start | |
| Implementation | Enablement — build with tight loops | /enable | flying blind until a big-bang reveal |
| Tenacity — finish with evidence | /tenacity | "done" that isn't |
State lives in .genius/<slug>.md (the genius-file skill owns the format). Each stage ends in a gate; the next stage checks it. Skips are allowed but always recorded — that's how gaps stay visible.
Underneath the flow run two cross-cutting layers. The domain-glossary skill keeps CONTEXT.md, the project's shared language — /wonder and /discern drive it actively; every other stage just speaks it. Unlike work files, it's project-level: it compounds across all work. The blindspot skill hunts the unknowns the stages can't reach — a read-only territory pass before unfamiliar work, judgment taught before a choice is extracted, a quiz that catches the user's map up with built work. /wonder, /discern, and /tenacity drive it; /blindspot <area> calls it directly.
No argument → report status. Start mechanical: run ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/genius-gates.sh status — one line per in-flight file: slug, stage, mode, current-gate progress, bypassed gates, gateless sections. Trust its arithmetic over your own skim; read a file's current section body only where the report needs substance (the unchecked items' wording, a skip's reason) — don't load whole files just for status. (Script not on disk — skills installed without the plugin? Do the same scan by hand: each non-done file's stage:, its **Gate — <Stage>** checkboxes, and skip markers.) Done files get one summary line — and their **Post-mortem:** lines get read as a set (grep the lines, not the files; only lines naming a genius vote — placeholders and abandoned — lines don't): when the same genius comes up weakest in two or more of the recent ones, report the pattern with the calibration it implies ("Wonder weakest in 3 of the last 5 — interview deeper before offering express"). Once is a data point; twice is a calibration. For each in-flight item show: slug, current stage, unchecked gate items, recorded skips, and the exact next command — and if the stage sits ahead of an earlier gate that's neither checked nor skipped, the next command is repairing that gate, not the stage command. Flag anything untouched for roughly two weeks or more as stale and offer to resume or abandon it. If nothing is in flight, show the flow table and how to start.
An idea or request → start work. Sizing is a decision you announce with its reason, not a menu you present: pick the path, say why in one line, and start moving — the user overrules with a sentence, and the overrule becomes the recorded sizing.
/galvanize. (/genius express <idea> forces this path.)genius-file skill to create the work file, then hand to /wonder.Announce the cost with the call. The full flow is insurance priced in tokens — a measured six-stage run cost 11× its no-plugin baseline (n=1, evals/RESULTS.md) — so the announcement names what the stages are buying ("two capable designs exist and the wrong one is expensive to unwind") or what makes them safe to skip ("one seam, no new concept"). Write the call and its reason as the **Sizing:** line under the work file's title (the genius-file skill owns the format): the close-out judges sizing calls against outcomes, and an unrecorded call can't be judged. "Just do it" on full-flow-shaped work buys delegated mode, not express — trimming checkpoints is a mode choice; skipping judgment on work that needs it is how plausible-but-wrong ships.
For the full flow, also settle the mode — recommend one with a reason and let the user pick: mode: guided (checkpoints as written), delegated (after the interview, run on your recommendations with one stop at the Galvanizing breakdown), or auto (after the interview, no stops; the user explicitly asked for hands-off). Every mode keeps the Wonder interview live — modes govern what happens after the confirmed problem, never the dialogue that confirms it. Modes live in the work file; the genius-file skill owns their semantics.
Both calls — sizing and mode — get bent by the record: check recent post-mortems (and any Lessons: in the ## Working Genius section) before recommending. A genius that keeps coming up weakest argues for the path that exercises it — repeated weak Wonder → slower to offer express; repeated weak Tenacity → recommend guided over auto. Say when the record changed your recommendation; that's the post-mortems earning their keep.
A work slug → deep status on that one: read its file, summarize where it stands, flag anything smelly (see below), and name the next command.
When work feels wrong, the skipped or rushed genius is the usual cause. Read the work file and match the symptom:
Three rules of the diagnosis:
Not everything starts at Wonder:
/galvanize; backfill Wonder and Discernment sections from the conversation, marked as backfilled.genius-file skill)./discern it first; imported plans deserve an attack before they deserve slices. Record the plan as an imported option (Invention skipped, reason recorded). The attack will surface questions the plan never answered — those are Wonder's questions: settle them with a targeted mini-interview (or assumed: lines), write them into a Wonder section marked backfilled, and check its gate before slicing. Imported plans import unexamined problems.