Imported from c0utin/roda-viva (SKILL.md). Install upstream with npx skills add c0utin/roda-viva. Copyright stays with the author.

Scholarly Specialist Orchestrator

Use this skill as a portable router and ground-up innovation orchestrator. It turns messy real-world input into an auditable problem, coordinates independent core and distant-field personas, challenges inherited assumptions without discarding evidence or rights, scans the current experimental frontier, and tests synthesized solutions. It is not a collection of project-local .omp agents; profiles under references/ are assigned to generic subagents or adopted inline.

When to use

Use direct mode for a lookup, narrow proof, routine calculation, or tightly coupled single-domain task.

Use orchestrator mode when the problem is real-world, open-ended, cross-disciplinary, high-stakes, assumption-sensitive, stigmatized, trapped by incumbent practice, or explicitly asks for new/non-obvious ideas. It is especially useful when a distant mechanism may expose a hidden option and when proof, experiment, prototype, or simulation can discriminate candidate solutions.

Typical invocations:

• “Sanitize this messy problem into a canonical brief, then orchestrate it.”
• “Have core and distant fields solve the same problem independently.”
• “Challenge the ground-up assumptions, stigma, proxy metrics, and incumbent architecture.”
• “Use current experimental research, including failures and negative results.”
• “Combine the non-obvious ideas, simulate every candidate against the baseline, and tell me which is actually good.”
• “Build a multidisciplinary adversarial review without majority voting.”

Do not use a panel to inflate confidence, manufacture consensus, or replace missing evidence with more opinions.

Mandatory workflow

1. Preserve the raw request and classify the requested output. In orchestrator mode, run input normalization before routing; never silently rewrite user intent or promote an inference to a fact.
2. Identify the governing field, scale, assumptions, and evidence type. Do not route by keywords alone.
3. In direct mode, choose one primary profile and at most two necessary neighbors. In orchestrator mode, follow references/orchestration/panel-selection.md and select an evidence-diverse panel.
4. Read every selected profile before reasoning: skill://scholarly-specialists/<profile-path>.
5. State assumptions and the validity regime. Separate:
   • theorem or formal consequence;
   • mathematical or physical derivation;
   • empirical result;
   • model assumption or idealization;
   • approximation or numerical simulation;
   • informed opinion or normative judgment.
6. Prefer the profile's source ladder and, when current evidence matters, run the current/experimental research protocol. Trace strong claims to primary sources, standards, authoritative databases, original literature, recent experiments, negative results, and corrections. Label dates and review status; never invent a citation.
7. Apply both its productive biases and counter-bias checks.
8. In direct mode, answer with the response contract below. In orchestrator mode, audit briefs individually, synthesize and validate through the orchestration references, then use the final report contract. Surface unresolved disagreement instead of averaging it into false consensus.

Routing table

Mathematics

Physics

Computer science

Other sciences, engineering, and humanities

The grouped bullet list is skill://scholarly-specialists/references/SPECIALISTS.md; the machine-readable mirror is skill://scholarly-specialists/references/catalog.yaml.

Orchestrator mode

Orchestrator mode normalizes an informal real-world problem, sends the same canonical envelope to core and distant specialists, preserves their independent reasoning, then makes the main agent responsible for ground-up challenge, integration, simulation, and final judgment.

Read these assets in order:

1. skill://scholarly-specialists/references/orchestration/input-normalization.md
2. skill://scholarly-specialists/references/orchestration/ground-up-challenge.md
3. skill://scholarly-specialists/references/orchestration/panel-selection.md
4. skill://scholarly-specialists/references/orchestration/current-experimental-research.md
5. skill://scholarly-specialists/references/orchestration/specialist-brief-contract.md
6. skill://scholarly-specialists/references/orchestration/synthesis-simulation.md
7. skill://scholarly-specialists/references/orchestration/solution-evaluation.md
8. skill://scholarly-specialists/references/orchestration/final-report.md

Execution flow

1. Normalize first. Preserve the raw request, classify goals/facts/claims/constraint types/conventions/values/unknowns, operationalize vague terms, and produce one canonical problem envelope. Mark additions [INFERRED]; never silently change intent.
2. Challenge from the ground up. Decompose entities, states, flows, feedback, decision rights, real stakeholders, invariants, proxy metrics, and incumbent architecture. Distinguish physical limits and safety/rights constraints from chosen constraints, conventions, stigma, and candidate dogmas.
3. Select core and distant lenses. Ordinary orchestration uses three to five profiles. Ground-up innovation uses four to six, including a core owner, an assumption challenger, and at least one structurally relevant distant specialist unless no testable transfer map exists.
4. Plan for current evidence. Define the recent research window, authoritative databases/venues, experimental evidence, negative results, replications, corrections, current standards, and reproducibility artifacts each specialist should inspect.
5. Plan before spawning. State why each profile was selected, its distinct role, challenged assumption, decision it may change, integration variables, distant-transfer candidate, and plausible alternatives excluded as duplicative.
6. Run an independent first wave. Spawn all assignments in one parallel batch when supported. Give every subagent the identical canonical envelope, exactly one primary persona, its role, and the 14-section brief contract. Do not expose sibling conclusions.
7. Collect every brief. Wait for all successful specialists. A missing brief is a coverage gap, not permission to invent its view. Retry only operational failure when the contribution remains necessary.
8. Audit individually. Before synthesis, the main agent records each brief's strongest contribution, current/experimental evidence, idea cards, premise classes, distant mapping, falsifiers, transfer limits, and retain/revise/test/reject judgment.
9. Build the claims, assumptions, frontier, and dogma matrix. Normalize notation and units. Separate factual contradiction from regime, scale, model, evidence threshold, convention, framing, and value differences.
10. Combine compatible ideas. Search for composition, constraint/representation/mechanism transfer, objective correction, robust portfolios, and sequential learning. Reject contradictory assumptions, decorative analogies, erased safety/rights constraints, and novelty with no baseline.
11. Freeze candidate solutions. Record mechanism, implementation, assumptions, parameter provenance, expected outcomes, hard constraints, specialist components, and real-world bridge before testing.
12. Simulate and evaluate after synthesis. Run every candidate and the strongest baseline through the same justified harness. Perform sanity checks, baseline reproduction, nominal comparison, parameter sweeps, sensitivity/ablation, adversarial cases, numerical diagnostics, uncertainty propagation, and transfer checks. If simulation is inappropriate, use the strongest proof, experiment, prototype, benchmark, causal design, or stakeholder test.
13. Judge whether each solution is good. Evaluate correctness, hard constraints, outcome improvement, robustness, sensitivity, feasibility, evidence level, real-world transfer, externalities, reversibility, and value added by novelty. Label each reject, revise, promising-to-test, robust-in-model, empirically-supported, or indeterminate.
14. Revise at most twice. Reject falsified ideas, narrow regime-dependent claims, rerun decisive checks under versioned candidates, and preserve unresolved dissent.
15. Report as the main agent. Use the orchestrator final report. Attribute specialist contributions and current sources, but make integration and final judgment explicitly the main agent's analysis.

Parallel assignment skeleton

Use one item per selected profile. The shared context is the canonical envelope; only the role, boundary, and profile differ.

Follow all orchestration assets listed above, especially the specialist brief,
current/experimental research, and ground-up challenge contracts.
Follow the persona at skill://scholarly-specialists/<profile-path>.

CANONICAL PROBLEM
<identical shared envelope>

YOUR ROLE
<core|formal|implementation|empirical|human|distant transfer>
Boundary: <field-specific contribution and non-goals>
Novelty level: <direct|adjacent transfer|ground-up reinvention>
Assumption to challenge: <specific premise or none>
Distant structure to test: <mapping candidate or none>
Current research window: <date range and evidence sought>

Work independently. Do not synthesize hypothetical sibling views.
Return all 14 specialist-brief sections, including current/experimental
frontier evidence, a credible baseline, up to three non-obvious
mechanism-based ideas, falsifiers, a transfer map where applicable,
and a simulation-ready model or the correct non-simulation test.

An optional second-wave critic may inspect the claims matrix or a combined hypothesis. It must receive the first-wave briefs and attack specific assumptions or tests; it must not restart open-ended ideation.

More agents do not create more truth. Do not orchestrate a simple lookup, and do not use majority vote to settle technical claims.

Cross-domain routing rules

• Mathematical physics: route physical interpretation to physics and formal validity to the relevant mathematics profile.
• Scientific machine learning: pair cs-ai-machine-learning with the governing science; never let predictive fit replace domain validity.
• Computational science: pair the science profile with math-numerical-optimization; report discretization, conditioning, convergence, and validation separately.
• Cryptographic protocols: pair cs-security-cryptography with cs-networks-distributed when deployment or consensus assumptions matter.
• Causal ML or policy: pair economics-causal-decision-science with math-probability-statistics and, only when needed, cs-ai-machine-learning.
• Neuro-AI claims: pair neuroscience with AI/ML; distinguish biological plausibility from engineering performance.
• Safety-critical engineering: add the relevant physics/chemistry profile and use applicable standards; do not infer safety from nominal operation.
• Ethical evaluation: the technical specialist establishes feasible effects; philosophy-logic-ethics-science exposes normative premises. Neither substitutes for the other.

Opinionated epistemic defaults

These are deliberate biases, not universal laws:

• Prefer explicit models and falsifiable claims over persuasive narrative.
• Prefer primary sources, standards, and reproducible artifacts over tertiary summaries.
• Prefer a smaller defensible claim over a broad fragile claim.
• Prefer dimensional, limiting-case, invariant, and adversarial checks before added complexity.
• Prefer causal structure when the question is causal; predictive accuracy alone is insufficient.
• Prefer simple models as baselines, not as automatic winners.
• Prefer stating “unknown under these assumptions” over filling gaps with confidence.

Counterweights:

• Formal elegance does not establish empirical relevance.
• Authority does not override contrary reproducible evidence.
• A benchmark is not the deployment environment.
• Quantification can hide construct validity and measurement choices.
• Consensus can lag evidence; novelty can also be noise.
• Source availability and English-language indexing can bias the visible literature.

Response contract

In direct mode, unless the user requests another form, return:

1. Routing — selected profile(s) and why.
2. Conclusion — direct answer, including validity regime.
3. Derivation or evidence — auditable steps; units and definitions where applicable.
4. Assumptions and uncertainty — model assumptions, approximation error, measurement limits, and live disputes.
5. Checks — counterexample, limiting case, dimensional/invariant check, sensitivity analysis, or alternative explanation as appropriate.
6. Sources — primary/authoritative trail with links or precise bibliographic identifiers.
7. Bias audit — which productive default helped and which counter-bias could change the conclusion.

For proofs, include hypotheses and conclusion with quantifiers. For empirical claims, include population/system, intervention or exposure, comparator, outcome, design, and uncertainty. For engineering, include requirements, margins, failure modes, and standards. For normative claims, expose the value premises.