Non vuoi configurarlo manualmente? Incolla un collegamento a questa pagina in una sessione di Devin e chiedigli di configurare tutto per te. Se nella tua app utilizzi già strumenti interni, usa [Ask Devin](https://app.devin.ai/search?utm_source=docs\&utm_medium=use-case-gallery) per capire i pattern esistenti prima di scrivere la tua specifica. Questo è particolarmente utile se vuoi che il nuovo strumento rispecchi l'architettura di ciò che è già presente: ```txt Scope internal tools architecture theme={null} Mostrami come sono strutturati i nostri strumenti interni esistenti: 1. Quali pagine esistono sotto /internal/ e come sono organizzate? 2. In che modo le pagine interne gestiscono l'autenticazione e il controllo degli accessi basato sui ruoli? 3. Quali componenti UI condivisi utilizzano (tabelle, form, modali)? 4. Come sono strutturate le migrazioni del database nel nostro schema Prisma? 5. Esistono già schemi di notifica (Slack, email)? ``` Usa le risposte per completare la tua specifica con riferimenti a file specifici, nomi di componenti e pattern, così che Devin crei qualcosa di coerente con i tuoi strumenti interni esistenti. Puoi anche avviare direttamente una sessione di Devin da Ask Devin, e verrà riportato tutto ciò che ha appreso come contesto. Gli strumenti interni — PTO tracker, pannelli di amministrazione, script per i dati, utility da CLI — sono essenziali ma ricevono raramente la priorità che meritano. Sono ideali per Devin perché i requisiti sono ben definiti, gli utenti sono le persone del tuo team e il fatto che “funzioni correttamente” conta più di un design perfetto al pixel. Sii specifico su cosa fa lo strumento, quali dati memorizza e a quali servizi si collega. Più dettagli includi, più la prima versione sarà vicina a ciò di cui hai bisogno. ```txt Build a team PTO tracker theme={null} Build an internal PTO tracker for our team under /internal/pto. ## Features - Employees can submit time-off requests with a date range, type (vacation, sick, or personal), and an optional note - Managers see a queue of pending requests and can approve or deny each one - A calendar view shows who's out on which days, color-coded by type - A dashboard shows every employee's PTO balance: total days, used days, remaining days, and pending requests - Each employee gets 20 PTO days per year - Employees can't request more days than their remaining balance - Requests can't overlap with their own existing approved PTO - Show a warning (not a block) if teammates are already out during the same dates ## Notifications - Slack notification to the manager when a request is submitted - Slack notification to the employee when it's approved or denied - Use SLACK_WEBHOOK_URL from env vars ## Technical notes - Use our existing Next.js app and Prisma ORM - Follow the layout pattern in /internal/users - Reuse DataTable and Calendar components from src/components/ui/ ## Planning - Before writing code, outline your implementation plan and share it with me for review ## Testing - Write tests for balance calculations, date overlap detection, and the approval workflow - After implementing, spin up the dev server and test every page and flow in the browser — submit a request, approve it, deny one, check the calendar, verify dashboard numbers, and test edge cases like overlapping dates and exceeding balance - Do not open a PR until everything works end-to-end ``` Puoi anche iterare sulla tua specifica usando Ask Devin: incolla una bozza e chiedi a Devin di identificare eventuali lacune o suggerire miglioramenti in base alla tua codebase. Passa tutte le API key e i token di cui Devin ha bisogno tramite [Secrets](/it/product-guides/secrets) — in questo caso, l'URL del webhook di Slack. L'approccio più semplice è memorizzarli come segreti dell'organizzazione prima di avviare la sessione: 1. Vai su **Settings > Secrets** e aggiungi `SLACK_WEBHOOK_URL` 2. Devin accede ai segreti come variabili d'ambiente, quindi non finiscono mai hardcoded nel tuo codice sorgente. I segreti dell'organizzazione devono essere aggiunti **prima** di avviare la sessione — vengono iniettati all'avvio della sessione. In alternativa, puoi fornire i segreti durante la sessione usando la chat e Devin ti chiederà in modo proattivo le credenziali di cui ha bisogno quando rileva variabili d'ambiente mancanti. Una volta avviata la sessione, puoi usare i comandi slash per guidare il flusso di lavoro di Devin: * **`/plan`** — Chiedi a Devin di creare un piano di implementazione dettagliato prima di scrivere qualsiasi codice. Esamina il piano e suggerisci modifiche prima che inizi a implementare. * **`/test`** — Chiedi a Devin di eseguire tutti i test e verificare il suo lavoro. Usalo dopo ogni traguardo importante per individuare i problemi in anticipo. * **`/review`** — Chiedi a Devin di rivedere il proprio codice per bug, casi limite e problemi di stile prima di aprire la pull request (PR). Questi comandi funzionano in qualsiasi momento durante la sessione: usa `/plan` all'inizio, `/test` dopo che ogni funzionalità è stata implementata e `/review` prima della PR finale. Devin tratta gli strumenti interni come qualsiasi funzionalità di produzione — scrive il codice, aggiunge i test e poi apre l'app nel suo browser integrato per verificare che l'interfaccia utente funzioni end-to-end. 1. **Esamina la tua codebase** — Trova i componenti `DataTable` e `Calendar`, legge il tuo schema Prisma e studia il layout esistente della pagina `/internal/` 2. **Crea la migrazione del database** — Aggiunge le tabelle `pto_requests` e `pto_balances` tramite Prisma 3. **Costruisce le pagine** — Modulo per l'invio delle richieste, coda di approvazione per i manager, vista calendario e dashboard dei saldi sotto `/internal/pto` 4. **Integra Slack** — Invia notifiche webhook quando le richieste vengono inviate e quando vengono approvate o rifiutate 5. **Scrive i test** — Test unitari per i calcoli dei saldi PTO e il rilevamento delle sovrapposizioni di date, test API per gli endpoint delle richieste, test di integrazione per il flusso di approvazione 6. **Apre l'app nel suo browser** — Naviga in ogni pagina, invia una richiesta PTO di test, la approva dalla vista del manager, verifica che il calendario si aggiorni, controlla i numeri nella dashboard e testa casi limite come date sovrapposte e saldi superati 7. **Apre una PR** — Consegna tutto: migrazione, script di seed, codice dell'applicazione, test e una sezione del README che spiega come usare lo strumento La verifica nel browser intercetta problemi che i test automatizzati non rilevano — layout dei moduli non corretti, un calendario che viene visualizzato ma non risponde ai clic, o un pulsante di invio che non svuota il modulo dopo l'invio riuscito. Una volta che il tool di base funziona, aggiungi funzionalità nelle sessioni successive: ```txt Add PTO conflict detection theme={null} Quando un dipendente invia una richiesta di PTO, verifica se qualcun altro del suo team è già assente nelle stesse date. Mostra un avviso nella UI: "Altri 2 membri del tuo team sono assenti dal 20 al 22 novembre." Non bloccare la richiesta, limitati a segnalare la sovrapposizione così che i manager possano pianificare. ``` ```txt Build a CSV export for HR theme={null} Aggiungi un pulsante nella dashboard PTO che esporti tutti i periodi di assenza approvati del trimestre corrente come CSV. Colonne: nome del dipendente, date, tipo, giorni utilizzati, saldo residuo. HR lo scarica ogni mese per le buste paga. ``` Quando Devin apre la PR, utilizza [Devin Review](https://app.devin.ai/review?utm_source=docs\&utm_medium=use-case-gallery) per esaminare le modifiche. Devin Review ha il contesto completo della tua codebase e può individuare bug, problemi di sicurezza e incoerenze di stile in tutto il diff.

{title}