Decisioni di architettura
Soppesa due design, traccia i confini dei moduli e definisci il rollback prima di sceglierne uno.
Casi d'uso
La maggior parte dei prompt non ha bisogno di un council. Questo è per quelli dove una risposta sicura e sbagliata ti costa un rollback, una migrazione o un bug che vedono prima i tuoi utenti.
Soppesa due design, traccia i confini dei moduli e definisci il rollback prima di sceglierne uno.
Passagli una patch e chiedi cosa si rompe: regressioni, test mancanti, il caso limite che ti sveglia alle 3 di notte.
Lascia che Leonardo faccia a pezzi la UX, poi fai guidare il browser a Bob prima che qualcuno dica «funziona».
Seymour va a caccia di latenza, memoria e carico sul database — e della domanda che tutti saltano: come la misuri?
La modalità skill-review verifica se la gente troverà il tuo strumento, lo userà e non inciamperà nelle regole che hai già scritto.
Scambia «secondo me va bene» con una lista: blocker, disaccordi aperti, cosa è testato, cosa resta ignoto.
Review del frontend
I bug di UI si nascondono nel comportamento, non negli screenshot — il focus trap che non si libera, lo sfondo che resta cliccabile, la modale che si sfascia sul telefono. Per questo le run sul frontend seguono un percorso più severo.
Scelta della modalità
| Situazione | Modalità | Perché |
|---|---|---|
| Decisione piccola e reversibile | fast |
Un passaggio rapido del Presidente, senza il costo del council intero. |
| Scelta implementativa o di architettura | standard |
Sei revisori e una fase di punteggio. Basta per la maggior parte dei casi. |
| Sicurezza, migrazione, perdita dati, parità di voti | deep |
Quando il rischio è concreto, lo scrutinio in più si ripaga. |
| Frontend, UX, modali, form, navigazione | standard --frontend-review |
Leonardo sull'esperienza, Bob sul browser quando c'è qualcosa da cliccare. |
| Usabilità di skill o plugin | --type skill --skill-review |
Lenti compatte su com'è costruito lo strumento e se qualcuno riesce a usarlo. |
Non abusarne