Skill Catalog — Domain Authority and Optimization Machinery for Case Resolution

Scope note. This catalog explains the skills across five families (MongoDB, psychology, writing, troubleshooting, and expertise) that together support automated and human-assisted MongoDB/Atlas case resolution. “Expertise” is covered in both senses: the domain-authority skills (the deep *-expert hubs) and the expertise-engineering machinery that captures, teaches, measures, and optimizes expertise. A later section explains the optimization-pipeline machinery that connects them. That machinery is also the subject of the companion whitepaper, “Compounding Expertise — An Iterative Skill-Optimization Pipeline.”

How to read this. The skill tree is organized hub-and-spoke: a hub skill routes to on-demand reference files (spokes). When an entry says “hub,” it is the routing entry point; its spokes load only when a task matches. Skill names in code font are the exact identifiers. Reference counts in parentheses reflect the skill tree when this catalog was drafted and drift as hubs are rebuilt.

1. MongoDB & Atlas — domain authority

These are the knowledge bases an answer is built from. They are split by plane (data vs. platform vs. operations) and by mode (distilled guidance vs. live diagnostics vs. raw lookup), so a task loads only the surface it needs.

2. Psychology — human factors

A correct diagnosis still fails if the delivery triggers resistance, or if a human over- or under-trusts the AI’s output. These skills cover the human side of resolution.

3. Writing — communication and synthesis

A resolution is only as good as the artifact that carries it. This family covers drafting and, critically for the pipeline, the critique loops that bring an artifact to publication quality.

4. Troubleshooting — diagnostic reasoning

Domain knowledge tells you what is true; diagnostic reasoning tells you how to find the fault. This family covers both the live act and the pedagogy and evaluation of fault-finding.

5. Expertise — both layers

Per scope, “expertise” spans two layers: (5a) the domain authorities that hold expertise, and (5b) the expertise-engineering skills that build, teach, measure, and tune it.

5a. Domain authorities (the experts)

The *-expert hubs and uber-mongodb-diagnostician from §1, plus the diagnostic-reasoning skills from §4. These are “expertise” in the everyday sense: the skills that know the most about a domain. They are the inputs the pipeline optimizes and composes.

5b. Expertise engineering (capture → teach → measure → optimize)

This layer is what makes the domain authorities good and keeps them good. It is the part most people miss, and it is where the pipeline’s advantage comes from.

Capture — elicit expert knowledge

Teach — encode expertise into instruction

Measure — quantify expertise and learning

Optimize — build and tune the skills, prompts, and code themselves (the meta layer)

6. The optimization-pipeline machinery (connective tissue)

The skills above are components. A small set of shared mechanisms connects them into a system whose predictive accuracy can be measured. The companion whitepaper covers these mechanisms in depth; they are catalogued here because they are themselves skills and artifacts.

The shared convergence-and-severity model. One canonical internal reference defines a severity ladder (Blocking/Critical → Major → Medium → Minor → Nit; fix everything Medium-and-above), 7 convergence exit conditions (clean / no-progress / content-cycling / stable-rewrite / loop-instability / iteration-cap / budget), iteration caps (prompts 5; skills and documents 3, raised to 5 if Medium+ findings dropped ≥50%), and a blind re-audit gate (a fresh-context subagent that re-audits the final artifact with no access to the findings history before “clean” can be declared). Every optimizer below is an instance of this one loop.

The deep-optimizer family is the same loop applied to different artifact types:

• prompt-deep-optimizer: prompts (16 passes, 5 parallel bundles)
• code-deep-optimizer: source code (18 passes; build/lint/test verification)
• document-critique / ddo: prose (passes 0–14)
• design-deep-optimizer: UI/visual designs (11 passes); not part of this case-resolution pipeline, listed for sibling-family completeness
• skill-optimizer: skills themselves

The acquisition and evaluation ends:

• concept-family-explorer: finds and fills knowledge gaps until a concept family saturates (front of the pipeline)
• diagnosis-methodology-backtest: blind, parallel, multi-agent evaluation against ground truth (back of the pipeline)
• eval-driven-development: the error-analysis discipline that the backtest operationalizes
• solve-case: the runtime orchestrator that composes the optimized components on a live case

The evidence so far

On a blind panel of 244 real support cases from one large enterprise customer (Customer A here), the skill-knowledge strategy scored as shown below. That strategy is optimized mongodb-* skill expertise, the input the pipeline produces. The predictor never saw the resolution, and the predictor was never the grader.

Confusion matrix: 158 Correct, 38 Partial, 0 Wrong, 48 Unverifiable. The skill-knowledge strategy beat both an authored-flowchart bundle and a documented-flowchart corpus; combining all three (Best-of-3, where any Correct wins) added only 7 correct cases (165 versus 158; 74.0% versus 72.5% raw accuracy). The skill-knowledge strategy alone therefore accounted for 158 of those 165 correct cases, about 96%.

Read these numbers with the author’s caveats. Most ground-truth resolutions in this panel are autoclose fallbacks, where the recorded resolution echoes the customer’s first message: 188 of 244 in the author’s count, with roughly 8 carrying substantive engineer narrative. The scores therefore measure plausibility against thin transcripts, not verified diagnostic accuracy. The zero-Wrong result is partly structural in the grading rules. The ranking also depends on the rubric. The calibrated rubric keeps autoclose-fallback resolutions gradable when a prediction preserves the case’s domain noun-phrase, which rewards a strategy that mirrors the customer’s prompt, and on a stricter 20-case seed panel the skill-knowledge strategy placed third of four. “Skill knowledge wins” is rubric-conditional, not absolute. Finally, no un-optimized baseline was run on this panel, so the scores are absolute performance, not a measured lift from the optimization pipeline; the author names that baseline as future work.

Source: the author’s internal evaluation writeup and comparative review for this panel.

7. How the families compose for case resolution

A live case flows through the families in order:

1. Troubleshooting chooses the diagnostic surface and gathers evidence (atlas-diagnostics-expert, software-engineering-patterns).
2. MongoDB domain authority generates and ranks root-cause hypotheses with citations (uber-mongodb-diagnostician over the 66-part reference; mongodb-kb and mongodb-docset-lookup for grounding).
3. Writing turns the cited analysis into a customer reply and an internal readout (content-and-marketing-writing, technical-writing-craft, document-critique/ddo, kill-the-AI-ism).
4. Psychology ensures the reply repairs trust and avoids reactance, and that humans calibrate their reliance on the AI hypothesis (applied-psychology, customer-comms-psychologist).
5. Expertise engineering runs underneath all of it: concept-family-explorer finds missing knowledge, the deep-optimizers tune every skill/prompt/document to production quality, and diagnosis-methodology-backtest measures how well the resulting diagnosis strategy predicts root causes, feeding errors back into the next optimization cycle.

solve-case is the orchestrator that runs steps 1–4 on a single case; the expertise-engineering layer (step 5) is the offline loop that makes steps 1–4 progressively better. The companion whitepaper argues that this composition (five complementary skillsets, each driven to convergence by one shared optimization loop and validated by one blind backtest) is what produces the measured accuracy above. No baseline run isolates that effect (see the caveats in §6).