/dry-run-skill — Valida uno skill in prosa senza eseguirlo in produzione

Quando ricevi questo comando (con il nome di uno skill, es. /dry-run-skill project), esegui un dry-run sorvegliato di quello skill: lo lanci in una sandbox usa-e-getta con input fissi, ne verifichi gli INVARIANTI dell'output, e riferisci PASS/FAIL — senza toccare aree reali.

Perché esiste: gli skill in prosa (/project, /discovery, generatori di scaffold/file) li esegue l'LLM — non hanno un test runtime nativo. Rifattorizzarli o modificarli "al buio" rompe in silenzio. Questa è la rete. Dettaglio e fondamento: SSOT DRYRUN_PROTOCOL e KNOW_HOW_TRANSFER_PROTOCOL (paradigma).

Quando usarlo

• PRIMA di modificare/rifattorizzare uno skill che genera artefatti verificabili (file, scaffold, descrittori, config).
• Per validare uno split/refactor (es. /project monolitico → micro-skill): si confronta il nuovo output col golden.
• Come test di accettazione di uno skill nuovo generatore.
• NON serve per skill conversazionali/consulenziali (niente output deterministico da snapshottare).

Il "kit" di dry-run di uno skill (convenzione)

Ogni skill validabile ha un kit con tre pezzi (è la convenzione da seguire/creare se manca):

• golden_inputs.json — risposte canoniche FISSE, scelte deterministiche e senza side-effect (per /project: paradigma-solo, niente librerie, RAG offline).
• verify.sh <dir> (o verify_scaffold.sh) — verifier degli INVARIANTI strutturali (NON byte-diff): placeholder risolti, campi-chiave corretti, schema atteso, ecc. Deve essere una rete vera (bocciare un albero rotto).
• golden/<...> — snapshot dell'output dello skill ATTUALE con quegli input (riferimento d'oro).

Kit di riferimento esistente per /project: os3-matrix/docs/tests/m-os3-065/.

Procedura (eseguila così)

1. Localizza il kit dello skill richiesto (golden_inputs.json + verify*.sh + golden/). Se manca, dillo e proponi di crearlo (non inventare input).
2. Sandbox: crea una dir usa-e-getta /tmp/dryrun-<skill>-<n>. Lavora SOLO lì.
3. Esecuzione sorvegliata: spawna un agente (o esegui tu) con istruzione di ESEGUIRE lo skill target (leggi il suo .md) contro la sandbox usando SOLO golden_inputs, in modalità non-interattiva (non chiedere nulla) e senza side-effect (NON clonare, NON installare, NON toccare aree reali).
4. Verifica: lancia verify*.sh <albero-prodotto> → exit 0 atteso. Se è un refactor, confronta anche i file chiave col golden/ (match semantico, non byte).
5. Riferisci: PASS (zero violazioni) o FAIL con l'elenco esatto degli scostamenti.
6. Teardown: rimuovi la sandbox.

Esito

• PASS = lo skill (o la sua versione rifattorizzata) produce un output conforme agli invarianti e allineato al golden.
• FAIL = scostamenti da spiegare e correggere PRIMA di attivare/spedire la modifica. Mai attivare al buio.

Vedi anche: agente skill-dryrun-guardian (si auto-attiva quando stai per toccare uno skill in prosa e ti ricorda di usare questa rete), KNOW_HOW_TRANSFER_PROTOCOL (perché questa capacità è nel prodotto, non in memoria privata).