Communitygithub.com

Banger-Explainer

Verwandle technische Inhalte in erklärende Beiträge, die geteilt werden, ohne an Substanz zu verlieren – mit einer klaren Trennung von Autorenstimme und technischer Präzision.

Was ist Banger-Explainer?

Das Banger-Explainer-Skill ist ein systematischer Workflow für technische Autoren, um erklärende Inhalte zu erstellen, die nicht nur unterhaltsam, sondern auch reproduzierbar sind. Es löst das klassische Problem technischer Erklärungen: Entweder sind sie zu oberflächlich (viel Voice, wenig Substanz) oder zu trocken (wie Dokumentation, die niemand teilt). Der Kernansatz basiert auf der Aufteilung in **Frame** (Autorenstimme, Story, Urteil) und **Payload** (technische Klarheit, konkrete Artefakte). Der Workflow beginnt mit der Benennung des Mechanismus und des falschen Modells, das der Leser vermutlich hat. Dann folgen Proof-Check, Tiefenanpassung an das Zielpublikum, Entwurf mit der Frame/Payload-Split und plattformspezifische Formatierung (X/Bluesky-Threads, LinkedIn, Newsletter, Video-Docs). Vor der Veröffentlichung durchläuft der Beitrag eine sechsstufige Qualitätskontrolle, die Kohärenz, Begriffskonsistenz und Nachvollziehbarkeit sicherstellt. Das Skill lädt Referenzen aus lokalen Frameworks (Voice-and-Audience, Technical-Clarity, Writing-Quality, Platform-Playbook) und unterstützt ein Freshness-Gate für Forschungsquellen.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Jeff-Kazzee/bangers/tree/main/skills/banger-explainer

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Banger Explainer — Lehrmaterial, das geteilt werden kann und seinen Wert behält

Lehrmaterial scheitert in zwei Richtungen. Zu viel Stimme und der Leser freut sich daran, kann es aber nicht wiederholen. Zu viel Spezifikation und es liest sich wie eine Dokumentation, die niemand teilt. Diese Prozedur weist jedem Register den Teil des Stücks zu, für den es tatsächlich gut ist.

Zuerst laden

  • ${CLAUDE_PLUGIN_ROOT}/references/frameworks/voice-and-audience.md — das Zielgruppenprofil und die harten Einschränkungen des Erstellers.
  • ${CLAUDE_PLUGIN_ROOT}/references/frameworks/technical-clarity.md — die Frame/Payload-Aufteilung und die Payload-Disziplin. Kernreferenz hier.
  • ${CLAUDE_PLUGIN_ROOT}/references/frameworks/writing-quality.md — das lebendige Tor, vor der Auslieferung ausführen.
  • Der Abschnitt zur Zielplattform von ${CLAUDE_PLUGIN_ROOT}/references/platforms/platform-playbook.md.

Frische-Prüfung

Bevor du Plattform-Benchmarks, Algorithmus-Behauptungen oder numerische Leistungsaussagen aus diesem Skill oder dem Playbook verwendest, überprüfe in references/research/source-ledger.md, ob noch nicht abgelaufene Unterstützung vorhanden ist. Fehlt die Unterstützung oder ist die Überprüfung abgelaufen, führe banger-research aus, kennzeichne die Behauptung als nicht verifiziert oder lass sie weg.

Schritt 1: benenne den Mechanismus

Schreibe einen Satz, für dich selbst, nicht für den Leser: Was versteht der Leser nach diesem Stück, was er vorher nicht verstanden hat? Ein Mechanismus pro Stück. Wenn es zwei Sätze braucht, sind es zwei Stücke.

Benenne dann das falsche Modell, das der Leser vermutlich gerade hat. Starke technische Inhalte ersetzen ein falsches Modell, anstatt ein leeres zu füllen. Dieses falsche Modell ist normalerweise der Haken.

Schritt 2: prüfe den Beweis

Benenne vor dem Entwurf:

  • das Artefakt (Repository, Datei, Commit, Screenshot, Fehlertext, Benchmark),
  • was tatsächlich passiert ist, einschließlich des Teils, der fehlgeschlagen ist,
  • was nicht getestet wurde, klar angegeben.

Wenn es kein Artefakt gibt, ist dies ein Meinungsbeitrag, kein Erklärstück. Leite an banger-threads oder banger-longform-written weiter und sage dies.

Schritt 3: lege die Erklärungstiefe fest

Verwende das Zielgruppenprofil aus voice-and-audience.md. Der oberste Grundsatz gilt: Passe den Wortschatz an die tatsächliche Kompetenz des Publikums an.

  • Nicht-Experten-Publikum — definiere jedes primitive Konzept im selben Atemzug, mit einer einfachen Analogie. Zeige den genauen Bildschirm, die Aufforderung und das Ergebnis. Der Payload wird länger, die Schritte werden kleiner. Sprich niemals von oben herab.
  • Praktiker-Publikum — Insider-Abkürzungen sind frei, und Übererklären verschwendet ihre Zeit. Nutze den Platz für Abwägungen, Fehlermodi und das, was du anders machen würdest.

Schritt 4: entwerfe mit der Aufteilung

Frame (Autorenstimme, nicht die Klarheitsregeln):

  • Ein Haken, der das spezifische falsche Modell oder den spezifischen Schmerz benennt, nicht die Kategorie.
  • Die Geschichte: was du getan hast, was kaputt ging, was es kostete.
  • Das Urteil: was du jetzt denkst und wie sicher du dir bist.
  • Der Handlungsaufruf, der für die Plattform typisch ist.

Payload (technische Klarheit):

  • Ein Name pro Konzept, für das gesamte Stück beibehalten.
  • Eine Idee pro Satz, etwa 25 Wörter, Schritte eher 20.
  • Aktiv mit einem benannten Akteur: "Der Parser liest die Datei".
  • Verben, keine Nominalisierungen. Zahlen gezeigt, nicht Qualität behauptet.
  • Konkrete Artefakte: echte Befehle, echte Fehler, echte Pfade.

Behalte Kontraktionen, Nebenbemerkungen, Humor und Meinung im Payload, wo sie Gewicht tragen. Disziplin ist nicht gleichbedeutend mit Einebnung.

Schritt 5: Plattformform

  • X- oder Bluesky-Thread — ein Mechanismus-Schritt pro Beitrag. Frame ist Beitrag eins und der letzte Beitrag. Payload-Beiträge enthalten nach Möglichkeit einen Code-Block oder Screenshot. Nie länger als der Mechanismus erfordert.
  • LinkedIn — Haken in den ersten 150 Zeichen, falsches-Modell-Rahmung, dann drei oder vier Payload-Schläge in kurzen Absätzen. Ende mit dem Urteil plus einer Frage. Keine Links im Textkörper.
  • Newsletter oder Substack — eine Überschrift pro Mechanismus-Schritt, ein Diagramm oder Code-Block pro Schritt, Urteil als herausgehobenes Zitat. Biete eigenständige Notes an, die aus dem Payload stammen, nicht aus dem Frame.
  • Videobeschreibung oder docs-artiger Beitrag — Payload dominiert, Frame schrumpft auf zwei Zeilen.
  • Facebook-Gruppe — verwende diese Prozedur nicht. Leite an banger-longform-written weiter, fragengeführt und kurz.

Schritt 6: vor der Auslieferung verifizieren

Führe das writing-quality.md-Tor aus, dann diese:

  1. Kann ein Leser den Mechanismus wiederholen, nachdem der Beitrag geschlossen ist?
  2. Wird jedes Konzept genau mit einem Namen bezeichnet?
  3. Hat etwas Qualität behauptet, anstatt sie zu zeigen?
  4. Klingt der Frame immer noch, als hätte der Autor ihn laut gesagt?
  5. Lässt sich jede Zahl, jedes Zitat und jedes Ergebnis auf ein echtes Artefakt zurückführen?
  6. Sind die harten Einschränkungen des Erstellers (verbotene Satzzeichen, Phrasen, Tonfall) erfüllt?

Ausgabeformat

Beginne mit dem fertigen Asset, bereit zum Einfügen, formatiert für die Plattform. Dann:

  • der Mechanismus-Satz und das falsche Modell, das er ersetzt,
  • das Artefakt, auf das jede Behauptung zurückgeht,
  • alles als nicht verifiziert Gekennzeichnete,
  • die nächste benötigte Freigabe.

Entwerfen ist kostenlos. Veröffentlichen, Planen und Öffentlichkeitsarbeit benötigen die ausdrückliche Freigabe des Erstellers für jeden einzelnen Beitrag.

Individual skills in this repo

This repo contains 11 individual skills — each has its own dedicated page.

Verwandte Skills