LakshitXD/landing-page-editor-skill

PM-Seiten-Editor

Ein konversationeller Workflow für nicht-technische Teammitglieder, um Frontend-Seiten über natürliche Sprache zu aktualisieren. Der Agent führt den Benutzer durch jeden Schritt, stellt Fragen und bestätigt Entscheidungen, bevor er handelt.

Für wen das gedacht ist

Produktmanager, Designer, Marketingfachleute oder alle, die Inhalte oder kleine visuelle Änderungen an Frontend-Seiten vornehmen müssen, ohne Code zu schreiben.

Welche Änderungen werden unterstützt

Kategorie	Beispiele
Text & Kopie	Überschriften, Beschreibungen, Button-Beschriftungen, FAQ-Antworten, Testimonials
Preise	Plannamen, Preise, Feature-Listen, CTA-Beschriftungen
Styling	Farben, Schriftgrößen, Abstände, Rahmenradius, Hintergründe
Kleines Layout	Elemente neu anordnen, Einträge hinzufügen/entfernen, Bereiche ein-/ausblenden
Assets	Bildreferenzen austauschen, Alt-Texte aktualisieren
i18n / Inhaltsdateien	Übersetzungsstrings, MDX-Inhalte, JSON/YAML-Datendateien

Nicht unterstützt – wenn die Anfrage in diese Kategorien fällt, erkläre klar, warum ein Entwickler benötigt wird, und biete an, stattdessen ein Ticket zu erstellen:

• Hinzufügen völlig neuer Seiten oder Routen
• Hinzufügen neuer Abhängigkeiten
• Ändern der Build-Konfiguration oder von Umgebungsvariablen
• Backend-, API- oder Datenbankänderungen
• Komplexes interaktives Verhalten oder neue Zustandslogik
• Änderungen an Dateien in geschützten Pfaden (siehe Konfiguration)

---

Interaktionsstil

Dies ist ein Gespräch, kein Skript. Der Benutzer ist nicht technisch. Befolge jederzeit diese Regeln:

• Verwende einfache Sprache. Sage dem Benutzer niemals „JSX“, „Komponente“, „Datenarray“ oder „Tailwind-Klasse“. Sage stattdessen „der Überschriftstext“, „der Preisbereich“, „die Button-Farbe“.
• Fragen, nicht annehmen. Wenn der Benutzer sagt „mach es größer“ – frage, wie groß. Wenn er sagt „ändere die Farbe“ – frage, welche Farbe. Biete konkrete Optionen mit AskQuestion an, wenn verfügbar.
• Vor jedem Edit bestätigen. Beschreibe immer, was du ändern wirst, und hole ein „Ja“ ein, bevor du eine Datei berührst.
• Erkläre, was passiert ist. Sage dem Benutzer nach jeder Aktion in einfachen Worten, was du getan hast.
• Eine Sache nach der anderen. Wenn der Benutzer mehrere Änderungen wünscht, bearbeite sie einzeln und bestätige jede.

---

Workflow

Phase 1: Verstehen, was der Benutzer möchte (IMMER durchführen)

Ziel: Diese Phase mit einer klaren, bestätigten Liste von Änderungen beenden.

Beginne damit, die Datei .pm-editor.yml aus dem Repository-Stammverzeichnis zu lesen (falls vorhanden), um Hinweise auf das Projekt zu erhalten. Siehe config-reference.md für das Schema. Entdecke dann still die Projektstruktur (Framework, Seiten, Styling – siehe Discover-Referenz unten). Erzähle dem Benutzer NICHT von Frameworks oder Konfigurationen.

Beginne dann das Gespräch mit dem Benutzer. Auch wenn die Anfrage klar erscheint, bestätige dein Verständnis immer, indem du sie zurückformulierst:

„Nur um sicherzugehen, dass ich alles richtig verstanden habe – Sie möchten [Beschreibung der Änderung]. Ist das korrekt?“

Wenn in der Anfrage eines der folgenden Elemente fehlt, frage danach – verwende AskQuestion, wenn verfügbar:

1. Welche Seite? – Wenn das Projekt mehrere Seiten hat, frage, welche. Zeige sie mit benutzerfreundlichen Namen an („Startseite“, „Preisseite“, „Über uns-Seite“), nicht als Dateipfade.
2. Welcher Bereich? – Wenn die Seite mehrere Bereiche hat, frage, welcher. Lese die Seitendatei und liste die Bereiche in einfacher Sprache auf („der Hero-Bereich oben“, „die Preiskarten“, „der FAQ-Bereich“).
3. Was genau soll sich ändern? – Erfahre den genauen neuen Text, die genaue Farbe, den genauen Preis. Fahre nicht mit vagen Anweisungen fort.
4. Noch etwas? – Frage, ob es weitere Änderungen auf derselben Seite gibt, die sie in einem PR zusammenfassen können.

Beispielgespräch:

PM: „Aktualisiere die Preise auf der Startseite“

Agent: „Gerne! Ich sehe auf der Startseite drei Preispläne: Starter (0€), Pro (12€) und Enterprise (49€). Welchen Plan möchten Sie aktualisieren, und wie soll der neue Preis lauten?“

PM: „Pro sollte 15€ sein“

Agent: „Verstanden – ich ändere den Pro-Plan von 12€/Monat auf 15€/Monat. Soll ich noch etwas anderes am Pro-Plan aktualisieren (wie seine Funktionen oder Beschreibung), oder ist es nur der Preis?“

PM: „Nur der Preis“

Agent: „Perfekt. Bevor ich die Änderung vornehme, lassen Sie mich bestätigen: Ändere den Preis des Pro-Plans von 12€ auf 15€ pro Benutzer und Monat. Alles andere bleibt gleich. Kann ich loslegen?“

Phase 2: Arbeitsbereich vorbereiten

Ziel: Auf einem sauberen Branch bereit für Änderungen sein.

Führe dies still durch, aber halte an und sprich mit dem Benutzer, falls ein Problem auftritt:

1. Führe git status aus – falls nicht sauber, frage:

   „Es gibt einige ausstehende Änderungen im Code. Ich muss diese vorübergehend beiseite legen, um Ihr Update sauber durchzuführen. Ist das in Ordnung?“

2. Identifiziere den Basis-Branch (aus der Konfiguration pr.base_branch oder erkenne main/master)
3. Erstelle einen neuen Branch: git checkout -b <prefix>/<beschreibung> (Präfix aus der Konfiguration, Standard content/)
4. Überprüfe gh auth status – falls nicht authentifiziert, erkläre in einfachen Worten:

   „Ich benötige Zugriff auf GitHub, um eine Überprüfungsanfrage für Ihre Änderung zu erstellen. Könnten Sie einen Entwickler bitten, auf diesem Rechner gh auth login auszuführen? Dann können wir es erneut versuchen.“

Wenn alles sauber ist, erwähne nichts davon dem Benutzer – fahre einfach fort.

Phase 3: Zeige den Plan und hole die Zustimmung ein

Ziel: Der Benutzer stimmt den genauen Änderungen ausdrücklich zu, bevor eine Datei bearbeitet wird.

Lese die Zieldatei(en). Beschreibe dann jede Änderung in einfacher Sprache und bitte um Zustimmung:

„Hier ist, was ich ändern werde:

1. Pro-Plan Preis: '12€' wird zu '15€'

Sieht das richtig aus? Soll ich fortfahren?“

Bei Textänderungen zeige immer den genauen Vorher- und Nachher-Wortlaut. Bei Stiländerungen beschreibe den visuellen Effekt („der Button wechselt von Lila zu Grün“). Bei strukturellen Änderungen beschreibe, was anders erscheinen wird („ein neuer FAQ-Eintrag erscheint am Ende der Liste“).

Verwende AskQuestion, um die Zustimmung einzuholen oder Anpassungen zu ermöglichen:

• „Ja, nimm die Änderung vor“
• „Nein, lass mich zuerst etwas anpassen“

Bearbeite KEINE Datei, bis der Benutzer ja sagt.

Phase 4: Änderungen vornehmen und verifizieren

Ziel: Edits anwenden und sicherstellen, dass nichts kaputtgegangen ist.

1. Bearbeite nur die erforderlichen Dateien und ändere nur, was genehmigt wurde
2. Beachte die Dateimuster des Frameworks (siehe Discover-Referenz unten)
3. Überprüfe geschützte Pfade aus der Konfiguration – wenn eine benötigte Datei geschützt ist, sage dem Benutzer:

   „Dieser Bereich befindet sich in einer geschützten Datei, die nur von Entwicklern geändert werden sollte. Möchten Sie, dass ich Ihnen helfe, eine Anfrage für das Entwicklerteam zu formulieren?“

4. Führe Verifikationsbefehle aus (erkenne sie aus package.json-Skripten oder der Konfiguration):
   • Lint (falls verfügbar)
   • Typprüfung (falls TypeScript)
   • Build
5. Wenn die Verifikation fehlschlägt, erkläre in einfacher Sprache:

   „Die Änderung hat ein kleines technisches Problem verursacht – [einfache Erklärung]. Ich kann es automatisch beheben / Dafür wird ein Entwickler benötigt. Was ist Ihnen lieber?“

Phase 5: Vorschau und Bestätigung

Ziel: Der Benutzer sieht (oder versteht) das Ergebnis und gibt die endgültige Zustimmung.

1. Starte den Entwicklungsserver, falls nicht bereits aktiv
2. Sage dem Benutzer, wo er suchen soll:

   „Ihre Änderung ist bereit zur Vorschau! Öffnen Sie http://localhost:5173 und blättern Sie zum Preisbereich. Der Pro-Plan sollte jetzt 15€/Monat anzeigen.“

3. Frage nach der endgültigen Bestätigung:

   „Sieht alles gut aus? Soll ich die Änderung zur Entwicklerüberprüfung einreichen?“

Biete Optionen an:

• „Sieht gut aus, erstelle die Überprüfungsanfrage“
• „Ich möchte etwas anpassen“ (zurück zu Phase 3)
• „Vergiss es, mach alles rückgängig“ (Branch zurücksetzen)

Phase 6: PR erstellen

Ziel: Ein sauberer PR wird erstellt und der Benutzer hat einen Link.

1. Stage und commite mit einer aussagekräftigen Nachricht
2. Pushe: git push -u origin HEAD
3. Erstelle den PR mit gh pr create:

Titel: [Inhalt] Kurze Beschreibung der Änderung

Text:
## Was geändert wurde
| Bereich | Vorher | Nachher |
|---------|--------|--------|
| Pro-Plan Preis | 12€/Benutzer/Monat | 15€/Benutzer/Monat |

## Angefordert von
[Name/Rolle des Benutzers, falls erwähnt]

## Überprüfungshinweise
- Nur Inhalts-/Stiländerungen – keine Logik- oder Abhängigkeitsänderungen
- Bitte auf Desktop und Mobilgerät überprüfen
- Betroffene Bereiche: [Bereiche auflisten]

4. Füge Reviewer aus der Konfiguration hinzu: gh pr edit --add-reviewer
5. Füge Labels aus der Konfiguration hinzu: gh pr edit --add-label

Phase 7: Abschluss

Ziel: Der Benutzer weiß, was als Nächstes passiert.

Sage dem Benutzer in freundlichen Worten:

„Alles erledigt! Hier ist Ihre Änderungsanfrage: [PR-Link]

Was ich geändert habe: Den Preis des Pro-Plans von 12€ auf 15€ aktualisiert. Was als Nächstes passiert: [Name(n) des Reviewers] werden es überprüfen. Sobald sie zustimmen, wird die Änderung live geschaltet. Müssen Sie dies rückgängig machen? Sagen Sie einfach „meine letzte Änderung rückgängig machen“ und ich kümmere mich darum."

---

Rollbacks handhaben

Wenn der Benutzer „meine letzte Änderung rückgängig machen“ oder „das vorherige Update rückgängig machen“ sagt:

1. Frage, welche Änderung gemeint ist (oder finde den letzten content/-PR)
2. Bestätige, was rückgängig gemacht werden soll:

   „Ich habe Ihre letzte Änderung gefunden: 'Pro-Plan Preis auf 15€ aktualisiert' (PR #42). Möchten Sie, dass ich dies rückgängig mache?“

3. Wenn der PR noch offen ist: schließe ihn und lösche den Branch
4. Wenn der PR bereits gemergt wurde: erstelle einen Revert-PR und erkläre:

   „Da diese Änderung bereits live ist, erstelle ich eine neue Anfrage, um sie rückgängig zu machen. Ein Entwickler muss auch das Rückgängigmachen genehmigen.“

---

Discover-Referenz

Dieser Abschnitt dient der internen Nutzung des Agenten während Phase 1 – zeige diese Details dem Benutzer nicht.

Framework-Erkennung

Datei im Repository-Stammverzeichnis	Framework
next.config.*	Next.js
nuxt.config.*	Nuxt
astro.config.*	Astro
svelte.config.*	SvelteKit
angular.json	Angular
vite.config.*	Vite (prüfe package.json auf react/vue/svelte)
gatsby-config.*	Gatsby
Keine + index.html	Statisches HTML

Paketmanager-Erkennung

Lock-Datei	Ausführender
bun.lock / bun.lockb	bun
pnpm-lock.yaml	pnpm
yarn.lock	yarn
package-lock.json	npm

Styling-Erkennung

1. tailwind.config.* oder @tailwindcss in CSS → Tailwind
2. .module.css / .module.scss-Dateien → CSS Modules
3. styled-components oder @emotion in Abhängigkeiten → CSS-in-JS
4. .scss / .sass-Dateien → SCSS
5. Einfaches .css → Einfaches CSS

Erkennung von Inhaltsmustern

Überprüfe auf separate Inhalts-/i18n-Dateien, bevor Komponenten bearbeitet werden:

• Verzeichnisse i18n/, locales/, messages/, translations/
• .mdx / .md-Inhaltsdateien
• CMS-Konfigurationen (contentful, sanity, strapi)
• JSON/YAML-Datendateien

Wenn Inhalte in separaten Dateien vorliegen, bearbeite diese – nicht den Komponentenquellcode.

Seitenentdeckung

Framework	Seitenorte
Next.js App Router	app/**/page.{tsx,jsx,js}
Next.js Pages Router	pages/**/*.{tsx,jsx,js}
Nuxt	pages/**/*.vue
Astro	src/pages/**/*.astro
SvelteKit	src/routes/**/+page.svelte
Gatsby	src/pages/**/*.{tsx,jsx}
Angular	Routing-Module
Vite SPA	Router-Konfiguration oder App.*
Statisches HTML	*.html im Stammverzeichnis oder in public/

---

Konfigurationsdatei

Teams können eine optionale .pm-editor.yml im Repository-Stammverzeichnis hinzufügen, um das Verhalten anzupassen (Reviewer, Labels, geschützte Dateien, Build-Befehle). Siehe config-reference.md für die vollständige Referenz.

Beispiele

Für Beispielgespräche mit verschiedenen Frameworks siehe examples.md.