Möchtest du das nicht manuell einrichten? Füge einen Link zu dieser Seite in eine Devin-Sitzung ein und bitte Devin, alles für dich einzurichten. Wenn du in deiner App bereits interne Tools hast, verwende [Ask Devin](https://app.devin.ai/search?utm_source=docs\&utm_medium=use-case-gallery), um die bestehenden Muster zu verstehen, bevor du deine Spezifikation schreibst. Das ist besonders hilfreich, wenn das neue Tool zur vorhandenen Architektur passen soll: ```txt Scope Architektur interner Tools theme={null} Zeig mir, wie unsere bestehenden internen Tools aufgebaut sind: 1. Welche Seiten existieren unter /internal/ und wie sind sie aufgebaut? 2. Wie gehen interne Seiten mit Authentifizierung und rollenbasierter Zugriffskontrolle um? 3. Welche gemeinsamen UI-Komponenten werden verwendet (Tabellen, Formulare, modale Dialoge)? 4. Wie sind Datenbankmigrationen in unserem Prisma-Schema strukturiert? 5. Gibt es bestehende Benachrichtigungsmuster (Slack, E-Mail)? ``` Nutze die Antworten, um deine Spezifikation mit konkreten Dateireferenzen, Komponentennamen und Mustern zu ergänzen, damit Devin etwas erstellt, das konsistent mit deinen bestehenden Tools ist. Du kannst auch direkt aus Ask Devin eine Devin-Session starten; dabei werden alle gewonnenen Informationen als Kontext übernommen. Interne Tools – PTO-Tracker, Admin-Oberflächen, Datenskripte, CLI-Utilities – sind essenziell, werden aber selten priorisiert. Sie eignen sich ideal für Devin, weil die Anforderungen klar definiert sind, die Zielgruppe dein Team ist und „funktioniert zuverlässig“ wichtiger ist als ein pixelgenaues Design. Sei präzise darin, was das Tool tut, welche Daten es speichert und mit welchen Services es sich verbindet. Je mehr Details du angibst, desto näher kommt die erste Version dem, was du brauchst. ```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 ``` Du kannst deine Spezifikation auch iterativ mit Ask Devin verfeinern – füge einen groben Entwurf ein und bitte es, Lücken zu identifizieren oder Verbesserungen auf Basis deiner Codebasis vorzuschlagen. Übergeben Sie alle API keys oder Tokens, die Devin benötigt, über [Secrets](/de/product-guides/secrets) – in diesem Fall die Slack-Webhook-URL. Der einfachste Ansatz ist, sie vor dem Start der Session als Organisations-Secrets zu speichern: 1. Gehen Sie zu **Settings > Secrets** und fügen Sie `SLACK_WEBHOOK_URL` hinzu. 2. Devin greift als Umgebungsvariablen auf Secrets zu, sodass sie niemals hart in Ihrem Quellcode codiert werden. Organisations-Secrets müssen **vor** dem Start der Session hinzugefügt werden – sie werden beim Start der Session injiziert. Alternativ können Sie während der Session über den Chat Secrets bereitstellen, und Devin wird Sie außerdem proaktiv nach allen benötigten Zugangsdaten fragen, wenn fehlende Umgebungsvariablen festgestellt werden. Sobald die Session gestartet ist, kannst du Slash-Befehle verwenden, um Devins Workflow zu steuern: * **`/plan`** — Bitte Devin, einen ausführlichen Implementierungsplan zu erstellen, bevor es mit dem Schreiben von Code beginnt. Überprüfe den Plan und schlage Änderungen vor, bevor Devin mit der Umsetzung startet. * **`/test`** — Weise Devin an, alle Tests auszuführen und seine Arbeit zu überprüfen. Verwende diesen Befehl nach jedem größeren Meilenstein, um Probleme frühzeitig zu erkennen. * **`/review`** — Bitte Devin, seinen eigenen Code auf Bugs, Edge Cases und Stilprobleme zu überprüfen, bevor der PR (Pull Request) eröffnet wird. Diese Befehle kannst du jederzeit während der Session verwenden — nutze `/plan` am Anfang, `/test`, nachdem jede Funktionalität fertiggestellt ist, und `/review` vor dem finalen PR. Devin behandelt interne Tools wie jedes andere Feature in der Produktion – es schreibt den Code, fügt Tests hinzu und öffnet dann die App in seinem integrierten Browser, um zu überprüfen, dass das UI End-to-End funktioniert. 1. **Untersucht eure Codebase** — Findet eure `DataTable`- und `Calendar`-Komponenten, liest euer Prisma-Schema und analysiert das bestehende `/internal/`-Seitenlayout 2. **Erstellt die Datenbankmigration** — Fügt `pto_requests`- und `pto_balances`-Tabellen mit Prisma hinzu 3. **Baut die Seiten** — Formular zur Antragseinreichung, Warteschlange für Manager-Genehmigungen, Kalenderansicht und Guthaben-Dashboard unter `/internal/pto` 4. **Integriert Slack** — Sendet Webhook-Benachrichtigungen, wenn Anträge eingereicht werden und wenn sie genehmigt oder abgelehnt werden 5. **Schreibt Tests** — Unit-Tests für PTO-Guthabenberechnungen und Erkennung von Datumsüberschneidungen, API-Tests für die Request-Endpunkte, Integrationstests für den Genehmigungs-Workflow 6. **Öffnet die App in seinem Browser** — Navigiert zu jeder Seite, reicht einen PTO-Testantrag ein, genehmigt ihn in der Manager-Ansicht, verifiziert die Aktualisierung des Kalenders, prüft die Dashboard-Zahlen und testet Randfälle wie sich überschneidende Zeiträume und überschrittene Guthaben 7. **Öffnet einen PR (Pull Request)** — Liefert alles: Migration, Seed-Skript, Anwendungscode, Tests und einen README-Abschnitt, der erklärt, wie das Tool zu verwenden ist Die Browser-Verifizierung fängt Probleme ab, die automatisierte Tests übersehen – kaputte Formular-Layouts, ein Kalender, der zwar gerendert wird, aber nicht auf Klicks reagiert, oder ein Submit-Button, der das Formular nach erfolgreicher Übermittlung nicht leert. Sobald das Basistool funktioniert, füge in Folgesitzungen weitere Funktionen hinzu: ```txt PTO-Konflikterkennung hinzufügen theme={null} Wenn ein*e Mitarbeiter*in einen Antrag auf bezahlten Urlaub (PTO) stellt, prüfe, ob jemand anderes aus dem Team im gleichen Zeitraum bereits abwesend ist. Zeige eine Warnung in der UI an: „2 andere Personen in deinem Team sind vom 20.–22. Nov abwesend.“ Blockiere den Antrag nicht, sondern mache die Überschneidung nur sichtbar, damit Manager entsprechend planen können. ``` ```txt CSV-Export für HR erstellen theme={null} Füge dem PTO-Dashboard eine Schaltfläche hinzu, die alle genehmigten Abwesenheiten für das aktuelle Quartal als CSV exportiert. Spalten: Name der Mitarbeiterin / des Mitarbeiters, Daten, Art, genutzte Tage, verbleibendes Guthaben. Die Personalabteilung (HR) lädt diese Datei monatlich für die Gehaltsabrechnung herunter. ``` Sobald Devin den PR eröffnet hat, verwenden Sie [Devin Review](https://app.devin.ai/review?utm_source=docs\&utm_medium=use-case-gallery), um die Änderungen zu überprüfen. Devin Review hat den vollständigen Kontext Ihrer Codebasis und kann Bugs, Sicherheitsprobleme und Stilinkonsistenzen im gesamten Diff erkennen.

{title}