Session F – CE ProductList mit Agent

Legende:

Vorbildlich

Problematisch

Achtung / Hinweis

Lerntipp

📋 Hintergrund

Ein neues TYPO3-Content-Element ProductList soll vollständig implementiert werden: TCA, TCA-Inline-Produkte (mit Name, Kategorie via sys_category, Beschreibung, Bild, Preis), Fluid-Template, TypoScript-Einbindung und eine Vue-Komponente mit Sortierung und Kategoriefilter. Dafür existiert ein .agent.md-File (/.github/agents/create-content-element.agent.md), das Copilot alle Projektkonventionen mitteilt.

🤖

Agent-File ist der Schlüssel. "do your job" als Eröffnungsprompt funktioniert nur, weil das Agent-File alle notwendigen Konventionen enthält: Namensschema (mm_-Präfix), Dateistruktur, TCA-Standards, welche DataProcessors das mmpackage bereitstellt. Ohne Agent-File würde "do your job" scheitern.

🔄 Session-Ablauf im Überblick

1 "do your job" → Agent fragt fehlende Pflichtangaben ab

2 Vollständige Spezifikation → Agent fragt 3 fehlende Details → "entscheide selbst" → Defaults vorgeschlagen

3 "passt" → Agent implementiert vollständig: TCA, TCA-Inline, Template, TypoScript, Vue-Komponente

4 "nutze sys_category relation" → gezielter Standard-Upgrade (TYPO3 13-konform)

5 translate.js-Integration → Agent erkennt Projektmuster selbstständig

6 "verallgemeinere die Hinweise zum mmpackage" → Agent-File wird verbessert

💬 Session-Austausche

Austausch 1 — Agent-Aktivierung

Entwickler

do your job

✓Delegation statt Beschreibung. "Do your job" funktioniert, weil das Agent-File create-content-element.agent.md alle notwendigen Konventionen enthält. Der Agent weiß, was er tun soll – er fragt nur die fehlenden Angaben ab.

💡Agent-Files sind Einmalarbeit mit Dauerrendite. Diese zwei Wörter funktionieren nur, weil jemand einmal ein vollständiges Agent-File geschrieben hat. Das ist die Investition, die sich täglich auszahlt.

Copilot

Auftrag verstanden: Ich bereite die Erstellung eines neuen TYPO3-Content-Elements vor.

Plan (Checkliste):
– Projektregeln geprüft.
– Erforderliche Angaben für das neue Element abfragen.
– Nach Ihrer Antwort die Dateien gemäß Konventionen erstellen.

Bitte gib mir die fehlenden Angaben:
1. Elementname (ohne Präfix): z.B. my_element
2. Titel (Backend-Label)
3. Kurze Beschreibung (1 Satz)
4. Benötigte Felder
5. Icon (TYPO3 Core Icon)
6. Einfügen nach welchem CType

✓Plan + Checkliste als Bestätigung. Der Agent wiederholt seinen Plan ("Checkliste") bevor er fragt. Das zeigt dem Entwickler, dass das Agent-File korrekt geladen wurde.

✓Vollständige Anforderungsliste. Der Agent kennt alle Pflichtangaben aus dem Agent-File und fragt strukturiert ab – keine versteckten Felder, die später fehlen.

Austausch 2 — Spezifikation + "entscheide selbst"

Entwickler

erstelle ein content element für eine produktliste. es soll ProductList heißen, einen Titel als Überschrift haben und eine kleine Beschreibung. Produkte sollen als TCA Inline Elemente dynamisch in der Liste angelegt werden. Jedes Produkt hat einen Namen, Kategorie, Beschreibung, Bild und Preis. Die Liste der Produkte soll im Frontend per Vue Komponente gerendert werden. Der Nutzer soll die Liste sortieren können und nach Kategorien filtern.

[Agent fragt 3 fehlende Details: Name, Icon, Insert-Position]

entscheide selbst

✓Vollständige fachliche Spezifikation. Alle inhaltlichen Anforderungen sind beschrieben: Felder, TCA Inline, Vue-Rendering, Sortierung, Kategoriefilter. Das ist mehr als genug für den Agenten.

✓"Entscheide selbst" für technische Details. Name, Icon und Insert-Position sind keine fachlichen, sondern technische Konventionsfragen. Der Agent kennt das Projekt – er kann diese Entscheidungen selbst treffen.

💡"Entscheide selbst" ist effizient, nicht faul. Wer jeden technischen Default selbst festlegen muss, vergeudet Zeit. Der Agent kennt das Namensschema (mm_-Präfix), Standard-Icons und Insert-Positionen.

Copilot

Du sagst "entscheide selbst" – ich schlage folgende Defaults vor:

1. Elementname: product_list → CType mm_product_list
2. Icon: content-table
3. Einfügen nach CType: textmedia

Wenn das passt, lege ich alles an. Alternativ kannst du mir die drei Werte geben.

✓Defaults transparent gemacht. Der Agent schlägt vor statt einfach zu handeln. Das gibt dem Entwickler die Chance zur Korrektur, ohne die Entscheidungslast für Trivialitäten.

✓Namenskonvention korrekt angewandt. mm_product_list – der mm_-Präfix kommt aus dem Agent-File. Ohne das File würde Copilot einfach product_list oder tx_extension_productlist nehmen.

Austausch 3 — Vollständige Implementierung

Entwickler

passt

✓Minimaler Bestätigungsprompt. Ein Wort reicht. Der Agent hat alle Angaben, kennt alle Konventionen, hat die Defaults bestätigt bekommen. Ab hier läuft alles autonom.

Copilot

[erstellt ~12 Dateien autonom:]

– TCA/mm_product_list.php: CType-Definition, fields header/bodytext
– TCA/tx_mmsitepackage_product.php: Inline-Produkt-Tabelle mit name, category, description, image, price
– ext_tables.sql: neue Tabelle tx_mmsitepackage_product
– TypoScript/Setup.typoscript: CE-Rendering-Config, DataProcessor
– Templates/ContentElements/ProductList.html: Fluid-Template mit Vue-Mount-Point
– Resources/Public/JavaScript/ProductList.vue: Vue-Komponente mit Sortierung und Kategoriefilter
– Resources/Public/JavaScript/ProductList.js: Vue-App-Bootstrap
– Configuration/TCA/Overrides/tt_content.php: CType-Registrierung
– Configuration/TCA/Overrides/sys_category.php: Kategorie-Relation
– Resources/Private/Language/locallang_db.xlf: Labels für alle Felder

✓Vollständiger Full-Stack-Output. Backend-TCA, Datenbank-Schema, TypoScript, Fluid-Template, Vue-Komponente, Labels – alles auf einmal. Das ist der Vorteil eines gut befüllten Agent-Files.

⚠Category als Textfeld implementiert. Das initiale Kategorie-Feld ist ein einfaches Input, nicht eine sys_category-Relation. Das ist fachlich unvollständig – aber korrigierbar (siehe Austausch 4).

Austausch 4 — TYPO3-Standard-Upgrade

Entwickler

nutze für das feld category eines produktes eine sys_category relation, halte die an die TYPO3 13 standards

✓Gezielter Standard-Upgrade. Statt alles nochmal zu spezifizieren, wird nur der eine Punkt korrigiert. "Halte die an TYPO3 13 Standards" gibt Copilot den Kontext ohne langes Erklären.

💡TYPO3-Version immer angeben. sys_category-Relations haben sich zwischen TYPO3 11, 12 und 13 verändert (MM-Tabellen, Slug-Felder, TCA-Typen). Die Versionsnummer sichert korrekten Code.

Copilot

Ich ändere das Kategorie-Feld von einfachem Input zu einer TYPO3-Kategorie-Relation gemäß TYPO3 13-Standards.

[aktualisiert tx_mmsitepackage_product.php: type='category', relationship='manyToMany']

Das Feld nutzt jetzt den nativen TYPO3 13 category-Type mit automatischer MM-Tabelle über sys_category_record_mm – kein manueller MM-Eintrag in ext_tables.sql nötig.

✓Nativer TYPO3 13 category-Type. TYPO3 13 hat einen dedizierten type='category' in TCA, der MM-Tabellen automatisch verwaltet. Copilot kennt diesen Standard und wendet ihn korrekt an.

✓Kein unnötiger SQL-Overhead. Die MM-Tabelle sys_category_record_mm ist TYPO3-core-seitig bereits vorhanden – kein manueller ext_tables.sql-Eintrag nötig. Copilot erklärt das proaktiv.

Austausch 5 — Projektmuster-Integration (translate.js)

Entwickler

über includeLanguageLabelFiles sind labels der frontend.xlf automatisch im frontend verfügbar, der in der translate.js ist eine importierbare Funktion, die Zugriff auf diese labels ermöglicht. passe die frontend labels für die produktliste entsprechend an

✓Projektspezifisches Muster erklärt. inlineLanguageLabelFiles + translate.js ist ein projekt-eigenes Pattern, das Copilot nicht kennen kann. Der Entwickler erklärt es kurz und präzise – Copilot passt die Vue-Komponente entsprechend an.

✓Kein Boilerplate nötig. Statt Copy-Paste aus anderen Komponenten als Kontext, reicht eine kurze Beschreibung. Copilot sucht selbstständig in der Codebase nach translate.js und versteht das Muster.

Copilot

Ich passe die Implementierung an, um das bestehende inlineLanguageLabelFiles-System mit translate.js zu nutzen, anstatt Labels über Props zu übergeben.

[aktualisiert ProductList.vue: importiert translate aus translate.js, ersetzt hardcodierte Strings durch Aufrufe wie translate('tx_mmsitepackage.productlist.sort_by')]

[ergänzt frontend.xlf mit allen UI-Labels: sort_by, filter_by_category, all_categories, price_asc, price_desc, name_asc, name_desc]

✓Komplettes i18n-Setup auf einmal. Copilot aktualisiert die Vue-Komponente und ergänzt gleichzeitig die XLF-Datei mit allen nötigen Labels. Kein manuelles Nacharbeiten.

💡Projektmuster sind Copilot-Konfiguration. translate.js-Muster ins Agent-File aufnehmen! Dann muss es beim nächsten Content Element nicht mehr erklärt werden.

Austausch 6 — Agent-File verbessern

Entwickler

verallgemeinere die Hinweise zum mmpackage, denn dieses hat nicht nur den CategoryProcessor

✓Session endet mit Agent-File-Verbesserung. Das ist vorbildlich: Erkenntnisse aus der Session fließen zurück in die Grundlage für zukünftige Sessions. Jedes CE verbessert die Basis für das nächste.

✓Präzise Verbesserungsanweisung. "Verallgemeinere die Hinweise zu mmpackage" ist klar – nicht "mach das Agent-File besser". Copilot weiß genau, welcher Abschnitt gemeint ist.

Copilot

Änderungen in /.github/agents/create-content-element.agent.md:

– Allgemeiner Hinweis zu mmpackage-DataProcessing ergänzt (mehrere Prozessoren, TypoScript-Aliases, Defaults im Repo prüfen)
– Best Practices: Hinweis auf "passenden mmpackage-Prozessor" statt ausschließlich CategoryProcessor

Wenn du noch weitere mmpackage-spezifische Patterns aufnehmen willst (z.B. ExtendedFilesProcessor-Defaults), sag Bescheid.

✓Proaktiver Hinweis auf weiteren Verbesserungsbedarf. Copilot schlägt selbst vor, weitere Patterns (ExtendedFilesProcessor) aufzunehmen. Das zeigt, dass er die Codebase versteht und Lücken erkennt.

🎯 Fazit

✓ Agent-gesteuerte Entwicklung in ihrer besten Form

Diese Session zeigt das volle Potenzial des Agent-File-Ansatzes. Vom "do your job" bis zum fertigen Full-Stack-Content-Element sind es sechs Austausche – bei einem manuellen Prozess wären es Stunden. Das Geheimnis ist das Agent-File, das alle Projekt-Konventionen vorab kodiert.

Drei Muster stechen heraus: "entscheide selbst" delegiert technische Details an Copilot und spart Entscheidungsaufwand. "passt" startet die Implementierung mit einem einzigen Wort. Und die abschließende Agent-File-Verbesserung ist die wichtigste Investition der Session – sie macht jede zukünftige CE-Session schneller.

Das einzige schwache Moment: Austausch 3 liefert anfänglich ein einfaches Input-Feld statt einer sys_category-Relation. Das ist ein klares Signal: Felddefinitionen präzise spezifizieren oder den TYPO3-Standard explizit fordern. Beides geht schnell – und Austausch 4 zeigt, wie einfach die Korrektur ist.

🎓 Learnings

💡

7 Learnings aus Session F

Agent-Files sind der größte Effizienz-Hebel

Ein vollständiges .agent.md-File für wiederkehrende Aufgaben (CE erstellen, Service anlegen, Extension erweitern) ist die beste Investition der ersten Woche. Es macht aus einem 30-Minuten-Prompt ein "do your job".

"Entscheide selbst" für technische Konventionsfragen

Name, Icon, Insert-Position sind keine fachlichen Entscheidungen – das sind Konventionen. Copilot kennt das Namensschema aus dem Agent-File. "Entscheide selbst" ist kein Kontrollverlust, sondern effiziente Delegation.

TYPO3-Version in Korrekturen immer nennen

"Halte die an TYPO3 13 Standards" gibt Copilot den Versionkontext für API-Entscheidungen. TCA, DataProcessors und Relations ändern sich zwischen Versionen. Ohne Versionsangabe wählt Copilot den "sichersten" (meist älteren) Ansatz.

Projektmuster kurz erklären, nicht copypaste

Für translate.js-Integration reicht eine kurze Beschreibung: "in translate.js ist eine importierbare Funktion". Copilot sucht die Datei selbst und versteht das Muster. Keine langen Erklärungen, kein Copy-Paste als Kontext.

Felddefinitionen vollständig spezifizieren

Copilot implementiert "Kategorie" als einfaches Input, wenn keine TYPO3-Standardrelation gefordert wird. Bei Feldern, die einen spezifischen TCA-Typ brauchen (sys_category, sys_file_reference), explizit benennen.

Session mit Agent-File-Verbesserung abschließen

Jede Session bringt neue Erkenntnisse über Projekt-Konventionen. Diese gehören zurück ins Agent-File. Das ist der Compounding-Effekt: Jede Session macht alle zukünftigen Sessions besser.

Vue + TYPO3: inlineLanguageLabelFiles ist der Standard

Für i18n in Vue-Komponenten innerhalb von TYPO3 den inlineLanguageLabelFiles-Mechanismus nutzen: Labels in XLF definieren, per TypoScript einbinden, via translate.js (oder direkt via TYPO3.lang) in Vue verwenden. Kein Props-Overhead.

📊 Session-Qualität im Überblick

Element	Qualität	Anmerkung
Austausch 1 – "do your job"	✓ Exzellent	Funktioniert dank Agent-File; Checkliste bestätigt korrekte Aktivierung
Austausch 2 – Spezifikation	✓ Sehr gut	Vollständige fachliche Anforderungen + "entscheide selbst" für Technisches
Austausch 3 – Implementierung	⚠ Gut mit Lücke	Full-Stack-Output sehr gut; Category-Feld ohne TYPO3-Standardrelation
Austausch 4 – sys_category	✓ Sehr gut	Gezielter Standard-Upgrade; TYPO3 13 nativer category-Type korrekt angewandt
Austausch 5 – translate.js	✓ Sehr gut	Kurze Musterbeschreibung reicht; vollständiges i18n-Setup inklusive XLF
Austausch 6 – Agent-File	✓ Vorbildlich	Session endet mit Basis-Verbesserung für alle zukünftigen Sessions

🔗 Weitere Walk-Throughs

→ RTE Farbtabellen CKEditor4 → MCP Tool implementieren → Iterative Test-Generierung → TCA-Migrationen TYPO3 13 → LLL-Referenzen TYPO3 14

Content Element ProductList

📋 Hintergrund

🔄 Session-Ablauf im Überblick

💬 Session-Austausche

🎯 Fazit

✓ Agent-gesteuerte Entwicklung in ihrer besten Form

🎓 Learnings

7 Learnings aus Session F

Agent-Files sind der größte Effizienz-Hebel

"Entscheide selbst" für technische Konventionsfragen

TYPO3-Version in Korrekturen immer nennen

Projektmuster kurz erklären, nicht copypaste

Felddefinitionen vollständig spezifizieren

Session mit Agent-File-Verbesserung abschließen

Vue + TYPO3: inlineLanguageLabelFiles ist der Standard

📊 Session-Qualität im Überblick

🔗 Weitere Walk-Throughs