Communitygithub.com

Banger Explainer — contenu pédagogique qui survit au partage

Ce skill structure la rédaction de contenus techniques en séparant la voix (frame) et la précision technique (payload) pour produire des explications à la fois engageantes et reproductibles par le lecteur.

Qu'est-ce que Banger Explainer — contenu pédagogique qui survit au partage ?

Ce skill résout le problème classique du contenu technique : soit il est agréable à lire mais impossible à reproduire, soit il est précis mais ennuyeux et peu partagé. 'Banger Explainer' propose une procédure en six étapes qui assigne chaque registre à la partie du texte où il excelle : la 'frame' (voix, histoire, jugement) et le 'payload' (concepts précis, artefacts concrets, langage actif). Il s'appuie sur des références externes chargées au démarrage (profils d'audience, clarté technique, qualité rédactionnelle, et playbook de plateforme) et intègre une vérification de fraîcheur des données via un registre de sources. Le skill est conçu pour Claude Code ou tout agent similaire capable de charger des fichiers markdown de référence. Il produit un asset prêt à publier, formaté selon la plateforme cible (X, LinkedIn, newsletter, etc.), avec des métadonnées de vérification et une demande d'approbation explicite avant publication.

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

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait Banger Explainer — contenu pédagogique qui survit au partage ?

Le contenu pédagogique échoue dans deux directions. Trop de voix et le lecteur apprécie mais ne peut pas répéter. Trop de spécifications et ça ressemble à une documentation que personne ne partage. Cette procédure assigne chaque registre à la partie du texte où il est réellement bon.

Chargement initial

  • ${CLAUDE_PLUGIN_ROOT}/references/frameworks/voice-and-audience.md — le profil d'audience et les contraintes dures du créateur.
  • ${CLAUDE_PLUGIN_ROOT}/references/frameworks/technical-clarity.md — la séparation frame/payload et la discipline du payload. Référence centrale.
  • ${CLAUDE_PLUGIN_ROOT}/references/frameworks/writing-quality.md — le contrôle qualité vivant, à exécuter avant la livraison.
  • La section sur la plateforme cible de ${CLAUDE_PLUGIN_ROOT}/references/platforms/platform-playbook.md.

Vérification de fraîcheur

Avant d'utiliser tout benchmark de plateforme, affirmation d'algorithme ou revendication de performance chiffrée provenant de ce skill ou du playbook, consultez references/research/source-ledger.md pour vérifier un support non expiré. Si le support est manquant ou a dépassé sa date de révision, exécutez banger-research, étiquetez l'affirmation comme non vérifiée, ou omettez-la.

Étape 1 : nommer le mécanisme

Écrivez une phrase, pour vous-même, pas pour le lecteur : qu'est-ce que le lecteur comprend après cela qu'il ne comprenait pas avant ? Un mécanisme par pièce. Si cela prend deux phrases, ce sont deux pièces.

Ensuite, nommez le modèle erroné que le lecteur a probablement en tête actuellement. Un bon contenu technique remplace un modèle erroné plutôt que de remplir un vide. Ce modèle erroné est généralement l'accroche.

Étape 2 : vérifier la preuve

Avant de rédiger, nommez :

  • l'artefact (dépôt, fichier, commit, capture d'écran, texte d'erreur, benchmark),
  • ce qui s'est réellement passé, y compris la partie qui a échoué,
  • ce qui n'a pas été testé, énoncé clairement.

S'il n'y a pas d'artefact, il s'agit d'un article d'opinion, pas d'un explicateur. Acheminez vers banger-threads ou banger-longform-written et dites-le.

Étape 3 : définir la profondeur d'explication

Utilisez le profil d'audience de voice-and-audience.md. La directive principale s'applique : adaptez le vocabulaire à la sophistication réelle de l'audience.

  • Audience non experte — définissez chaque primitive dans le même souffle, avec une analogie simple. Montrez l'écran exact, l'invite et le résultat. Le payload s'allonge, les étapes deviennent plus petites. Ne jamais parler de haut.
  • Audience de praticiens — le jargon d'initié est gratuit, et sur-expliquer leur fait perdre du temps. Utilisez l'espace pour les compromis, les modes d'échec et ce que vous feriez différemment.

Étape 4 : rédiger avec la séparation

Frame (voix de l'auteur, pas les règles de clarté) :

  • Une accroche qui nomme le modèle erroné spécifique ou la douleur spécifique, pas la catégorie.
  • L'histoire : ce que vous faisiez, ce qui a cassé, ce que ça a coûté.
  • Le jugement : ce que vous pensez maintenant, et votre niveau de confiance.
  • L'appel à l'action natif de la plateforme.

Payload (clarté technique) :

  • Un nom par concept, maintenu pendant toute la pièce.
  • Une idée par phrase, environ 25 mots, les étapes plutôt 20.
  • Voix active avec un acteur nommé : "le parser lit le fichier".
  • Verbes, pas de nominalisations. Chiffres montrés, pas de qualité affirmée.
  • Artefacts concrets : vraies commandes, vraies erreurs, vrais chemins.

Gardez les contractions, apartés, humour et opinions à l'intérieur du payload là où ils ont du poids. La discipline n'est pas synonyme d'aplatissement.

Étape 5 : mise en forme selon la plateforme

  • X ou thread Bluesky — une étape du mécanisme par post. La frame est le post un et le dernier post. Les posts de payload contiennent un bloc de code ou une capture d'écran si possible. Jamais plus long que le mécanisme ne le nécessite.
  • LinkedIn — accroche dans les 150 premiers caractères, cadrage du modèle erroné, puis trois ou quatre battements de payload en paragraphes courts. Terminez sur le jugement plus une question. Pas de liens dans le corps.
  • Newsletter ou Substack — un en-tête par étape du mécanisme, un diagramme ou bloc de code par étape, citation du jugement en pull-quote. Fournissez des Notes autonomes tirées du payload, pas de la frame.
  • Description vidéo ou post de type documentation — le payload domine, la frame se réduit à deux lignes.
  • Groupe Facebook — n'utilisez pas cette procédure. Acheminez vers banger-longform-written, en mode question et court.

Étape 6 : vérifier avant de livrer

Exécutez le contrôle de writing-quality.md, puis ceux-ci :

  1. Un lecteur pourrait-il répéter le mécanisme avec le post fermé ?
  2. Chaque concept est-il appelé exactement par un seul nom ?
  3. Quelque chose a-t-il affirmé de la qualité au lieu de la montrer ?
  4. La frame ressemble-t-elle toujours à ce que l'auteur a dit à voix haute ?
  5. Chaque nombre, citation et résultat est-il traçable jusqu'à un artefact réel ?
  6. Les contraintes dures du créateur (ponctuation, phrases, ton interdits) sont-elles satisfaites ?

Format de sortie

Commencez par l'asset final, prêt à coller, formaté pour la plateforme. Ensuite :

  • la phrase du mécanisme et le modèle erroné qu'elle remplace,
  • l'artefact auquel chaque affirmation se rattache,
  • tout ce qui est étiqueté non vérifié,
  • l'approbation nécessaire ensuite.

La rédaction est libre. La publication, la planification et la promotion nécessitent l'approbation explicite du créateur pour chaque élément.

Individual skills in this repo

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

Skills associés