---
name: seo-eeat
description: Pipeline de production SEO content (Lumenia + EEAT 2025). Détecte automatiquement les fichiers Lumenia.io (`premium-*.txt`) dans un dossier, scrape les URLs concurrentes via Firecrawl, et exécute un flow 6 phases (déconstruction SERP → analyse Lumenia → brief → jugement EEAT 2025 → architecture Hx → rédaction Markdown) avec checkpoints révisables. Sortie écrite en fichiers à côté des inputs (page finale, sidecar JSON meta + coverage, trace audit), dans la langue du brief. À déclencher dès que l'utilisateur veut produire / rédiger / générer une page SEO orientée EEAT, traiter un brief Lumenia.io, optimiser pour Google E-E-A-T / Helpful Content, ou battre une SERP concurrente sur une query donnée. Utiliser ce skill même si l'utilisateur ne le nomme pas explicitement, dès qu'on voit un brief Lumenia ou une demande de page SEO long-form orientée autorité.
---

# seo-eeat

Pipeline qui transforme un brief Lumenia.io + 7 URLs SERP en page SEO long-form publiable, en passant par un flow 6 phases avec checkpoints utilisateur entre les étapes coûteuses. La page produite vise à battre les concurrents en profondeur sémantique tout en respectant les guidelines Google E-E-A-T 2025 (Helpful Content, first-hand signals, transparence).

**Pourquoi un flow 6 phases avec checkpoints** : la rédaction d'une page SEO peut tourner à 3000-5000 mots. Si la Phase 5 (architecture Hx) tape à côté du brief, on jette plusieurs milliers de mots. Les checkpoints intermédiaires permettent de pivoter avant que le coût (en tokens ET en temps utilisateur) ne soit irrécupérable.

**Pourquoi écrire les outputs dans des fichiers** : la Phase 6 seule dépasse souvent la limite de réponse chat. Les sidecars (meta JSON + workflow audit) servent à itérer plus tard sans rejouer le pipeline complet.

## Inputs requis

| Input | Forme | Obligatoire |
|---|---|---|
| Dossier contenant les fichiers Lumenia | `<dir>/premium-XXXXXXXX.txt` + `<dir>/premium-XXXXXXXX-brief.txt` | ✅ |
| 7 URLs SERP concurrentes (top-ranking sur la query) | array string | ✅ |

**Auto-détection** : `find <dir> -maxdepth 1 -name 'premium-*.txt'` retourne 2 fichiers. Celui qui se termine en `-brief.txt` est le brief, l'autre est le guide top-terms.

Si un input requis manque ou est ambigu, afficher : `⚠️ MISSING INPUT: <description précise>`. Ne jamais inventer un fichier absent ou compléter par hallucination — il vaut mieux bloquer et demander.

## Flow général

| Phase | Action | Checkpoint |
|---|---|---|
| 0. Setup | Parser le guide Lumenia + le brief | ⏸ Récap inputs → GO |
| 1. Déconstruction | Firecrawl batch sur les 7 URLs + tableau comparatif | ⏸ Valider la déconstruction |
| 2. Analyse Lumenia | Top terms / n-grams / entities priorisés + grammage cible | ⏸ Valider le grammage |
| 3. Brief | Intent, objectifs, topics, FAQ, ton, value prop | pas de checkpoint |
| 4. Jugement EEAT | Auto-critique selon `references/eeat-rubric-2025.md`, score /20 | ⏸ Valider le jugement |
| 5. Architecture Hx | Structure H1 → H4 complète + FAQ | ⏸ Valider l'archi |
| 6. Rédaction | Page Markdown finale dans la langue du brief | écrit dans un fichier |

Annoncer le titre de chaque phase avant son output. Chain-of-thought explicite — l'utilisateur doit pouvoir lire la progression sans deviner où on en est.

## Phase 0 — Setup & parsing

1. Vérifier que le dossier d'inputs existe et contient exactement 2 fichiers `premium-*.txt`.
2. Parser le guide Lumenia selon `references/lumenia-format.md`. Extraire : `query`, `language`, `top_terms` (50), `two_grams` (20), `three_grams` (20), `named_entities` (20).
3. Parser le brief Lumenia. Extraire : `intent`, `objectives`, `key_subjects`, `questions`, `tone`, `style`, `value_proposition`.
4. Vérifier que la liste des 7 URLs est fournie. Si seulement N < 7, demander si on continue avec N ou si l'utilisateur en ajoute.
5. Présenter un récap court :
   ```
   Query : <query>
   Language : <language>     ← cette langue dicte la langue de sortie Phase 6
   Top terms : 50 chargés (top 5 : …)
   Named entities : 20 chargées (5 premières : …)
   Brief : intent=<intent>, <N> topics, <N> questions FAQ
   URLs à scraper : <N>/7
   ```
6. ⏸ **Checkpoint 0** : attendre `GO` ou modifications avant Phase 1.

## Phase 1 — Déconstruction concurrentielle

1. Pour chacune des 7 URLs, appeler le MCP **Firecrawl** en mode `markdown` (la version self-hosted est dans l'env utilisateur — utiliser l'outil natif disponible). Si une URL échoue, log le fail et continuer. Si ≥ 3 échecs sur 7, stopper et demander des URLs de remplacement.
2. Pour chaque page scrapée, extraire et tabuler selon le template de `references/phase-templates.md` (section "Phase 1 — Competitors table") :
   - `URL`, `meta_title`, `meta_description`, `grammage_réel` (compter les mots du body), `structure_Hx` (H1 → H4 récupérés depuis le markdown), `angle_éditorial` (résumé 1 phrase), `EEAT_forces`, `EEAT_faiblesses`.
3. Produire une synthèse comparative (200 mots max) couvrant :
   - Patterns récurrents dans les structures Hx
   - Topics sur-couverts vs sous-couverts par la concurrence
   - Gaps d'opportunité (angles non exploités)
   - **`MAX(grammage_concurrents)`** : valeur chiffrée explicite.
4. ⏸ **Checkpoint 1** : présenter le tableau + la synthèse + `MAX(grammage)`. Attendre `GO`.

## Phase 2 — Analyse Lumenia & grammage cible

1. Classer les top terms par priorité d'intégration. Heuristique : termes courts et fréquents au début du fichier > termes longs en fin. Garder les 50 mais signaler le top 20.
2. Lister les 20 prioritaires pour chacun des 2-grams et 3-grams.
3. Lister les 20 named entities — toutes considérées comme **obligatoires** (autorité E-E-A-T : les citer dans la page renforce la pertinence sémantique).
4. Calculer : `grammage_final = MAX(grammage_concurrents) + 500 à 1000 mots`. Afficher en clair :
   ```
   🎯 Grammage final visé : XXXX mots (MAX concurrent = YYYY + ZZZ)
   ```
5. ⏸ **Checkpoint 2** : attendre `GO` sur le grammage cible. L'utilisateur peut demander un overshoot plus agressif (ex: + 2000).

## Phase 3 — Analyse brief

Lecture déterministe du brief, pas de jugement. Restituer en 4 blocs :
- **Intent** : informational / transactional / etc.
- **Objectifs** : liste à puces
- **Topics & questions** : key_subjects → seront H2/H3 ; questions → seront H3 dans la section FAQ
- **Ton & style** : à reproduire FIDÈLEMENT en Phase 6
- **Value proposition** : à matérialiser dans intro et conclusion

Pas de checkpoint — la Phase 4 enchaîne directement.

## Phase 4 — Jugement EEAT 2025

Évaluer le plan d'attaque (concurrents + Lumenia + brief) selon la grille de `references/eeat-rubric-2025.md`. Remplir le tableau :

| Critère EEAT 2025 | Score /5 | Justification | Action corrective |
|---|---|---|---|
| Experience (first-hand signals) | | | |
| Expertise (vocabulaire, entities) | | | |
| Authoritativeness (sources, data) | | | |
| Trustworthiness (transparence) | | | |
| **Helpful Content** (people-first, AI disclosure si pertinent) | | | |

**Seuil** : score total minimum **16/20 sur les 4 premiers critères**. Le critère Helpful Content est qualitatif (pass/fail) et ne compte pas dans les 20 — mais un fail bloque autant qu'un score insuffisant.

**Si < 16/20 OU fail Helpful Content** : itérer le plan (renforcer les zones faibles, ex: chercher plus d'entities citables, ajouter des marqueurs first-hand). Maximum **2 itérations**. Au-delà, escalader à l'utilisateur : relaxer le seuil ou repartir d'un autre angle.

⏸ **Checkpoint 4** : présenter le jugement final + actions correctives appliquées. Attendre `GO` avant Phase 5.

## Phase 5 — Architecture Hx

Construire la structure complète selon le template de `references/phase-templates.md` (section "Phase 5 — Hx architecture") :

- **H1** : titre principal incluant le keyword + un angle différenciant identifié en Phase 1.
- **H2** : un par topic du brief, plus une section **FAQ** finale, plus une **Conclusion**.
- **H3 sous chaque H2** : sous-sections détaillant le H2. Sous la FAQ, chaque question du brief = un H3.
- **H4** : uniquement si le détail le justifie. Ne pas multiplier pour la profondeur.

**Contraintes** :
- Couvrir TOUS les topics et toutes les questions du brief.
- Refléter les 3-grams Lumenia dans les titres Hx quand c'est naturel (jamais forcé).
- Battre la **profondeur structurelle** des concurrents (plus de couverture, pas plus de niveaux).
- Ordre logique : définition → processus → matériaux / méthodes → technologies → business → éthique / durabilité → FAQ → conclusion.

⏸ **Checkpoint 5** : présenter l'arborescence complète. Attendre `GO` avant la rédaction longue.

## Phase 6 — Rédaction finale

Rédiger le contenu Markdown complet **dans la langue du brief** (`brief.language` parsé en Phase 0), en respectant le contrat d'output défini dans `references/phase-templates.md` (section "Phase 6 — Output contract").

**Contraintes rédactionnelles** :
- **Grammage** : `grammage_final ± 5%`. Compter en fin de rédaction et ajuster si hors-bande.
- **Ton et style** : strictement ceux du brief. Le brief est l'ancre, pas le prompt.
- **Densité sémantique** : intégrer naturellement les top terms / 2-grams / 3-grams. Pas de keyword stuffing — si une formule sonne forcée, reformuler.
- **Named entities** : citer toutes les entities pertinentes (autorité). Si une entity n'est pas pertinente au sujet, l'omettre plutôt que la forcer.
- **EEAT inline** : insérer des marqueurs d'expérience ("In practice…", "Industry data shows…", "Manufacturers typically…"). Citer des sources / standards / études quand mentionnés dans le brief ou la déconstruction concurrents. Pour toute donnée chiffrée sans source identifiée, utiliser `[SOURCE TO ADD]` — l'utilisateur complétera manuellement. **Ne jamais inventer un chiffre ou une citation.**
- **Lisibilité** : phrases courtes, paragraphes 3-5 lignes max, listes à puces, tableaux comparatifs où pertinent. Pas de phrase de remplissage.

**Outputs à écrire** (chemins relatifs au dossier d'inputs) :

1. `<query-slug>.md` — la page SEO complète, prête CMS. `<query-slug>` est dérivé de `brief.query` (ex: `jewellery manufacturing` → `jewellery-manufacturing`). Si le fichier existe déjà, suffixer `-v2`, `-v3`, etc.
2. `<query-slug>.meta.json` — `{ meta_title, meta_description, slug, word_count, lumenia_coverage }`. Schéma exact dans `references/phase-templates.md`.
3. `<query-slug>.workflow.md` — trace lisible des Phases 1 à 5 (tableau competitors, analyse Lumenia, analyse brief, jugement EEAT, archi Hx). Sert d'audit et permet d'itérer plus tard sans rejouer le pipeline.

Annoncer à l'utilisateur les 3 chemins écrits + le word count final + un résumé une ligne de la `lumenia_coverage` (`% top terms intégrés, % entities citées`).

## Garde-fous

- **`⚠️ MISSING INPUT: <champ>`** explicite quand un input requis est absent ou ambigu. Jamais d'invention.
- **Aucun chiffre ni citation inventés.** Toute donnée chiffrée non sourcée → `[SOURCE TO ADD]`.
- **Named entities = whitelist.** Citer uniquement celles présentes dans le guide Lumenia, plus les sources / études explicitement mentionnées dans le brief ou les scrapes concurrents.
- **Firecrawl partial fail** : si 1-2 URLs échouent sur 7, continuer avec les autres et le signaler. Si ≥ 3 échouent, demander des remplaçantes.
- **Loop EEAT plafonné à 2 itérations.** Au-delà → escalader à l'utilisateur.
- **Pas de merge de Phase** : ne pas sauter de checkpoint pour gagner du temps. Le coût d'un Phase 6 jeté est largement supérieur au coût d'un checkpoint.

## Hors-scope (intentionnellement)

- ❌ Génération du brief Lumenia (Lumenia.io le produit déjà).
- ❌ Support YourTextGuru ou autres providers. Lumenia uniquement.
- ❌ Scripts utilitaires (`scripts/`) — le parsing Lumenia est trivial et Firecrawl est appelé via MCP.
- ❌ Publication CMS automatique.
- ❌ Multi-langue : la sortie suit `brief.language`, point.
- ❌ Re-rédaction itérative post-Phase 6 (l'utilisateur édite à la main).
- ❌ Fallback "dumps Markdown locaux au lieu d'URLs" — le MVP exige Firecrawl. Support local éventuel plus tard.

## Pièges à signaler à l'utilisateur

- **`brief.language` ≠ langue de la query.** Une query peut être en EN même si l'utilisateur écrit le brief en FR. Le skill suit toujours `brief.language` pour la rédaction. Si l'utilisateur veut forcer une autre langue, le dire explicitement avant Phase 6.
- **Le grammage cible peut paraître démesuré.** Un MAX concurrent à 4500 mots donne un cible à 5000-5500. Si le sujet ne le justifie pas, l'utilisateur peut overrider en Checkpoint 2.
- **Named entities Lumenia peuvent contenir du bruit.** Ex: dans la fixture jewellery-manufacturing, "Japan" et "China" sont des entities — pertinentes seulement pour les sections "fabrication géographique". Ne pas les citer en intro où elles n'apportent rien.
- **Knip / .vercelignore** : les outputs (`.md`, `.meta.json`, `.workflow.md`) écrits dans `tmp/` ne doivent pas finir déployés. Si le projet cible a un `.vercelignore`, vérifier que le dossier d'inputs y est exclu (cf. règles Next.js du repo).

## Fixture de test

`tmp/seo/jewellery-manufacturing/` contient un brief Lumenia complet (query = "jewellery manufacturing"). Pour un dry-run du skill, l'utilisateur doit fournir 7 URLs SERP réelles sur cette query. Output attendu : `jewellery-manufacturing.md` + sidecars dans le même dossier.