CtrlK
BlogDocsLog inGet started
Tessl Logo

consult

Use when you want to learn how experts would think about a design tradeoff, architecture choice, repeated failure, or domain question. Triggers on expert names, "mentor", "panel", "debate", "what would [X] say", "stuck on", style requests.

83

0.00x
Quality

Does it follow best practices?

Impact

0%

0.00x

Average score across 1 eval scenario

SecuritybySnyk

Passed

No known issues

SKILL.md
Quality
Evals
Security

Surface expert knowledge — names, reasoning, and the tensions between them visible — so the user can learn and decide for themselves.

Principles

  • Ground every claim in documented work — this is internal discipline.
  • Show the reasoning, not just the verdict. The user should see HOW each expert gets there, in their voice.
  • Never converge for the user. Do not land on "the one recommendation" — surface positions and let the tension stand.
  • Tensions between experts are the payload. If everyone agrees easily, the wrong experts were selected.

Modes

Two modes. MENTOR leads — the un-forced default. PANEL is opt-in.

ModeBreadthShape
MENTORone lens, deepa single expert reasons through the question in their own voice
PANELmulti-perspective2-4 experts, each reasoning visibly; the tensions between them are the point

Refute is an orthogonal opt-in flag, never a mode and never the default. When the user asks to be challenged, experts attack the chosen position to find where it breaks instead of surveying alternatives. Available on either mode; off unless the user turns it on.

Goals (PANEL only)

In PANEL, an optional goal tunes only how many experts and how diverse — nothing more. No goal forces a reasoning posture or pushes toward one answer.

GoalCountDiversity
depth-novelty2-3same + adjacent domain
coverage3-4cross-domain
unblock2-3cross-lens

Default: depth-novelty. Goal selection is optional — skip it and the default stands. (To challenge a position, turn on the refute flag; it is not a goal.)

Presentation

These rules govern how consult communicates.

  • Experts are visible — names, sources, and attribution appear throughout findings. "Fowler argues...", "Hickey would push back...". The user learns who thinks what and why.
  • Show the reasoning — present each expert's actual argument as readable attributed prose between prompts, not a one-line verdict. Keep it scannable (short paragraphs, one expert per block), but never strip the reasoning down to a label.
  • Surface tensions explicitly — where experts disagree, name the disagreement and both sides.

Workflow

Step 1: Route the pool

Domain-match the question into a pool — over-fetch to ~6-8 candidates so any mode has reshuffle slack. The pool is a fact about the question: fixed once, re-routed only if the question changes. No text output — go straight to Step 2.

  • Match using the domain map below
  • Max 2 from same domain row — diversity requires crossing domains
  • Collect absolute profile paths — Step 3's agents read them, never the main conversation
  • No domain match → tell the user no profile covers the question, then offer an in-weights panel: relevant experts simulated purely from model knowledge. If accepted, run the same workflow with expert names in place of profile paths.

Step 2: Pick mode

One AskUserQuestion. Options: MENTOR (recommended — one expert, deep) and PANEL (multi-perspective). Each option's detail panel shows the candidate expert name(s) it would draw from the pool, so the user shapes the lens. Include refute as a selectable add-on in the prompt (off by default).

  • MENTOR projects the single best-fit lens from the pool.
  • PANEL projects a panel using the chosen goal's Count + Diversity (default depth-novelty).
  • After the user picks, confirm the expert(s) by name with one of: Accept, Reshuffle (re-project from unused pool candidates), Switch mode/goal.

Step 3: Reason

Fan out one Agent per selected expert, all launched in a single message so they run in parallel.

Each agent's prompt: read the profile at its absolute path; reason through the question from documented positions applied to the user's context, respecting the "Would NEVER Say" guardrails; for living figures prefer newer model knowledge past the Verified: date; if the refute flag is on, attack the user's position to find where it breaks. Return the expert's actual argument — a few sentences of reasoning the user can learn from — plus, for PANEL, one dissent line stating where this expert pushes back against the likely consensus. Attribution is preserved, not stripped — names stay attached.

Step 4: Present

Present each expert's reasoning as attributed prose (Presentation rules). MENTOR: one expert's argument, in depth. PANEL: each expert's position, then the tensions between them named explicitly.

Close with one AskUserQuestion for direction — never a forced recommendation:

  • Go deeper — narrow the lens, re-reason (Step 3)
  • Different perspective — reshuffle or switch mode/goal (Step 2)
  • Challenge it — turn on the refute flag and re-reason
  • Done — no recap

Domain Map

Profiles live in profiles/. Route by domain:

DomainProfiles
React / Stateabramov
CSS / Stylingwathan
Design Systemsfrost
Web Animationperry
TypeScript (type-level)vergnaud
JavaScriptsimpson, osmani
Go / Systemspike, cox
Distributed Systemslamport, kleppmann, helland
Formal Methods / Verificationlamport, kleppmann
Concurrencypike, armstrong, lamport
Pythonhettinger
Performancegregg, osmani, muratori
Architecture / Patternsfowler, martin, alexander
TDD / Testingbeck, freeman, hughes
DDDevans, vernon
Event Sourcing / CQRSyoung
Legacy / Refactoringfeathers, fowler
Microservicesnewman
Rails / Monolithdhh
DevOps / Observabilityhightower, majors, humble, forsgren
REST / HTTPfielding
API / Library Designbloch
Product Managementcagan, jobs
UX / Design Psychologynorman
Design Leadershipzhuo
Startupsgraham, dhh
Databases / Data Evolutionpavlo, helland, sadalage, young, kleppmann
Reliability / Stabilitynygard, armstrong, cook
Team / Org Designskelton-pais, forsgren, zhuo
Accessibilitysoueidan
Simplicity / Data-Orientedhickey
Category Theory / FPmilewski
FP in JS (pragmatic)simpson
State Machineskhorshid
AI / LLMswillison, karpathy, huyen, cherny, osmani
Note Systems / Memorymatuschak
Interactive Explanationvictor, case
Malleable / End-User SWinkandswitch, litt, kleppmann
Knowledge Gardensappleton, brander
Computing Visionarieskay, papert
Decisions / Behaviorkahneman, klein, fogg, norman, simon
Systems Thinkingmeadows, deming, snowden
Quality / Managementdeming
Strategyboyd, rumelt, goldratt
Constraints / Flowgoldratt
Communicationtufte, orwell, minto, jobs
Legibility / Emergent Ordergeertz, jacobs, scott
Incentives / Metrics / Commonsgoodhart, ostrom
Epistemology / Languagepopper, kuhn, wittgenstein
Organizational Failure / Safetyperrow, vaughan, reason, cook
Evolution / Complexitykauffman, dawkins
Learningvygotsky, bruner
Securityschneier, shostack

Boundaries

Consult surfaces knowledge — it does not execute or decide. The caller owns the decision; expert perspectives are understanding to learn from, not prescriptions to follow.

Repository
saadshahd/moo.md
Last updated
Created

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.