Dnnecessary/skills – Content-Methodik-Analyse

Analyse der Inhaltsmethodik eines Autors

Eingabevertrag

Der Aufrufer muss Folgendes bereitstellen:

• input_dir oder eine eindeutige Liste von Dateien/Dokumentinhalten
• output_dir
• Name des Autors oder Kontos
• Optional: Eine Artikelliste, idealerweise mit Titel, Link und Veröffentlichungsdatum
• generate_html: Standard true
• sync_lark: Standard true

Bei unzureichender Eingabe wird zuerst nach im Arbeitsbereich auffindbaren Inhalten gesucht. Erst wenn immer noch keine Textproben vorliegen, wird der Benutzer gefragt. Es ist nicht erlaubt, nur auf Basis von Titeln zu analysieren.

Unterstützte Formate und Verarbeitungsgrenzen:

• Markdown/TXT: Verwendung des integrierten Parsers.
• DOCX: Bevorzugt Verwendung von python-docx; falls nicht verfügbar, wird ein klarer Fehler gemeldet.
• PDF mit extrahierbarem Text: Bevorzugt Verwendung von pypdf; bei gescannten PDFs ohne Text wird OCR markiert, ohne den Text zu fälschen.
• Feishu-Dokumente: Zuerst mit dem aktuellen lark-doc Skill lesen, dann den Text als Eingabe verwenden.
• Bei Mischung mehrerer Formate werden diese einheitlich in Artikelaufzeichnungen umgewandelt, wobei der ursprüngliche Dateipfad und der Quelltyp erhalten bleiben.

Ausgabevertrag

Wird immer in das vom Aufrufer bereitgestellte output_dir geschrieben:

<output_dir>/
  <Blogger>-Methodikbericht.md
  <Blogger>-Copywriting-Framework.md
  <Blogger>-Analysedaten.json
  <Blogger>-Artikelmerkmale.csv
  <Blogger>-Methodik-Dashboard.html                  # Standardmäßig generiertes Dashboard aus Lernendenperspektive
  <Blogger>-Feishu-Sync.json                    # Wird nach erfolgreicher Synchronisierung generiert
  <Blogger>-Konkurrenten-Titelproben.json                # Wird generiert, wenn Konkurrenzproben bereitgestellt werden

Alle Produkte im Stammverzeichnis werden einheitlich nach dem Schema „<Blogger>-<Funktion>.<Erweiterung>“ benannt. <Blogger>-Analysedaten.json und <Blogger>-Artikelmerkmale.csv sind prüfbare Liefergegenstände, keine temporären Dateien. Bericht, HTML und Feishu-Inhalt müssen auf denselben Analysedaten basieren. Nur wenn der Benutzer explizit „kein HTML generieren“ oder „nicht mit Feishu synchronisieren“ angibt, werden die entsprechenden Schritte deaktiviert.

Dieses Skill generiert das Copywriting-Framework selbstständig basierend auf references/copywriting-framework-template.md und ist nicht auf ein externes Skill namens creator-copywriting-framework angewiesen.

Arbeitsablauf

1. Erstellung der Probenliste

• Ausführung des deterministischen Analysescripts:

  python3 scripts/analyze_corpus.py \
    --input "<input_dir>" \
    --output "<output_dir>"
  

• Das Script ist verantwortlich für die Formatparsung, Deduplizierung, Beibehaltung von Bildverweisen, Basisstatistiken und artikelbezogene Merkmale.

• Bei weniger als 5 Artikeln wird nur eine deskriptive Analyse durchgeführt und explizit auf die geringe Stabilität hingewiesen; bei weniger als 3 Artikeln dürfen keine Aussagen zu Trends, Entwicklungen oder stabilem Stil getroffen werden.

• Bei mehr als 50 Artikeln wird vorrangig eine vollständige Basisstatistik erstellt; nur wenn der Kontext oder die Verarbeitungskosten offensichtlich zu hoch sind, wird eine Stichprobe gezogen, und die Stichprobenmethode wird offengelegt.

2. Vorverarbeitung des Textes

• Löschen von Rauschen wie Navigation, Werbung und urheberrechtlichen Fußnoten.
• Bild-Markdown wird aus der reinen Textanalyse-Kopie entfernt, aber die ursprüngliche Position, der relative Pfad und der umgebende Text müssen im Artikelprotokoll für die visuelle Analyse erhalten bleiben.
• Beibehaltung von Überschriftenebenen, Listen, Zitaten, Fallbeispielen, Daten und Schlussfolgerungsabschnitten.
• Unterscheidung zwischen Originaltextfragmenten und Modellzusammenfassungen, Beibehaltung der Zuordnung von Beweisen zu Artikeltiteln.

3. Detaillierte Datenanalyse

Zuerst <Blogger>-Analysedaten.json und <Blogger>-Artikelmerkmale.csv lesen, dann die erklärende Analyse gemäß references/data-analysis-framework.md durchführen. Deterministische Indikatoren dürfen nicht vom Modell neu geschätzt werden. Standardmäßig abgedeckt:

• Probenqualität und Datenvollständigkeit
• Veröffentlichungshäufigkeit, -zyklus, -kontinuität und zeitliche Verteilung
• Textlänge, Absätze, Sätze, Bilder und strukturelle Komplexität
• Verteilung von Themen, Motiven, Objekten, Szenarien, Problemen und Inhaltstypen
• Schlüsselwörter, Begriffe, Konzeptkombinationen und semantische Zusammenhänge
• Überschriftenlänge, Aufhänger, Satzstruktur, Objekt, Versprechen und Konsistenz zwischen Überschrift und Text
• Einleitung, Hauptteil, Wendepunkt, Fazit, CTA und gängige Erzählpfade
• Argumentationseinheiten wie Meinung, Fakt, Kausalität, Vergleich, Gegenbeispiel, Grenzen und Vorschläge
• Beweistypen wie Daten, Zitate, Praxistests, Fallstudien, Autoritätsquellen und Erfahrungen
• Entitätsnetzwerke aus Personen, Unternehmen, Produkten, Technologien, Ereignissen, Branchen, Orten und Modellen
• Starke/Schwache Urteile, Bestimmtheit, Zeithorizont, Risikoeinstellung und Wertorientierung
• Wortschatz, Satzlänge, Rhythmus, Rhetorik, Umgangssprachlichkeit, Fachlichkeit und Lesbarkeit
• Zielgruppe, Nutzungsszenario, Schmerzpunkte, Inhaltsversprechen und Lesernutzen
• Handlungsaufforderungen im Text wie Kommentare, Materialdownload, Kauf (nur als Beobachtung der Schreibstruktur)
• Bilddichte, Bildposition im Text und Funktion des visuellen Inhalts (wenn Daten verfügbar)
• Entwicklung von Themen, Ausdruck und Urteilen im Laufe der Zeit (wenn Veröffentlichungsdaten verfügbar)
• Kreuzbeziehungen zwischen Themen und Überschrift, Struktur, Beweis, Länge, CTA usw.
• Anomalien in Proben, inhaltliche Lücken, übermäßige Konzentration und Möglichkeiten zur Serialisierung
• Keine Analyse von Lese-, Teil-, Like-, Lesezeichen-, Follower- oder Konversionsleistungen aus der Plattform-Backend
• Zerlegung der Überschriftenmethode: Gesamtstatistik zu konkreten Zahlen, Spannungsfragen, Schmerzpunktkonflikten, Trendaktualität, klarem Nutzen; repräsentative Überschriften erklären Formel, Grund, Nachahmungsmethode und Anwendungsbedingungen
• Demonstration der Artikelstruktur: Rhythmus durch Einleitungsaufgabe, Hauptteilaufgabe, Schlussaufgabe erklären und umsetzbare Übungen für Lernende bereitstellen
• Wie man den Veröffentlichungsrhythmus lernt: Beobachtung der Inhaltsbereitstellungsweise des Autors anhand von Veröffentlichungstag, Wochentagsverteilung, mehreren Artikeln am selben Tag und Artikelabständen; dann nach der Zeit, Beweissammlungsgeschwindigkeit und Schaffensphase des Lernenden einen nachhaltigen Rhythmus entwerfen
• Radar konkurrierender Themen: Öffentliche Suche nach Titeln von Mitbewerbern und Aufzeichnung der Quellenlinks, Themenart und Probengrenzen

Daten und repräsentative Proben dienen nur der Erklärung der Methode des Autors. Das Dashboard darf nicht als Bewertung, Selbstcheck, Bestehen/Nichtbestehen oder Bericht zur Verbesserung des Autors geschrieben werden. Kennzahlen zur Backend-Leistung der Plattform gehen nicht in das Dashboard ein. Andere nicht berechenbare Inhalte dürfen nicht geschätzt oder erfunden werden. Worthäufigkeit kann nicht direkt mit der Einstellung des Autors gleichgesetzt werden; subjektive Labels wie Thema, Leitsatz, Emotion und Haltung müssen Klassifikationsregeln und Beweise enthalten.

Standardmäßig wird eine Lernendenperspektive eingenommen, nicht nur eine Bewertung des Bloggers. Jedes Kernmodul muss erklären:

• Was dieser Autor konkret tut;
• Warum diese Methode effektiv ist;
• Welche Fähigkeiten es zu lernen lohnt;
• Welche Übung der Lernende ausführen kann;
• Welche Abhängigkeiten von persönlicher Erfahrung, Ressourcen oder Plattformbedingungen bestehen und nicht direkt übernommen werden können;
• Wie man feststellt, ob die Methode bereits in die eigene Fähigkeit überführt wurde und nicht nur den oberflächlichen Stil imitiert.

Subjektive Labels müssen in die annotations von <Blogger>-Analysedaten.json geschrieben werden, jeder Eintrag enthält:

dimension,label,article_ids,evidence,rule,confidence

Damit sind die Schlussfolgerungen zu Thema, Haltung, Leser und Leitsätzen im Bericht auf die Artikel zurückführbar.

4. Destillation der Methodik

Der Hauptbericht verwendet references/report-template.md. Das Datenkapitel verweist auf Indikatoren und Artikel-IDs aus <Blogger>-Analysedaten.json und erstellt keinen zweiten Satz von Zahlen; das Methodikkapitel ist für die Erklärung der Datenfakten verantwortlich und umfasst mindestens:

Die „Probenbeschreibung“ des Berichts muss dataset_sha256 enthalten, zur Konsistenzprüfung.

1. Positionierung des Autors und Inhalts-Persona
2. Leserprofil und Inhaltsnutzen
3. Karte der Inhaltswerte
4. Themensystem
5. Analyse-Rahmen
6. Bewertungskriterien
7. Ausdrucksvorlagen
8. Fallsammlung
9. Stil von Leitsätzen
10. Inhaltliche Lücken und Themenchancen
11. Wiederverwendbare Schreib-SOP
12. Risiken und Grenzen
13. Probenliste

Für jede wichtige Schlussfolgerung werden möglichst 2-5 Artikelüberschriften, kurze Textausschnitte oder Fallbeispiele zitiert. Originalzitate bleiben notwendig und kurz; abstrakte Vorlagen müssen mit „abstrakte Vorlage“ gekennzeichnet werden, strukturierte Beispiele müssen mit „Nicht-Originaltext des Autors“ gekennzeichnet werden.

5. Generierung eines unabhängigen Copywriting-Frameworks

Verwendung von references/copywriting-framework-template.md zur Generierung von <Blogger>-Copywriting-Framework.md. Die Vorlage gibt nur die Struktur vor, ohne voreingestellte Satzstrukturen des Autors; alle Formeln müssen aus den Probenbeweisen abgeleitet werden, einschließlich:

• Themengerüst
• 8-15 Überschriftenformeln
• Mehrere Arten von Einleitungsvorlagen
• Mindestens 3 Textstrukturen
• Absatzsatzstrukturen und Übergangssätze
• Generatoren für Leitsatz-Strukturen
• Schluss-CTA
• 1-2 strukturierte Beispiele mit geändertem Thema, geänderten Fallbeispielen und geänderter Ausdrucksweise
• Checkliste vor der Veröffentlichung und verbotene Grenzen

Nur die Struktur lernen, nicht die einzigartige Ausdrucksweise des Autors reproduzieren, den Autor nicht imitieren.

6. Automatische Generierung von HTML

Das HTML-Dashboard ist ein Standard-Liefergegenstand dieses Skills, kein optionaler Chat-Anhang. Bei der Generierung muss zwingend references/interactive-dashboard-template.md gelesen und das eingebaute scripts/generate_dashboard.py dieses Skills verwendet werden. Es darf nicht ad hoc auf eine andere universelle BI-Vorlage umgestellt werden.

Standardmäßige Ausführung:

python3 scripts/generate_dashboard.py \
  --data "<output_dir>/<Blogger>-Analysedaten.json" \
  --output "<output_dir>/<Blogger>-Methodik-Dashboard.html"

HTML und Markdown müssen die deterministischen Statistiken aus <Blogger>-Analysedaten.json gemeinsam nutzen. Vom Modell generierte Methodik-Zusammenfassungen können als zusätzliche Daten in annotations geschrieben werden, dürfen aber die vom Script berechneten Felder nicht überschreiben.

Das Dashboard muss die folgende feste Struktur einhalten:

1. Auf einen Blick
2. Positionierung und Wert
3. Inhaltskarte
4. Themenmethode
5. Artikel-Schreibweise
6. Meinung und Beweise
7. Sprachstil
8. Lernenswert
9. Betrieb und Wachstum
10. Lernen und Transfer

Alle Kapitel stehen aus der Perspektive des Lernenden und konzentrieren sich auf die Beantwortung der Fragen „Was sollte ich lernen, wie lerne ich es“. Sie dürfen nicht in eine Selbstkontrolle des Autors, eine Artikelbewertung oder eine Analyse der Plattformleistung umgewandelt werden. Am Ende der Seite befinden sich nur kurze Quellenangaben und Haftungsausschlüsse, ohne ein separates Kapitel „Daten und Grenzen“.

Nach der Generierung wird die Konsole, die Hauptinteraktionen und die visuelle Lesbarkeit im Browser überprüft.

Wird nur übersprungen, wenn der Benutzer explizit angibt, kein HTML zu generieren, d.h. generate_html=false.

7. Automatische Synchronisierung mit Feishu

Zunächst Prüfung der Quellenbeschränkungen:

• Proben stammen ausschließlich aus öffentlichen URLs oder öffentlichen Artikelnachlässen: Standardsynchronisierung.
• Proben stammen aus lokalen Interviews, internen Dokumenten, privaten Feishu-Dokumenten oder bei Treffer sensibler Suche: Automatischer Upload wird pausiert und der Benutzer um Bestätigung gebeten.

Nach Bestätigung der Synchronisierbarkeit wird lark-doc geladen:

1. Zuerst das lokale Markdown abschließen.
2. Wenn in <Blogger>-Feishu-Sync.json bereits ein zugänglicher doc_token vorhanden ist, wird dieses Dokument aktualisiert; andernfalls wird ein neues Dokument erstellt.
3. Gemäß den aktuellen Schnittstellenspezifikationen des lark-doc Skills schreiben und zur Überprüfung erneut lesen.
4. doc_token, URL, Titel, Inhaltsfingerabdruck und Aktualisierungszeit in <Blogger>-Feishu-Sync.json schreiben.
5. Nach Überprüfung der Existenz der Kernkapitel wird die URL zurückgegeben.

Ein Fehler in Feishu darf den Abschlussstatus der lokalen Dateien nicht beeinträchtigen.

Wird nur übersprungen, wenn der Benutzer explizit angibt, nicht mit Feishu zu synchronisieren, d.h. sync_lark=false.

Qualitätsschwelle

• <Blogger>-Analysedaten.json und <Blogger>-Artikelmerkmale.csv müssen vom Script generiert werden.

• Schlussfolgerungen basieren auf dem Text und legen die Probengrenzen offen.

• Beobachtbare Statistiken und subjektive Zusammenfassungen werden klar unterschieden.

• Die Datenanalyse deckt möglichst alle berechenbaren Dimensionen ab und gibt explizit an, welche Felder nicht verfügbar sind.

• Jede wichtige Statistik gibt die Definition, den Nenner, die Klassifikationsregel oder die Berechnungsmethode an.

• Jedes Datenmodul ist mit repräsentativen Artikeln und methodischen Erkenntnissen verbunden.

• Jedes Kernmodul enthält Beweise und wiederverwendbare Aktionen.

• Bei unzureichenden Fallbeispielen wird explizit „noch keine stabile Fallsammlung gebildet“ geschrieben.

• Keine Rückschlüsse auf die Absicht des Autors, die nicht durch die Proben gestützt werden.

• Alle lokalen Ausgabepfade befinden sich im output_dir.

• HTML und Feishu werden standardmäßig abgeschlossen; wenn der Benutzer explizit deaktiviert, wird der Grund für das Überspringen aufgezeichnet.

• Die HTML-Navigation muss aus zehn festen Kapiteln bestehen, der Footer muss Quellenangaben und Haftungsausschluss enthalten.

• Das HTML darf kein separates Kapitel „Daten und Grenzen“ enthalten, keine Bewertungsmodule in Richtung des Autors wie „Selbstkontrolle, Bewertung, Bestehen/Nichtbestehen“.

• Abschließende Ausführung:

  python3 scripts/validate_outputs.py "<output_dir>"
  

Referenzen

• references/report-template.md: Wird beim Generieren des Hauptberichts gelesen.
• references/data-analysis-framework.md: Wird beim Ausführen der detaillierten Datenanalyse gelesen.
• references/copywriting-framework-template.md: Wird beim Generieren des unabhängigen Copywriting-Frameworks gelesen.
• references/interactive-dashboard-template.md: Wird beim standardmäßigen Generieren von HTML gelesen.
• references/analysis-data.schema.json: Gemeinsame Analysedatenstruktur.
• scripts/analyze_corpus.py: Analysiert das Korpus und generiert deterministische Merkmalsdaten.
• scripts/generate_dashboard.py: Generiert Offline-HTML aus der gemeinsamen Datenquelle.
• scripts/validate_outputs.py: Überprüft die Konsistenz von Daten, Bericht, HTML und Synchronisierungsmetadaten.