---
name: repo-to-deck-brief
description: "Usa quando un repository software è la fonte di evidenze per un brief commerciale o executive."
---

# Dal repository al brief

Leggi le istruzioni del repository analizzato e quelle della presentazione. Ricostruisci l'asset da README, codice/configurazione, contratti, test e documenti attivi; usa `reality-check` se lo stato dichiarato è dubbio. Tool di code intelligence solo quando disponibili e utili, non prerequisiti.

Il brief deve far capire cosa entra, cosa fa oggi il sistema, come opera a livello executive, cosa produce, quali risultati sono osservabili e quali limiti restano. Solo dopo distingui evoluzione proposta, benefici da validare, rischi, effort ed economics. Non saltare dal nome della POC a una roadmap senza spiegare l'asset.

Distingui fatti, deduzioni, stime e domande aperte. Codice presente non significa deploy, metriche simulate non significano benefici provati. Non convertire una stima in offerta né completare un business case con numeri inventati.

Riusare la forma del brief corrente: sezioni sufficienti a sostenere la storyline, non quindici capitoli obbligatori. Il risultato è materiale source-grounded per il deck, non un'autorizzazione a implementare o rifattorizzare il repository.