Diese Session ist der Ausgangspunkt des gesamten FAL-Feature-Zweigs. Jens hat Copilot zunächst gebeten, die bestehende Extension vollständig zu analysieren – eine klassische Onboarding-Strategie für Copilot in einem neuen Projekt. Danach folgte sofort das erste Feature-Planning: ein Toolset, das der KI Zugang zu TYPO3-Storages, Ordnern und Datei-Metadaten gibt.
Plan-Modus von Anfang an. Beide Austausche fanden im Plan-Modus statt – Copilot hat ausschließlich analysiert und geplant, aber noch keinen Code geschrieben. Die Implementierung erfolgte in separaten Sessions (MCP3–MCP5).
typo3-mcp-server extension by gathering comprehensive context about its structure, purpose, and implementation.ResourceFactory, FileRepository, StorageRepository).getAccessibleStorages(), getFolder(), resolvePathToFolder(), canAccessFile()FileAccessService vor – analog zum bestehenden TableAccessService. Das zeigt, dass Copilot das Architektur-Pattern aus der Analyse erkannt und konsequent anwendet.is_browsable-Prüfung werden in "Further Considerations" erwähnt – ohne dass der Prompt danach fragt. Das ist Production-Quality-Denken.BrowseFolderTool wird zu ListFilesTool, FileAccessService entfällt als separate Schicht. Der Plan hier ist ein guter erster Entwurf, nicht das finale Design.Diese Session illustriert eine bewährte Copilot-Strategie für neue Projekte: Zuerst eine vollständige Extension-Analyse anfordern, dann erst Features planen. Copilot baut sich dabei eine interne Karte der Codebase auf – die Qualität aller Folge-Prompts profitiert davon.
Der FAL-Plan in Austausch 2 ist ein gutes Beispiel dafür, wie detaillierte Constraints ("TYPO3 coding guidelines", "official TYPO3 APIs", "consuming AI") die Antwort-Qualität prägen. Copilot spiegelt den Plan exakt in der Architektursprache der bestehenden Extension.
Wichtige Erkenntnis: Pläne aus dem Plan-Modus sind Entwürfe, keine finalen Specs. Der tatsächlich implementierte Plan (Session MCP3) ist schlanker und eleganter. Das ist normal – Planung ist iterativ.
Vor dem ersten Feature-Prompt eine vollständige Codebase-Analyse anzufragen ("analyze this extension") ist eine effektive Onboarding-Strategie. Copilot versteht danach Architektur-Patterns, Namespace-Konventionen und Teststrategien – und wendet sie in Folge-Prompts automatisch an.
Ein vollständiger Feature-Prompt enthält: (1) Was gebaut wird, (2) Architektur-Constraints, (3) API/technische Constraints, (4) die Nutzerperspektive. Alle vier Dimensionen sind im Prompt "I need a new tool that..." enthalten – das ist warum Copilot einen so präzisen Plan liefert.
Der Hinweis, dass die Toolset-API von einer KI konsumiert wird, ist kein Marketing-Sprech. Er beeinflusst konkret das Interface-Design: Welche Felder werden zurückgegeben? Wie werden sie formatiert? Copilot berücksichtigt diesen Kontext bei Feldauswahl und Textformatierung.
Der hier erstellte Plan (mit FileAccessService, BrowseFolderTool, FileFormattingUtility) weicht vom tatsächlich implementierten Design ab. Das ist kein Fehler. Erste Pläne sind zu komplex, Implementierungen sind oft schlanker. Plan-Iteration ist Teil des Prozesses.
Copilots "Further Considerations" in Plänen enthalten oft wichtige unausgesprochene Anforderungen: Sicherheit (Pfad-Traversal), Performance (Paginierung), Erweiterbarkeit (EXIF, sys_file_reference). Diese sollte man aktiv lesen und entscheiden, welche davon in den Scope aufgenommen werden.
| Element | Qualität | Anmerkung |
|---|---|---|
| Austausch 1 – Prompt | ⚠ Ausreichend | Sehr kurz ("analyze this extension") – funktioniert nur mit Workspace-Kontext |
| Austausch 1 – Antwort | ✓ Sehr gut | Breite Analyse: Tools, Auth, Workspace-Transparenz, Tests, Beta-Status |
| Austausch 2 – Prompt | ✓ Sehr gut | Vier Dimensionen: Was, Architektur, API, Nutzerperspektive |
| Austausch 2 – Antwort | ✓ Gut | Konsistenter Service-Layer-Ansatz, gute Sicherheits-Überlegungen – aber Plan wird in MCP3 überarbeitet |