mixture-of-experts

Mixture of Experts (MoE) Audit

The Mixture of Experts pattern is a powerful critical-thinking framework. It prevents tunnel vision by forcing multiple independent "expert personas" to analyze a single topic from completely different angles, before cross-referencing their findings.

It can be applied to literally anything: a codebase, a feature plan, a deployment process, or a repository's governance skills.

When to use

• "Review this architecture plan using a mixture of experts"
• "Do we have skills with duplicated intent?"
• "Audit this deployment script for security and performance"
• You encounter a complex design decision and need rigorous, multi-faceted critique.

Workflow

1. Identify the Topic Understand what the user wants to audit (e.g. "repo skills overlap", "new caching architecture", "release process").

2. Define Expert Personas Invent 2-3 specialized experts whose lenses are highly relevant but orthogonal to the topic. Use more than 3 only when the user explicitly asks for broad subagent coverage or when the domains are truly independent; default maximum is 4. Do not spawn agents to restate the parent plan. For each expert, write a short ownership contract:

   • Role: the critical lens.
   • Scope: what evidence or subsystem they inspect.
   • Out of scope: what they must not decide or edit.
   • Expected output: findings, contradiction, or artifact recommendation.
   • Fallback: what to do if the lens times out or returns partial evidence.
   • Integration contract: exact docs, checks, skills, or code surfaces their finding would affect.

   Examples:

   • For repo governance: "Codebase Auditor", "Skills Analyst"
   • For a system architecture: "Security Specialist", "Scalability Engineer", "Cost Analyst"
   • For a frontend component: "Accessibility Auditor", "Performance Expert"
   • For product claims or external platform support: "Evidence / Validation QA". This lens asks what claim is being made, what evidence proves exactly that claim, what validation or source freshness is required, and what remains a non-claim. Use it when a thread touches platform support, generated assets, cross-repo cleanup, benchmark proof, public compatibility, or external APIs.
   • For evidence archives, PDSA loops, dogfood notes, templates, and proof packets: "Evidence / Retention QA". This lens asks whether the artifact is an ADR, current ledger, historical evidence, public reproducibility card, template, check/tool candidate, or deletion candidate; whether it is for maintainer routing, current status, historical provenance, or public audit; what claim it protects; whether it has status/type/limitations/non-claims; and what next disposition prevents stale-proof drift.
   • For E2E Execution & Evals (Dogfooding): "Harness QA Expert". When a workflow, toolchain, typed action, or benchmark loop changes, include a Harness QA lens. Use a subagent when available; otherwise run the lens sequentially and label it. If the change claims H2+ maturity or changes action/benchmark behavior, capture a review artifact in the final or PR summary: scope, repo used, commands/actions exercised, evidence level reached, and remaining non-proof. Docs-only alignment can use softer wording and does not need a separate artifact unless it changes a readiness claim.
   • For stewardship, tools, harnesses, or growing products: "Generational Architecture Skeptic". This lens asks what can be deleted, collapsed, kept native, moved to docs/FAQ, extracted to a public API, generated from schema, or promoted to harness proof. It must ask whether the design helps the next repo, next agent, next version, and next maintainer, or instead creates path magic, one-consumer hacks, overclaims, "full adoption" drift, or tool dependency loops. The clean promise is: Skill Steward helps a repo notice when it has outgrown its current shape, choose the smallest next layer, and prove the change reduces future work.
   • For stalled PDSA, repeated blockers, evidence loops, or repo pain: "Loop Compression / Pain Tutor". This lens asks what original user goal is being delayed, which owner can be fixed now, which native gate proves the fix, which surface can disappear, and whether the pain should become an error message, FAQ row, test, schema, script, action candidate, or current-ledger update instead of another evidence artifact.

3. Spawn Subagents Use the available subagent capability for the current host to launch these experts independently. Give them explicit prompts to audit the target topic through their specific lens. Keep read-only lenses read-only unless the user explicitly asked for implementation. If no subagent tool is available, run the expert lenses sequentially and label the output as a non-parallel MoE.

4. Cross-reference Findings Wait for all subagents to report back, or stop at the declared fallback point. Synthesize their independent critiques. Look for structural contradictions, missed edge cases, maintenance traps, and (in the case of repo skills) duplicated intent. If a lens times out or returns unusable evidence, label it as missing_lens, partial_lens, timed_out_lens, or superseded_lens; either retry, continue with downgraded confidence, or state that the missing lens blocks a stronger claim. Include a compact lens-status summary whenever the MoE result affects implementation, evidence, or a readiness claim.