← ClaudeAtlas

polymathlisted

Polymath split-brain research methodology. Maps the possibility space of open-ended problems by building a max-distance lens roster across three relatedness tiers (close/mid/far), composing polymath expert personas from the tiers, spawning N parallel sub-agents, then synthesizing their disagreements into a landscape map. TRIGGER when: the user explicitly invokes the technique ("polymath", "split-brain", "multiagency", "let's run agents to/for X", "remember our polymath multiagency"); OR asks to brainstorm/ideate across multiple framings of an architecture, design, or strategy problem; OR when ALL of these are true: (a) the problem is research/strategy/framing-level, (b) the user has indicated framing uncertainty (not debugging), (c) the cost of picking the wrong frame is high, (d) the user has not already specified an approach. DO NOT TRIGGER when: debugging ("stuck on this regex/error/build/typo/merge conflict"), file/syntax lookups, single-answer questions, naming/styling micro-decisions, or anything where
DROOdotFOO/agent-skills · ★ 1 · Code & Development · score 75
Install: claude install-skill DROOdotFOO/agent-skills
# Polymath Split-Brain Workflow A meta-method for mapping the possibility space of a problem before committing to an approach. Forces uncorrelated views by spawning parallel agents that each see the problem through a different disciplinary lens. The value comes from the **spread** of returned ideas, not from averaging them -- disagreement is the signal. ## What You Get - Landscape map: N sub-agent outputs covering uncorrelated disciplinary lenses - Synthesis of disagreements in structured template (not averaged consensus) - Actionable divergence points highlighting where frames conflict ## Killer items -- silent failures if skipped These are load-bearing. Skipping any produces output that _looks_ successful but is wrong: - **[K1] Step 0 triage produced an explicit go-decision** -- without this, the workflow burns lenses on a problem that didn't need them. - **[K2] Step 2 rosters were built by THREE PARALLEL sub-agents (close/mid/far tiers), each running max-distance walk within its tier WITHOUT looking at the problem's specific features** -- without this, orchestrator bias leaks into tier construction and the composed polymath personas lose their spread. - **[K3] Step 7 pre-spawn checklist was filled out and announced to the user before any sub-agent call** -- without this, the user has no chance to correct the framing or refuse the cost. - **[K4] All sub-agent dispatches went out in a SINGLE message with multiple tool blocks** -- sequential dispatch silently wastes 10x