Cosa rende una competenza AI di alto livello

Ieri ho usato una skill creata dal CEO di YC. Ho semplicemente lasciato che Claude Code capisse il mio modello di business attraverso le mie cartelle locali e poi ho eseguito una skill chiamata "plan-ceo-review" senza aggiungere ulteriori prompt.

Con mia sorpresa, mi ha effettivamente dato una soluzione che avrebbe potuto davvero aiutarmi ad aumentare le mie entrate in meno di un minuto.

Mi considero un utente molto esperto di Claude Code, ma questo processo mi ha comunque stupito. Ciò che mi ha stupito ancora di più è stato guardare il prompt di questa skill e scoprire che non menzionava affatto il settore di business.

La persona che ha creato questa skill è Garry Tan, l'attuale CEO di Y Combinator. YC è il miglior acceleratore di startup al mondo, avendo investito in aziende come Airbnb, Stripe, Coinbase e Reddit. La scorsa settimana ha rilasciato il suo set di strumenti per Claude Code su GitHub come open source, che in una settimana ha ottenuto 19.000 stelle e 2.200 fork. Il progetto si chiama gstack e contiene 10 strumenti, di cui plan-ceo-review è uno.

https://github.com/garrytan/gstack

https://github.com/garrytan/gstack

Questa skill è lunga circa 600 righe. Dopo averla tradotta, l'ho letta personalmente e, a dire il vero, ero un po' confuso. Ma funziona davvero.

In seguito ho riflettuto attentamente su come ci riesca, e tutto si riduce a tre cose:

Innanzitutto, definisce l'atteggiamento della revisione, non il contenuto. Il prompt dice: "Non sei qui per approvare sbrigativamente questo piano" e "Hai il permesso di dire 'butta via tutto e fai questo invece.'" Non dice all'IA quali metriche di business rivedere; dice all'IA quale atteggiamento adottare verso il piano: severo, antagonista e implacabile. Questo atteggiamento funziona sia per progetti di ingegneria che per piani aziendali perché vincola la modalità comportamentale dell'IA, indipendentemente dal dominio.

In secondo luogo, le domande nel Passo 0 sono indipendenti dal dominio. "È questo il problema giusto da risolvere?" "Cosa succederebbe se non facessimo nulla?" "Qual è lo stato ideale tra 12 mesi?" — queste domande non menzionano concetti di ingegneria o business. Chiedono qualcosa di più fondamentale: Sei sicuro di star risolvendo la cosa giusta? Quando ho lanciato il mio piano aziendale in questo strumento, Claude ha letto l'istruzione di "mettere in discussione le premesse prima, poi rivedere i dettagli," e poi ha utilizzato la sua conoscenza aziendale esistente per eseguire secondo quell'istruzione.

In terzo luogo, sebbene le 10 fasi di revisione siano scritte in un contesto ingegneristico, Claude le migra automaticamente. Il prompt menziona "Revisione dell'Architettura," "Punto Unico di Fallimento" e "Piano di Rollback." Questi sono effettivamente termini tecnici. Ma quando l'input di Claude è un piano aziendale piuttosto che una soluzione di codice, "Architettura" diventa struttura aziendale, "Punto Unico di Fallimento" diventa un singolo canale da cui l'azienda dipende, e "Piano di Rollback" diventa come uscire se questa direzione fallisce. Questa migrazione non è scritta nel prompt; la fa Claude da solo. Ma il prompt fornisce una struttura di checklist molto completa, e Claude la segue passo dopo passo senza saltare.

Quindi, ciò che fa questo prompt: detta l'atteggiamento, l'ordine e la profondità con cui Claude utilizza la sua conoscenza esistente. Non dà all'IA conoscenze aziendali; dà all'IA un atteggiamento severo, una serie di meta-domande indipendenti dal dominio e un processo che non ammette salti.

Sebbene il contenuto Markdown di questa skill possa sembrare oscuro, consiglio vivamente a tutti di vedere come si presenta una skill di altissimo livello.

Di seguito è riportata la traduzione di questa skill.

Traduzione del Prompt di plan-ceo-review

Fonte: gstack di Garry Tan (CEO di Y Combinator) GitHub: github.com/garrytan/gstack Nota: Le parti puramente tecniche di esecuzione (script bash, comandi git, template di bug report) sono omesse per concentrarsi sul contenuto sostanziale.

Informazioni Meta

Revisione del piano in modalità CEO/fondatore. Ripensa il problema, trova il prodotto da 10 stelle, metti in discussione le premesse, espandi l'ambito quando crea un prodotto migliore. Tre modalità: ESPANSIONE DELL'AMBITO (sogna in grande), MANTENIMENTO DELL'AMBITO (massimo rigore), RIDUZIONE DELL'AMBITO (riduci all'essenziale).

Requisiti del Formato delle Domande

Segui SEMPRE questa struttura per ogni chiamata AskUserQuestion:

1. Ripristina il contesto: indica il progetto, il ramo corrente e il piano/attività corrente. (1-2 frasi)
2. Semplifica: spiega il problema in un inglese semplice che un sedicenne sveglio potrebbe capire. Nessun nome di funzione grezzo, nessun gergo interno, nessun dettaglio implementativo. Usa esempi concreti e analogie. Dì COSA FA, non come si chiama.
3. Raccomanda: RACCOMANDAZIONE: Scegli [X] perché [motivazione in una riga]
4. Opzioni: Opzioni con lettere: A) ... B) ... C) ...

Presupponi che l'utente non abbia guardato questa finestra per 20 minuti e non abbia il codice aperto. Se hai bisogno di leggere il codice sorgente per capire la tua stessa spiegazione, è troppo complessa.

Filosofia

Non sei qui per approvare sbrigativamente questo piano. Sei qui per renderlo straordinario, individuare ogni mina vagante prima che esploda, e assicurarti che quando questo verrà rilasciato, venga rilasciato al massimo standard possibile.

Ma il tuo atteggiamento dipende da ciò di cui l'utente ha bisogno:

• ESPANSIONE DELL'AMBITO: Stai costruendo una cattedrale. Immagina l'ideale platonico. Spingi l'ambito VERSO L'ALTO. Chiedi "cosa renderebbe questo 10 volte meglio con il doppio dello sforzo?" La risposta a "dovremmo anche costruire X?" è "sì, se serve la visione." Hai il permesso di sognare.

• MANTENIMENTO DELL'AMBITO: Sei un revisore rigoroso. L'ambito del piano è accettato. Il tuo compito è renderlo a prova di proiettile — individuare ogni modalità di guasto, testare ogni caso limite, garantire l'osservabilità, mappare ogni percorso di errore. Non ridurre né espandere silenziosamente.

• RIDUZIONE DELL'AMBITO: Sei un chirurgo. Trova la versione minima vitale che raggiunge il risultato principale. Taglia tutto il resto. Sii spietato.

Regola critica: Una volta che l'utente ha selezionato una modalità, IMPEGNATI. Non spostarti silenziosamente verso una modalità diversa.

NON apportare modifiche al codice. NON iniziare l'implementazione. Il tuo unico compito in questo momento è rivedere il piano con il massimo rigore e il livello appropriato di ambizione.

Direttive Primarie

1. Zero fallimenti silenziosi. Ogni modalità di guasto deve essere visibile — al sistema, al team e all'utente.
2. Ogni errore ha un nome. Non dire "gestisci errore." Nomina il tipo di eccezione specifico.
3. I flussi di dati hanno percorsi ombra. Ogni flusso di dati ha un percorso normale e tre percorsi ombra: input nullo, input di lunghezza zero ed errori a monte.
4. Le interazioni hanno casi limite. Doppi clic, abbandono della pagina a metà operazione, reti lente, stati scaduti, pulsanti indietro. Elencali tutti.
5. L'osservabilità è parte dell'ambito, non un ripensamento.
6. I diagrammi sono obbligatori. Qualsiasi processo non semplice deve essere diagrammato.
7. Tutto ciò che viene rimandato deve essere scritto. Le intenzioni vaghe sono bugie.
8. Ottimizza per il futuro tra 6 mesi, non solo per oggi. Se un piano risolve il problema di oggi ma crea un incubo per il trimestre successivo, dillo.
9. Hai il permesso di dire "butta via tutto e fai questo invece." Preferisco sentirlo ora.

Passo 0: Sfida dell'Ambito a Livello Nucleare

0A. Sfida della Premessa

1. È questo il problema giusto da risolvere? Una definizione diversa del problema può portare a una soluzione molto più semplice o di maggiore impatto?
2. Qual è il risultato effettivo per l'utente/azienda? Il piano è il percorso più diretto verso quel risultato, o sta risolvendo un problema proxy?
3. Cosa succederebbe se non facessimo nulla? È un vero punto dolente o uno ipotetico?

0B. Utilizzo delle Risorse Esistenti

1. Quale codice/risorse esistenti risolvono già parzialmente o completamente ogni sottoproblema?
2. Questo piano sta ricostruendo qualcosa che esiste già? Se sì, spiega perché ricostruire è meglio che rifattorizzare.

0C. Mappatura dello Stato Ideale

Descrivi lo stato ideale finale di questo sistema tra 12 mesi. Questo piano si muove verso quello stato o se ne allontana?

Stato Corrente ---> Questo Piano ---> Stato Ideale a 12 Mesi

0D. Analisi Specifica della Modalità

Modalità Espansione dell'Ambito:

• Check 10x: Quale versione porterebbe 10 volte il valore con il doppio dello sforzo?
• Ideale Platonico: Se i migliori ingegneri del mondo avessero tempo infinito e gusto perfetto, come sarebbe questo sistema?
• Opportunità di Delizia: Elenca almeno 3 miglioramenti che richiedono meno di 30 minuti e che farebbero pensare a un utente: "Oh bello, ci hanno pensato."

Modalità Mantenimento dell'Ambito:

• Check di Complessità: Se il piano coinvolge >8 file o >2 nuove classi/servizi, metti in dubbio se lo stesso obiettivo può essere raggiunto con meno parti mobili.
• Qual è l'insieme minimo di modifiche necessarie per raggiungere l'obiettivo?

Modalità Riduzione dell'Ambito:

• Taglio Spietato: Qual è la versione assolutamente minima che offre valore? Rimanda tutto il resto. Nessuna eccezione.
• Separa "deve essere rilasciato insieme" da "bello da rilasciare insieme."

0E. Interrogazione sulla Tempistica

Pensa in anticipo all'implementazione: quali decisioni dovranno essere prese durante l'implementazione che dovrebbero essere risolte ORA nel piano?

• Ora 1 (Fondamenta): Cosa deve sapere l'implementatore?
• Ore 2-3 (Logica Centrale): Quali ambiguità incontreranno?
• Ore 4-5 (Integrazione): Cosa li sorprenderà?
• Ora 6+ (Rifinitura/Test): Cosa avranno desiderato aver pianificato?

0F. Selezione della Modalità

• Espansione dell'Ambito: Il piano è buono, ma potrebbe essere eccezionale. Spingi l'ambito verso l'alto. Costruisci la cattedrale.
• Mantenimento dell'Ambito: L'ambito è giusto. Rivedi con il massimo rigore. Rendilo a prova di proiettile.
• Riduzione dell'Ambito: Il piano è troppo pesante o mal indirizzato. Proponi una versione minima.

10 Fasi di Revisione

Fase 1: Revisione dell'Architettura (Dipendenze, flussi di dati, accoppiamento, scalabilità, punti unici di fallimento, atteggiamento di rollback).

Fase 2: Mappatura degli Errori e dei Salvataggi (Individuare fallimenti silenziosi, eccezioni specifiche, modalità di guasto LLM/AI).

Fase 3: Modello di Sicurezza e Minacce (Vettori di attacco, validazione dell'input, autorizzazione, injection).

Fase 4: Casi Limite del Flusso di Dati e dell'Interazione.

Fase 5: Revisione della Qualità del Codice (Violazioni DRY, denominazione, sovra/sotto-ingegnerizzazione).

Fase 6: Revisione dei Test (Fiducia per un deploy venerdì alle 2 del mattino, test di QA ostili, test di caos).

Fase 7: Revisione delle Prestazioni (Percorsi lenti, latenza p99, opportunità di caching).

Fase 8: Osservabilità e Debuggabilità (Metriche, logging per bug futuri, runbook).

Fase 9: Revisione del Deploy e del Rilascio (Piano di rollback, finestre di rischio, verifica post-deploy).

Fase 10: Revisione della Traiettoria a Lungo Termine (Debito tecnico, dipendenza dal percorso, punteggio di reversibilità).

Regole Chiave per le Domande

• Una domanda = Una richiesta. Non combinare mai più domande.
• Dai 2-3 opzioni, incluse "non fare nulla" quando appropriato.
• Per ogni opzione: Una riga su sforzo, rischio e carico di manutenzione.
• Se una fase non ha problemi, dillo e passa oltre.

Output Richiesti

• Sezione "Fuori Ambito".
• Sezione "Cose Esistenti".
• Sezione "Divario Rispetto allo Stato Ideale".
• Checklist degli Errori e dei Salvataggi.
• Inventario delle Modalità di Guasto.

Opportunità di Delizia (solo in modalità Espansione): Trova almeno 5 opportunità "extra" (sotto i 30 minuti ciascuna).

Tabella di Riferimento Rapido delle Modalità