# SEO Os

> seo-os — Orchestrateur du système SEO unifié

- Skill: `lcrvl2/seo-os` (Agent Skill, multi-file: 14 files)
- Install (CLI): `npx skillmds@latest add lcrvl2/seo-os`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lcrvl2/seo-os/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: lcrvl2 (https://skillmd.com/u/lcrvl2)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lcrvl2/seo-os

---


# seo-os — Orchestrateur du système SEO unifié

`seo-os` est le **point d'entrée** du système SEO. Il route les commandes vers les branches existantes (audit, contenu, refresh, monitoring), en résolvant à chaque fois le **client** concerné depuis sa configuration.

## Rôle exact (à ne pas confondre)

- **Aujourd'hui (local)** : `seo-os` est la **structure de build + l'outil de démo**. Lucas lance les commandes à la main pour construire, valider et démontrer chaque branche. **Ce n'est PAS le produit final.**
- **Cible (cloud)** : le produit final est autonome (Trigger.dev planifie les branches par client, le client reçoit un dashboard). `seo-os` ne fait que router ; il n'embarque aucune logique métier SEO — celle-ci vit dans les branches.

## Principe multi-client

Chaque client a un dossier `clients/<slug>/` :
- `client.json` — manifest (domaine, gsc_property, langue, business_type, competitors, context_dir, cms, api_keys en réfs d'env, seuils de fraîcheur). **Source de vérité** ; aucune branche ne redemande ces infos.
- `context/` — 11 fichiers markdown (ligne éditoriale + positionnement) qui calent le contenu sur la voix du client.
- `data/` — **réserve de données mutualisée** (`crawl/`, `gsc/`, `dataforseo/`), datée. Toutes les branches lisent dedans. Une branche ne (re)crawle/(re)requête que si la donnée est périmée (seuils dans `client.json`).
- `outputs/` — sorties **versionnées par date** par branche → reporting comparable d'un run à l'autre.
- `state/` — planning local des tâches auto.

Le slug est la clé primaire. Toute branche reçoit `--client <slug>`, lit `client.json` via `scripts/resolve_client.py`, et résout ses chemins.

## Commandes

| Commande | Action | Skill/branche invoqué |
|---|---|---|
| `/seo client new <slug>` | Crée la structure de base d'un client | `scripts/new_client.py` |
| `/seo client list` | Liste les clients existants | `scripts/resolve_client.py` |
| `/seo audit <slug>` | Audit SEO complet (technique + GEO + recos mesurables) | `technical-seo-audit` |
| `/seo audit-page <slug> <url>` | Audit d'une page précise (Phase 2) | `page-audit` |
| `/seo strategy <slug>` | Stratégie de contenu : keywords client + **local** → plan de pages à créer/améliorer | `seo-strategy` |
| `/seo keywords <slug>` | Gap concurrentiel (sur quoi les concurrents rankent que le client ne couvre pas) | `keyword-gap` + Phase 3 audit |
| `/seo content <slug> "<keyword>"` | Brief → rédaction → QA (sans kanban) | `Content-brief-creator` → `Article-creator` → `Content-quality-evaluator` |
| `/seo refresh <slug>` | Détection contenu à rafraîchir + brief de MAJ | `Content-refresh` |
| `/seo monitor <slug>` | Monitoring léger + alerte (déclins vs run précédent) | `scripts/monitor.py` (Phase 2) |
| `/seo publish <slug> <article>` | Publication WordPress ou livraison fichier (Phase 4) | `publish-wordpress` |
| `/seo report <slug>` | Recompile le dernier audit / compare au précédent | `technical-seo-audit` + `compare_audits.py` (Phase 5) |

`references/block-map.md` détaille, pour chaque commande, le skill invoqué, ses inputs (depuis `client.json` + la réserve) et où il écrit ses outputs.

## Comment router une commande

1. **Résoudre le client** : lire `clients/<slug>/client.json` via `scripts/resolve_client.py` (expose les chemins absolus + helpers de réserve `is_fresh`/`latest_data`/`data_dir`/`output_dir`).
   ```bash
   python seo/seo-os/scripts/resolve_client.py <slug> --json
   ```
2. **Vérifier la réserve** : pour les branches qui consomment crawl/gsc/dataforseo, tester la fraîcheur. Si périmé, la branche régénère et dépose dans `data/<kind>/<date>/` ; sinon elle lit le dernier dossier daté.
3. **Invoquer la branche** en lui passant le slug et les chemins résolus. La branche écrit ses sorties dans `outputs/<branche>/<date>/`.
4. **Ne jamais hardcoder de domaine/clé** : tout vient de `client.json`. Les clés API sont celles du **client** (réfs d'env), appels REST directs.

## Création d'un client

```bash
python seo/seo-os/scripts/new_client.py <slug> --name "Nom Client" --domain example.com --lang fr --business-type local --cms none
```
Crée le dossier, le manifest, les 11 fichiers de contexte (à remplir), la réserve vide, et enregistre le client dans `registry/clients.json`. Compléter ensuite `client.json` (competitors, cms, api_keys) à la main ou via `populate-context.py` pour le contexte.

## Fichiers

- `scripts/new_client.py` — crée la structure de base d'un client.
- `scripts/resolve_client.py` — résout un client (chemins + réserve). Importé par les branches.
- `registry/clients.json` — index de tous les clients.
- `references/block-map.md` — mapping commande → branche → inputs/outputs.
- `templates/context/` — gabarits des 11 fichiers de contexte (copiés à la création d'un client).

## Démo "système global"

Le but de la démo de vente est de montrer **un output par branche** (audit, brief, article, refresh, alerte monitoring) sur un client test — pas une seule branche polie. Les branches sur données publiques (technique, page, contenu, GEO, SERP) tournent sur un site test ; les branches qui dépendent du GSC/GA4 (impact trafic, monitoring, refresh) utilisent des **inputs simulés réalistes** (générateur dédié). On démontre que la machine complète produit un livrable par branche.