The Great Minds Constellation

Most people using AI for creative and technical work eventually run into the same problem: the same session that helped them write a product brief is now being asked to review a line of TypeScript. The output degrades — not because the model is incapable, but because the context is contaminated.

The Great Minds Constellation is the architectural answer to that problem.

What the Constellation is

Eleven plugins. Each represents a distinct craft — prose, visual storytelling, packaging, distribution, engineering, design, operations, law, research, education, and orchestration. Each is independently installable, versioned, and replaceable. Together they form what you would staff if you were building a full creative company.

All eleven now ship in one marketplace at github.com/sethshoultes/great-minds-constellation. Five anchor the foundation — great-minds (orchestration), great-authors (prose), great-filmmakers (visual storytelling), great-publishers (packaging), and great-marketers (distribution). Six expansion plugins — covered in Module 3 — extend the set into engineering, design, operations, counsel, research, and education. The course preserves Module 3's original framing of these as "stars not yet lit" as a record of how the constellation grew; the plugins themselves are installable today.

What every shipped plugin shares

Walk into any of the five plugins and you will find the same skeleton. A persona file written in the craft's own register. A decision table mapping signals to personas — when is this a Hemingway problem versus a Baldwin problem? A pipeline that moves from discovery to debate to plan to build to QA to review.

The skeleton is not an accident. It is the interface. When you know where to find the persona file in great-authors, you know where to find it in great-filmmakers. The pattern is load-bearing.

The concrete shape

Open .great-authors/hemingway-persona.md and you will not find a biography. You will find: cut adverbs, trust the noun, what is left out carries the weight. That is a register document, not a job description. The model reads it, adopts it, and stays in it.

Open .great-minds/decision-table.md and you will find columns: signal type, routing persona, escalation condition. When a project ships copy that reads like a press release, the table routes to Hemingway, not to Ogilvy. The decision is codified, not implicit.

Why this matters

A single omnibus prompt for all creative work produces mediocre results across the board — not terrible, but never tuned. The Constellation produces craft-native output because each plugin context is clean. The prose session never drifts into systems architecture. The orchestration session never writes a sentence.

If you get stuck

If it is not clear which plugin owns a given task, the problem is usually that the task spans two crafts. A product launch, for example, needs both great-marketers (positioning, channel strategy) and great-publishers (the actual artifacts: one-pager, press kit, landing page). Separate them. Run each plugin on its half.

If the persona file is producing generic output, the file itself is probably generic. Read it out loud. If it sounds like a Wikipedia article rather than the person's actual voice, rewrite it.

Deliverable

Name the five shipped plugins and their crafts without looking. Then name the decision that separates them — what makes great-authors its own plugin rather than a section of great-minds.

Further reading

This course is drawn from two essays on sethshoultes.com: "The Constellation" (the architectural argument) and "Great Minds Constellation: Ten Plugins, One Marketplace" (the plugin-by-plugin tour). The marketplace itself is at github.com/sethshoultes/great-minds-constellation.

• "Three Shapes of the Same Pattern" — the moment the same plugin shape repeats across great-minds, great-authors, and great-filmmakers, and what that pattern actually is.
• "Stars Aligned: The Writers Wrote the Engineers" — the five "not-yet-lit" plugins shipped during the writing of the original Constellation post; the data point on whether the pattern is actually reusable.

The word you use for your tools shapes how you design them. If you call your AI setup a "suite," you will be tempted to bundle everything. If you call it a "platform," you will build for lock-in. The word "constellation" is doing real architectural work.

What a suite actually is

A suite bundles crafts into one interface. Adobe Creative Suite. Microsoft Office. You buy the whole thing or nothing. Features pile on features because the business model requires constant additions to justify the subscription. Complexity is the product.

In AI terms, a suite is a single system prompt that tries to be a writer, a designer, and a strategist simultaneously. The outputs are competent and interchangeable. Nothing sounds like it came from someone who thinks in a specific craft.

What a platform actually is

A platform hosts things. Notion, Salesforce, Figma's component library. The platform wins when you build on it, not around it. Vendor lock-in is not a bug — it is the business model.

An AI platform would be one place where all your prompts live, maintained by one provider, with one API, one pricing tier. The surface area is clean. The leverage is held by someone else.

What a constellation actually is

A constellation keeps each craft in its own plugin. great-authors does not know about great-filmmakers. They share an architectural shape — the same skeleton — but they run independently. You install what you need. You version them separately. When great-authors ships a new Baldwin persona, you update that plugin; everything else holds still.

This is the software engineering principle of separation of concerns applied to creative work. It is not a metaphor. The .great-authors/ directory is a distinct repository. The .great-filmmakers/ directory is a distinct repository. They share nothing at runtime.

The architectural insight

Most attempts at AI-staffed pipelines fail because they are built as suites: one big context window, one system prompt, one river of conversation. Everything affects everything. The marketers' output bleeds into the writers' context. The engineers' constraints contaminate the designers' brief.

The Constellation solves this by making the contamination impossible. The craft context is sealed inside the plugin. The orchestration layer — great-minds — passes structured handoffs between plugins, not raw conversation history.

If you get stuck

If you find yourself asking "should this persona live in great-authors or great-minds," the question reveals the answer. Personas who write live in great-authors. The persona who decides who writes lives in great-minds. The orchestrator is never a craftsperson.

If two plugins feel like they are overlapping, look for the interface between them. What does great-authors pass to great-publishers? A finished draft. What does great-publishers return? A packaged artifact with a format decision. The handoff is the boundary.

Cross-reference

Lesson 5 (One plugin equals one craft) goes deeper on where the boundary falls and how to test it when you are designing a new plugin.

Deliverable

State in one sentence what the Constellation has that a suite does not, and what a platform has that the Constellation does not. If you cannot produce both sentences without looking, the lesson has not landed yet.

Each of the five shipped plugins has a specific problem it solves and a specific shape it uses to solve it. Walking through them in order is the fastest way to see the architectural pattern repeated.

great-minds — Orchestration

This is the plugin that decides who does what. Phil Jackson coordinates the pipeline. Steve Jobs reviews taste. Elon Musk debates first principles. Marcus Aurelius mediates conflicts when a debate produces a stalemate.

The plugin does not produce prose, code, or designs. It produces decisions and handoffs. When you open a session in great-minds, the output is a plan: which personas run in which order, what each one receives, what each one returns.

The persona file for Phil Jackson is not a biography. It is a decision protocol: when does the team need a play call versus an adjustment versus a time-out. Read .great-minds/jackson-persona.md and you will see the protocol laid out in plain language.

great-authors — Prose

Five core personas: Hemingway (compression), McCarthy (weight), Didion (cool observation), Baldwin (moral urgency), Vonnegut (compression with irony). Each has a distinct register and a distinct decision table entry.

The decision table answers: given a signal — voice falling flat, argument losing energy, description going generic — which author runs the fix? A flat sentence gets Hemingway. A scene that needs moral weight gets Baldwin. A paragraph that is doing too much at once gets Vonnegut.

The plugin does not pick personas randomly. The signal drives the routing. The routing is documented.

great-filmmakers — Visual Storytelling

Directors who think in frames and cuts. The plugin manages scenes, shots, and sequences. Where great-authors thinks in sentences and paragraphs, great-filmmakers thinks in blocking, pacing, and rhythm.

The interface with great-authors is well-defined: a scene description from great-authors becomes a shot list in great-filmmakers. The filmmakers do not edit prose. The authors do not specify shot angles.

great-publishers — Packaging

Chip Kidd for covers. Tina Brown for magazines. This is the layer that takes a finished artifact from great-authors or great-filmmakers and asks: what format does this ship in, what does the container look like, and what does the reader encounter first.

Publishers are not editors. Editors live in great-authors. Publishers make decisions about containers, not content.

great-marketers — Distribution

Ogilvy for direct response. Bernbach for clever. This is the go-to-market craft — the plugin that takes a packaged artifact from great-publishers and asks: who sees it, through which channel, with what message.

Marketers do not make the thing. They find the people who need it.

The pattern across all five

Each plugin: one craft, one or more named personas, a decision table for routing, a pipeline shape (discovery → debate → plan → build → QA → review), and a defined interface for receiving and returning artifacts.

If you get stuck

If you cannot tell which plugin owns a task, write down what the task produces. A sentence: great-authors. A cover: great-publishers. A channel strategy: great-marketers. A shot list: great-filmmakers. A decision about which of those to run first: great-minds. The output names the craft.

If a plugin session is producing output that belongs in another plugin — a writer session that starts making packaging decisions — stop the session and route to the correct plugin.

Cross-reference

Lesson 7 (Persona files are written in craft register) goes into the mechanics of what makes a persona file work. Lesson 8 (Plugins ship prompts, projects ship renders) explains what each plugin actually produces and where that artifact lives.

Deliverable

For each of the five plugins, state: the craft it owns, one named persona, and what artifact it returns. Five rows, three columns, written without looking.

Most people using Claude for multiple tasks are already running an informal constellation. The problem is the boundaries are invisible and the routing is ad hoc. This exercise makes the structure explicit.

What you are building

A constellation map: the crafts your work actually requires, the personas you trust for each, and the interfaces between them. Three to five plugins is the right size for most projects. Ten is the maximum. One is not a constellation.

Step 1 — List your crafts

Write down every distinct type of work your project requires. Be specific. "Writing" is not a craft — "product copy for a developer audience" is. "Design" is not a craft — "information architecture for a dashboard" is. "Strategy" is not a craft — "go-to-market sequencing for an enterprise product" is.

You are looking for domains where the vocabulary, the quality bar, and the failure modes are different enough that a single persona cannot hold all of them without slipping.

Step 2 — Map personas to crafts

For each craft, name one or two people — real or historical — whose work you trust as the quality bar. Do not name people you admire abstractly. Name people whose specific decisions you can point to. "Hemingway" is useful because you can open a page of his prose and ask: does this match. "A great writer" is not useful.

If you cannot name a person, your craft definition is still too vague.

Step 3 — Find the seams

Look at your list of crafts and ask: where does one end and the next begin? Who decides when the writer hands off to the publisher? Who resolves a conflict between the designer's brief and the engineer's constraints?

Draw those seams on paper or in a text file. The seams are where you need an orchestration persona — a Phil Jackson, not a craftsperson.

Step 4 — Write the interface

For each seam, write one sentence describing what artifact passes across it. "The author passes a finished draft. The publisher receives it and returns a format decision and a container specification." If you cannot write the sentence, the seam is not real — you have drawn a boundary in the wrong place.

Step 5 — Write the one-sentence brief

For each persona, write a single sentence describing their mandate. Not their biography. Their mandate. "Hemingway: cut until the sentence cannot be shortened without losing the noun." "Phil Jackson: decide who runs next, not what they produce."

If you get stuck

If you have more than seven crafts, you are probably subdividing one craft into sub-tasks. Sub-tasks belong in the same plugin. Crafts have different registers. Sub-tasks have the same register with different parameters.

If you cannot name a persona for a craft, that is useful information. It means the craft has no exemplar you trust, which means you are not yet sure what "good" looks like. Resolve that before building the plugin.

Deliverable

A text file with three to five entries. Each entry: craft name, persona name, one-sentence mandate, and one-sentence interface description (what it receives, what it returns). Save it as constellation-map.md in your project root.

The rule is simple to state and hard to follow: one plugin, one craft. When you violate it, you will not notice immediately. The output will seem fine. The degradation is gradual, and it looks like model limitations rather than architectural drift.

What a craft actually is

A craft is a domain of expertise with three markers: a distinct vocabulary, a distinct quality bar, and a distinct set of failure modes. Engineering has its own vocabulary (invariants, coupling, throughput). It has its own quality bar (correctness, then performance, then readability). It has its own failure modes (concurrency bugs, off-by-one errors, premature optimization).

Poetry also has a vocabulary (meter, caesura, enjambment). It has a quality bar (the word that could not be any other word). It has failure modes (sentimentality, forced rhyme, decoration without compression).

A craft is not a job title. A "creative technologist" is a job title, not a craft. It names a person who does two things. The Constellation splits them.

The test for plugin boundaries

Three questions. If you can answer all three without hesitation, you have a craft:

One — can you describe the craft in one sentence? Not a paragraph. One sentence. "great-authors owns prose: the selection, arrangement, and revision of words to produce a specific effect in a specific reader."

Two — can you name three people who exemplify the craft at its best? Real people, historical people, fictional people. The names are not decoration. They are the quality bar made concrete. When you cannot name three people, you cannot train the model on the register.

Three — can you name what this craft does not do? Every craft has a negative space. great-authors does not make format decisions. That is great-publishers. great-filmmakers does not write dialogue. That is great-authors. The negative space is as important as the positive definition.

What happens when you mix crafts

A prompt that asks a single persona to write copy and then decide the packaging format will produce copy that unconsciously bends toward the packaging constraints it is about to encounter. The writer starts making publisher decisions without declaring them. The output is coherent, but not optimized for either craft.

This is subtle because it still looks like output. It is only when you run the same task through a clean great-authors session, then hand the artifact to a clean great-publishers session, that you see the difference. The separate passes produce better copy and a more deliberate format choice.

The one legitimate exception

Early in a project, when you are still discovering what the work requires, you may run a broad session to map the terrain. This is not a violation of the rule — it is reconnaissance. The output of that session is not the artifact. It is a brief. You then split the brief into craft-specific sessions.

Reconnaissance is allowed. Shipping the reconnaissance as the final artifact is not.

If you get stuck

If you are unsure whether two crafts belong in one plugin or two, look at the failure modes. If the failure modes are different, the crafts are different. If a plugin session could fail in two distinct ways that require different diagnostics, the plugin is holding two crafts.

If splitting the plugin seems like too much overhead, you are probably not splitting at the right seam. The split should feel like relief — like two sessions that each know exactly what they are doing, rather than one session that is unsure.

Cross-reference

Lesson 6 (Why mixed registers fail) gives a worked example of what happens when you put two crafts in one context window and let them run.

Deliverable

Pick one task you currently give Claude in a single session. Apply the three-question test. If it passes, name the craft. If it fails, name where the split should go and what the two crafts are.

Further reading

• "When You Draw Departments Inside a Plugin, You've Found a Split" — the diagnostic that says a plugin is holding two crafts: the moment you draw an org chart inside it.

A register is not a tone. Tone is how warm or formal you sound. A register is the full system: the vocabulary you use, the assumptions you make about what the reader already knows, the kind of evidence you reach for, and the shape of your sentences when you are thinking well.

When registers mix in a single context window, the output starts making decisions that belong to both crafts — and optimizing for neither.

A worked example

Ask a single Claude session to: (1) write a product description for a developer tool, and then (2) design the information architecture for the landing page that will display it.

Watch what happens to the product description. It will be shorter than it would have been in a pure writing session. It will front-load the features rather than the problem. It will read like a bullet list waiting to happen, because the model is already anticipating the IA work and shaping the prose toward scannability.

The IA work will also suffer. The information architecture will assume the prose constraints rather than questioning them. A pure IA session might challenge the section order, or decide that the product description should not appear at all above the fold. The mixed session makes a packaging decision and then writes toward it.

Neither output is terrible. Both outputs are compromised.

The designer who codes

A persona that switches between visual design and systems programming produces mediocre design and mediocre code — not because the person (or model) lacks both skills, but because the context required for each is incompatible. Good visual design requires holding the user's perceptual experience as the primary constraint. Good systems programming requires holding correctness and performance as the primary constraints. A context window cannot hold both without one dominating.

The way out is a well-defined interface. The designer passes a wireframe. The engineer builds to it. Neither crosses into the other's register. The wireframe is the negotiated boundary.

When the register shift is acceptable

At the orchestration layer. Phil Jackson does not stay in a single craft register — he moves between them because his job is to understand all of them well enough to coordinate them. The orchestrator's register is meta: it talks about crafts rather than within them.

The key word is meta. The orchestrator says "the writer needs to tighten the hook before the publisher makes a format decision." The orchestrator does not tighten the hook. The orchestrator does not make the format decision. It names the sequence.

If you get stuck

If a session starts making decisions that belong to a different plugin — a writing session that starts specifying fonts, a design session that starts writing headline copy — stop the session. The context has drifted. Extract the artifact produced so far, open the correct plugin, and continue from there.

If the same drift keeps happening, the problem is in the brief. The brief you are passing to the plugin includes constraints or signals from the other craft. Strip them out. The brief should contain only what this craft needs to know.

Cross-reference

Lesson 9 (Practice — audit your plugin boundaries) is the hands-on version of this lesson. It walks you through reading your own existing prompts for register contamination.

Deliverable

Take one prompt you use regularly that asks Claude to do two things. Identify the two registers. Write the one-sentence interface — what the first craft produces, what the second craft receives — and split the prompt accordingly.

Further reading

• "The Architecture Is Not Neutral" — what the named personas in a pipeline are actually doing when they "vote": transmitting the operator's theory of value, not running an autonomous process.
• "The Orchestrator Does Not Write" — why a session that holds two registers at once produces hollow prose; the orchestrator dispatches, doesn't pattern-match.

The most common way a persona file fails is that it describes the person rather than embodying the person. A description is inert. An embodiment is active.

The difference is not tone. It is structure. A description tells you about Hemingway. An embodiment shows you how Hemingway reads a draft.

What goes in a persona file

Four things. Not three. Not five. Four.

One — the craft's quality bar. What does "good" look like in this craft, stated in the craft's own terms. For Hemingway: the sentence that cannot be shortened without losing the weight. For Dijkstra: the proof that holds at the boundary conditions. Not "writes clearly." Something specific enough to apply.

Two — representative examples. Three to five works that define the standard. Not works the persona admired. Works the persona produced. These are the training set for the register. The model reads them and adjusts. Vague praise of an author produces vague prose. Specific examples produce specific register.

Three — decision patterns. How does this persona prioritize when two good options conflict? When Hemingway must choose between precision and brevity, he chooses brevity. When Baldwin must choose between argument and witness, he chooses witness. The decision pattern is the personality made operational.

Four — failure modes. What does this persona avoid, and why. Not "avoids clichés" — every persona file says that. What is the specific failure mode of this craft, this register, this person. Hemingway's failure mode is minimalism that tips into obscurity. Baldwin's failure mode is urgency that tips into polemic. The failure modes are as important as the strengths because they define the edges of the register.

The Hemingway persona file — what it looks like

Not: "Hemingway was a journalist and novelist known for his sparse prose and iceberg theory."

Instead:

Cut adverbs. If the verb needs help, find a stronger verb.
Trust the noun. The thing is more interesting than your reaction to it.
Iceberg theory: what is left out carries the weight. The reader feels the submerged seven-eighths.
Failure mode: minimalism that becomes evasion. Sparse is not the same as empty.
Three representative passages: [actual passages from Hemingway's work]
Decision rule: when brevity and precision conflict, choose brevity — but only if the cut does not remove load-bearing structure.

That file is active. It gives the model something to do with each sentence.

Why the model responds to craft-native prose

The model does not adopt the register because you told it to. It adopts the register because the file it read was written in that register. If the Hemingway persona file is written in academic summary prose, the model will produce academic summary prose. The file is the training signal.

This is why persona files require care. A file written carelessly in three minutes produces a persona that works carelessly. A file written in the craft's own voice — tight, specific, in register — produces a persona that works in register.

If you get stuck

If a persona session is producing output that sounds generic, read the persona file out loud. If it takes more than thirty seconds before you hear the person's actual voice, the file is generic. Rewrite it. Do not patch the session prompt. Fix the file.

If you are not sure what the person's actual voice sounds like, open a primary source. Read three pages. Then write one paragraph of the persona file. Read three more pages. Write another paragraph. The file should feel like you are translating from the primary source, not summarizing it.

Cross-reference

Lesson 5 (One plugin equals one craft) explains how to define the craft before writing the persona file. If the craft definition is weak, the persona file will be weak regardless of how carefully you write it.

Deliverable

Write a persona file for one persona you currently use with Claude. Include all four elements: quality bar, representative examples (at least three), decision patterns (at least two), and failure modes (at least two). Keep it under 300 words. If you cannot fit it in 300 words, the file is not specific enough.

Further reading

• "The Persona Will Lie to You in a Beautiful Voice" — when the file produces a persona convincing enough to claim invented facts confidently, and what guardrails the file itself has to carry.

This distinction is the one that gets violated most often, and when it gets violated, the architecture becomes impossible to maintain.

A plugin is a set of prompts. It lives in a repository. It is versioned. It is shared across multiple projects. When you improve the Hemingway persona file in great-authors, every project that uses great-authors gets the improvement on the next pull.

A render is a specific output — a tightened paragraph, an approved design, a shot list for a scene. It lives in the project. It is not versioned in the plugin. It does not belong to anyone except this project.

The rule stated plainly

Do not put renders in plugins. Do not put prompts in projects (unless they are project-specific overrides, and even then, be careful).

The Hemingway prompt lives in .great-authors/hemingway-persona.md. The paragraph the Hemingway session produced for your product launch lives in projects/launch-2026/copy/hero-paragraph.md. These are not the same file. They are not in the same repository.

Why the separation matters

Prompts are meant to be reused. Renders are not. If you embed a render in the plugin — if you paste last week's approved copy into the persona file "as an example" — you have contaminated the plugin with project context. The next time you use the plugin for a different project, the persona will bend toward that embedded example. The output will be subtly wrong.

The reverse failure is less common but still real. If you store prompts in the project — if you copy the persona file into the project directory and modify it for this project — you now have two versions of the persona file. When you improve the plugin, the project does not see the improvement. You are maintaining two codebases.

What the pipeline looks like

The plugin receives a brief (project-specific context: audience, constraints, artifact type). The plugin runs and produces a render. The render goes back to the project. The plugin is unchanged.

Plugin:  great-authors/hemingway-persona.md  (versioned, shared)
Brief:   projects/launch-2026/briefs/hero-copy-brief.md  (project-specific)
Render:  projects/launch-2026/copy/hero-paragraph.md  (project output)

Three files. Three purposes. None of them in the wrong place.

If you get stuck

If you are not sure whether a file belongs in the plugin or the project, ask: would I want this file to affect the output of a different project using the same plugin? If yes, it belongs in the plugin. If no, it belongs in the project.

If a render is so good that you want to use it as a model for future work, do not paste it into the persona file. Write a new section in the persona file that describes what made it work — in the craft's terms — without including the render itself.

Cross-reference

Lesson 3 (The five shipped plugins) showed what each plugin produces as its interface artifact. This lesson explains where that artifact goes after the session ends.

Deliverable

Audit your current AI working setup. For each prompt or file you maintain, classify it: plugin (would improve all projects using this plugin) or project (specific to this project). If you find renders living in plugin files, move them out. If you find prompts duplicated into projects, delete the duplicates.

Further reading

• "The Hand-off: The Psychology of Trust in Agentic Workflows" — what crosses the seam between plugin and project, and what makes the hand-off feel safe to a human reader.

Most people using Claude for multiple tasks are already running an informal constellation. The problem is that the boundaries are implicit and the register contamination is invisible until the output starts degrading in ways that feel like model limitations.

This exercise makes the contamination visible.

What you are auditing

Your existing Claude prompts. Every role you ask Claude to play. Every system prompt, persona instruction, or "act as" that you have written or saved.

If you do not have formal prompts, audit your conversation habits. What do you ask Claude to do in a single conversation, and in what order?

Step 1 — Inventory

List every distinct role you ask Claude to play. Writer, coder, designer, strategist, researcher, editor, reviewer, formatter, summarizer — whatever applies. Be honest about granularity. "Writer" might actually be three roles: product copy writer, technical documentation writer, and email ghostwriter. These have different registers.

Step 2 — Read for register

Take each prompt or role description and read it for register. Ask: is this written in one craft's vocabulary, or does it shift? A prompt that opens with instructions for persuasive writing and then includes a section on code review has shifted registers. Flag it.

Then read each output you have saved. Does the output stay in one register throughout, or does it shift mid-piece? A paragraph that writes like Hemingway for three sentences and then writes like a product manager for two sentences is showing register contamination.

Step 3 — Find the split points

For each flagged prompt or output, identify where the split should go. What is the artifact that the first craft produces? What does the second craft receive? Write the interface sentence.

If you cannot write the interface sentence, the split is in the wrong place. Look for a different seam.

Step 4 — Rewrite one prompt

Pick the most contaminated prompt from your inventory. Rewrite it as two separate prompts: one per craft. Each prompt should pass the three-question test from Lesson 5: one-sentence description, three exemplars, and a clear negative space.

Do not rewrite all of them today. One is enough to learn the pattern. The others will follow naturally once the pattern is clear.

If you get stuck

If you cannot see register contamination in your prompts, look at your outputs instead. Find an output that felt slightly off — competent but not quite right. Read it for the moment when it stops being in one register and starts being in another. Then trace that moment back to the prompt.

If your prompts are very short (under 50 words), they may not show contamination directly. In that case, look at the conversation. Is there a message where you asked Claude to shift tasks? That shift is the unwritten seam.

Cross-reference

Lesson 6 (Why mixed registers fail) gave the theory. This practice gives you the diagnosis against your own work.

Deliverable

A cleaned-up set of personas — at minimum, one rewritten prompt that has been split into two. Each persona: single craft, one-sentence description, one-paragraph voice document. Save them where you will actually use them, not in a folder you will not open.

Every person who has seen the shipped Constellation asks the same question immediately: where is great-engineers? It is the most conspicuous absence, and the reason it is absent is not neglect. It is complexity.

Why engineering is hard to package

Engineering is not one craft. It is a family of crafts that share a common orientation toward correctness — and almost nothing else.

Systems design (Carmack) has a different register than algorithm correctness (Dijkstra). Frontend architecture (Dan Abramov, in the sense of the problems he has worked on publicly) has a different register than object design (Sandi Metz). Kernel-level clarity (Linus Torvalds, in his code review mode) has a different register than distributed systems thinking (Leslie Lamport).

A single "great-engineers" plugin that tried to hold all of these would violate the one-craft rule immediately. The persona would be incoherent. The output would be generic engineering prose — correct in a general sense, optimized for no particular problem.

The approach that will work

great-engineers ships as a constellation within the Constellation: multiple sub-plugins, each with a narrow craft definition. (At the time this lesson was originally written, the plugin had not yet shipped; it has since.)

Carmack: systems programming at the performance boundary. The register is physics-adjacent — cache lines, branch prediction, the cost of abstraction. What would this implementation cost to run on 1990s hardware?

Dijkstra: correctness at the boundary conditions. The register is mathematical — preconditions, postconditions, invariants, proof obligations. The question is always: what breaks this, and can you prove it cannot break.

Sandi Metz: object design for changeability. The register is humanist — code is read more than it is run, and the reader deserves consideration. Dependencies, cohesion, the cost of coupling.

Linus: code review for kernel-level clarity. The register is adversarial — if it is not obviously right, it is wrong. Simple over clever. The comment that explains why, not what.

What it unlocks

Code review by persona. Architecture decisions filtered through multiple engineering voices in sequence. The ability to ask "what would Dijkstra say about this invariant?" and receive an answer in Dijkstra's register, not in generic code-review prose.

The pipeline would run: Sandi Metz for the initial design review (is this cohesive, are the dependencies right), Dijkstra for the correctness pass (what breaks this), Carmack for the performance pass (what does this cost), and Linus for the final review (is it obviously right, or is it clever in a way that will cost someone later).

If you get stuck

If you are designing a great-engineers-style plugin for your own stack and you are not sure where to draw the sub-plugin boundaries, use the failure-mode test from Lesson 5. If two engineering sub-crafts fail in different ways that require different diagnostics, they need different personas.

If the personas you want to use are not historical figures but living engineers, you can still write the persona file — just use their public writing, their code reviews (GitHub for open-source contributors), and their documented decisions as the primary sources.

Cross-reference

Lesson 5 (One plugin equals one craft) is the principle that explains why great-engineers ships as multiple sub-plugins rather than one.

Plugin source

The shipped plugin lives at github.com/sethshoultes/great-minds-constellation/plugins/great-engineers. Nine engineering personas (Carmack, Hopper, Knuth, Torvalds, DHH, Hejlsberg, Eich, Dijkstra, Sandi Metz) — installable now, despite this lesson's framing as "not yet shipped."

Deliverable

Pick one engineering problem you are currently working on. Identify which sub-craft it primarily requires. Write a two-sentence brief for that persona: what problem they are receiving, what they are being asked to produce.

Design is the craft of making choices that the user never has to think about. The choice of where to put a control, what to call it, how much space to leave around it, and what happens when it is activated — these are all decisions that disappear into the product when they are made well. When they are made poorly, the user feels the friction without knowing why.

Why great-designers is a distinct plugin

The failure mode of mixing design with engineering is that the designer starts making implementation decisions and the engineer starts making aesthetic decisions. Neither craft goes deep enough. The product ships with compromises that feel like limitations rather than choices.

great-designers keeps the design register clean. The plugin does not write code. It does not specify implementation. It produces: wireframes, decision rationales, and design critiques written in the vocabulary of perception and cognition — not of components and APIs.

The personas

Dieter Rams: restraint as a discipline. His ten principles are a decision table — if a feature does not contribute to the product's primary function, it should not exist. The Rams register is architectural: what does this product not do, and is that absence intentional.

Don Norman: cognitive flows and error prevention. The Norman register is psychological — affordances, feedback loops, the gap between the designer's mental model and the user's. A Norman review asks: where will the user go wrong, and what in the design prevents them from recovering.

Edward Tufte: information density without decoration. The Tufte register is editorial — every mark on the surface that does not encode data is noise, and noise degrades signal. A Tufte review of a dashboard asks: how much information is here, and how much of the visual complexity is carrying it.

Susan Kare: icons and pixels at the smallest useful scale. The Kare register is tactile — an icon works when it is recognizable at 16 pixels, not because it is beautiful at 256. The constraint is the design.

Paula Scher: typography and identity at scale. The Scher register is theatrical — what does this say before anyone reads it? The type choice, the color, the hierarchy — these speak before the words do.

What it unlocks

Design review filtered through specific lenses in sequence. Not "make this look better," but: Rams on whether the feature should exist, Norman on whether the user will understand it, Tufte on whether the information is presented efficiently, and Kare on whether the smallest interactive elements are legible.

Each review speaks in its own register. The feedback is not generic. It is specific to the craft lens — which means it is actionable.

If you get stuck

If you are not sure which design persona to route a problem to, describe the problem's primary friction. If the friction is "too many features," Rams. If the friction is "users keep making the wrong choice," Norman. If the friction is "the dashboard is confusing," Tufte. If the friction is "the icons are unclear," Kare. If the friction is "the brand does not read at a distance," Scher.

The friction names the lens.

Cross-reference

Lesson 6 (Why mixed registers fail) gave the general principle. This lesson shows what that principle looks like in the specific case of design — a craft that is particularly vulnerable to contamination from adjacent crafts.

Plugin source

The shipped plugin lives at github.com/sethshoultes/great-minds-constellation/plugins/great-designers. Nine design personas (Norman, Zhuo, Spool, Rams, Kare, Cagan, Scher, Hatfield, Tufte).

Deliverable

Take one interface decision you have made recently — a label, a layout, a control placement. Route it through two design personas from the list above. Write two sentences of critique from each persona. Note where the critiques agree and where they conflict.

Operators are the craft of making things work at scale. Not building the thing — that is engineering. Not designing the thing — that is design. Making the thing run, reliably, at volume, with a team.

The operator's register is different from the engineer's register in a specific way: the engineer asks "does this work?" The operator asks "does this work when the person running it is not the person who built it, under time pressure, at 2 AM."

Why great-operators is a distinct plugin

The failure mode of mixing operations with strategy is that the strategist makes plans that cannot be executed, and the operator makes processes that optimize the wrong things. Keeping them separate forces each to produce its own artifact: the strategist produces a direction, the operator produces a system for executing in that direction.

great-operators does not set direction. That is great-minds. It does not make the product. That is great-engineers and great-designers. It makes the machinery that produces the product reliably.

The personas

Tim Cook: supply chain and execution discipline. The Cook register is about dependencies, lead times, and what happens when one node in the chain fails. A Cook review of a launch plan asks: what are the critical path dependencies, and what is the fallback when each one fails.

Andy Grove: management clarity and OKRs. The Grove register is about output versus activity — measuring what ships, not what was attempted. A Grove review of a team structure asks: where is the output measure, and what happens when it is not met.

Charlie Munger: mental models for decision-making under uncertainty. The Munger register is checklist-adjacent — what are the known failure modes of this class of decision, and which ones apply here. Not what should we do, but what would a rational actor with these constraints do.

Patty McCord: people operations and team design. The McCord register is about who you need on a team to produce a specific kind of output — not who is available, but who is required. A McCord review of a hiring decision asks: what does this person need to be able to do on day ninety, and does this candidate show evidence of that capability.

What it unlocks

Operations reviews before a launch. Hiring decisions filtered through someone who has staffed high-output teams. Process design that asks "does this scale" before the process is built.

The most valuable use is the pre-mortem: run the plan through each operations persona before it ships and ask what breaks. Cook identifies the dependency failures. Grove identifies the measurement gaps. Munger identifies the decision errors. McCord identifies the team gaps.

If you get stuck

If you are not sure whether a problem belongs in great-operators or great-minds, ask whether it is a direction problem or an execution problem. Direction: great-minds. Execution at scale: great-operators.

If you are not sure which operations persona to route to, describe what would go wrong. Supply chain failure: Cook. Measurement failure: Grove. Decision failure under uncertainty: Munger. Team capability failure: McCord.

Cross-reference

Lesson 10 (great-engineers) and this lesson both describe expansion plugins that shipped after the foundational five. Compare them: engineering is sub-divided by craft register; operations is sub-divided by the failure mode each persona is designed to catch.

Plugin source

The shipped plugin lives at github.com/sethshoultes/great-minds-constellation/plugins/great-operators. Nine operations personas (Cook, Grove, Munger, McCord, Deming, Ohno, Horowitz, Walton, Kelleher).

Deliverable

Take one process you own that runs on a regular cadence. Run it through the Cook review: what are the dependencies, and what fails when each dependency is late or unavailable. Write three sentences of Cook's critique.

Every craft in the Constellation answers a different question. Engineering asks "does it work." Design asks "will people use it well." Operations asks "will it run reliably." great-counsels asks: should we.

That question is different in kind. The other questions have technical answers. Should we is a question about values, rights, and what we are willing to be responsible for. It requires a different craft and a different register.

Why the should-we register is a distinct craft

The failure mode of skipping the should-we register is that you build things that work technically and fail ethically, legally, or politically — and you discover the failure after the thing has shipped. The cost of discovery is proportional to how far the thing has traveled from its origin.

great-counsels is the craft of catching those failures before they are shipped. It is not a compliance checklist. It is a set of personas who think rigorously about rights, power, and consequence — and who have a track record of being right about which things matter.

The craft runs best before the build. An hour with great-counsels at the design stage costs less than a year with great-counsels at the litigation stage.

The personas

Lawrence Lessig: digital law and the relationship between code and power. The Lessig register asks: what does this system enable that could not exist before, and who controls the enabling. Copyright, platform power, the architecture of the internet as a political structure — these are his problems.

Ruth Bader Ginsburg: civil rights strategy and the long game. The RBG register is strategic — not "is this fair" but "what is the argument that moves the standard, and in what order should the cases be built." A RBG review asks whether you are building the precedent you want or the one you will regret.

John Rawls: ethical reasoning behind the veil of ignorance. The Rawls register is structural — design the system as if you did not know which position in the system you would occupy. If the answer changes depending on whether you are the platform owner or the lowest-tier user, the design has a problem.

Hannah Arendt: political philosophy and the conditions of action. The Arendt register is historical — this has happened before, in different clothes. What is the structure of this situation, and what does history say about how structures like this tend to resolve. The banality of evil is not a moral condemnation. It is an observation about how ordinary processes produce extraordinary harms.

What it unlocks

The ability to ask "should we?" before "how do we?" Legal review for products at the design stage. Policy memos that understand the stakeholder landscape before the policy is written. Ethical frameworks that survive contact with adversarial users.

The most valuable use case is the adversarial review: run your product or policy through each great-counsels persona and ask them to find the strongest case against it. The critique that survives all four lenses is the critique you should take seriously.

If you get stuck

If you are not sure which persona to route a problem to, describe the primary domain of the harm. Digital rights and platform power: Lessig. Civil rights and legal strategy: RBG. Structural fairness: Rawls. Historical pattern and political structure: Arendt.

If the problem has more than one domain, run more than one persona. The conflicts between their reviews are informative — they mark the genuinely hard trade-offs.

Cross-reference

This plugin has the most overlap with great-minds — specifically with the Marcus Aurelius persona, which mediates conflicts. The difference: Aurelius mediates between crafts within a project. great-counsels mediates between the project and the world it will affect.

Plugin source

The shipped plugin lives at github.com/sethshoultes/great-minds-constellation/plugins/great-counsels. Nine counsel personas (RBG, Marshall, Scalia, Lessig, Wu, Brandeis, Sunstein, Arendt, Rawls). Note: the plugin produces a craft register, not legal advice.

Deliverable

Take one decision you have made recently about a product, policy, or process. Run it through the Rawls test: state the decision as if you did not know which position in the affected system you would occupy. Does the decision hold, or does it depend on your position? Write three sentences of analysis.

Further reading

• "The $0.35 Article, and the AI Editor Who Refused to Ship It" — what it looks like when a persona genuinely holds the should-we register: an editor who blocks the publish step rather than rubber-stamping it.

Research and synthesis is the craft of moving from evidence to explanation without losing the evidence along the way. It is not the same as writing. A good writer can make a weak argument feel compelling. A good researcher cannot afford that — the explanation has to hold under examination.

great-researchers is the craft of inquiry: what questions to ask, what counts as evidence for an answer, and how to explain the answer to someone who was not in the room when the evidence was assembled.

Why great-researchers is a distinct plugin

The failure mode of mixing research with writing is that the writer starts shaping the evidence toward the argument before the evidence has been fully examined. Confirmation bias is not malicious. It is structural — writers look for the material that builds the piece, and they find what they are looking for.

A separate great-researchers plugin examines the evidence before the writer sees it. The researcher produces a synthesis: here is what the evidence says, here is what it does not say, here is the strongest counter-evidence. The writer receives that synthesis as a brief and builds from it.

The separation is not a process overhead. It is error correction at the stage when correction is cheapest.

The personas

Carl Sagan: science communication without condescension. The Sagan register moves between the rigorous and the accessible without simplifying the former or patronizing the latter. A Sagan review asks: is this explanation true to the evidence, and does it give the reader enough to think with rather than just enough to agree.

Stephen Jay Gould: natural history and the long argument. The Gould register is essayistic — the evidence for a large claim is assembled over time, from unexpected places, and the argument is built sideways as much as forward. A Gould review asks: what is the evidence from the adjacent domain that bears on this question.

Mary Roach: popular science with primary source rigor. The Roach register is reporting — she goes to the source, asks the uncomfortable question, and brings back what she found rather than what she expected. A Roach review asks: have you talked to the people doing the thing, or are you synthesizing secondary sources.

Oliver Sacks: narrative neurology and the particular case. The Sacks register is clinical and humane — the general principle emerges from the specific case, and the specific case is never reduced to an illustration. A Sacks review asks: where is the particular person in this explanation, and what do they reveal about the general rule.

Atul Gawande: medical investigation and the systems behind outcomes. The Gawande register is accountability journalism — not "what happened" but "what in the system made this happen, and what would have to change for it to happen differently." A Gawande review asks: what is the system explanation, and what is the individual explanation, and where do they conflict.

What it unlocks

Research synthesis that preserves the evidence rather than flattening it. Literature reviews that name what the literature does not resolve. Explanatory writing that gives the reader tools rather than conclusions.

The most valuable use: run a first-pass synthesis through Sacks or Gould before handing it to great-authors. The researcher flags where the evidence is thin, where the argument is ahead of the support, and where the counter-evidence has been ignored. The writer then builds from a brief that is honest about the limits.

If you get stuck

If you are not sure which research persona to route to, describe the kind of evidence the question requires. Empirical science: Sagan. Historical pattern: Gould. Primary source reporting: Roach. Particular case: Sacks. Systems analysis: Gawande.

If the synthesis is coming out too confident — if it does not name the limits of the evidence — run it through any of the five personas and ask specifically: what does this evidence not establish.

Cross-reference

great-researchers is the natural upstream partner of great-authors. The research synthesis is the brief. The author builds the piece. Keep the handoff clean — the researcher does not shape the prose, and the author does not re-examine the evidence.

Plugin source

The shipped plugin lives at github.com/sethshoultes/great-minds-constellation/plugins/great-researchers. Nine researcher personas (Sagan, Gould, Roach, Sacks, Gawande, Diamond, Wilson, Skloot, Caro). Like great-counsels, the plugin produces a craft register — not academic peer review.

Deliverable

Take one claim you have made recently in a piece of writing or a decision memo. Apply the Gawande test: what is the systems explanation for why this is true, and what would have to change for it to be false. If the claim cannot survive that test, revise it before the writing proceeds.

Further reading

• "Twenty-Five Years of Building, and This Was the First Week That Felt Structurally Different" — the longer claim that the research-and-evidence layer of the constellation actually changes what's possible, examined against twenty-five years of prior shifts.

Every craft in the Constellation produces an artifact someone else has to use. Engineers ship code. Designers ship interfaces. Authors ship prose. Each of these artifacts succeeds or fails on whether the next person — the user, the reader, the maintainer — can pick it up and act. great-educators is the craft of making that pickup tractable.

The plugin does not write curricula. It shapes how an artifact is encountered for the first time: what the learner sees on page one, what they can do unaided by the end of section one, what they can verify themselves before they need to ask. It is the craft of designing the path from "never seen this before" to "I just used it correctly."

Why great-educators is a distinct plugin

The failure mode of skipping the educator register is that the artifact technically exists but no one can adopt it. A Skill file is correct and unused. A doc page is accurate and ignored. An onboarding flow covers everything and teaches nothing. The work was done; the handoff failed. The cost of that failure is invisible because it shows up as low adoption rather than a bug report.

A separate great-educators plugin runs a different review than great-authors. The author asks: is this prose clear. The educator asks: can the reader DO something with it after they read it. Two related questions; two different success conditions.

The plugin runs best at three points: when material is being designed (sequence, scaffolding, the order in which difficulty is introduced), when material is being tested (does a real beginner succeed unaided), and when material is being revised (where in the flow did the learner get stuck and why).

The personas

Richard Feynman: explanation from first principles, with the right analogy. The Feynman register strips ceremonial language and finds the physical metaphor that lets a learner see the thing clearly for the first time. A Feynman review asks: where in this explanation am I substituting jargon for understanding, and what is the analogy that would let the reader see the behavior before they meet the equation.

Maria Montessori: developmental scaffolding and self-correcting design. The Montessori register isolates difficulty — one new challenge at a time, structured so the outcome itself reveals correctness. A Montessori review asks: which prerequisite skills am I assuming, and where in the sequence does the learner verify their own progress without needing me.

Paulo Freire: dialogue rather than lecture, lived reality as the starting point. The Freire register treats the learner as a co-investigator, not a recipient. A Freire review asks: am I telling the reader what I want them to know, or am I posing the problem in a way that requires them to think and act, starting from where they actually stand.

What it unlocks

Documentation that converts curiosity into competence. Onboarding flows that produce confident operators rather than passive readers. Skill files whose first sentence orients the learner in their own situation rather than introducing the system's terminology. Lessons that produce a deliverable, not a passive read.

The most valuable use: run a first-pass review of any artifact intended for a beginner — a README, a Skill file, a tutorial — through Montessori before publishing. She will find the prerequisite the artifact assumes but does not name. That single fix accounts for most of the adoption drop-off in technical material.

If you get stuck

If you are not sure which persona to route to, describe what is going wrong. The reader cannot follow the argument: Feynman. The reader cannot complete the task unaided: Montessori. The material does not connect to the reader's actual situation: Freire.

If a piece of teaching is failing all three, the artifact is not the problem — the artifact is too far ahead of the audience. Pull back to the prerequisite the audience actually has, and rebuild from there.

Cross-reference

great-educators is the natural downstream partner of great-authors and the natural upstream partner of great-publishers. The author writes the prose; the educator structures how it is encountered; the publisher decides what container it ships in. When the three handoffs are clean, the artifact converts.

Plugin source

The shipped plugin lives at github.com/sethshoultes/great-minds-constellation/plugins/great-educators. Three educator personas (Feynman the explainer, Montessori the scaffold designer, Freire the dialogic educator). The plugin produces a craft register for instructional design — not certified pedagogy.

Deliverable

Take one piece of writing or documentation you published in the last month that was meant to teach something. Apply the Montessori test: name the prerequisite skill the artifact assumes the reader has. If you cannot name it without re-reading, the artifact assumed it implicitly — which is the most common cause of an artifact that "everyone read and no one used." Write three sentences identifying the assumption and the fix.

Further reading

• "Skills as SOPs" — the longer argument for treating instructional artifacts as factory SOPs: institutional memory fixed in writing, with the order of steps and the verification points specified, so adoption does not depend on the next reader being clever.

The constellation ships as a Claude Code plugin marketplace, and that fact makes the whole pipeline look locked to one runtime. It is not. A Kimi K2.6 session in another project ran the book-proposal recipe end-to-end — dispatched McCarthy, Gottlieb, and Maya Angelou across two plugins, and the Plan → Build → QA → Review shape held. The marketplace is the distribution. The runtime is something else.

This lesson assumes you have already dispatched a sub-agent at least once. If you have not, go back to l8 (Plugins ship prompts. Projects ship renders) and run one before continuing. The architectural claim only lands once the protocol is in your hands.

The container, not the truck

What carries between runtimes is not the model and not the CLI. It is the dispatch protocol. Three rules, all visible from the brief you write:

1. The brief is self-contained — every file path, every voice rule, every constraint goes in the prompt.
2. The sub-agent reads the project bible at .great-authors/ in fresh context before writing.
3. Output goes to a deterministic path on disk, not back into the conversation.

Look at how shipping containers move. The forty-foot box is the contract — its corners, its hooks, its dimensions are standardized first. After that, every port that handles intermodal cargo can move it. The trucks change. The cranes change. The ships change. The container does not. The dispatch protocol has the same property. The brief is the corner-casting, the bible read is the hook, the deterministic output path is the chassis. Anything that can move that shape can move your recipes.

What carries, what does not

Two columns. This is the audit you need.

Carries:

• Persona files (plain markdown, no runtime calls inside)
• The bible at .great-authors/
• The dispatch-and-read-first pattern
• The deterministic output path
• The Plan → Build → QA → Review pipeline shape

Does not carry:

• The Agent tool surface itself — other CLIs may not expose subagent_type cleanly
• The plugin marketplace
• Per-project enablement in .claude/settings.json
• Slash skills like /team-build

If a persona file contains a line like "use the Agent tool to dispatch...", that file is coupled to one harness. Rewrite it in protocol terms: "dispatch this persona with a self-contained brief." The first phrasing dates within a year. The second reads correctly in any runtime that supports sub-agent dispatch.

Pick the model by what the orchestrator is doing

Routing four parallel dispatches and stitching their outputs is not reasoning-heavy work. The reasoning happens inside the personas. The orchestrator is switching cables. When billing matters, route the orchestrator to a cheaper model — Sonnet, Kimi K2.6 — and let Opus run only when the integration step itself requires real reasoning. Run the same recipe twice, once with each, and read the artifacts side by side. Most come back indistinguishable.

The pinch-hit byline

When a plugin you depend on is not loaded in the current runtime, the orchestrator can absorb the persona's job. But the substitution gets named. The byline string looks like this:

Researcher: Robert Caro (substituted: direct web research + synthesis)

The recipe still runs. The case study stays honest. Without the explicit substitution, the prose drifts from register and you cannot tell from the artifact whether the constellation worked or whether the orchestrator faked it.

If you get stuck

• The persona file references the harness. Lines like "use the Agent tool" or "set this in settings.json" couple the prompt to one runtime. Rewrite in protocol terms — name the dispatch action, not the CLI.
• The orchestrator absorbed the persona's job without saying so. The output reads coherent but flat. Stop. Either dispatch the persona, or add the byline string that names what you covered.
• The README does not separate protocol from harness. The next operator porting the work cannot tell what is load-bearing. Split it into two sections — one paragraph each.

Cross-reference

Lesson 8 (Plugins ship prompts. Projects ship renders) is the file-separation rule this lesson depends on. The persona files belong to the plugin, the bible and renders belong to the project, the dispatch couples them — and the dispatch is what carries.

Deliverable

Open one persona file from your own constellation. Find every line that references the Agent tool, the plugin marketplace, or .claude/settings.json. Rewrite each in protocol-level terms. Then update your project README to split protocol-level requirements (dispatch, briefs, bible, deterministic paths) from harness-level requirements (the CLI you currently run on). Two sections, two paragraphs each.

Further reading

• "The Orchestrator Does Not Write" — the same separation that makes the orchestrator role coherent is what makes the dispatch protocol portable.