Pillar-Landing-Pages

Pillar-Landing-Pages (Landing Pages je Säule)

Erweitert eine einzelne Positionierungsvorlage, die mehrere Fähigkeiten, Säulen oder Subprodukte umfasst, zu eigenständigen Landing-Page-Briefs – eine pro Säule, jeweils mit eigener URL, eigenem Keyword-Targeting und vollständigem Text von der Hero-Section bis zum finalen CTA.

Eingaben

Lies zuerst company-context.md (Projektstamm oder durchsuche den Workspace danach) und verwende die Felder, die für diesen Skill relevant sind. Falls die Datei oder eine Zeile fehlt, frage einmal und biete dann an, die Antwort wieder in die Datei zu speichern. Ersetze niemals eine Lücke durch eine Annahme über das Unternehmen.

Funktionsweise

• Eingabe: Eine Positionierungsvorlage, die Säulendokumente aus capability-pillar-research sowie die Evidenzdokumente aus use-case-evidence-research. Jede Behauptung auf jeder Seite muss auf diese Quellen zurückführbar sein.
• Ausgabe: Ein Seitenbrief pro Säule, wobei die Claim-Tags (Behauptungskennzeichnungen) mitgeführt werden, sowie optional eine kombinierte übergeordnete Seite auf Anfrage.
• Nächster Schritt: Copywriting und Design. Führe claim-propagation-sweep über diese Briefs aus, sobald sich eine Produkttatsache ändert.

Falls die Säulen- oder Evidenzdokumente nicht existieren, erstelle sie zuerst, anstatt Seiten aus dem Gedächtnis zu schreiben.

Warum dies sich von einer einzigen kombinierten Seite unterscheidet

Eine kombinierte Seite erlaubt es den stärksten zwei oder drei Fähigkeiten, sie zu tragen, während schwächere untergeordnet werden. Die Aufteilung in N Seiten entfernt dieses Sicherheitsnetz: Jede Säule erhält gleich viel Platz, unabhängig davon, ob sie gleich viel Evidenz hat. Eine dünne Säule kann eine eigene Seite haben, aber diese Seite muss ehrlich darüber sein.

Prozess, pro Säule

1. URL. Ein konsistenter übergeordneter Pfad mit der Säule als letztem Segment, sodass die Seiten als Familie lesbar sind.
2. Keyword-Research für diese Säule, nicht der universelle Produktbegriff, der überall wiederverwendet wird. Ziehe Volumen, Schwierigkeit und CPC heran (überprüfe die Währungseinheiten des Tools; manche APIs geben CPC in Cent zurück). Markiere:
   • Keywords, die mit der Markenpositionierung kollidieren (das beste Keyword ist „Ticketing-System“, aber das Produkt argumentiert gegen Ticket-Warteschlangen): behalte es im Titel, in der Meta-Beschreibung und in einer unterstützenden Überschrift oder markiere es für einen Menschen.
   • Begriffe, deren Suchergebnisse von einem anderen Format dominiert werden (Listicles, Vergleiche): empfehle ein anderes Asset für diesen Begriff, anstatt die Produktseite in Konkurrenz treten zu lassen.
3. Titel-Tag und Meta-Beschreibung aus dem primären Keyword.
4. Zusammenfassung der Positionierung: 3-5 Sätze aus der Quellvorlage, der Kernbehauptung der Säule und der stärksten Evidenz.
5. Die Seite, einheitlich strukturiert über die gesamte Familie hinweg:
   • Hero (H1, Untertitel, CTA): die schärfste, spezifischste Behauptung der Säule, die den Mechanismus benennt.
   • Proof-Strip: 3-4 kurze, belegte Behauptungen. Falls eine Statistik existiert, aber nicht freigegeben ist, sage dies; verwende sie nicht oder lasse sie stillschweigend weg.
   • 2-4 Textabschnitte basierend auf der tatsächlichen Evidenz dieser Säule: was sie tut (aus dem Fähigkeitskatalog), warum sie die offensichtliche Alternative schlägt, der Einwand, den diese Säule beantworten muss.
   • Vertrauens- oder Sicherheitsabschnitt, platziert an oberer Stelle, wenn die Säule Berechtigungen, Compliance oder KI-Sicherheitsbedenken berührt.
   • Ehrlichkeitshinweis-Abschnitt, nur wenn die Evidenz der Säule dünner ist als die ihrer Geschwisterseiten.
   • Cross-Links zu den Geschwisterseiten.
   • Finaler CTA.
6. Kennzeichne jede Behauptung (gemeinsame Regel 4) und führe die Zitatprüfung für alle verwendeten Kundenreferenzen durch.
7. Seitenspezifische offene Punkte am Ende jedes Briefs: unbestätigte Zahlen, Kunden, die noch auf Freigabe warten, oder eine echte Frage, ob die Säule eine eigene Seite verdient.

Erledigt, wenn

• Jede Seite ihr eigenes Keyword-Research hat.
• Jede Hero- und Proof-Behauptung auf die Quelldokumente zurückführbar ist.
• Ungleiche Evidenz in mindestens einem Ehrlichkeitshinweis sichtbar ist, falls die Säulen ungleich sind.
• Seiten untereinander Cross-Links haben.

Gemeinsame Regeln (identisch für alle vier Skills in diesem Set)

1. Evidenz vor Text. Jede Produktbehauptung, jede Statistik und jedes Zitat ist auf eine benannte Quelle zurückführbar. Erfinde niemals eine Fähigkeit, Zahl, Kundengeschichte oder ein Zitat. Wenn die Evidenz fehlt, sage dies.
2. Ausgeliefert bedeutet ausgeliefert. Gib den Status einer Fähigkeit (ausgeliefert, in Arbeit, geplant) nur so an, wie die Quelle ihn angibt. Käuferwünsche, die das Produkt nicht erfüllen kann, gehören unter Hoffnungen oder Wünsche, niemals unter Fähigkeiten.
3. Zitate sind wortgetreu und stammen vom Käufer. Kopiere exakte Wörter; kürze mit „...“ aber ändere sie niemals. Zitiere niemals das eigene Personal des Anbieters als einen Käufer. Bevor du abschließt, führe die Zitatprüfung durch (das Skript wird mit use-case-evidence-research als verify_quotes.py ausgeliefert) und korrigiere oder entferne alles, was nicht gefunden wird.
4. Claim-Tags. Markiere Text und Behauptungen als SAFE (sicher), NEEDS VERIFY: (was wäre erforderlich, um es zu klären) oder INTERNAL ONLY (Kundenmaterial ohne Freigabe). Trage Tags von der Ausgabe eines Skills in die nächste weiter; entferne sie nicht.
5. Dünne Evidenz wird klar benannt. Zähle verschiedene Konten, nicht Zitate. Polstere niemals einen schwachen Bereich auf, um ihn einem starken anzugleichen.
6. Fertige Dokumente, keine Änderungsprotokolle. Keine „aktualisiert“, „hinzugefügt“, „neu“, Versionsnummern, Sweep- oder Sitzungsverweise in Dokumenten, die als Referenzen gelesen werden sollen. Das Versionsverzeichnis enthält diese Informationen.
7. Extern-sicherer Modus (wenn der Benutzer „extern“ sagt, für Anzeigen, für Kunden, halte es sauber): nur Berufsbezeichnung und Unternehmen, keine Personennamen; keine Daten; Wettbewerbsnamen innerhalb von Zitaten durch eine neutrale eckige Klammer wie „[das alte Tool]“ ersetzen; keine Hinweise auf Freigaben, Quellen oder Verwendung. Teile dem Benutzer in deiner Antwort mit, dass Kundenreferenzen noch freigegeben werden müssen.
8. Tonfall. Klar und direkt. Keine Gedankenstriche. Keine Füllwörter. Charakterisiere Wettbewerber nicht über das hinaus, was Käufer selbst sagen. Keine Dateinamen im Text eines Dokuments.

Wie die vier Skills zusammenarbeiten

1. use-case-evidence-research: Sammelt und verifiziert die Evidenz (Produktfähigkeiten, Käuferschmerzen, Hoffnungen, Reaktionen) pro Anwendungsfall oder Feature.
2. capability-pillar-research: Gruppiert diese Evidenz nach Verben (was das Produkt tut) neu, wenn die Positionierung nach Verhalten und nicht nach Feature erfolgt.
3. pillar-landing-pages: Verwandelt die Positionierung in einen Seitenbrief pro Säule oder Feature, wobei nur Behauptungen aus den Schritten 1-2 verwendet werden.
4. claim-propagation-sweep: Wird immer dann ausgeführt, wenn sich eine Produkttatsache ändert, über alles, was die Schritte 1-3 produziert haben, und führt Korrekturen zurück in die Evidenzdokumente.

Die Ausgaben eines Schritts sind die Eingaben des nächsten. Wenn du nach einem späteren Schritt gefragt wirst und die frühere Ausgabe nicht existiert, erstelle zuerst den früheren Schritt (oder teile dem Benutzer mit, dass er fehlt), anstatt aus dem Gedächtnis zu schreiben.