Faculty Meeting

Mode 2: Manual Selection

When the user specifies personas with --with:

/faculty-meeting --with chicago-economist,gibs-pioneer,feminist-org

1. Parse the persona IDs from the --with flag
2. Verify each exists in catalog.yaml
3. Load each persona's SKILL.md and references/tradition.md
4. Generate perspectives and synthesize as above

Selection Rules

• Minimum 3, maximum 5 advisors. Fewer than 3 lacks tension; more than 5 becomes noise.
• Always include at least one contrasting voice. If the question is about competitive strategy, don't select only strategy-aligned advisors — include someone (CBS critical, feminist-org, complexity-scientist) who will push back on the framing itself.
• Prefer diversity across dimensions. Try to vary region, methodology, and theoretical tradition — not just domain.
• Include a historical giant when relevant. If the question touches decision-making (Simon), behavioral economics (Kahneman), firm growth (Penrose), or management practice (Drucker), include the relevant giant alongside school-based advisors.
• Only select personas with status: built. Do not attempt to simulate unbuilt personas.

Output Format

## Faculty Meeting

**Question:** [restated clearly]
**Panel:** [list of selected advisors with 1-line tradition description]

---

### [Advisor Name] — [Tradition]

[Full perspective in the advisor's authentic voice]

---

### [Advisor Name] — [Tradition]

[Full perspective in the advisor's authentic voice]

---

[...additional advisors...]

---

## Synthesis

### Where They Agree
[Bullet points]

### Where They Diverge
[Specific disagreements, named clearly]

### Productive Tensions
[New questions, framings, or research directions that emerge from the disagreement]

### Recommended Next Steps
[Concrete actions for the researcher]

The Ground Rule: Sincere Disagreement

The entire value of a faculty meeting is destroyed if advisors converge on a comfortable consensus. These rules are non-negotiable:

• Each advisor speaks in their own voice. Don't flatten the perspectives into a uniform analytical tone. Harvard sounds like Harvard. CBS sounds like CBS. Simon sounds like Simon.
• Advisors must engage with each other, not just the question. Each advisor should respond to what the other traditions would say — not in a generic way, but by naming specific points of disagreement with specific other panelists.
• No false consensus. If two advisors appear to agree, interrogate the agreement. Are they actually saying the same thing, or using the same words to mean different things? Surface the difference.
• No "both sides have a point" hedging. Each advisor believes their tradition gets closer to the truth. They should argue for their view, not diplomatic middle ground. The synthesis is where nuance lives — the individual perspectives should be committed.
• Concessions must be specific. An advisor may acknowledge another's point, but only by naming exactly what their own framework cannot explain — not by vaguely deferring.
• The synthesis does not resolve the disagreement. The synthesis section maps the terrain of disagreement precisely. It names what the researcher gains from each perspective, what remains unresolved, and what new questions emerge from the friction. The researcher decides — the panel does not.
• Name the blind spots. Each advisor should acknowledge where their lens is weakest. The synthesis should identify what the full panel still misses.
• Be honest about unbuilt personas. If the best panel would include an unbuilt persona, note this in the output: "This question would also benefit from [persona], which is not yet available."

After the Synthesis

End every faculty meeting with a brief, warm feedback check:

Did any of these perspectives feel off to you? — wrong for the tradition, too generic, sounded like a caricature instead of the real thing? If so, just say what felt wrong and I'll make sure it gets to the maintainers so they can fix it.

If the researcher responds with feedback about a specific advisor, follow the process in the /report-issue skill: one round of clarification at most, then file automatically. The filing tries three methods in order — the feedback endpoint (curl to faculty-meeting.vercel.app/api/feedback), then gh issue create, then saves locally to ~/.faculty-meeting/pending-feedback/ for later submission. Include the researcher's anonymous ID from ~/.faculty-meeting/researcher-id (create it if it doesn't exist).

The researcher should never have to know about GitHub, issue trackers, endpoints, or commands. You handle all of that. They just tell you what felt wrong, in plain language.