# Ingegneria dei prompt (/it/docs/verdent-for-vscode/best-practices/prompts)
> Buone pratiche per scrivere prompt efficaci
***
I prompt efficaci sono la base di uno sviluppo assistito dall'AI di successo. Richieste chiare e specifiche, con il contesto appropriato, permettono a Verdent di fornire risultati accurati e pertinenti.
### Cosa imparerai [#cosa-imparerai]
* Buone pratiche per scrivere prompt efficaci
* Come fornire contesto ed evitare gli errori più comuni
* Tecniche avanzate come le @-menzioni e la delega ai sottoagenti
* Esempi di prompt ben strutturati
* Strategie di perfezionamento iterativo
***
## Cosa rende efficace un prompt [#cosa-rende-efficace-un-prompt]
I prompt efficaci sono chiari, specifici e forniscono il contesto necessario affinché Verdent comprenda le tue intenzioni e fornisca risultati accurati.
**Principi chiave:**
* **Sii specifico** - Indica esattamente ciò di cui hai bisogno, senza richieste vaghe
* **Includi i dettagli** - Fornisci specifiche tecniche quando hai delle preferenze
* **Definisci l'ambito** - Chiarisci quali file/componenti sono coinvolti
* **Fornisci contesto** - Aiuta Verdent a comprendere la tua architettura
* **Descrivi i risultati** - Descrivi come si presenta il successo
* **Usa il linguaggio naturale** - Non serve alcuna sintassi speciale
**Esempi di trasformazioni:**
**Sbagliato:**
```
Fix the code
```
**Corretto:**
```
Add input validation to the email field in ContactForm.js to reject invalid email formats
```
**Sbagliato:**
```
Add authentication
```
**Corretto:**
```
Add JWT authentication using the same middleware pattern as auth.js, store tokens in httpOnly cookies
```
***
## Errori comuni nei prompt [#errori-comuni-nei-prompt]
**Prompt di esempio:**
```
Make the app better
```
```
Fix the bugs
```
| Problema | Soluzione |
| ------------------------------------------------------------------ | ------------------------------------------------------------------------ |
| Verdent non sa quali miglioramenti desideri o quali bug affrontare | Specifica esattamente cosa deve essere migliorato o quale bug correggere |
**Prompt di esempio:**
```
Add authentication
```
| Problema | Soluzione |
| --------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| Verdent potrebbe implementare JWT quando usi OAuth, o viceversa | Specifica l'approccio implementativo, i pattern esistenti e i requisiti tecnici |
**Prompt di esempio:**
```
Build the entire user management system with authentication, authorization, profiles, settings, and admin dashboard
```
| Problema | Soluzione |
| --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Le richieste complesse su più sistemi sono più difficili da eseguire correttamente in un colpo solo | Suddividi in attività più piccole - inizia con l'autenticazione, poi l'autorizzazione, poi i profili |
**Prompt di esempio:**
```
Update the validation logic
```
| Problema | Soluzione |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| Non è chiaro quali file o quale validazione modificare | Specifica l'ambito: "Aggiorna la validazione in UserController.js per richiedere password sicure" |
**Prompt di esempio:**
```
Expecting Verdent to know your specific business rules or constraints
```
| Problema | Soluzione |
| ----------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Verdent implementa soluzioni generiche senza i tuoi requisiti specifici | Dichiara esplicitamente tutti i vincoli, le regole di business e i requisiti |
**Prompt di esempio:**
```
Referencing files without including them in context
```
| Problema | Soluzione |
| --------------------------------------------------------------- | -------------------------------------------------------------- |
| Verdent potrebbe non avere accesso ai file di cui stai parlando | Usa @filename.js per includere esplicitamente i file rilevanti |
**Prompt di esempio:**
```
Repeatedly asking for the same thing when Verdent encounters errors
```
| Problema | Soluzione |
| --------------------------------------------- | ------------------------------------------------------------------------ |
| Lo stesso approccio produce gli stessi errori | Leggi i messaggi di errore, adatta il prompt in base a ciò che è fallito |
**Prompt di esempio:**
```
Requesting large refactorings or multi-file changes without using Plan Mode first
```
| Problema | Soluzione |
| -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Non vedi l'intero ambito finché i file non sono già stati modificati | Passa a Plan Mode per le attività complesse, così da rivedere l'approccio prima dell'esecuzione |
Abilita Plan Mode per le modifiche complesse, così da rivedere l'approccio prima dell'esecuzione: questo intercetta i malintesi in anticipo.
**Prompt di esempio:**
```
Using Auto-Run or Skip Permission Mode without Git initialized
```
| Problema | Soluzione |
| ------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Nessuna rete di sicurezza se Verdent apporta modifiche indesiderate | Abbi sempre Git inizializzato e con commit prima di usare le modalità permissive |
**Prompt di esempio:**
```
Providing incomplete requirements and expecting Verdent to guess correctly
```
| Problema | Soluzione |
| ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
| Verdent implementa basandosi su ipotesi che potrebbero non corrispondere alle tue esigenze | Chiedi a Verdent di intervistarti: "Fammi domande di chiarimento sui requisiti prima di creare il piano" |
***
## Esempi di prompt ben strutturati [#esempi-di-prompt-ben-strutturati]
Creare nuove funzionalità con requisiti e vincoli chiari:
```
Create a POST /api/tasks endpoint that:
- Accepts task title (required), description (optional), and category_id (required)
- Validates that the category exists in the database
- Returns 400 if validation fails with descriptive error messages
- Saves the task to the database and returns the created task with 201 status
- Add this to the existing tasks router in routes/tasks.js
- Create the controller method in controllers/taskController.js
- Use the existing error handling pattern from other controllers
```
**Cosa lo rende efficace:**
* Requisiti chiari per input e validazione
* Posizioni specifiche dei file per l'implementazione
* Riferimento ai pattern esistenti per mantenere la coerenza
* Codici di stato HTTP attesi e gestione degli errori
Descrivere i problemi con contesto e soluzioni proposte:
```
Fix the race condition in payment processing at checkout. When multiple users submit payments simultaneously, some transactions fail with "duplicate order ID" errors. The issue appears to be in PaymentController.js around line 45 where we generate order IDs. Implement proper locking or use UUID generation to ensure unique IDs even under concurrent load.
```
**Cosa lo rende efficace:**
* Descrizione chiara del problema con i sintomi
* Posizione specifica del problema (file e numero di riga)
* Contesto su quando si verifica (utenti concorrenti)
* Approcci di soluzione suggeriti
Modificare l'implementazione preservando il comportamento:
```
Refactor the authentication middleware in middleware/auth.js to use JWT tokens instead of session cookies. Keep the same authorization logic, but:
- Replace session validation with JWT verification
- Store tokens in httpOnly cookies
- Maintain the existing user object structure that routes expect
- Update only the authentication mechanism, don't change authorization rules
- Ensure all existing routes continue to work without modification
```
**Cosa lo rende efficace:**
* Obiettivo chiaro (JWT invece delle sessioni)
* File specifico da rifattorizzare
* Vincoli espliciti (cosa NON dovrebbe cambiare)
* Requisito di retrocompatibilità
Scrivere test con copertura completa:
```
Write comprehensive unit tests for the UserService class in services/UserService.js. Cover:
- User creation with valid and invalid data
- Email validation edge cases (empty, malformed, duplicate)
- Password hashing verification
- User lookup by ID and email
- Error handling for database failures
Use Jest and follow the testing patterns in existing service tests
```
**Cosa lo rende efficace:**
* Classe/file specifico da testare
* Elenco completo degli scenari da coprire
* Framework di test specificato
* Riferimento ai pattern di test esistenti
Costruire componenti UI con specifiche dettagliate:
```
Create a reusable SearchBar component for the product catalog with:
- Text input with real-time debounced search (300ms delay)
- Category dropdown filter (fetch options from /api/categories)
- Price range slider (min $0, max $1000)
- Clear filters button
- Use Material-UI components to match existing design
- Emit search parameters via onChange callback to parent
- Include PropTypes for all props
```
**Cosa lo rende efficace:**
* Elenco completo delle funzionalità con dettagli specifici
* Specifiche tecniche (debounce di 300ms, intervallo di prezzo)
* Libreria UI specificata (Material-UI)
* Approccio di integrazione (callback verso il genitore)
***
## Tecniche avanzate di prompting [#tecniche-avanzate-di-prompting]
Riferisciti a file, componenti o sottoagenti specifici:
```
@auth.js @UserController.js Refactor authentication to use the same validation pattern
```
**Vantaggi:**
* Garantisce a Verdent il contesto esatto includendo esplicitamente file specifici
* Previene l'ambiguità in codebase estese con nomi di file simili
* Assicura che tutto il codice rilevante sia visibile simultaneamente per un refactoring e una corrispondenza di pattern accurati
* Essenziale quando si fa riferimento a pattern di implementazione da un file per applicarli in un altro
Passa a Plan Mode prima dell'esecuzione per modifiche di grandi dimensioni:
```
Switch to Plan Mode
Refactor the entire API layer to use TypeScript with strict type checking
```
**Vantaggi:**
* Rivedi l'approccio completo di Verdent prima che qualsiasi file venga modificato
* Previene errori costosi in refactoring di grandi dimensioni o modifiche architetturali
* Itera sul piano, aggiungi vincoli o reindirizza completamente prima che inizi l'esecuzione
* Richiedi che Verdent ti intervisti con domande di chiarimento per raccogliere tutti i requisiti in anticipo
Delega attività specializzate a sottoagenti integrati o personalizzati:
```
@Code-reviewer Review the security vulnerabilities in authentication flow
@Explorer Find all files that import the deprecated API client
@Verifier Validate the authentication logic in the middleware
```
**Vantaggi:**
* Sfrutta agenti specializzati ottimizzati per attività specifiche (esplorazione, verifica, revisione del codice)
* Competenza focalizzata e risultati più rapidi rispetto all'elaborazione generica
* Esegui più analisi in parallelo per ridurre drasticamente il tempo totale di esecuzione
* Crea sottoagenti personalizzati con conoscenza specifica del dominio per i requisiti unici del tuo progetto
**Sottoagenti predefiniti integrati:**
* `@Verifier` - Controlli rapidi del codice e validazione
* `@Explorer` - Esplorazione veloce della codebase e ricerca dei file
* `@Code-reviewer` - Valutazione della qualità del codice
Usa @Explorer per le domande sulla codebase e @Code-reviewer per l'analisi di sicurezza: la delega mirata è più rapida del routing tramite l'agente principale.
Abilita il ragionamento esteso per le sfide più sofisticate:
```
Think: Design the optimal database schema for a multi-tenant SaaS application
```
**Vantaggi:**
* Attiva il ragionamento esteso per un'analisi più approfondita dei problemi complessi da più angolazioni
* Valuta approcci alternativi e casi limite in modo più accurato
* Produce soluzioni robuste dove la correttezza è fondamentale
* Risposte più lente e maggior consumo di crediti, ma previene costose rilavorazioni dovute a soluzioni frettolose e subottimali
Think Hard Mode eccelle nelle decisioni architetturali, nel debugging complesso e nei problemi algoritmici che richiedono un'analisi approfondita.
Costruisci sulle risposte precedenti con un perfezionamento progressivo:
```
Initial: "Create a dashboard component"
Follow-up: "Add real-time data updates using WebSockets"
Follow-up: "Now add filtering and sorting capabilities"
```
**Vantaggi:**
* Consente uno sviluppo incrementale con test a ogni passo prima di aggiungere complessità
* Riduce il rischio validando il corretto funzionamento di ogni livello prima di costruirci sopra
* Correggi immediatamente la rotta se le iterazioni producono risultati inattesi
* Rende più facile individuare quale modifica specifica ha introdotto un bug, poiché ogni iterazione è piccola e contenuta
Il perfezionamento iterativo riduce il rischio: inizia con un ambito ristretto, verifica i risultati, poi espandi gradualmente.
Specifica cosa NON cambiare oltre a cosa cambiare:
```
Add caching to the API endpoints, but:
- Don't modify the authentication middleware
- Keep the existing error handling unchanged
- Maintain backward compatibility with mobile clients
```
**Vantaggi:**
* Definisce esplicitamente i confini per evitare di modificare sistemi critici (autenticazione, pagamenti)
* Protegge i sistemi stabili che devono rimanere invariati per requisiti di conformità o di rischio
* Evita cicli costosi di implementazione delle modifiche, scoperta di funzionalità rotte e rilavorazione delle soluzioni
* Mantiene la retrocompatibilità e protegge il codice collaudato da refactoring non necessari
Indica il codice esistente come esempio di implementazione:
```
Implement the new ProductService following the same pattern as UserService.js, including error handling, validation, and database transaction management
```
**Vantaggi:**
* Garantisce che le nuove implementazioni mantengano coerenza con le convenzioni consolidate
* Rende la codebase più manutenibile e prevedibile
* Riduce drasticamente le spiegazioni necessarie: indica gli esempi invece di descrivere gli approcci in dettaglio
* Sfrutta pattern comprovati e collaudati invece di reinventare le soluzioni
* Riduce i bug e garantisce un'integrazione senza intoppi con i sistemi esistenti
Crea un file todos.md per tracciare attività complesse e in più passaggi:
```
Create a todos.md file with these tasks:
1. Refactor authentication to use JWT tokens
2. Update all controllers to use new auth middleware
3. Add tests for authentication flow
4. Update API documentation
```
**Vantaggi:**
* Crea una roadmap chiara e scritta che può essere rivista, perfezionata e condivisa con i colleghi
* Si adatta facilmente man mano che i requisiti evolvono nel corso del progetto
* Persiste tra le sessioni, così puoi mettere in pausa il lavoro, riprenderlo più tardi e capire immediatamente dove ti eri fermato
* Funge da artefatto di progetto che documenta ciò che è stato pianificato, completato e rimane da fare, utile per la manutenzione futura e l'onboarding
Avvia nuove sessioni tra i diversi todo per un contesto fresco:
```
After completing todo #1: "Start a new session"
Then: "Let's work on todo #2 from todos.md"
```
**Vantaggi:**
* Previene la contaminazione del contesto, dove i dettagli dell'attività precedente influenzano impropriamente il lavoro corrente
* Garantisce la concentrazione solo sul todo corrente, senza il peso delle attività precedenti
* Riduce l'uso di token non caricando cronologie di conversazione non necessarie
* Rende le risposte più rapide ed efficienti in termini di crediti
* Crea checkpoint naturali per testare e fare il commit delle modifiche, mantenendo una cronologia git pulita e un isolamento dei problemi più facile
Usa i server MCP (Model Context Protocol) per iniettare contesto specializzato:
* Documentazione specifica del progetto
* Specifiche API (OpenAPI, schemi GraphQL)
* Conoscenza specifica del framework
**Vantaggi:**
* Migliora la comprensione di Verdent di framework personalizzati, strumenti interni e domini specializzati non presenti nei suoi dati di training
* Elimina la necessità di spiegare ripetutamente i sistemi personalizzati iniettando direttamente le specifiche API e la documentazione specifiche dell'organizzazione
* Consente l'uso corretto di API interne e sistemi proprietari che sarebbe impossibile comunicare solo tramite prompt
***
## Includere il contesto nei prompt [#includere-il-contesto-nei-prompt]
Includi esplicitamente i file rilevanti nel contesto:
```
@models/User.js @controllers/UserController.js Add password reset functionality
```
**Quando usarle:**
* Quando lavori con file strettamente accoppiati (model e controller, service e test)
* Per riferirti a pattern di implementazione da un file da applicare in un altro
* Per coordinare modifiche su più file correlati
* In codebase estese con nomi di file simili, dove il rilevamento automatico potrebbe perdere il contesto
* Usa sempre le @-menzioni quando chiedi a Verdent di "seguire lo stesso pattern di..." per assicurarti che disponga del codice esatto
Includi contesto di alto livello sul tuo stack:
```
This is a MERN stack application (MongoDB, Express, React, Node.js) with JWT authentication. Add role-based access control following our existing middleware pattern.
```
**Quando usarlo:**
* Quando implementi funzionalità che devono integrarsi con il tuo stack tecnologico esistente
* Al primo lavoro in una codebase o per funzionalità che attraversano più livelli (dal frontend al database)
* Quando il tuo stack ha forti opinioni (GraphQL vs REST, Redux vs Context API) che influenzano le scelte implementative
* Quando hai bisogno che Verdent scelga l'approccio adatto al tuo sistema invece di una soluzione generica
Indica il codice che dimostra le tue convenzioni:
```
Follow the same error handling pattern used in ProductController.js - return consistent error objects with status codes and descriptive messages
```
**Quando usarli:**
* Quando vuoi che il nuovo codice mantenga coerenza con le convenzioni consolidate (gestione degli errori, validazione, logging, test)
* Per implementare funzionalità simili in una nuova area della codebase
* Per l'onboarding in parti sconosciute della codebase, dove vuoi imparare e replicare i pattern esistenti
* Quando vuoi evitare di descrivere i pattern in dettaglio e hai bisogno che Verdent colga le sfumature difficili da articolare
Dichiara limitazioni o requisiti:
```
We're using TypeScript with strict mode enabled, React 18 with hooks only (no class components), and Material-UI v5 for styling
```
**Quando usarli:**
* Quando il tuo progetto ha requisiti tecnologici specifici (modalità strict di TypeScript, solo React hooks, nessuna dipendenza esterna)
* Quando lavori con vincoli legacy (supporto IE11, compatibilità con Node.js 14)
* Quando i requisiti di conformità dettano le scelte (accessibilità WCAG, gestione dei dati GDPR)
* Quando usi versioni specifiche di librerie con modifiche incompatibili tra versioni
* Quando devi impedire a Verdent di proporre soluzioni che violano i confini tecnici del tuo progetto
Spiega le regole specifiche del dominio:
```
Users can only view tasks assigned to them or their team. Managers can view all tasks in their department. Admins can view everything.
```
**Quando usarla:**
* Quando implementi funzionalità con regole specifiche del dominio che Verdent non può dedurre dal solo codice
* Logica di autorizzazione (chi può accedere a cosa), flussi di lavoro di business (processi di approvazione, macchine a stati)
* Regole di validazione (policy sulle password, vincoli sui dati), vincoli di dominio (limiti di inventario, regole di prezzo)
* Quando costruisci modelli di dati in cui le relazioni tra entità e la cardinalità necessitano di spiegazione
* Quando implementi calcoli (regole di sconto, calcolo delle imposte, strutture di commissione)
* Quando hai bisogno che Verdent applichi correttamente le regole di business della tua organizzazione, non solo codice funzionante
Condividi messaggi di errore o log durante il debug:
```
Getting "TypeError: Cannot read property 'id' of undefined" at UserController.js:42 when trying to update user profiles. The req.user object exists but doesn't have an id property after the recent auth middleware changes.
```
**Quando usarlo:**
* Includi sempre i messaggi di errore completi, gli stack trace e i log quando correggi i bug
* Errori di runtime (eccezioni, crash), fallimenti di build (errori di compilazione, violazioni di linting)
* Fallimenti dei test (errori di assertion, problemi di timeout), comportamenti inattesi (output errato, dati mancanti)
* Quando hai messaggi di errore esatti con numeri di riga e stack trace completo che mostra la catena di chiamate
* Quando puoi fornire contesto su quando si verifica (sempre, in modo intermittente, in condizioni specifiche)
* Quando vuoi migliorare drasticamente la capacità di Verdent di identificare le cause profonde invece di tirare a indovinare
Verdent carica automaticamente i file rilevanti in base alla tua richiesta:
* File menzionati per nome nei prompt
* File correlati nella stessa cartella
* File di progetto a cui si accede di frequente
**Quando affidarti a questo:**
* Per riferimenti standard a file dove le relazioni sono ovvie
* Quando menzioni componenti per nome e Verdent deve caricare quel file specifico
* Quando lavori con file nella stessa cartella che comunemente funzionano insieme
* Quando accedi a file di progetto usati di frequente (package.json, file di configurazione)
* Funziona bene per scenari semplici in codebase ben organizzate
* Per refactoring complessi su più file, parti distanti della codebase o nomi di file ambigui, usa invece le @-menzioni esplicite
Configura contesto persistente tramite i file delle regole (Settings → Rules):
**Regole utente (VERDENT.md):**
Preferenze globali applicate a tutti i progetti
**Regole di progetto (AGENTS.md):**
Standard specifici del progetto - pattern architetturali, standard di codifica
**Regole del piano (plan\_rules.md):**
Personalizza il formato e il contenuto del piano in Plan Mode
**Quando usarle:**
* Quando fornisci ripetutamente lo stesso contesto tra le sessioni
* Regole utente per le preferenze personali (stile di codifica, librerie preferite, pattern che prediligi)
* Regole di progetto per gli standard del team (decisioni architetturali, convenzioni di denominazione, requisiti di test)
* Preziose per l'onboarding di nuovi membri del team (codificano la conoscenza informale)
* Per mantenere la coerenza in team di grandi dimensioni e ridurre la verbosità dei prompt
* Investi nei file delle regole quando il tuo progetto è abbastanza maturo da avere pattern consolidati che vale la pena documentare
Includi screenshot, mockup o diagrammi:
```
@screenshot.png Implement this UI design with React components
```
**Quando usarli:**
* Quando le informazioni visive comunicano i requisiti in modo più efficace del testo
* Implementazione UI/UX (mockup di design, wireframe, flussi utente)
* Debug di problemi visivi (screenshot di un layout rotto, problemi di rendering)
* Comprensione di architetture complesse (diagrammi di sistema, schemi di database, diagrammi di flusso)
* Essenziali per il design responsive, l'analisi dell'accessibilità e la riproduzione degli errori
* Per tradurre in codice i design da strumenti come Figma o Sketch
* Un singolo screenshot ben catturato spesso trasmette dettagli che richiederebbero paragrafi per essere descritti
Riferisciti a documentazione o esempi esterni:
```
Ultrathink: Read this API documentation at https://api-docs.example.com/v1/endpoints and implement the authentication flow
```
**Quando usarli:**
* Quando implementi integrazioni con API o librerie esterne che hanno documentazione ufficiale online
* Particolarmente utile quando la libreria ha opzioni di configurazione complesse o flussi di autenticazione
* Usa il prefisso "Ultrathink:" per istruire Verdent a recuperare e analizzare i contenuti web prima di generare il codice
* Essenziale per API in rapida evoluzione, dove la documentazione è più aggiornata dei dati di training
* Quando segui pattern specifici del framework (Next.js App Router, Vue Composition API)
* Garantisce che le implementazioni corrispondano alle versioni API correnti e seguano le raccomandazioni ufficiali
***
## Strategie di perfezionamento iterativo [#strategie-di-perfezionamento-iterativo]
**Prompt iniziale:**
```
Add authentication to the API
```
La risposta di Verdent potrebbe essere generica. Perfeziona:
```
Use JWT tokens stored in httpOnly cookies, implement refresh token rotation, and follow the authentication pattern from our existing UserController
```
**Quando usarla:** Quando inizi con una richiesta generale e poi aggiungi dettagli in base alla risposta iniziale
Se l'implementazione di Verdent non corrisponde alle aspettative:
```
The validation logic is good, but use Joi schema validation instead of manual checks. Match the validation pattern in ProductController.js
```
**Quando usarla:** Dopo aver rivisto l'output e identificato miglioramenti specifici
Costruisci in modo incrementale:
```
Initial: "Create a UserProfile component"
Follow-up: "Add an avatar upload feature with image preview"
Follow-up: "Add validation - max 5MB, only jpg/png formats"
Follow-up: "Show upload progress with a progress bar"
```
**Quando usarli:** Per costruire funzionalità progressivamente nella stessa sessione
Se l'implementazione sembra inaspettata:
```
Why did you use Redux instead of Context API? Can you explain the trade-offs for this use case?
```
Poi perfeziona in base alla comprensione:
```
Actually, use Context API for consistency with the rest of our application
```
**Quando usarla:** Per comprendere il ragionamento prima di richiedere modifiche
Per modifiche complesse:
```
Switch to Plan Mode
Show me how you would refactor the authentication system to support OAuth providers
```
Rivedi il piano, poni domande e itera sull'approccio prima dell'esecuzione.
**Quando usarlo:** Per modifiche architetturali importanti che richiedono revisione
Se lo stile di Verdent non corrisponde al tuo:
```
The component structure is close, but use this pattern instead:
[paste example of your preferred structure]
Apply this same pattern to the remaining components
```
**Quando usarli:** Per stabilire o rafforzare le preferenze di stile del codice
Se l'output viola vincoli non dichiarati:
```
Good approach, but don't modify the database schema - work within the existing User table structure
```
**Quando usarla:** Per aggiungere vincoli scoperti dopo aver visto l'implementazione iniziale
Inizia con la funzionalità di base e aggiungi funzionalità in modo iterativo:
```
Step 1: "Create basic CRUD endpoints for tasks"
Step 2: "Add pagination to the GET endpoint"
Step 3: "Add filtering by status and priority"
Step 4: "Add full-text search across title and description"
```
**Quando usarlo:** Per costruire funzionalità complesse in modo incrementale con test a ogni passo
***
## Domande frequenti [#domande-frequenti]
Sii abbastanza specifico da eliminare l'ambiguità, ma non spiegare eccessivamente dettagli ovvi. Includi: percorsi esatti dei file, approccio implementativo, risultati attesi e vincoli. Sbagliato: "Correggi il codice" - troppo vago. Corretto: "Aggiungi la validazione dell'input al campo email in `ContactForm.js` per rifiutare i formati email non validi" - ambito e obiettivo chiari. In caso di dubbio, opta per una maggiore specificità.
Verdent carica automaticamente i file menzionati per nome nei prompt e i file correlati nella stessa cartella. Le `@-mentions` (`@filename.js`) garantiscono esplicitamente che un file sia nel contesto, il che è fondamentale quando lavori con file strettamente accoppiati, ti riferisci a pattern da un file da applicare in un altro, o quando il rilevamento automatico potrebbe perdere il contesto in codebase estese. Usa sempre le `@-mentions` quando chiedi a Verdent di "seguire lo stesso pattern di..." per garantire un riferimento esatto al codice.
Usa Plan Mode per: refactoring di grandi dimensioni o modifiche architetturali, modifiche su più file dove vuoi rivedere l'ambito prima dell'esecuzione, attività complesse in cui sei incerto sui requisiti, o quando vuoi che Verdent ti intervisti con domande di chiarimento prima dell'implementazione. Salta Plan Mode per: attività semplici e ben definite, correzioni rapide di bug o operazioni di routine. Plan Mode aggiunge un sovraccarico ma previene errori costosi nei lavori complessi.
Usa il perfezionamento iterativo: rivedi l'output, identifica cosa non va, poi fornisci correzioni in un prompt di follow-up. Esempio: "La logica di validazione va bene, ma usa la validazione con schema Joi invece dei controlli manuali. Segui il pattern di validazione in `ProductController.js`." Puoi anche chiedere spiegazioni: "Perché hai usato Redux invece di Context API?" e poi perfezionare in base alla comprensione. Non ripetere lo stesso prompt: adattalo in base a ciò che è fallito.
No: Verdent mantiene il contesto della conversazione all'interno di una sessione, quindi non devi ripetere dettagli dell'architettura o convenzioni già discusse. Tuttavia, per vincoli critici o quando le sessioni si allungano (`100+` messaggi), ribadisci il contesto importante. Approccio migliore: usa le regole di progetto (`AGENTS.md`) per documentare il contesto persistente come stack tecnologico, standard di codifica e pattern, così non dovrai mai ripeterli.
Prompt ben strutturati, con intento chiaro, contesto rilevante e vincoli specifici, producono costantemente risultati migliori.
***
## Vedi anche [#vedi-anche]
Gestione delle finestre di contesto e strategie di ottimizzazione
Comprendere le modalità di esecuzione per i diversi scenari
Gestione degli errori e risoluzione dei problemi