| name | edtech-pilot-design |
| description | Usa quando occorre progettare uno studio pilota o quasi-sperimentale in ambito Ed-Tech (AI a scuola, HCI per l'apprendimento) con approccio mixed-methods. Non usare per revisioni sistematiche, studi osservazionali puri o studi già avviati. |
Progettazione Studio Pilota Ed-Tech (Mixed-Methods)
Overview
Questa skill guida la progettazione rigorosa di studi pilota o quasi-sperimentali in ambito Ed-Tech (AI in classe, HCI per l'apprendimento). Produce un Protocollo di Ricerca strutturato, pronto per essere sottomesso, condiviso con le scuole o usato come base per un paper.
Cos'è un pilot study — L'obiettivo primario è la fattibilità (feasibility): verificare che gli strumenti funzionino, stimare l'effect size per dimensionare lo studio completo, rilevare problemi procedurali. L'efficacia dell'intervento è un obiettivo secondario nel pilot.
Tipo di skill: Rigida — segui le fasi nell'ordine indicato senza saltarne alcuna.
Regola d'oro: Non passare alla fase successiva senza conferma esplicita dell'utente. Conta come conferma esplicita: una risposta affermativa chiara ("sì", "ok", "procedi", "confermo"), oppure la risposta completa alle domande della fase. Non conta: silenzio, risposta parziale, o un semplice "capito". Se l'utente vuole saltare una fase, avvisalo che il protocollo risulterà incompleto, documenta la lacuna nel file e prosegui secondo la sua scelta.
Avvio
Contesto dello studio (prima di tutto)
Prima di qualsiasi altra verifica, identifica il contesto istituzionale:
"Lo studio che vuoi progettare è rivolto a: (a) scuola secondaria italiana, (b) università, o (c) formazione professionale / altro contesto?"
- Scuola secondaria → applica tutte le raccomandazioni sul calendario MIUR, consenso informato dei genitori (GDPR minori), autorizzazione del Dirigente Scolastico.
- Università → adatta: niente consenso genitori, calendario accademico, maggiore probabilità di randomizzazione, soggetti adulti.
- Altro → chiedi dettagli prima di procedere.
Dichiara esplicitamente all'utente: "Contesto identificato: [contesto scelto]. Adatto le raccomandazioni di conseguenza."
Ripresa di sessione (priorità assoluta)
Prima ancora di presentare le fasi, verifica se esistono già file prodotti da sessioni precedenti:
- Se
protocollo_ricerca.md esiste → leggi solo il Blocco STATO nelle prime righe (non l'intero file). Dichiara esplicitamente: "Ho trovato protocollo_ricerca.md. Ripristino il contesto dal Blocco STATO."
- Identifica la fase corrente dal Blocco STATO e chiedi: "Eravamo alla Fase [N]. Confermi di voler proseguire da lì?"
- Leggi le sezioni complete del file solo quando la fase corrispondente è in esecuzione.
- Non riformulare mai decisioni già prese nelle fasi precedenti senza esplicita richiesta dell'utente
Controlla se esiste un report PRISMA (prodotto dalla skill prisma-review o creato manualmente):
- Cerca prima il file standard
prisma_synthesis.md nella cartella corrente.
- Se non esiste, chiedi esplicitamente: "Hai già un report di revisione sistematica (PRISMA o simile)? Se sì, indicami il nome o il percorso del file."
- Accetta qualsiasi nome di file (es.
review_prisma_definitiva.md, prisma_log.md, sintesi_metodologica.md, ecc.).
- Se l'utente fornisce un percorso → leggilo integralmente e trattalo come se fosse
prisma_synthesis.md.
- Se il file esiste (qualunque nome) → leggilo subito e estrai automaticamente le sezioni "OUTPUT PER PILOT STUDY" o sezioni equivalenti:
- Effect size aggregati → pre-compila il valore
d per la power analysis in Fase 2d
- Framework teorici dominanti → pre-compila la sezione Framework Teorico in Fase 1
- Strumenti di misura più usati → pre-compila la scelta strumenti in Fase 3
- RQ non ancora investigate → suggeriscile come domande di ricerca candidate in Fase 1
- Gap di popolazione → inseriscilo nella motivazione del pilot in Fase 1
- Durata tipica degli interventi → usa il range come vincolo realistico in Fase 4
- Comunica all'utente: "Ho letto il report PRISMA (
[nome file]). Ho pre-compilato i campi bibliografici nelle fasi pertinenti. Vuoi procedere con questi valori o preferisci inserirne di diversi?"
Se non esiste protocollo_ricerca.md, dichiara esplicitamente: "Nessun file di sessione precedente trovato. Parto dalla Fase 1."
Ingresso alternativo — dati già raccolti: prima di procedere, chiedi:
"Hai già raccolto i dati, o sei ancora in fase di progettazione?"
- Progettazione → segui il workflow completo dalla Fase 1.
- Dati già raccolti → salta alle Fasi già coperte e vai direttamente alla Fase 5 (Piano di Analisi) o alla Fase 6 (Results Paper). Avvisa l'utente: "Poiché i dati sono già stati raccolti, salto le fasi di progettazione. Iniziamo dalla Fase [N]."
Controlla se esiste un database RAG (creato dalla skill hybrid-rag durante una precedente prisma-review):
- Verifica se esiste
rag_db/ nella cartella di lavoro corrente.
- Se esiste → aggiorna il Blocco STATO con
RAG: sì e informa l'utente: "Trovato database RAG locale. Posso interrogarlo durante la progettazione per recuperare evidenze specifiche dalla letteratura."
- Quando si discutono framework, strumenti o ipotesi nelle fasi successive, suggerisci query mirate:
py hybrid_rag.py query "<costrutto>" --n 3
- Se
rag_db/ non esiste → RAG: no nel Blocco STATO; la progettazione si basa solo su prisma_synthesis.md.
Se non viene trovato nessun report PRISMA, chiedi:
"Hai già condotto una revisione sistematica della letteratura (es. con PRISMA) su questo tema?"
- Sì, ho un file → chiedi il percorso esatto e leggilo come descritto sopra (accetta qualsiasi nome)
- Sì, ma non ho il file → chiedi di condividere verbalmente i risultati chiave (gap, framework, strumenti, effect size medi)
- No, ma ho tempo per una revisione → suggerisci di invocare prima la skill
prisma-review tramite il tool Skill di Claude Code. Il pilot senza revisione sistematica rischia di replicare studi già esistenti o di scegliere strumenti non validati nel contesto.
- No, e non ho tempo per una PRISMA completa → proponi questa alternativa leggera: "Possiamo fare una scoping review rapida: 2-3 query mirate su Semantic Scholar + ERIC per identificare i 5-10 studi più citati sul tuo tema, estrarre framework e strumenti dominanti, e usare d=0.5 come effect size conservativo per la power analysis. Ci vogliono circa 2 ore invece di settimane. Vuoi procedere così?" Documenta nel protocollo che la revisione è una scoping review rapida (non una revisione sistematica PRISMA) e le implicazioni per la generalizzabilità.
Poi presenta all'utente:
- Le 6 fasi del processo (Framework → Design → Strumenti → Procedura → Analisi/Etica → Preprint)
- I 4 file che verranno prodotti progressivamente
- La distinzione tra obiettivi di fattibilità (pilot) e di efficacia (studio completo)
- La regola d'oro (una fase alla volta, con conferma esplicita)
Poi avvia la Fase 1 (o la fase successiva a quella già completata).
File generati dalla Skill
Crea tutti i file nella cartella di lavoro corrente. Se non è chiaro quale sia, chiedi all'utente di specificarla prima di procedere.
protocollo_ricerca.md — Il documento principale, aggiornato fase per fase. Struttura:
# Protocollo di Ricerca — [Titolo Studio]
<!-- Blocco STATO -->
## 1. Introduzione e Motivazione
## 2. Framework Teorico
## 3. Domande di Ricerca e Ipotesi
## 4. Partecipanti e Campione
## 5. Research Design
## 6. Variabili (IV, DV, Covariate)
## 7. Power Analysis
## 8. Procedura e Intervento
## 9. Piano di Analisi
## 10. Considerazioni Etiche
## 11. Riferimenti
strumenti_valutazione.md — Test, questionari validati e tracce per le interviste.timeline_pilota.md — Pianificazione settimanale (Gantt) delle attività sul campo.preprint_bozza.md — Bozza del paper scientifico in formato IMRAD, generata nella Fase 6.
Blocco STATO (ottimizzazione contesto)
All'inizio di ogni sessione e dopo ogni fase completata, mantieni aggiornato il Blocco STATO nelle prime righe di protocollo_ricerca.md:
<!-- STATO
Fase corrente: [N]
Contesto: [secondaria/università/altro]
Framework: [es. SRL/Zimmerman]
Design: [es. Explanatory Sequential, quasi-sperimentale]
N previsto: [es. 40, 2 classi]
PRISMA: [nome file o "nessuno"]
RAG: [sì/no — indica se esiste rag_db/ nella cartella di lavoro]
Dati raccolti: [sì/no]
Ultima modifica: [data]
-->
Alla ripresa di sessione: leggi solo il Blocco STATO (non l'intero file) per ripristinare il contesto in pochi token. Leggi le sezioni specifiche del file solo quando la fase corrispondente è in esecuzione.
Workflow Interattivo
FASE 1: Framework Iniziale e Ipotesi
Poni le domande una alla volta in modo conversazionale: aspetta la risposta dell'utente prima di passare alla successiva. Non elencare tutte e 4 insieme.
- Qual è l'Obiettivo Principale del pilota? Distingui: obiettivi di fattibilità (es. "verificare che il chatbot sia usabile da studenti liceali") da obiettivi di efficacia (es. "migliorare il punteggio MSLQ").
- Qual è il Framework Teorico di riferimento? (es. Self-Regulated Learning di Zimmerman, Self-Determination Theory, UTAUT/TAM per l'adozione tecnologica). Il framework guida la scelta degli strumenti e la formulazione delle ipotesi.
- Quali sono le Domande di Ricerca (RQ) e le Ipotesi (H1, H0)?
Se l'utente non sa come formularle, proponi questo template e adattalo insieme:
RQ1: [Variabile dipendente] degli studenti che usano [intervento] differisce
significativamente da quella del gruppo di controllo dopo [N] settimane?
H1: Il gruppo sperimentale mostrerà [outcome] significativamente maggiore
rispetto al gruppo di controllo (d ≥ [valore da PRISMA o 0.5]).
H0: Non vi è differenza significativa tra i gruppi (d ≈ 0).
Se è disponibile un report PRISMA, usa l'effect size medio come benchmark per d in H1.
- Qual è la Popolazione e il Campione previsto? (es. 2 classi di liceo, N=40)
Se l'utente ha una revisione PRISMA disponibile, estrai da essa e inserisci nel protocollo:
- Il gap identificato → diventa la motivazione del pilot (sezione Introduzione)
- Il framework teorico emergente dalla letteratura → integra o conferma la risposta al punto 2
- Le RQ non ancora indagate nella letteratura → affina le ipotesi del punto 3
- Le caratteristiche dei campioni degli studi inclusi → orienta la scelta del campione al punto 4
Azione: Leggi protocollo_ricerca.md se già esiste, poi aggiorna o crea le sezioni: Introduzione, Framework Teorico, Obiettivi, Ipotesi, Partecipanti. Se disponibile, aggiungi "Giustificazione dallo studio bibliografico" con i risultati PRISMA. Aggiorna il Blocco STATO con Fase corrente: 1 e i campi Framework e N previsto. Chiedi conferma esplicita prima di procedere.
FASE 2: Design della Ricerca (Mixed-Methods)
2a. Design Quantitativo
Suggerisci il design più adatto:
- Quasi-sperimentale Pre-test/Post-test con Gruppo di Controllo (se hai 2+ classi)
- Within-subjects (se hai una sola classe, con crossover o misure ripetute)
Avvisi metodologici:
- Non-equivalenza dei gruppi: In un quasi-esperimento i gruppi non sono assegnati casualmente. Verifica l'equivalenza baseline (t-test o ANCOVA sul pre-test) e riporta le covariate rilevanti.
- Testing effect: Il pre-test può sensibilizzare gli studenti e gonfiare il post-test. Valuta se usare un design Solomon a 4 gruppi se la contaminazione è probabile.
- Attrition differenziale: Il dropout non casuale tra i gruppi invalida i confronti. Pianifica come gestirlo (intento-a-trattare vs. per-protocol analysis) e registra i motivi di abbandono.
2b. Design Mixed-Methods — scegli il tipo
Non tutti i design MM sono equivalenti. Scegli in base alle tue domande di ricerca:
| Design | Logica | Quando usarlo |
|---|
| Convergent Parallel | Quant e qual raccolti in parallelo, integrati alla fine | Quando vuoi confrontare/triangolare le due fonti |
| Explanatory Sequential | Prima quant, poi qual per spiegare risultati inattesi | Quando vuoi capire perché i numeri dicono quello che dicono |
| Exploratory Sequential | Prima qual, poi quant per generalizzare | Quando il fenomeno è poco noto e vuoi costruire strumenti |
Per pilot su AI in classe, il design più comune è Explanatory Sequential.
2c. Variabili
- Variabile Indipendente: l'intervento Ed-Tech (es. uso del chatbot RAG)
- Variabili Dipendenti: gli outcome misurabili (es. punteggio MSLQ, voti)
- Covariate: sesso, background tecnologico, conoscenze pregresse
2d. Power Analysis
Per studi pilota, la power analysis serve principalmente a stimare l'effect size per lo studio completo, non a garantire potenza sufficiente nel pilot stesso:
- Riferimento orientativo pilota: N ≥ 30 per gruppo è una soglia di massima. Se il campione disponibile è inferiore (es. una sola classe, N=20), il pilot rimane valido ai fini della fattibilità — dichiara esplicitamente che la potenza statistica è insufficiente per conclusioni sull'efficacia e che il risultato principale è la stima dell'effect size per il dimensionamento futuro.
- Riporta l'effect size ottenuto nel pilot come input per il dimensionamento futuro.
Se è disponibile una revisione PRISMA, usa gli effect size degli studi inclusi come stima a priori più informata (es. d medio ponderato dalla meta-analisi) al posto del valore convenzionale d = 0.5. Questo rende la power analysis molto più solida e giustificabile ai reviewer.
Passi operativi G*Power (per stimare N nello studio completo):
- Apri G*Power →
F tests → ANOVA: Fixed effects, main effects and interactions (o t-tests → Means: Two independent groups per confronti semplici)
- Inserisci: Effect size d (es. 0.5 da PRISMA), α = .05, Power = .80, N groups = 2
- Clicca
Calculate → G*Power restituisce N per gruppo
- Riporta nel protocollo: "Per rilevare d = [X] con α = .05 e potenza = .80, lo studio completo richiede N = [Y] per gruppo (GPower 3.1)."*
- Confronta con il N del pilot: se il pilot ha meno del 50% del N richiesto, enfatizza che i risultati sono preliminari.
Chiedi all'utente se ha già un N previsto e valuta insieme se è sufficiente agli obiettivi.
Azione: Leggi protocollo_ricerca.md, poi aggiorna la sezione Research Design e Variabili mantenendo tutto il contenuto precedente. Aggiorna il Blocco STATO con Fase corrente: 2 e il campo Design. Chiedi conferma.
FASE 3: Strumenti e Misure
3a. Misure Quantitative — Questionari validati
| Costrutto | Strumento | Note |
|---|
| Self-Regulated Learning | MSLQ (Pintrich et al., 1991) | 81 item, 15 sottoscale; verifica validità sottoscale in italiano |
| Accettazione tecnologia | TAM (Davis, 1989) | 12 item, PU + PEU |
| Carico cognitivo | NASA-TLX (Hart & Staveland, 1988) | 6 dimensioni |
| Engagement | UWES-S (Schaufeli et al., 2002) | versione studenti |
| Atteggiamento verso l'AI | GAAIS (Schepman & Rodway, 2020) | scala generale fiducia/atteggiamento AI |
| Qualità interazione AI | AIQUE (Laupichler et al., 2023) | specifica per contesti educativi con AI — REGOLA: prima di usare qualsiasi strumento, verifica item, sottoscale e disponibilità versione italiana dalla fonte primaria. Non affidarsi mai alla memoria del modello per i dettagli psicometrici degli strumenti. |
Per ogni strumento scelto, ricorda di:
- Verificare l'affidabilità (α di Cronbach ≥ .70 atteso) sui tuoi dati
- Verificare la validità di costrutto (validità convergente e discriminante), non solo l'affidabilità
- Preferire versioni tradotte e validate in italiano quando disponibili
Se è disponibile una revisione PRISMA, controlla quali strumenti sono stati più usati negli studi inclusi: la convergenza su uno strumento in più studi è evidenza di fatto della sua adozione nel campo e facilita il confronto dei risultati con la letteratura esistente. Segnalalo all'utente come criterio aggiuntivo di scelta.
3b. Misure Qualitative
Stendi 4-5 domande aperte per interviste o focus group. Esempi:
- "Descrivi come hai usato l'AI nelle ultime settimane di studio."
- "Qual è stata la sfida maggiore nell'usare il chatbot per studiare?"
- "In che modo ti ha aiutato (o ostacolato) nel pianificare il tuo studio?"
Se il coding è svolto da più ricercatori, prevedi una procedura di inter-rater agreement (Cohen's κ ≥ .70).
3c. Learning Analytics (Opzionale)
Definisci quali dati di sistema raccogliere (non come estrarli tecnicamente). Esempi concreti:
- Numero di prompt inviati per sessione
- Durata media delle sessioni
- Frequenza di accesso (giorni attivi/settimana)
- Tipologia delle richieste (classificazione manuale o automatica a posteriori)
Azione: Crea strumenti_valutazione.md con questa struttura per ogni strumento scelto. Aggiorna il Blocco STATO con Fase corrente: 3.
# Strumenti di Valutazione — [Titolo Studio]
## Strumenti Quantitativi
### [Nome strumento] — [Costrutto misurato]
**Riferimento:** [Autore, Anno]
**N item / sottoscale:** [es. 81 item, 15 sottoscale]
**Tempo somministrazione:** [es. 15-20 min]
**Scala risposta:** [es. Likert 1-7]
**Scoring:** [es. media per sottoscala; punteggi alti = maggiore SRL]
**Versione italiana:** [disponibile / da verificare / non disponibile]
**Affidabilità attesa:** α di Cronbach ≥ .70 — verifica sui tuoi dati
**Note:** [es. adattamenti per minori, eventuali item eliminati]
---
## Traccia Interviste / Focus Group
**Domande principali:**
1. [Domanda aperta 1]
2. [Domanda aperta 2]
...
**Probe suggeriti:** [es. "Puoi farmi un esempio?", "Come ti sei sentito in quel momento?"]
**Durata prevista:** [es. 20-30 min per intervista]
**Metodo registrazione:** [audio con consenso / note scritte]
---
## Learning Analytics (se applicabile)
| Dato raccolto | Fonte (sistema) | Frequenza | Note privacy |
|---|---|---|---|
| [es. N prompt/sessione] | [log chatbot] | [per sessione] | [anonimizzato] |
Chiedi conferma.
FASE 4: Procedura e Intervento Pedagogico
Definisci cosa succede concretamente in classe:
-
Qual è il ruolo del docente durante l'intervento?
-
Quanto dura il pilota? Adatta al calendario scolastico italiano: evita periodi di scrutinio (febbraio, giugno), giornate di orientamento, o settimane precedenti agli esami. Un pilota realistico in una scuola secondaria italiana è tipicamente 3-5 settimane effettive, non 4 settimane continuative.
-
Cosa fa il gruppo di controllo mentre lo sperimentale usa la tecnologia? (Cruciale per la validità interna — se privare il gruppo di controllo è eticamente problematico, suggerisci un wait-list design: il gruppo di controllo riceve lo stesso intervento in un secondo momento, dopo la fine del pilot; tutti i partecipanti accedono alla tecnologia, ma in momenti diversi. Elimina il problema etico e consente un confronto pre/post all'interno del gruppo di controllo quando riceve l'intervento.)
-
Fidelity check: come si verifica che l'intervento sia somministrato come previsto? (es. log di accesso, checklist docente, osservazione in classe)
-
Vincoli burocratici italiani: ricorda all'utente di ottenere: autorizzazione del Dirigente Scolastico, consenso informato dei genitori (GDPR minori, D.Lgs. 196/2003 + Reg. EU 679/2016), eventuale notifica al DPO dell'istituto se si raccolgono dati personali digitali.
Azione aggiuntiva: chiedi: "Vuoi che generi un modulo di consenso informato per i genitori, conforme al GDPR?" Se sì, genera un documento con: intestazione istituto, descrizione dello studio in linguaggio non tecnico, dati raccolti e finalità, soggetto titolare del trattamento, diritti dell'interessato (art. 15-22 GDPR), firma genitore + data, firma ricercatore. Avvisa che il testo va verificato dal DPO o dal legale dell'istituto prima dell'uso.
Azione: Crea timeline_pilota.md con cronoprogramma:
- Settimana 1: Pre-test e Onboarding
- Settimane 2-3: Intervento (con fidelity check a metà percorso)
- Settimana 4: Post-test, Interviste/Focus Group
Aggiorna la procedura in protocollo_ricerca.md. Aggiorna il Blocco STATO con Fase corrente: 4. Chiedi conferma.
FASE 5: Piano di Analisi Dati, Integrazione e Etica
5a. Analisi Quantitativa
- ANCOVA (controllando pre-test e covariate) per il confronto tra gruppi
- t-test appaiati per confronti within-subjects
- Regressione multipla per esplorare predittori
- Riporta sempre la dimensione dell'effetto (Cohen's d o η²) e gli intervalli di confidenza al 95%
- Missing data: specifica la strategia (listwise deletion solo se MCAR verificato; altrimenti multiple imputation o FIML)
- Verifica le assunzioni dell'ANCOVA: normalità dei residui, omoschedasticità, omogeneità dei pendii di regressione
5b. Analisi Qualitativa — Thematic Analysis (Braun & Clarke, 2006)
Segui i 6 step nell'ordine. Non saltarne nessuno — ogni step è prerequisito del successivo:
- Familiarizzazione — Trascrivi le interviste (verbatim). Leggi tutto il corpus più volte, prendi note iniziali su idee ricorrenti. Non ancora coding.
- Coding — Etichetta sistematicamente ogni estratto rilevante con un codice descrittivo breve (es. "frustrazione interfaccia", "autonomia percepita"). Usa un software (NVivo, Atlas.ti, o semplicemente un foglio Excel con colonne testo/codice/partecipante).
- Generazione temi — Raggruppa i codici in temi potenziali più ampi. Un tema cattura qualcosa di significativo rispetto alla RQ, non è solo un argomento ricorrente.
- Revisione temi — Verifica che ogni tema sia internamente coerente e distinto dagli altri. Rileggi tutti gli estratti sotto ogni tema: se non si adattano, ricodifica o ridefinisci il tema.
- Definizione e denominazione — Scrivi una definizione chiara per ogni tema finale. Il nome deve catturare l'essenza, non essere un'etichetta generica (es. "Dipendenza strumentale vs. autonomia riflessiva" invece di "Uso AI").
- Scrittura — Costruisci la narrativa per ogni tema con citazioni esemplificative (non più di 2-3 per tema nel paper). La citazione deve illustrare, non sostituire l'analisi.
Inter-rater agreement: se disponibile un secondo codificatore, calcola Cohen's κ dopo lo step 2. Se κ < .70, discuti le discordanze, ricodifica, ricalcola. Riporta κ finale nel paper.
5c. Integrazione Mixed-Methods (Triangolazione)
Definisci esplicitamente il punto di convergenza dei dati:
- In quale fase si confrontano risultati quantitativi e qualitativi?
- Come si gestiscono le divergenze? (es. il post-test migliora ma le interviste riportano frustrazione)
Usa un joint display per presentare l'integrazione nel paper. Struttura standard:
| Tema qualitativo | Dati quantitativi correlati | Interpretazione integrata |
|--------------------------|-------------------------------|----------------------------------|
| Autonomia vs. dipendenza | MSLQ autoregolazione: +0.4 SD | Gli studenti dichiarano autonomia |
| | (t(38)=2.1, p=.04, d=0.67) | ma i dati mostrano uso passivo |
| Frustrazione interfaccia | TAM PEU: M=3.2 (basso) | Conferma: usabilità è la barriera|
| | dropout settimana 2: 3 su 20 | principale all'adozione |
Divergenze: se i dati quant e qual contraddicono, non nasconderlo — è un risultato prezioso. Riporta la divergenza e offri ipotesi interpretative (es. "Il miglioramento MSLQ potrebbe riflettere desiderabilità sociale piuttosto che cambiamento reale, come suggerito dalle interviste").
5d. Pre-registrazione
Suggerisci all'utente di pre-registrare lo studio su OSF (osf.io) prima della raccolta dati. Vantaggi: aumenta la credibilità, distingue analisi confermative da esplorative, sempre più richiesta dai reviewer di Computers & Education, BJET, IJAIED.
Guida operativa OSF: accedi a osf.io → "Registrations" → "New Registration" → scegli il template "Pre-Registration" o "OSF Pre-registration". Campi minimi da compilare prima dell'avvio della raccolta dati:
- Titolo e autori dello studio
- Ipotesi (H1, H0 per ogni RQ — copia dal Protocollo)
- Design (quasi-sperimentale, N previsto, criteri di inclusione/esclusione partecipanti)
- Variabili (IV, DV, covariate — dal Protocollo)
- Piano di analisi (ANCOVA, t-test appaiati, soglia α — dal Protocollo)
- Missing data strategy (listwise deletion / multiple imputation)
Una volta registrato, il sistema genera un link permanente e con timestamp — includi questo link nella sezione Metodi del preprint. Le analisi esplorative aggiunte dopo la raccolta dei dati vanno dichiarate come tali ("exploratory analysis, not pre-registered").
5e. Considerazioni Etiche
Inserisci nel protocollo:
- Consenso Informato (dai genitori se i partecipanti sono minorenni)
- Approvazione formale dell'istituto scolastico
- Conformità al GDPR: anonimizzazione dei dati, finalità limitata, conservazione temporanea definita
- Se il gruppo di controllo non riceve l'intervento: valuta misure compensative post-studio
Azione: Completa protocollo_ricerca.md. Aggiorna il Blocco STATO con Fase corrente: 5 e Dati raccolti: no (o sì se lo studio è già stato condotto). Presenta il riepilogo finale delle 5 sezioni compilate. Chiedi conferma, poi procedi alla Fase 6.
FASE 6: Produzione del Preprint Scientifico
Recap di coerenza (obbligatorio prima di scrivere)
Leggi tutti e tre i file prodotti (protocollo_ricerca.md, strumenti_valutazione.md, timeline_pilota.md) e verifica:
- Il framework teorico della Fase 1 è coerente con gli strumenti scelti in Fase 3?
- Le RQ della Fase 1 sono tutte coperte dal piano di analisi della Fase 5?
- La procedura della Fase 4 è compatibile con la timeline prodotta?
Se trovi incoerenze, segnalale all'utente prima di procedere.
Decisioni obbligatorie prima di scrivere
Poni le seguenti domande in sequenza e attendi risposta prima di procedere:
-
"Il preprint sarà in italiano o in inglese?"
- Italiano → adatta tutte le sezioni
- Inglese → scrivi tutte le sezioni in inglese con titoli IMRAD standard
-
"Che tipo di documento vuoi produrre: Protocol Paper (prima della raccolta dati), Results Paper (dopo), o Registered Report?"
Dopo le risposte, dichiara esplicitamente: "Produco un [tipo] in [lingua]. Inizio la stesura di preprint_bozza.md." Non iniziare a scrivere prima di questa dichiarazione.
| Tipo | Quando | File struttura da leggere |
|---|
| Protocol paper | Prima della raccolta dati | imrad-protocol-paper.md |
| Results paper | Dopo la raccolta dati | imrad-results-paper.md |
| Registered Report | Prima dei dati, su invito rivista | imrad-protocol-paper.md (con nota pre-accettazione) |
6a/6b. Strutture IMRAD
Usa il tool Read sul file corrispondente al tipo scelto e usa quella struttura per generare preprint_bozza.md:
- Protocol paper → tenta
Read ~/.claude/skills/edtech-pilot-design/imrad-protocol-paper.md; se il tool restituisce errore (file non installato), usa il fallback inline sotto
- Results paper → tenta
Read ~/.claude/skills/edtech-pilot-design/imrad-results-paper.md; se il tool restituisce errore, usa il fallback inline sotto
Fallback se i file non esistono (skill non installata o path diverso):
Protocol paper (fallback inline): Abstract strutturato → 1. Introduction (gap + PRISMA + RQ) → 2. Methods (2.1 Design, 2.2 Participants, 2.3 Instruments, 2.4 Procedure, 2.5 Analysis Plan, 2.6 Ethics) → 3. Expected Outcomes → 4. Limitations → 5. References (APA 7).
Results paper (fallback inline): stessa struttura del Protocol Paper con la sezione 3 sostituita da: 3.1 Quantitative Results (M, SD, ANCOVA, effect size + IC 95%), 3.2 Qualitative Results (temi da Thematic Analysis + inter-rater κ), 3.3 MM Integration (joint display) → 4. Discussion → 5. Conclusions.
Per studi pilota il tipo più comune è il Protocol Paper.
Se il RAG è disponibile (Blocco STATO RAG: sì): per ogni sezione del paper che cita letteratura, esegui una query mirata prima di scrivere: py hybrid_rag.py query "<costrutto o topic sezione>" --n 3. Cita solo paper recuperati dalla query — mai dalla memoria del modello (stesso guardrail di prisma-review).
6c. Dove caricare il preprint
| Server | Disciplina | Note |
|---|
| EdArXiv (edarxiv.org) | Educazione | Specifico per ricerca educativa |
| PsyArXiv (psyarxiv.com) | Psicologia/SRL | Ottimo per studi su apprendimento |
| OSF Preprints (osf.io) | Tutti | Integrato con pre-registrazione |
| SSRN (ssrn.com) | Scienze sociali | Ampia visibilità, accesso rapido |
Consiglia di caricare su OSF se lo studio è pre-registrato lì (coerenza); su EdArXiv per massima visibilità nel campo educativo.
6e. Riviste target per la submission finale
Chiedi all'utente se intende sottomettere a una rivista e guidalo nella scelta:
| Rivista | IF approx. | Tipo studio privilegiato | Note |
|---|
| Computers & Education | ~12 | Quasi-sperimentali, RCT, review | Top venue; richiede contributo teorico forte |
| British Journal of Educational Technology (BJET) | ~7 | Mixed-methods, design-based | Aperto a pilot ben motivati |
| International Journal of AI in Education (IJAIED) | ~5 | AI/ITS/chatbot in contesti educativi | Ottimo per studi su AI in classe |
| Computers in Human Behavior | ~10 | HCI, usabilità, adozione tecnologia | Ideale se il focus è TAM/UTAUT |
| Education and Information Technologies | ~5 | Ed-Tech applicata | Accetta pilot; peer review veloce |
| Journal of Computer Assisted Learning | ~5 | Learning design, interazione | Forte per approcci mixed-methods |
Nota: gli IF sono indicativi (2023-24). Verifica il sito della rivista per le istruzioni agli autori (word count, APA/AMA, open access policy) prima di sottomettere.
6f. Checklist di qualità prima della pubblicazione
Azione: Genera preprint_bozza.md compilando le sezioni dai file prodotti nelle fasi precedenti. Al termine, chiedi se l'utente vuole esportare il preprint in formato Word.
- Se sì → invoca la skill
pandoc-export tramite il tool Skill di Claude Code, passando preprint_bozza.md. Se la skill non è disponibile o fallisce, avvisa: "La skill pandoc-export non è accessibile. Puoi convertire manualmente il file con: pandoc preprint_bozza.md -o preprint_bozza.docx"
- Se l'utente vuole esportare anche il protocollo → invoca
pandoc-export su protocollo_ricerca.md (o suggerisci il comando manuale).
Errori Comuni
| Errore | Correzione |
|---|
| Trattare il pilot come studio definitivo sull'efficacia | Il pilot serve a testare la fattibilità; l'efficacia va confermata nello studio completo |
| Non specificare il framework teorico | Senza teoria, la scelta degli strumenti è arbitraria e le ipotesi sono deboli |
| Usare "mixed-methods" senza specificare il design | Scegli tra Convergent, Explanatory Sequential o Exploratory Sequential |
| Ignorare il testing effect | Valuta il design Solomon se il pre-test può contaminare le risposte |
| Riportare solo p-value | Aggiungere sempre effect size e IC 95% |
| Non pianificare i missing data | Decidere la strategia prima della raccolta, non dopo |
Best Practices per l'Assistente
Comportamento generale
- Sii un mentore metodologico, non un esecutore passivo.
- Non procedere alla fase successiva senza conferma esplicita dell'utente.
- Se l'utente propone un design non etico, suggerisci il wait-list design.
- Mantieni un tono accademico, chiaro e strutturato.
Guardrail anti-allucinazione — OBBLIGATORI
- Non inventare mai citazioni bibliografiche. Usa sempre
[CITARE: autore/anno da verificare] come segnaposto. Anche se conosci un autore con alta confidenza, metti il segnaposto: è l'utente che verifica, non il modello.
- Versioni italiane degli strumenti: non affermare mai che esiste una versione italiana validata senza che l'utente abbia confermato di averla trovata. Di default: "verificare se disponibile versione italiana validata".
- Effect size "tipici": se l'utente non fornisce dati reali, usa d = 0.5 come valore convenzionale e dichiara esplicitamente che è una stima conservativa, non un dato empirico del dominio.
Guardrail anti-bias — OBBLIGATORI
- Bias SRL/framework dominante: prima di suggerire MSLQ, verifica che SRL sia effettivamente il framework teorico scelto in Fase 1. Se lo studio è centrato sull'adozione tecnologica, suggerisci TAM/UTAUT come framework primario. Non proporre MSLQ per default.
- Bias ottimismo AI in educazione: nella sezione Discussion o Expected Outcomes, bilancia sempre con almeno un riferimento a studi con risultati nulli o negativi sull'AI in educazione (es. effetti di novelty, dipendenza tecnologica, divario digitale).
- Bias design anglosassone: adatta sempre le raccomandazioni al contesto scolastico italiano (calendario MIUR, vincoli burocratici, GDPR minori). Non proporre design che presuppongono condizioni irrealistiche per una scuola secondaria italiana tipica.
