Dnnecessary/skills

Analyse Méthodologique du Contenu d'un Auteur

Contrat d'Entrée

L'appelant doit fournir :

• input_dir ou une liste explicite de fichiers/contenu de documents
• output_dir
• Le nom de l'auteur ou du compte
• Une liste d'articles optionnelle, de préférence avec titre, lien et date de publication
• generate_html : par défaut true
• sync_lark : par défaut true

En cas d'entrée insuffisante, rechercher d'abord le contenu disponible dans l'espace de travail. Si aucun échantillon de texte n'est trouvé, demander à l'utilisateur. Ne pas analyser uniquement sur la base des titres.

Formats pris en charge et limites de traitement :

• Markdown/TXT : utiliser l'analyseur intégré.
• DOCX : utiliser python-docx de préférence ; si indisponible, signaler une erreur explicite.
• PDF avec texte extractible : utiliser pypdf de préférence ; pour les PDF scannés sans texte, marquer comme nécessitant une OCR, ne pas fabriquer de texte.
• Documents Lark : lire d'abord avec le skill lark-doc actuel, puis utiliser le texte comme entrée.
• Lorsque plusieurs formats sont mélangés, les convertir en enregistrements d'articles uniformes, mais conserver le chemin du fichier d'origine et le type de source.

Contrat de Sortie

Toujours écrire dans le output_dir fourni par l'appelant :

<output_dir>/
  <auteur>-rapport-méthodologique.md
  <auteur>-framework-copywriting.md
  <auteur>-données-analyse.json
  <auteur>-caractéristiques-articles.csv
  <auteur>-tableau-de-bord-méthodologique.html  # Tableau de bord par défaut, perspective apprenant
  <auteur>-synchronisation-lark.json                    # Généré après synchronisation réussie
  <auteur>-échantillons-titres-concurrents.json        # Généré si des échantillons concurrents sont fournis

Tous les artefacts racines sont nommés selon le modèle "<auteur>-<fonction>.<extension>". <auteur>-données-analyse.json et <auteur>-caractéristiques-articles.csv sont des livrables audités, pas des fichiers temporaires. Le rapport, le HTML et le contenu Lark doivent utiliser les mêmes données d'analyse. Ne désactiver l'étape correspondante que si l'utilisateur demande explicitement "ne pas générer de HTML" ou "ne pas synchroniser Lark".

Ce skill génère lui-même le framework de copywriting en utilisant references/copywriting-framework-template.md et ne dépend pas d'un skill externe nommé creator-copywriting-framework.

Flux de Travail

1. Établir la Liste des Échantillons

• Exécuter le script d'analyse déterministe :

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

• Le script est responsable de l'analyse de format, de la déduplication, de la conservation des références d'images, des statistiques de base et des caractéristiques au niveau de l'article.

• Si moins de 5 articles : effectuer uniquement une analyse descriptive et signaler explicitement la faible stabilité. Si moins de 3 articles : ne pas produire de conclusions sur les tendances, l'évolution ou le style stable.

• Si plus de 50 articles : effectuer de préférence des statistiques de base sur l'ensemble ; n'échantillonner que si le contexte ou le coût de traitement est clairement trop élevé, et divulguer la méthode d'échantillonnage.

2. Prétraiter le Texte

• Supprimer le bruit tel que la navigation, les publicités et les notes de bas de page de copyright.
• Supprimer les images Markdown de la copie d'analyse en texte brut, mais conserver leurs positions d'origine, les chemins relatifs et le texte adjacent dans l'enregistrement de l'article pour l'analyse visuelle.
• Conserver les niveaux de titres, les listes, les citations, les études de cas, les données et les paragraphes de conclusion.
• Distinguer les extraits originaux des résumés du modèle, et conserver le mappage des preuves aux titres d'articles.

3. Analyse Détaillée des Données

Lire d'abord <auteur>-données-analyse.json et <auteur>-caractéristiques-articles.csv, puis effectuer l'analyse interprétative selon references/data-analysis-framework.md. Les indicateurs déterministes ne doivent pas être réestimés par le modèle. Couvrir par défaut :

• Qualité de l'échantillon et intégrité des données
• Fréquence de publication, périodicité, continuité et distribution temporelle
• Longueur, paragraphes, phrases, images et complexité structurelle
• Distribution des thèmes, motifs, objets, scénarios, problèmes et types de contenu
• Mots-clés, termes, combinaisons de concepts et associations sémantiques
• Longueur des titres, accroches, structures de phrases, objets, promesses et cohérence titre-texte
• Ouvertures, corps, transitions, conclusions, CTA et chemins narratifs courants
• Unités argumentatives : opinions, faits, causes/conséquences, comparaisons, contre-exemples, limites et suggestions
• Types de preuves : données, citations, tests, études de cas, sources faisant autorité et expériences
• Réseaux d'entités : personnes, entreprises, produits, technologies, événements, industries, lieux et modèles
• Jugements forts/faibles, certitude, échelles de temps, attitude face au risque et orientation des valeurs
• Vocabulaire, longueur des phrases, rythme, rhétorique, familiarité, niveau technique et lisibilité
• Lecteurs cibles, scénarios d'utilisation, points douloureux, promesses de contenu et bénéfices lecteur
• Appels à l'action dans le texte (commentaires, téléchargements, achats) (uniquement comme observation de structure d'écriture)
• Densité des images, positions texte-image et rôle du contenu visuel (lorsque les données sont disponibles)
• Évolution des thèmes, de l'expression et des jugements au fil du temps (lorsque les dates de publication sont disponibles)
• Corrélations croisées entre thèmes et titres, structure, preuves, longueur, CTA, etc.
• Échantillons anormaux, lacunes de contenu, sur-spécialisation et opportunités de sérialisation
• N'analysez PAS les performances de back-office (lectures, partages, likes, bookmarks, abonnements ou conversions)
• Déconstruction de la méthode des titres : statistiques globales sur les chiffres, suspense/questions, douleur/conflit, actualité/tendance, bénéfices clairs ; pour les titres représentatifs, expliquer la formule, la raison, la méthode d'imitation et les conditions d'application
• Démonstration de la structure des articles : expliquer le rythme à l'aide des tâches d'ouverture, de corps et de fin, et fournir des exercices pratiques pour l'apprenant
• Comment apprendre le rythme de publication : utiliser les jours de publication, la distribution hebdomadaire, les articles multiples le même jour et les intervalles pour observer la méthode d'approvisionnement en contenu de l'auteur, puis concevoir un rythme durable en fonction du temps, de la vitesse d'accumulation de preuves et de l'étape de création de l'apprenant
• Radar des concurrents : rechercher publiquement les titres des concurrents et enregistrer le lien source, le type de sujet et les limites de l'échantillon

Les données et les échantillons représentatifs ne sont utilisés que pour expliquer la méthode de l'auteur. Le tableau de bord ne doit pas être rédigé comme un rapport d'évaluation, d'auto-vérification, de réussite/échec ou d'amélioration de l'auteur. Les indicateurs de performance de back-office ne doivent pas figurer dans le tableau de bord. Les autres contenus qui ne peuvent pas être calculés ne doivent pas être estimés ou fabriqués. La fréquence des mots ne peut pas être directement assimilée à l'attitude de l'auteur ; les étiquettes subjectives telles que les thèmes, les phrases marquantes, l'émotion et la position doivent expliquer les règles de classification et les preuves.

Adopter par défaut une perspective d'apprenant pour la sortie, sans se contenter d'évaluer l'auteur. Chaque module principal doit expliquer :

• Ce que l'auteur fait spécifiquement ;
• Pourquoi cette méthode est efficace ;
• Quelles compétences méritent d'être apprises ;
• Quel exercice l'apprenant peut exécuter ;
• Ce qui dépend de l'expérience personnelle, des ressources ou des conditions de la plateforme et ne peut pas être copié directement ;
• Comment juger si la méthode a été transférée en ses propres compétences, plutôt que de simplement imiter le style de surface.

Les étiquettes subjectives doivent être écrites dans les annotations de <auteur>-données-analyse.json, chaque entrée contenant :

dimension,label,article_ids,evidence,rule,confidence

Ainsi, les conclusions du rapport sur les thèmes, la position, les lecteurs et les phrases marquantes peuvent être retracées jusqu'aux articles.

4. Distiller la Méthodologie

Le rapport principal utilise references/report-template.md. Les sections de données citent les indicateurs et les IDs d'articles de <auteur>-données-analyse.json, sans recréer un deuxième ensemble de chiffres. Les sections de méthodologie sont responsables de l'interprétation des faits de données, comprenant au minimum :

La "description de l'échantillon" du rapport doit inclure dataset_sha256 pour la vérification de cohérence.

1. Positionnement de l'auteur et persona de contenu
2. Portrait du lecteur et bénéfices du contenu
3. Carte des actifs de contenu
4. Système de sélection des sujets
5. Cadre d'analyse
6. Critères de jugement
7. Modèles d'expression
8. Bibliothèque d'études de cas
9. Style de phrases marquantes
10. Lacunes de contenu et opportunités de sujets
11. SOP d'écriture réutilisable
12. Risques et limites
13. Liste des échantillons

Chaque conclusion clé doit si possible citer 2 à 5 titres d'articles, courts extraits ou études de cas. Les extraits originaux doivent être nécessaires et concis. Les modèles abstraits doivent être marqués "modèle abstrait", les exemples structurés doivent être marqués "pas un texte original de l'auteur".

5. Générer un Framework de Copywriting Indépendant

Utiliser references/copywriting-framework-template.md pour générer <auteur>-framework-copywriting.md. Le modèle ne définit que la structure, sans pré-remplir de phrases dans le style de l'auteur. Toutes les formules doivent être induites à partir des preuves de l'échantillon, y compris :

• Échafaudage de sélection de sujets
• 8 à 15 formules de titres
• Plusieurs modèles d'ouverture
• Au moins 3 structures de corps
• Structures de phrases de paragraphe et phrases de transition
• Générateur de phrases de style
• CTA de fin
• 1 à 2 exemples structurés avec changement de sujet, de cas et de formulation
• Liste de vérification avant publication et limites interdites

N'apprendre que la structure, ne pas reproduire l'expression unique de l'auteur, ne pas usurper l'identité de l'auteur.

6. Générer Automatiquement le HTML

Le tableau de bord HTML est un livrable standard de ce skill, pas un contenu de discussion optionnel. Lors de la génération, lire references/interactive-dashboard-template.md et utiliser directement le script scripts/generate_dashboard.py intégré à ce skill, ne pas utiliser un autre modèle BI générique.

Exécuter par défaut :

python3 scripts/generate_dashboard.py \
  --data "<output_dir>/<auteur>-données-analyse.json" \
  --output "<output_dir>/<auteur>-tableau-de-bord-méthodologique.html"

Le HTML et le Markdown doivent partager les statistiques déterministes de <auteur>-données-analyse.json. Les résumés méthodologiques générés par le modèle peuvent être écrits en tant que données supplémentaires dans annotations, mais ne doivent pas remplacer les champs calculés par le script.

Le tableau de bord doit conserver la structure fixe suivante :

1. Vue d'ensemble
2. Positionnement et valeur
3. Carte du contenu
4. Méthode de sélection des sujets
5. Écriture des articles
6. Opinions et preuves
7. Style de langue
8. À apprendre
9. Croissance opérationnelle
10. Apprentissage et transfert

Tous les chapitres sont du point de vue de l'apprenant, en se concentrant sur "ce que je dois apprendre, comment je dois apprendre", sans revenir à l'auto-vérification de l'auteur, à la notation des articles ou à l'analyse des performances de la plateforme. Le pied de page ne doit contenir qu'une brève mention de la source et une clause de non-responsabilité, sans chapitre "Données et limites" séparé.

Après la génération, vérifier la console, les principales interactions et la lisibilité visuelle dans un navigateur.

Ne sauter que si l'utilisateur demande explicitement de ne pas générer de HTML, c'est-à-dire generate_html=false.

7. Synchronisation Automatique avec Lark

Vérifier d'abord les limites de la source :

• Échantillon entièrement provenant d'URLs publiques ou d'archives publiques d'articles : synchronisation par défaut.
• Échantillon provenant d'entretiens locaux, de documents internes, de documents Lark privés, ou si un scan de sensibilité est déclenché : suspendre le téléchargement automatique et demander la confirmation de l'utilisateur.

Une fois la synchronisation confirmée, charger lark-doc :

1. Terminer d'abord le Markdown local.
2. Si <auteur>-synchronisation-lark.json contient déjà un doc_token accessible, mettre à jour ce document ; sinon créer un nouveau document.
3. Écrire et vérifier la lecture conformément aux spécifications de l'interface du skill lark-doc actuel.
4. Écrire doc_token, l'URL, le titre, l'empreinte du contenu et l'heure de mise à jour dans <auteur>-synchronisation-lark.json.
5. Après avoir vérifié que les chapitres clés sont présents, retourner l'URL.

Un échec de synchronisation avec Lark ne doit pas affecter l'état d'achèvement des fichiers locaux.

Ne sauter que si l'utilisateur demande explicitement de ne pas synchroniser Lark, c'est-à-dire sync_lark=false.

Seuils de Qualité

• <auteur>-données-analyse.json et <auteur>-caractéristiques-articles.csv doivent être générés par le script.

• Les conclusions sont basées sur le texte et divulguent les limites de l'échantillon.

• Distinguer clairement les statistiques observables des inférences subjectives.

• L'analyse des données doit couvrir autant que possible toutes les dimensions calculables, et signaler explicitement les champs indisponibles.

• Chaque statistique importante doit expliquer la définition, le dénominateur, les règles de classification ou la méthode de calcul.

• Chaque module de données doit être connecté à des articles représentatifs et à des inspirations méthodologiques.

• Chaque module principal doit contenir des preuves et des actions réutilisables.

• En cas d'absence d'études de cas, écrire explicitement "pas de bibliothèque de cas stable".

• Ne pas inférer les intentions de l'auteur qui ne peuvent pas être étayées par l'échantillon.

• Tous les chemins de sortie locaux doivent se trouver dans output_dir.

• HTML et Lark sont terminés par défaut ; si l'utilisateur les désactive explicitement, enregistrer la raison du saut.

• La navigation HTML doit comporter dix chapitres fixes, et le pied de page doit contenir une mention de la source et une clause de non-responsabilité.

• Le HTML ne doit pas comporter de chapitre "Données et limites" séparé, ni de modules d'évaluation orientés auteur tels que "auto-vérification, notation, réussite/échec".

• Exécution finale :

  python3 scripts/validate_outputs.py "<output_dir>"
  

Références

• references/report-template.md : lu lors de la génération du rapport principal.
• references/data-analysis-framework.md : lu lors de l'analyse détaillée des données.
• references/copywriting-framework-template.md : lu lors de la génération du framework de copywriting indépendant.
• references/interactive-dashboard-template.md : lu par défaut lors de la génération du HTML.
• references/analysis-data.schema.json : structure de données d'analyse partagée.
• scripts/analyze_corpus.py : analyse le corpus et génère les données de caractéristiques déterministes.
• scripts/generate_dashboard.py : génère un HTML hors ligne à partir de la source de données partagée.
• scripts/validate_outputs.py : vérifie la cohérence des données, du rapport, du HTML et des métadonnées de synchronisation.