# Worked Example: mining reale del 2026-07-10 su S:\mcp-servers

Caso di studio reale (non illustrativo): il mining che ha originato questa stessa skill, eseguito il 2026-07-10 sul repository S:\mcp-servers.

## Contesto

**Repository**: S:\mcp-servers (framework aziendale skill/hook/MCP per agenti AI), 18 skill esistenti al momento del mining.
**Fonti disponibili**: Codex CLI, Claude Code, Cursor, Antigravity, Copilot (tramite un tool `analytics-mcp-server` con conteggi aggregati multi-fonte).
**Obiettivo**: individuare, con evidenze verificabili, casi d'uso ricorrenti e conclusi con successo nelle sessioni storiche che giustificassero nuove skill o enhancement di skill esistenti.

## Passo 0: inventario skill

Lette tutte le 18 `SKILL.md` esistenti, annotando scopo, MCP/tool usati, presenza di `evals/`/`references/`, sovrapposizioni sospette. Emerso subito un gap: 4 skill ad alto uso (`mcp-database-expert`, `mcp-browser-automation`, `mcp-analytics-operator`, `mcp-runtime-integrator`) non avevano alcun eval.

## Passo 1: diffidare del conteggio aggregato

Il tool `analytics-mcp-server` riportava inizialmente "~1097 sessioni" multi-fonte (Codex 902, Claude 145, Cursor 25, Copilot 20, Antigravity 5). Verificando sul filesystem reale:
- Codex CLI: `session_index.jsonl` conteneva realmente **148** righe/thread, con **183** file di trascrizione grezzi (`rollout-<timestamp>-<id>.jsonl`) — la differenza tra 148 e 902 era dovuta al fatto che il conteggio aggregato includeva sub-agent/worker paralleli come "sessioni" separate.
- Claude Code: **150** file `.jsonl` reali su 9 cartelle progetto, di cui solo 16 erano sessioni "top-level" dell'utente e 134 erano trascrizioni di sub-agent lanciati da un orchestratore.

Questa verifica ha evitato di sovrastimare il volume reale da campionare e ha chiarito che molte "sessioni" del conteggio aggregato non erano thread utente indipendenti.

## Passo 2: campionamento per cluster

**Codex CLI**: letto per intero l'indice `session_index.jsonl` (148 titoli, economico), raggruppati per tema. Cluster più rilevanti: implementazione ticket su un portale claim B2C React/TS (~18 thread, sempre concluso con successo, pattern: spec ticket incollata in chat -> pianificazione con sub-agent low-cost -> implementazione -> aggiornamento obbligatorio della documentazione di progetto -> gate typecheck+build); bug ricorrenti di rendering/scroll/drag su una grid proprietaria (Blazor+DevExpress, denominata internamente "TesiGrid"/"SuperPlanning") osservati su più date diverse, mai risolti strutturalmente; pattern di onboarding regole agenti (AGENTS.md/CLAUDE.md) su un progetto client.

**Claude Code**: analizzate le 9 cartelle progetto, con priorità sul progetto del framework stesso (dove è emerso che una sessione precedente aveva già esteso l'installer/analytics a nuovi client AI, concludendosi con la creazione della skill `mcp-runtime-integrator` — prova diretta che il ciclo "lavoro reale -> skill" funziona) e su due progetti client con lo stesso identico pattern: audit read-only di un sistema legacy (DB + funzionalità + UI) tramite fan-out di decine di sub-agent per dominio, propedeutico a una futura riscrittura. Trovate anche **4 sessioni indipendenti**, nello stesso progetto, sullo stesso identico sintomo grid (flicker, scrollbar, drag su virtualizzazione, glitch al primo load) già visto lato Codex — convergenza multi-fonte su un sistema reale, segnale molto forte.

**Cursor/Copilot/Antigravity**: volume basso (rispettivamente ~3 sessioni sostanziali, dati non recuperabili localmente, e praticamente nessun dato — solo 5 sessioni note via analytics aggregato). Trattati come nota, non come fonte di pattern.

## Passo 3: scoperta di un'analisi precedente

Durante il mining Codex è emerso che l'utente aveva già eseguito, il giorno prima (2026-07-09/10), una sessione con lo stesso identico obiettivo, usando `mcp-master-orchestrator` con sub-agent dedicati. Quella sessione aveva prodotto un piano a 4 ondate con candidati simili, mai eseguito oltre la fase di pianificazione. Questo piano precedente è stato trattato come **input aggiuntivo da validare**, non accettato acriticamente: alcuni suoi candidati sono stati confermati dal campionamento indipendente odierno, altri sono stati ridimensionati per evidenza insufficiente.

## Passo 4: cross-reference e matrice finale

Per ogni cluster, verifica esplicita contro l'inventario skill prima di proporre "nuovo". Risultato (sintetico, si veda `docs/mcp-skills-candidate-matrix-2026-07-10.md` nel repository per il dettaglio completo):

| Candidato | Tipo | Evidenza | Decisione |
|---|---|---|---|
| Debug grid UI proprietaria (rendering/scroll/drag) | Nuova skill | Convergenza Codex + Claude Code, 4+ sessioni indipendenti sullo stesso sistema reale | **ADOTTATA** (`mcp-grid-ui-debugger`) |
| Implementazione da spec ticket con doc-sync e build gate | Enhancement | ~18 thread Codex, stesso progetto, sempre concluso con successo | **ENHANCE** skill correlazione ticket/commit esistente |
| Audit documentale leggendo il codice sorgente invece di altra doc | Enhancement | Confermato indipendentemente da due fonti (mining odierno + piano del giorno prima) | **ENHANCE** skill documentale esistente |
| Audit legacy pre-migrazione (fan-out sub-agent read-only per dominio) | Enhancement | 2 progetti client indipendenti, stesso schema | **ENHANCE** skill di analisi tecnica esistente |
| Onboarding regole agenti AI su nuovo progetto client | Nuova skill (contestata) | Segnale misto: forte per una fonte, sotto soglia per l'altra (1 solo progetto con evidenza diretta) | **BACKLOG/WATCH** — non adottata, serve più evidenza |
| Checklist business-rule/document sync su stack legacy specifico | Enhancement | 1 solo caso, esito non confermato | **BACKLOG/WATCH** — sotto soglia minima di 2 casi indipendenti |

## Limiti del campionamento dichiarati

- Non tutte le sessioni sono state lette per intero: per fonti ad alto volume, letti solo indice/titoli + primo e ultimo messaggio delle sessioni campionate per cluster.
- Alcuni progetti con decine di sub-agent (es. 44 sub-agent su un audit legacy) sono stati campionati parzialmente (2-3 sub-agent), non esaustivamente.
- Cursor/Antigravity/Copilot trattati con evidenza minima per mancanza di dati locali sufficienti.

## Lezione principale

Il conteggio aggregato di un tool di analytics multi-fonte non va mai usato come numero definitivo di "sessioni reali": va sempre verificato sul filesystem, perché può includere sub-agent/worker come voci separate e gonfiare il volume percepito di un ordine di grandezza.