CommunityImagegithub.com

umairmsm/wp-content

Étape 4 d’un site WordPress avec du contenu réel : photos et textes approuvés par le propriétaire, audits des revendications, mots interdits, preuves factices, pages légales, pipeline photo (dédoublonnage, réel uniquement, suppression EXIF, WebP, texte alternatif, registre IA) et suivi des modifications.

Qu'est-ce que wp-content ?

Ce skill automatise l’étape 4 d’une construction WordPress (« wp-site-kit ») : la mise en place du contenu réel (textes et photos). Il garantit que chaque page publique contient uniquement des textes approuvés par le propriétaire et des photos réelles, légales et optimisées. Il orchestre la rédaction en deux temps : d’abord une collecte des faits (prix, horaires…) depuis le BRIEF ou des fichiers de données, puis une rédaction assistée par IA mais marquée comme « brouillon » jusqu’à validation. Un audit des revendications supprime les termes interdits et exige des preuves pour tout chiffre ou récompense. Les photos sont passées par un pipeline strict (dédoublonnage par hash perceptuel, validation humaine, suppression des métadonnées EXIF, conversion WebP, texte alternatif, et enregistrement dans un registre IA si générées). Les modifications du contenu en ligne transitent par des fichiers JSON et un script shell – jamais d’édition manuelle. Le skill supporte les agents Claude Code, Cursor ou Codex, et repose sur un ensemble de scripts Python, fichiers de manifeste et vérifications automatiques. Il est conçu pour des projets WordPress professionnels où la vérité du contenu, la légalité et la traçabilité sont critiques.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/umairmsm/wp-site-kit/tree/HEAD/skills/wp-content

Installed? Explore more Image skills: steipete/songsee, affaan-m/frontend-design, mattpocock/improve-codebase-architecture · View all 6 →

Demander à votre IA préférée

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

Documentation

Étape 4 : Contenu

Objectif : chaque page publique porte un texte approuvé par le propriétaire et des photos réelles, légales et légères. Rien sur le site ne prétend ce que l’entreprise ne peut pas prouver.

Étapes de rédaction

  1. Inventaire : lister chaque page et élément avec ce dont il a besoin (texte, faits, photos) dans docs/data/content-plan.md.
  2. Faits d’abord :
    • Les faits (prix, prestations incluses, horaires, politiques, consignes de sécurité) viennent du propriétaire via docs/BRIEF.md ou un fichier de données dans docs/data/<type>/.
    • Manquant → PENDING-<qui> dans une liste de drapeaux (docs/data/<type>/_SUMMARY.md). Ne jamais inventer un fait.
  3. Brouillon : L’IA peut rédiger, mais le brouillon est marqué comme tel (un champ <préfixe>_copy_status dans les métadonnées, ou une liste dans le plan de contenu) jusqu’à l’approbation du propriétaire.
  4. Audit des revendications avant toute mise en ligne (references/copy-and-claims.md) :
    • chaque affirmation est vérifiée par rapport à sa source ;
    • les mots interdits sont supprimés ;
    • les chiffres, récompenses et avis nécessitent une preuve. Si l’agent claims-auditor est installé, exécutez-le.
  5. Relecture par le propriétaire sur le staging, par lots. Envoyez des messages courts, chacun avec une question pouvant être répondue par oui ou non. Les longs questionnaires restent sans réponse pendant des semaines.
  6. Pages légales : avis de confidentialité (avec la durée de conservation des demandes de renseignements), conditions générales ou politique de réservation (uniquement le texte du propriétaire), avis relatif aux cookies si un suivi nécessite un consentement, et un imprint là où la loi l’exige (Allemagne, Autriche).
  7. Les modifications du contenu en ligne passent par docs/data/content-changes/*.json et scripts/apply-content-change.sh (étape wp-ship). Jamais d’éditions manuelles en direct.

Étapes photos (détails : references/photo-library.md)

  1. Conservez les originaux du propriétaire dans un dossier sauvegardé hors du dépôt git.
  2. python3 -I scripts/photos/photos.py review <dossier> → un CSV de révision : doublons (hash perceptuel), photos déjà dans la bibliothèque, petites photos.
  3. Examinez chaque candidat vous-même, ou faites-le faire par un modèle moins cher à l’aide du CSV. Décidez IMPORT, HOLD-people (pas de consentement), HOLD-licence (stock ou inconnue) ou SKIP.
  4. Écrivez le manifeste (groupe,fichier,clé,alt). Lancez l’import avec --dry-run, puis pour de vrai. Collez les lignes imprimées dans photo-library.php.
  5. Les modèles utilisent <préfixe>_photo( 'clé' ). Utilisez au maximum deux photos par section, et seule l’image LCP se charge en eager.

Contrôle (cocher dans SITE_STATUS.md)

  • Chaque page publique a un texte approuvé par le propriétaire (dates)
  • Photos réelles importées avec texte alternatif ; images IA journalisées dans AI_IMAGES.md
  • Avis de confidentialité, conditions générales et politiques publiés (texte du propriétaire)
  • Aucun fait PENDING- et aucun texte de substitution sur les pages publiques

Jamais

  • Faux avis ou nombres d’avis importés, étoiles, badges « vu dans », « 12 000+ clients satisfaits » sans preuve. (Nous avons supprimé un nombre inventé de ce type, et des nombres d’avis inventés sur un ancien site.)
  • Images IA d’une pièce, d’un lieu, d’un produit ou d’une personne nommée, ou quoi que ce soit disant « voici ce que vous obtenez ».
  • Photos de personnes sans leur consentement. Photos libres de droits sans licence que vous pouvez montrer.
  • Un prix ou une phrase de politique tapé(e) dans un modèle ou une traduction.

Individual skills in this repo

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

umairmsm/wp-build

Stage 3 of a wp-site-kit WordPress build - local DDEV site, the core must-use plugin (modules), the presentation-only child theme with skins, the content model (custom post types, meta, WP_Query, render functions), and the enquiry pipeline that saves leads before forwarding. Use when building or changing features, templates, content types, forms or plugin modules on a wp-site-kit site.

umairmsm/wp-design

Stage 2 of a wp-site-kit WordPress build - design direction, a static HTML/CSS prototype with design tokens, owner sign-off with screenshots, self-hosted fonts, and porting the approved look into a swappable WordPress skin. Use for "design the site", "new look", "redesign", "change colours or fonts", "make a new skin", "port the prototype to WordPress".

umairmsm/wp-kickoff

Stage 1 of a wp-site-kit WordPress build. Use when starting a new WordPress website or taking over or rebuilding an existing one - discovery brief, stack decision, creating the project with bin/wp-site-new, locked decisions, private repo and credentials inventory. Triggers - "new WordPress site", "start a client website", "rebuild this site", "take over this WordPress site".

umairmsm/wp-operate

Stage 8 of a wp-site-kit WordPress build and everything after launch - backups with an off-machine copy, restore drills, the disaster-recovery runbook, credentials inventory, update policy, alerts, and working from more than one machine (bridge file, workstation doctor, encrypted state bundle, rescuing unpushed work). Use for "backup", "restore", "move to a new machine/server", "update plugins", "what if the server dies", "work from the cloud box", "set up a second machine".

umairmsm/wp-seo

Stage 5 of a wp-site-kit WordPress build - titles and descriptions, canonical URLs, one schema owner and JSON-LD, sitemaps, robots.txt and llms.txt, AI crawler access, redirects (301 vs 302), legacy URL maps, Search Console, and adding languages one pilot at a time with Polylang (hreflang, .po/.mo strings, native review). Use for "SEO", "schema", "redirect", "old URLs", "translate the site", "add French/Spanish", "hreflang", "canonical".

umairmsm/wp-ship

Stage 7 of a wp-site-kit WordPress build - staging behind Cloudflare Access, server hardening, safe deploys from a commit (scripts/deploy-safe.sh), database content changes, the launch audit, DNS cutover without breaking a running business, and the first week after launch. Use for "deploy", "set up staging", "go live", "launch", "cutover", "move DNS", "harden the server".

umairmsm/wp-site

Start here for any WordPress website built with wp-site-kit, from an empty folder to a live site. Use when someone says "build a WordPress site", "new website for a client", "where are we on the site", "what is next before launch", or asks to continue a site project. Finds the current stage from SITE_STATUS.md, applies the hard rules, and hands over to the right stage skill.

Skills associés