Next.js-Projektplanungs-Fähigkeit (nextjs-plan)
Eine strukturierte Orchestrierungsfähigkeit zur Planung von Next.js App Router-Anwendungen. Beim Aufruf extrahiert sie technische Spezifikationen aus vorhandenen Workspace-Dateien, führt ein gezieltes Grilling-Interview zu Benutzeranforderungen durch und gibt kanonische Projektspezifikationen (docs/project.json), typsichere Code-Registries in lib/, Design-Briefings in docs/design/ und eine 7-phasige modulare Implementierungs-Roadmap in docs/plan/ aus.
Workflow-Übersicht
flowchart TD
Invoke["Aufruf /nextjs-plan"] --> Step1["1. Automatisierte Workspace-Inspektion<br/>(Abhängigkeiten, Verzeichnislayout, Styles, Konfigurationen, Routen extrahieren)"]
Step1 --> Step2["2. Grilling-Interview zu Seiten & Anforderungen<br/>(Seiten ➔ Abschnitte ➔ Komponenten)"]
Step2 --> Step3["3. Kanonische Spezifikationen generieren<br/>(docs/project.json & lib/ Registries)"]
Step3 --> Step4["4. Strategie & Designsystem dokumentieren<br/>(docs/design/ 01-strategie, 02-sitemap, 03-tokens)"]
Step4 --> Step5["5. 7-Phasen-Modularen-Implementierungsplan generieren<br/>(docs/plan/ README.md & 01-07 Phasendateien)"]
Step5 --> Step6["6. Abschluss & Zusammenfassung<br/>(Zusammenfassungs-Dashboard präsentieren; KEINE nachgelagerten Fähigkeiten aufrufen)"]
Standardisierte Projektverzeichnis-Architektur
├── lib/ # Typsichere Next.js-Code-Source of Truth
│ ├── routes.ts # Zentrale Routen-Registry & Pfad-Builder
│ ├── site-config.ts # Zentrale Site-Metadaten, Autoren-Bio, Social-Links
│ └── utils.ts # Tailwind cn-Helfer
├── docs/ # Architektur, Planung & Design-Begründung
│ ├── project.json # Kanonische maschinenlesbare Spezifikationen
│ ├── plan/ # 7-Phasen-Modulare-Implementierungs-Roadmap
│ │ ├── README.md # Master-Dashboard: Fortschrittsverfolgung & Phasenindex
│ │ ├── 01-discovery-and-architecture.md
│ │ ├── 02-environment-and-cicd.md
│ │ ├── 03-system-health-probe.md
│ │ ├── 04-core-foundations.md
│ │ ├── 05-pages-and-components.md
│ │ ├── 06-server-functions-and-metadata.md
│ │ └── 07-integrations-and-release.md
│ ├── design/ # UX-, UI- & Bildschirm-Spezifikationen
│ │ ├── 01-strategy-brief.md # Zweck, Personas, Ziele, KPIs, Benchmarks
│ │ ├── 02-sitemap-and-routes.md # Seiteninventar, Bereichshierarchie, Rendering-Matrix
│ │ ├── 03-ui-design-tokens.md # Semantische CSS-Tokens, Typografie, Komponenten-Primitive
│ │ └── components/ # Komponenten-Design-Spezifikationen & Stitch-Screenshots
│ └── adr/ # Architecture Decision Records
Schritt-für-Schritt-Ausführungs-Runbook
1. Automatisierte Workspace-Inspektion (Null Unterbrechung)
[!IMPORTANT] Zuerst inspizieren, dann fragen. Fordere den Benutzer niemals nach Fakten, die direkt aus den Workspace-Dateien abgeleitet werden können.
- Workspace-Kontext scannen: Untersuche
package.json, Lockfiles (pnpm-lock.yaml,bun.lockb), Routing-Struktur (app/vssrc/app/), Komponentenverzeichnis,app/globals.css, UI-Bibliotheken (shadcn/ui,lucide-react, Animationen),next-intl-Setup (rootmessages/-Ordner), vorhandene Routen (page.tsx,route.ts) sowie Test- und Docker-Konfigurationen. - Für die vollständige Inspektions-Checkliste konsultiere workspace-inspection.md.
2. Benutzer-Grilling-Interview (Seiten ➔ Abschnitte ➔ Komponenten)
- Adaptives Grilling-Interview durchführen: Binde den Benutzer in strukturierten Runden unter Verwendung der Grilling-Frontier-Methodik ein. Nummeriere jede Frage und gib empfohlene Antworten.
- Verbindliche Grilling-Reihenfolge:
- Seiten-Grilling: Liste alle erforderlichen Webseiten und Ziel-URL-Routen auf.
- Abschnitts-Grilling: Identifiziere für jede Seite alle Inhaltsabschnitte von oben nach unten.
- Komponenten-Grilling: Definiere für jeden Abschnitt alle erforderlichen UI-Komponenten.
- Kernfragen: Problemstellung, Ziel-Personas, Authentifizierung, Datenebene/ORM, i18n-Sprachen & RTL, visueller Ästhetik-Stil und Bereitstellungsziel.
- Für Interview-Vorlagen und Entscheidungsbaum-Regeln konsultiere grilling-interview.md.
3. Kanonische Spezifikationen & typsicheren Code generieren
-
docs/project.jsonerstellen: Befülle technische Metadaten (Paketmanager, Komponentenverzeichnisse, Styles, UI-/Animations-/Testbibliotheken, unterstützte Sprachen, Wörterbuchpfade). Konsultiere project-schema.md und verwende project.json.template. -
lib/routes.tserstellen: Generiere typsichere Routen-Registry aus routes.ts.template. -
lib/site-config.tserstellen: Generiere zentrales Site-Profil und Metadaten aus site-config.ts.template.
4. Designstrategie in docs/design/ dokumentieren
-
docs/design/01-strategy-brief.mderstellen: Verwende 01-strategy-brief.md.template. -
docs/design/02-sitemap-and-routes.mderstellen: Verwende 02-sitemap-and-routes.md.template. -
docs/design/03-ui-design-tokens.mderstellen: Verwende 03-ui-design-tokens.md.template.
5. 7-Phasen-Modularen-Implementierungs-Roadmap generieren (docs/plan/)
-
docs/plan/-Verzeichnis erstellen: Stelle die modularen Plandateien unter Verwendung der Vorlagen in resources/templates/plan/ bereit:docs/plan/README.md(Master-Fortschritts-Dashboard)docs/plan/01-discovery-and-architecture.md(Phase 1)docs/plan/02-environment-and-cicd.md(Phase 2)docs/plan/03-system-health-probe.md(Phase 3:/api/healthLiveness-Probe)docs/plan/04-core-foundations.md(Phase 4: Umgebungsvariablen, i18n, Theme-Tokens, Layouts, OTel)docs/plan/05-pages-and-components.md(Phase 5: Kanonische Seiten- & Komponenten-Checklisten mit SEO & Support-Dateien)docs/plan/06-server-functions-and-metadata.md(Phase 6: Server Actions, API-Routen, Globales SEO)docs/plan/07-integrations-and-release.md(Phase 7: Integrationen & Produktions-Release)
- Single Source of Truth mit verbindlichen seitenbezogenen Dateien: Phase 5 (
05-pages-and-components.md) ist die exklusive kanonische Checkliste für Seiten und Komponenten. Erzwinge für jede Seite Unter-Checklisten-Aufgaben fürpage.tsx,loading.tsx,error.tsx,generateMetadata,JSON-LD SchemaundgenerateStaticParams()(für dynamische Routen). - Seitenabschluss-Regel: Markiere in Phase 5 ein Seiten-Element als
- [x]genau dann, wenn alle zugehörigen Komponenten-Unter-Checklisten-Elemente und SEO-/Support-Aufgaben auf Seitenebene abgeschlossen sind. - Konsultiere plan-checklist-structure.md für vollständige Phasenrichtlinien.
6. Abschluss & Fertigstellungs-Gate
- Präsentiere dem Benutzer einen präzisen Zusammenfassungsbericht mit Workspace-Ergebnissen, Spezifikationen in
docs/project.jsonund der Roadmap indocs/plan/README.md. - Rufe NICHT automatisch nachgelagerte Next.js-Fähigkeiten auf. Beende die Ausführung und erlaube dem Benutzer, den Plan zu überprüfen.
Randfälle & bekannte KI-Fallstricke
[!WARNING]
- Befehlsverkettung: Führe niemals zusammengesetzte Befehle mit
&&,||oder;in einer einzigen Zeile aus. Führe Terminal-Befehle immer einzeln aus.- Fragen vor dem Inspizieren: Frage den Benutzer nicht nach grundlegenden Fakten, die direkt aus
package.jsonoder Verzeichnislisten ausgelesen werden können.- Umgekehrte Meilenstein-Reihenfolge: Health-Probe (
/api/health) gehört in Phase 3, gefolgt von Core Foundations (i18n, Theme, Layouts, OTel) in Phase 4 vor der Seiten-/Komponenten-Implementierung.- Auslassen von seitenbezogenen Dateien: Lasse beim Erstellen von Phase 5-Checklisten niemals
loading.tsx,error.tsx,generateMetadataoder JSON-LD Schema-Aufgaben für irgendeine Seite aus.- Seitenlisten-Duplikation: Halte die gesamte Verfolgung von Seiten und Komponenten strikt in
docs/plan/05-pages-and-components.md.- Vorzeitiges Abhaken von Seiten: Eine Seite in Phase 5 muss
- [ ]bleiben, bis alle untergeordneten Komponenten und Support-Dateien auf Seitenebene abgeschlossen sind.- Falscher Wörterbuch-Speicherort: In Next.js i18n-Konfigurationen befinden sich Wörterbücher im root-
messages/(z. B.messages/en.json), niemals inapp/dictionaries.- Nachgelagerte Fähigkeiten auslösen: Löse nach Abschluss des Plans nicht automatisch Implementierungs- oder Styling-Fähigkeiten aus; stoppe und warte auf Benutzeranweisungen.
Ausgabe-Zusammenfassungs-Schema
Präsentiere nach Abschluss der Planungsphase die Zusammenfassung in diesem Format:
### Next.js-Projektplan abgeschlossen
- **Kanonische Spezifikationen**: `[docs/project.json](file:///...)`
- **Typsichere Registries**: `[lib/routes.ts](file:///...)` | `[lib/site-config.ts](file:///...)`
- **Design- & Strategie-Spezifikationen**: `[docs/design/01-strategy-brief.md](file:///...)`, `[docs/design/02-sitemap-and-routes.md](file:///...)`, `[docs/design/03-ui-design-tokens.md](file:///...)`
- **Modulares Roadmap-Dashboard**: `[docs/plan/README.md](file:///...)`
- **Identifizierte Seiten**: X insgesamt gemappte Routen
- **Identifizierte Komponenten**: Y insgesamt über Z Abschnitte katalogisierte Komponenten
- **Abgeschlossene Phasen**: N / 7 Phasen verifiziert
_Planung abgeschlossen. Überprüfe `docs/plan/README.md`, um mit dem Komponentendesign oder der Implementierung fortzufahren._
Referenzleitfäden & Vorlagen
- Workspace-Inspektionsleitfaden — Checkliste zur Codebase-Erkundung vor dem Interview.
- Grilling-Interview-Leitfaden — Mehrrunden-Frageprotokoll und Untersuchungsbereiche.
- Projekt-Schema-Referenz — Spezifikationsfelder und Validierungskriterien für
docs/project.json. - Plan-Architektur-Referenz — 7-Phasen-modulare Roadmap-Struktur und Seiten-Komponenten-Regeln.
- Projekt-JSON-Vorlage — Startschema für
docs/project.json. - Modulare Plan-Vorlagen — Startvorlagen für
docs/plan/. - Routes-TypeScript-Vorlage — Typsichere Routendefinitionen für
lib/routes.ts. - Site-Config-Vorlage — Zentrales Site-Profil für
lib/site-config.ts. - Strategie-Briefing-Vorlage — Vorlage für
docs/design/01-strategy-brief.md. - Sitemap- & Routen-Vorlage — Vorlage für
docs/design/02-sitemap-and-routes.md. - UI-Design-Tokens-Vorlage — Vorlage für
docs/design/03-ui-design-tokens.md. - Umgebungsvariablen-Beispiel-Vorlage — Single Source of Truth-Vorlage für
.env.example(umbenannt in.envfür Produktionsbereitstellungen). - Entwicklungsumgebungs-Vorlage — Standard-Entwicklungsvariablen für
.env.development(lokale Entwicklung, gitignoriert).